Gestioneu fàcilment les configuracions de microserveis amb microconfig.io

Un dels principals problemes en el desenvolupament i posterior funcionament dels microserveis és la configuració competent i precisa de les seves instàncies. Al meu entendre, un nou marc pot ajudar amb això microconfig.io. Us permet resoldre algunes tasques rutinàries de configuració d'aplicacions amb força elegància.

Si teniu molts microserveis i cadascun d'ells inclou el seu propi fitxer/fitxers de configuració, hi ha una gran probabilitat de cometre un error en un d'ells, cosa que pot ser molt difícil de detectar sense l'habilitat adequada i un sistema de registre. La tasca principal que es defineix el marc és minimitzar els paràmetres de configuració d'instàncies duplicades, reduint així la probabilitat d'afegir un error.

Vegem-ne un exemple. Suposem que tenim una aplicació senzilla amb un fitxer de configuració yaml. Pot ser qualsevol microservei en qualsevol idioma. Vegem com es pot aplicar el marc a aquest servei.

Però primer, per a una major comoditat, creem un projecte buit a Idea IDE, després d'instal·lar-hi el connector microconfig.io:

Configurem la configuració de llançament del connector, podeu utilitzar la configuració predeterminada, com a la captura de pantalla anterior.

El nostre servei s'anomena ordre, llavors en un nou projecte crearem una estructura similar:

Col·loqueu el fitxer de configuració a la carpeta amb el nom del servei - aplicació.yaml. Tots els microserveis es llancen en algun tipus d'entorn, per la qual cosa, a més de crear una configuració per al propi servei, cal descriure l'entorn en si: per a això crearem una carpeta envs i afegiu-hi un fitxer amb el nom del nostre entorn de treball. Així, el marc crearà fitxers de configuració per als serveis de l'entorn dev, ja que aquest paràmetre s'estableix a la configuració del connector.

Estructura del fitxer dev.yaml serà ben senzill:

mainorder:
    components:
         - order

El marc funciona amb configuracions que s'agrupen. Per al nostre servei, trieu un nom per al grup ordre principal. El marc troba cadascun d'aquests grups d'aplicacions al fitxer d'entorn i crea configuracions per a totes, que troba a les carpetes corresponents.

Al mateix fitxer de configuració del servei ordre Especifiquem només un paràmetre de moment:

spring.application.name: order

Ara executem el connector i generarà la configuració necessària per al nostre servei segons el camí especificat a les propietats:

llauna Portar-se bé i sense instal·lar un connector, simplement baixant la distribució del marc i executant-la des de la línia d'ordres.
Aquesta solució és adequada per al seu ús en un servidor de compilació.

Val la pena assenyalar que el marc entén perfectament propietat sintaxi, és a dir, fitxers de propietats normals que es poden utilitzar junts a yaml configuracions.

Afegim un altre servei pagament i complicar l'existent.
В ordre:

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

В pagament:

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

El principal problema d'aquestes configuracions és la presència d'una gran quantitat de còpia i enganxa a la configuració del servei. Vegem com el marc ajudarà a desfer-se'n. Comencem pel més obvi: la presència de la configuració eureka a la descripció de cada microservei. Creem un nou directori amb el fitxer de configuració i afegim-hi una nova configuració:

I ara afegim la línia a cadascun dels nostres projectes #inclou eureka.

El marc trobarà automàticament la configuració eureka i la copiarà als fitxers de configuració del servei, mentre que no es crearà una configuració eureka separada, ja que no l'especificarem al fitxer d'entorn. dev.yaml. Servei ordre:

#include eureka
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100

També podem moure la configuració de la base de dades a una configuració independent canviant la línia d'importació a #inclou eureka, oracle.

Val la pena assenyalar que el marc fa un seguiment de cada canvi quan es regenera els fitxers de configuració i el col·loca en un fitxer especial al costat del fitxer de configuració principal. L'entrada del seu registre té aquest aspecte: "S'ha emmagatzemat 1 propietat canvia a order/diff-application.yaml" Això us permet detectar ràpidament els canvis en fitxers de configuració grans.

L'eliminació de parts comunes de la configuració us permet desfer-vos de moltes còpies i enganxes innecessàries, però no us permet crear de manera flexible una configuració per a diferents entorns: els punts finals dels nostres serveis són únics i codificats, això és dolent. Intentem eliminar això.

Una bona solució seria mantenir tots els punts finals en una configuració que altres puguin fer referència. Amb aquesta finalitat, s'ha introduït el suport per a marcadors de posició al marc. Així és com canviarà el fitxer de configuració eureka:

 client:
   serviceUrl:
     defaultZone: http://${endpoints@eurekaip}:6782/eureka/

Ara vegem com funciona aquest marcador de posició. El sistema troba un component anomenat punts finals i hi busca sentit eurekaip, i després el substitueix a la nostra configuració. Però què passa amb els diferents entorns? Per fer-ho, creeu un fitxer de configuració punts finals el següent tipus application.dev.yaml. El marc de manera independent, en funció de l'extensió del fitxer, decideix a quin entorn pertany aquesta configuració i la carrega:

Contingut del fitxer de desenvolupament:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

Podem crear la mateixa configuració per als ports dels nostres serveis:

server.port: ${ports@order}.

Tots els paràmetres importants es troben en un sol lloc, reduint així la probabilitat d'errors a causa dels paràmetres dispersos als fitxers de configuració.

El marc proporciona molts marcadors de posició ja fets, per exemple, podeu obtenir el nom del directori on es troba el fitxer de configuració i assignar-lo:

#include eureka, oracle
server.port: ${ports@order}
spring.application.name: ${this@name}

Gràcies a això, no cal especificar addicionalment el nom de l'aplicació a la configuració i també es pot col·locar en un mòdul comú, per exemple, en el mateix eureka:

client:
   serviceUrl:
     defaultZone: http://${endpoints@eurekaip}:6782/eureka/
 spring.application.name: ${this@name}

El fitxer de configuració ordre es reduirà a una línia:

#include eureka, oracle
server.port: ${ports@order}

Si no necessitem cap paràmetre de la configuració principal, ho podem especificar a la nostra configuració i s'aplicarà durant la generació. És a dir, si per algun motiu necessitem un nom únic per al servei de comandes, només deixarem el paràmetre nom.de.aplicació.molla.

Suposem que necessiteu afegir paràmetres de registre personalitzats al servei, que s'emmagatzemen en un fitxer separat, per exemple, logback.xml. Creem-hi un grup separat de configuracions:

A la configuració bàsica, direm al marc on col·locar el fitxer de configuració de registre que necessitem mitjançant un marcador de posició @ConfigDir:

microconfig.template.logback.fromFile: ${logback@configDir}/logback.xml

A l'arxiu logback.xml configurem apèndixs estàndard, que al seu torn també poden contenir marcadors de posició que el marc canviarà durant la generació de configuracions, per exemple:

<file>logs/${this@name}.log</file>

Afegint importació a les configuracions del servei enrere la sessió, obtenim automàticament el registre configurat per a cada servei:

#include eureka, oracle, logback
server.port: ${ports@order}

És hora de familiaritzar-se amb més detall amb tots els marcadors de posició disponibles del marc:

${this@env} - retorna el nom de l'entorn actual.
${…@name} — retorna el nom del component.
${…@configDir} — retorna el camí complet al directori de configuració del component.
${…@resultDir} — retorna el camí complet al directori de destinació del component (els fitxers resultants es col·locaran en aquest directori).
${this@configRoot} — retorna el camí complet al directori arrel del magatzem de configuració.

El sistema també us permet obtenir variables d'entorn, per exemple, el camí a java:
${env@JAVA_HOME}
O bé, ja que el marc està escrit JAVA, podem obtenir variables del sistema similars a la trucada System::getProperty utilitzant una estructura com aquesta:
${[protegit per correu electrònic]}
Val la pena esmentar el suport per a l'idioma d'extensió Primavera EL. Les expressions següents són aplicables a la configuració:

connection.timeoutInMs: #{5 * 60 * 1000}
datasource.maximum-pool-size: #{${[email protected]} + 10} 

i podeu utilitzar variables locals als fitxers de configuració mitjançant l'expressió #var:

#var feedRoot: ${[email protected]}/feed
folder:
 root: ${this@feedRoot}
 success: ${this@feedRoot}/archive
 error: ${this@feedRoot}/error

Per tant, el marc és una eina força potent per a l'ajustament i la configuració flexible dels microserveis. El marc compleix perfectament la seva tasca principal: eliminar el còpia i enganxar a la configuració, consolidar la configuració i, com a resultat, minimitzar possibles errors, alhora que us permet combinar fàcilment configuracions i canviar-les per a diferents entorns.

Si esteu interessats en aquest marc, us recomano visitar la seva pàgina oficial i familiaritzar-vos amb el complet documentació, o investigar les fonts aquí.

Font: www.habr.com