Répertoire d'articles
(1) Le problème de la configuration locale
1.
Mise à jour dynamique de la configuration Dans les applications pratiques, il y aura des exigences pour la mise à jour dynamique de la configuration, comme la modification de l'adresse de connexion de service et de la configuration de limitation actuelle. En mode traditionnel, vous devez modifier manuellement le fichier de configuration et redémarrer l'application pour prendre effet. Cette méthode est trop inefficace et le redémarrage entraînera également l'indisponibilité temporaire du service.
2. Gestion centralisée de la configuration
Dans l'architecture des microservices, certains services de base déploieront des centaines de nœuds afin de garantir des performances élevées. Si un fichier de configuration est conservé dans chaque nœud, une fois qu'un certain attribut du fichier de configuration doit être modifié, au fur et à mesure que vous peut imaginer, la charge de travail est énorme.
3. Sécurité et autorité du contenu de
configuration Les fichiers de configuration sont soumis à la base de code avec le code source, ce qui peut facilement provoquer une fuite de données des informations de configuration de l'environnement de production.
4. Gestion de la configuration
dans différents environnements de déploiement Comme mentionné précédemment, le mécanisme de profil est utilisé pour gérer les configurations dans différents environnements, cette méthode est lourde pour la maintenance quotidienne.
(2) Centre de configuration Nacos
(1) Introduction de base
Il existe de nombreuses solutions open source dans le centre de configuration, telles que ZooKeeper, Disconf, Apollo, Spring Cloud Config, QConf, Nacos, etc. De même, quel que soit le type de solution, sa fonction principale ne changera pas.
Nacos est le middleware open source d'Alibaba.Nous savons qu'il y a deux modules dans le diagramme d'architecture de Nacos, à savoir Config Service et Naming Service. Parmi eux, Config Service est le module de base utilisé par Nacos pour implémenter le centre de configuration.Il implémente des fonctions telles que CRUD, la gestion des versions, la gestion des gris, la gestion de la surveillance, la trajectoire push et l'agrégation des données pour la configuration. Nous nous concentrons principalement sur l'analyse approfondie du module Config Service dans Nacos pour réaliser la fonction du centre de configuration.
(2) Configurer l'extension de fichier YAML en fonction de l'ID de données
Lorsque Spring Cloud Alibaba Nacos Config charge la configuration depuis Nacos Config Server, elle correspond à l'ID de données. Dans l'implémentation de SpringCloud Nacos, la règle par défaut pour l'ID de données est
Par défaut, il ira au serveur Nacos pour charger l'ID de données dans
$(spring.application.name}.${
file-extension : properties}
Configuration de base pour le préfixe.
Par exemple, lorsque nous configurons des propriétés dans le fichier bootstrap.properties
spring.application.name = spring-cloud-nacos-config-sample
Lorsque le préfixe d'ID de données n'est pas spécifié via spring.cloud.nacos.configprefix,
les informations de configuration avec l'ID de données de spring-cloud-nacos-config-sample.properties dans le serveur de configuration Nacos seront lues par défaut .
Si la propriété spring.cloud.nacos.config.prefix = example est explicitement spécifiée, la configuration avec Data ID = example sera chargée.
spring.profile.active représente le support multi-environnement, qui est également applicable à Nacos
Dans les applications pratiques, si vous utilisez le format de configuration YAML, Nacos Config prend également en charge le format de configuration YAML.
Déclarez
spring.cloud.nacos.config.file-extension = yaml dans bootstrap.properties
(3) Commutation de configuration de différents environnements
Dans Spring Boot, la commutation de configuration dans différents environnements peut être réalisée en fonction de spring.profiles.active, qui est plus utilisé dans le travail réel. De nombreuses entreprises disposent d'environnements de développement, d'environnements de test, d'environnements de production, etc. Les services sont déployés dans différents environnements, et certaines configurations sont différentes, nous espérons donc pouvoir spécifier facilement l'environnement de déploiement d'application actuel via une propriété, et selon différents. l'environnement charge la configuration correspondante. Les étapes de configuration pour la prise en charge multi-environnement basée sur le projet Spring Boot sont les suivantes.
Lors du chargement de la configuration dans Nacos Config Server dans Spring Cloud Alibaba Nacos Config, non seulement l'ID de données est chargé
$(spring.application.name}.${
file-extension : properties}
Est la configuration de base du préfixe et charge également l'ID de données comme
$(spring.applicationname)}-${profile}.$(file-extension : properties}
La configuration de base de cette méthode offre un très bon support pour la commutation entre différents environnements.
Exemple: où oauth-center est le nom correspondant à spring.applicationname dans le fichier de configuration, dev correspond au profil et yaml correspond à l'extension de fichier
La méthode de configuration est la même que Spring Boot et les étapes d'implémentation spécifiques sont les suivantes.
Déclarez spring.profiles.active = prod dans bootstrap.properties. Il est à noter qu'il doit être déclaré dans bootstrap.properties.
Il n'y a aucune différence entre la commutation entre différents environnements basés sur Nacos Config et la commutation entre différents environnements de configuration locale. Si nous devons basculer vers l'environnement de test, il suffit de modifier spring.profiles.active = test. Cependant, la configuration de cette propriété est codée en dur dans le fichier bootstrap.properties et sa modification est très difficile. La pratique habituelle consiste à spécifier l'environnement via le paramètre -Dspring.profiles.active = $ {profile} pour atteindre l'objectif d'une commutation flexible.
(Trois) Analyse du principe de réalisation de Nacos Config
（1） SDK 和 OpenAPI
Adresse de référence du document:
https://nacos.io/zh-cn/docs/sdk.html
https://nacos.io/zh-cn/docs/open-api.html
【获取 配置】
public String getConfig (String dataId, String group, long timeoutMs) lève NacosException
/ nacos / v1 / cs / configs GET
【监听 配置】
public void addListener (String dataId, String group, Listener listener)
/ nacos / v1 / cs / configs / listener post
【删除 监听】
public void removeListener (String dataId, String group, Listener listener)
【发布 配置】
public boolean publishConfig (String dataId, String group, String content) lance NacosException;
@Since 1.4.1
public boolean publishConfig (String dataId, String group, String content, String type) lève NacosException;
/ nacos / v1 / cs / configs POST
【删除 配置】
public boolean removeConfig (String dataId, String group) lève NacosException
/ nacos / v1 / cs / configs SUPPRIMER
(2) CRUD configuré
Pour Nacos Config, il fournit en fait une fonction de gestion centralisée pour la configuration, puis fournit une interface d'accès CRUD externe afin que le système d'application puisse effectuer les opérations de base de configuration. En fait, ce scénario n'est pas compliqué. Pour le serveur, il ne s'agit que de savoir comment la configuration est stockée et si elle doit être conservée. Pour le client, il s'agit d'interroger les données correspondantes du serveur via l'interface, et puis revenez.
Il est à noter que le stockage des données du serveur Nacos utilise par défaut la base de données Derby et prend en charge la base de données MySQL. Si vous devez le modifier, personnalisez-le en fonction de la configuration de la base de données MySQL.
(3) Pull Or Push pour une surveillance dynamique
Lorsque la configuration sur le serveur de configuration Nacos change, l'application associée doit être consciente du changement de configuration, puis du changement d'application, ce qui oblige le client à surveiller la configuration qui l'intéresse. Alors, comment le client Nacos implémente-t-il les mises à jour en temps réel des changements de configuration?
D'une manière générale, l'interaction des données entre le client et le serveur ne se résume qu'à deux manières: Pull et Push.
1. Pull signifie que le client extrait activement les données du serveur.
2. Push signifie que le serveur pousse activement les données vers le client.
Il n'y a pas de différence entre ces deux méthodes, cela dépend simplement de la méthode la plus adaptée à la scène actuelle. Par exemple, ActiveMQ prend en charge les modes Push et Pull. Les utilisateurs peuvent choisir différents modes dans des scénarios spécifiques pour obtenir les messages des consommateurs.
Pour le mode Push, le serveur doit maintenir une longue connexion avec le client. Si le nombre de clients est important, le serveur doit consommer beaucoup de ressources mémoire pour enregistrer chaque connexion et afin de vérifier la validité de la connexion, un mécanisme de pulsation est également nécessaire pour maintenir l'état de chaque connexion.
En mode Pull, le client doit extraire périodiquement les données du serveur une fois. Puisqu'il y aura un certain intervalle de temps pour la tâche de chronométrage, la nature en temps réel des données ne peut pas être garantie. Et lorsque la configuration du serveur n'est pas mise à jour pendant une longue période, les tâches de chronométrage du client feront des Pulls invalides
Nacos utilise le mode Pull, mais ce n'est pas un simple Pull, mais un long mécanisme d'interrogation, qui combine les avantages de Push et Pull. Le client utilise une méthode d'interrogation longue pour lancer périodiquement une demande d'extraction afin de vérifier si les informations de configuration du serveur ont changé. En cas de modification, le client obtiendra la dernière configuration en fonction des données modifiées. L'interrogation dite longue signifie qu'après que le client a lancé une requête d'interrogation, s'il y a un changement de configuration côté serveur, elle reviendra directement.
Si après que le client a lancé une pull request, il s'avère que la configuration du serveur et la configuration du client sont cohérentes, alors le serveur "suspendra" d'abord la requête, c'est-à-dire que le serveur ne sera pas dans la période spécifiée de temps après l'obtention de la connexion. Renvoyer le résultat. Jusqu'à ce que la configuration change pendant cette période, le serveur renverra la demande initiale "Attente". Comme le montre la figure, une fois que le serveur Nacos a reçu la demande, il vérifiera d'abord si Si ce n'est pas le cas, configurez une tâche chronométrée, retardez l'exécution de 29,5 secondes et ajoutez la connexion d'interrogation longue du client actuel à la file d'attente allSubs. À ce stade, il existe deux façons de déclencher le retour du résultat de la connexion:
La première consiste à déclencher le mécanisme de vérification automatique après avoir attendu 29,5 s. A ce moment, peu importe si la configuration a changé, le résultat sera renvoyé au client. Et 29,5 s est la durée de cette longue connexion.
La seconde consiste à modifier la configuration via Nacos Dashboard ou API à tout moment dans les 29,5 secondes, ce qui déclenchera un mécanisme d'événement. La tâche qui écoute l'événement traversera la file d'attente allSubs et trouvera l'élément de configuration correspondant qui a changé. Dans le ClientLongPolling, les données modifiées sont renvoyées via la connexion dans la tâche et une opération "push" est terminée.
Cela garantit non seulement que le client est conscient des changements de configuration en temps réel, mais réduit également la pression sur le serveur. Parmi eux, le délai d'expiration de session de cette longue connexion est de 30 s par défaut.