L'un des principaux problèmes rencontrés dans le développement et l'exploitation ultérieure des microservices est la configuration compétente et précise de leurs instances. À mon avis, le nouveau cadre
microconfig.io peut aider. Il vous permet de résoudre avec élégance certaines des tâches de routine de configuration des applications.
Si vous avez beaucoup de microservices et que chacun d'entre eux est livré avec son propre fichier / fichier de paramètres, il est probable qu'il fasse une erreur dans l'un d'eux, qui sans une dextérité appropriée et un système de journalisation peut être très difficile à détecter. La tâche principale que le cadre se fixe est de minimiser les paramètres d'instance en double, réduisant ainsi la probabilité d'ajouter une erreur.
Regardons un exemple. Supposons qu'il existe une application simple avec un
fichier de configuration
yaml . Il peut s'agir de n'importe quel microservice dans n'importe quelle langue. Voyons comment le cadre peut être appliqué à ce service.
Mais d'abord, pour plus de commodité, nous allons créer un projet vide dans l'IDE Idea en y installant d'abord le plugin microconfig.io:
Nous configurons la configuration de lancement du plugin, vous pouvez utiliser la configuration par défaut, comme dans la capture d'écran ci-dessus.
Notre service s'appelle commande, puis dans un nouveau projet nous allons créer une structure similaire:
Dans le dossier avec le nom du service, nous mettons le fichier de configuration -
application.yaml . Tous les microservices sont lancés dans une sorte d'environnement, donc en plus de créer la configuration du service lui-même, il est nécessaire de décrire l'environnement lui-même: pour cela, créez le dossier
envs et ajoutez-y un fichier avec le nom de notre environnement de travail. Ainsi, le framework créera des fichiers de configuration pour les services dans l'environnement de développement, car ce paramètre est défini dans les paramètres du plugin.
La structure du fichier
dev.yaml sera assez simple:
mainorder: components: - order
Le framework fonctionne avec des configurations regroupées. Pour notre service, sélectionnez un nom pour le groupe de commande principal. Le framework recherche chacun de ces groupes d'applications dans le fichier d'environnement et crée pour chacun d'eux des configurations qu'il trouve dans les dossiers correspondants.
Dans le fichier des paramètres du service de
commande lui-même, nous n'indiquerons pour l'instant qu'un seul paramètre:
spring.application.name: order
Maintenant, exécutez le plugin et il générera pour nous la configuration souhaitée de notre service selon le chemin spécifié dans les propriétés:
Vous pouvez
vous passer de l'installation du plugin en téléchargeant simplement le kit de distribution du framework et en l'exécutant depuis la ligne de commande.
Cette solution peut être utilisée sur le serveur de génération.
Il convient de noter que le framework comprend parfaitement la syntaxe des
propriétés , c'est-à-dire les fichiers de propriétés ordinaires qui peuvent être utilisés ensemble dans les configurations
yaml .
Ajoutez un service de
paiement supplémentaire et compliquez le service existant en même temps.
Pour :
eureka: instance.preferIpAddress: true client: serviceUrl: defaultZone: http://192.89.89.111:6782/eureka/ server.port: 9999 spring.application.name: order db.url: 192.168.0.100
En
paiement :
eureka: instance.preferIpAddress: true client: serviceUrl: defaultZone: http://192.89.89.111:6782/eureka/ server.port: 9998 spring.application.name: payments db.url: 192.168.0.100
Le principal problème avec ces configurations est la présence d'une grande quantité de copier-coller dans les paramètres de service. Voyons comment le cadre aide à s'en débarrasser. Commençons par le plus évident - la présence de la configuration
eureka dans la description de chaque microservice. Créez un nouveau répertoire avec le fichier de paramètres et ajoutez-lui une nouvelle configuration:
Et dans chacun de nos projets, nous allons maintenant ajouter la ligne
#include eureka .
Le framework trouvera automatiquement la configuration eureka et la copiera dans les fichiers de configuration du service, tandis qu'une configuration eureka distincte ne sera pas créée, car nous ne la spécifierons pas dans le
fichier d' environnement
dev.yaml .
Ordre de service:
#include eureka server.port: 9999 spring.application.name: order db.url: 192.168.0.100
Nous pouvons également définir les paramètres de la base de données dans une configuration distincte en remplaçant la ligne d'importation par
#include eureka, oracle .
Il convient de noter qu'à chaque changement lors de la régénération des fichiers de configuration, le framework surveille et place dans un fichier spécial à côté du fichier de configuration principal. L'entrée dans son journal ressemble à ceci: «La propriété stockée 1 change en
order / diff-application.yaml ». Cela vous permet de détecter rapidement les modifications dans les fichiers de configuration volumineux.
La suppression des parties communes de la configuration vous permet de vous débarrasser de nombreux copier-coller inutiles, mais ne vous permet pas de créer de manière flexible une configuration pour différents environnements - les points de terminaison de nos services sont uniques et codés en dur, c'est mauvais. Essayons de le supprimer.
Une bonne solution serait de conserver tous les points de terminaison dans une configuration que d'autres pourraient référencer. Pour ce faire, un support pour les espaces réservés a été introduit dans le cadre. Voici comment le fichier de configuration
eureka change:
client: serviceUrl: defaultZone: http://${endpoints@eurekaip}:6782/eureka/
Voyons maintenant comment fonctionne cet espace réservé. Le système trouve un composant nommé
endpoints et y recherche
eurekaip , puis le remplace dans notre configuration. Mais qu'en est-il des différents environnements? Pour ce faire, créez le fichier de paramètres dans les
points de terminaison du type suivant
application.dev.yaml . Le framework indépendamment, par extension de fichier, décide à quel environnement cette configuration appartient et la charge:
Le contenu du fichier dev:
eurekaip: 192.89.89.111 dbip: 192.168.0.100
Nous pouvons créer la même configuration pour les ports de nos services:
server.port: ${ports@order}.
Tous les paramètres importants sont au même endroit, ce qui réduit la probabilité d'une erreur due aux paramètres dispersés dans les fichiers de configuration.
Le cadre fournit de nombreux espaces réservés prêts à l'emploi, par exemple, vous pouvez obtenir le nom du répertoire dans lequel se trouve le fichier de configuration et l'affecter:
#include eureka, oracle server.port: ${ports@order} spring.application.name: ${this@name}
Pour cette raison, il n'est pas nécessaire de spécifier en plus le nom de l'application dans la configuration et elle peut également être déplacée vers un module commun, par exemple, vers la même eureka:
client: serviceUrl: defaultZone: http://${endpoints@eurekaip}:6782/eureka/ spring.application.name: ${this@name}
Le fichier de configuration de la
commande sera réduit à une seule ligne:
#include eureka, oracle server.port: ${ports@order}
Dans le cas où nous n'avons besoin d'aucun paramètre de la configuration parent, nous pouvons le spécifier dans notre configuration et il sera appliqué lors de la génération. Autrement dit, si pour une raison quelconque, nous avons besoin d'un nom unique pour le service de commande, laissez simplement le paramètre
spring.application.name .
Disons que vous devez ajouter des paramètres de journalisation personnalisés au service, qui sont stockés dans un fichier séparé, par exemple,
logback.xml . Créez-lui un groupe de paramètres distinct:
Dans la configuration de base, nous indiquerons le framework où placer le fichier de paramètres de journalisation dont nous avons besoin en utilisant l'espace
réservé @ConfigDir:
microconfig.template.logback.fromFile: ${logback@configDir}/logback.xml
Dans le fichier
logback.xml ,
nous configurons des ajouteurs standard, qui à leur tour peuvent également contenir des espaces réservés, que le cadre changera lors de la génération des configurations, par exemple:
<file>logs/${this@name}.log</file>
En
ajoutant une importation de
déconnexion dans la configuration du service, nous obtenons automatiquement la journalisation configurée pour chaque service:
#include eureka, oracle, logback server.port: ${ports@order}
Il est temps de vous familiariser plus en détail avec tous les espaces réservés de framework disponibles:
$ {this @ env} - retourne le nom de l'environnement actuel.
$ {... @ name} - retourne le nom du composant.
$ {... @ configDir} - retourne le chemin complet vers le répertoire config du composant.
$ {... @ resultDir} - retourne le chemin complet vers le répertoire de destination du composant (les fichiers reçus seront placés dans ce répertoire).
$ {this @ configRoot} - Renvoie le chemin d'accès complet au répertoire racine du magasin de configuration.
Le système vous permet également d'obtenir des variables d'environnement, par exemple, le chemin d'accès à java:
$ {env @ JAVA_HOME}Ou, puisque le framework est écrit en
JAVA , nous pouvons obtenir des variables système similaires à l'appel de
System :: getProperty en utilisant une construction comme celle-ci:
${system@os.name}Il convient de mentionner la prise en charge du langage d'extension
Spring EL . Dans la configuration, des expressions similaires sont applicables:
connection.timeoutInMs: #{5 * 60 * 1000} datasource.maximum-pool-size: #{${this@datasource.minimum-pool-size} + 10}
et vous pouvez utiliser des variables locales dans les fichiers de configuration en utilisant l'expression
#var :
#var feedRoot: ${system@user.home}/feed folder: root: ${this@feedRoot} success: ${this@feedRoot}/archive error: ${this@feedRoot}/error
Ainsi, le framework est un outil assez puissant pour une configuration fine et flexible des microservices. Le cadre remplit parfaitement sa tâche principale - éliminer le copier-coller dans les paramètres, consolider les paramètres et, par conséquent, minimiser les erreurs possibles, tout en facilitant la combinaison des configurations et les modifications pour différents environnements.
Si vous êtes intéressé par ce framework, je vous recommande de visiter sa page officielle et de lire la
documentation complète, ou de plonger dans la source
ici .