Annuaire
Problèmes de configuration rencontrés par les systèmes distribués
Introduction à Spring Cloud Config
Problèmes de configuration rencontrés par les systèmes distribués
Les microservices signifient que l'entreprise dans une application monolithique doit être divisée en services individuels. La granularité de chaque service est relativement petite, donc un grand nombre de services apparaîtra dans le système. Étant donné que chaque service nécessite les informations de configuration nécessaires pour fonctionner, une fonction de gestion de configuration centralisée et dynamique est essentielle. SpringCloud fournit ConfigServer pour résoudre ce problème. Chacun de nos microservices est livré avec un application.yml, qui est géré par des centaines de fichiers de configuration.
Introduction à Spring Cloud Config
SpringCloud Config fournit une prise en charge de configuration externe centralisée pour les microservices dans l'architecture de microservice Le serveur de configuration fournit une configuration externe centralisée pour tous les environnements de différentes applications de microservices.
SpringCloud Config est divisé en serveur et client.
Le serveur est également connu sous le nom de centre de configuration distribué. Il s'agit d'une application de microservice indépendante qui est utilisée pour se connecter au serveur de configuration et fournir des interfaces d'accès aux clients pour obtenir des informations de configuration et des informations de chiffrement / déchiffrement.
Le client gère les ressources d'application et le contenu de configuration lié à l'entreprise via un centre de configuration désigné, et obtient et charge les informations de configuration à partir du centre de configuration au démarrage.
Le serveur de configuration utilise git pour stocker les informations de configuration par défaut, ce qui est utile pour la gestion des versions de la configuration de l'environnement, et peut facilement gérer et accéder au contenu de la configuration via l'outil client git.
Usages
Gérez de manière centralisée les fichiers de configuration.
Différentes configurations pour différents environnements, mises à jour de configuration dynamiques, déploiement de sous-environnement tels que dev / test / prod / beta / release.
Ajustez dynamiquement la configuration pendant le fonctionnement. Il n'est plus nécessaire d'écrire des fichiers de configuration sur la machine sur laquelle chaque service est déployé et le service sera soumis au centre de configuration.
Tirez et configurez de manière unifiée vos propres informations.
Lorsque la configuration change, le service peut détecter la modification de configuration et appliquer la nouvelle configuration sans redémarrer.
Exposez les informations de configuration sous la forme d'une interface REST.
Architecture de configuration
springCloudConfig est divisé en un serveur et un client. Le serveur est responsable de la publication des fichiers de configuration stockés dans le local, git ou svn dans une interface de style REST. Le client peut obtenir la configuration à partir de l'interface REST côté serveur. Cependant, le client ne peut pas détecter activement le changement de configuration, de manière à obtenir activement la nouvelle configuration. Cela nécessite que chaque client déclenche sa propre interface / rafraîchissement via la méthode POST. Et le SpringCloudBus que nous avons mentionné ci-dessus a joué son rôle
SpringCloudBus connecte les nœuds d'un système distribué (un peu comme une file d'attente de messages) via un courtier de messages léger. Cela peut être utilisé pour diffuser des changements d'état (tels que des changements de configuration) ou d'autres instructions de gestion. SpringCloudBus fournit un point de terminaison / bus / actualisation accessible via la méthode post (le démarrage de printemps a de nombreux points de terminaison surveillés, tels que / health). Cette interface est généralement appelée par la fonction git hook (déclencheur d'écoute) pour informer chaque client SpringCloudConfig d'aller Le serveur met à jour la configuration .
Le serveur git extraira le fichier de configuration du git distant et le stockera dans la bibliothèque de fichiers git locale. Lorsque le git distant n'est pas disponible, il extraira les informations de configuration de la bibliothèque de fichiers git locale
Ce qui suit est un diagramme de flux de travail de configuration de nuage de printemps combiné avec le bus
La seconde est la relation de priorité lors de l'accès au fichier de configuration. Veuillez consulter la figure suivante (les données que j'ai essayées moi-même, accessibles directement depuis le serveur)
La priorité configurée est de haut en bas, la plus élevée
