Bestuur mikrodienskonfigurasies maklik met microconfig.io

Een van die hoofprobleme in die ontwikkeling en daaropvolgende werking van mikrodienste is die bekwame en akkurate konfigurasie van hul gevalle. Myns insiens kan ’n nuwe raamwerk hiermee help microconfig.io. Dit laat jou toe om 'n paar roetine-toepassingskonfigurasietake redelik elegant op te los.

As jy baie mikrodienste het, en elkeen van hulle kom met sy eie konfigurasielêer/lêers, dan is daar 'n groot waarskynlikheid om 'n fout in een van hulle te maak, wat baie moeilik kan wees om te vang sonder behoorlike vaardigheid en 'n aantekenstelsel. Die hooftaak wat die raamwerk vir homself stel, is om duplikaatinstansie-konfigurasieparameters te minimaliseer, en sodoende die waarskynlikheid van die byvoeging van 'n fout te verminder.

Kom ons kyk na 'n voorbeeld. Kom ons sê ons het 'n eenvoudige toepassing met 'n konfigurasielêer yaml. Dit kan enige mikrodiens in enige taal wees. Kom ons kyk hoe die raamwerk op hierdie diens toegepas kan word.

Maar eers, vir groter gerief, laat ons 'n leë projek in Idea IDE skep, nadat ons die microconfig.io-inprop daarin geïnstalleer het:

Ons stel die inprop-bekendstellingkonfigurasie op, u kan die verstekkonfigurasie gebruik, soos in die skermkiekie hierbo.

Ons diens word orde genoem, dan sal ons in 'n nuwe projek 'n soortgelyke struktuur skep:

Plaas die konfigurasielêer in die gids met die diensnaam - application.yaml. Alle mikrodienste word in 'n soort omgewing bekendgestel, dus, benewens die skep van 'n konfigurasie vir die diens self, is dit nodig om die omgewing self te beskryf: hiervoor sal ons 'n gids skep envs en voeg 'n lêer daarby met die naam van ons werksomgewing. Die raamwerk sal dus konfigurasielêers vir dienste in die omgewing skep dev, aangesien hierdie parameter in die inpropinstellings gestel is.

Lêerstruktuur dev.yaml dit sal redelik eenvoudig wees:

mainorder:
    components:
         - order

Die raamwerk werk met konfigurasies wat saam gegroepeer is. Kies 'n naam vir die groep vir ons diens hooforde. Die raamwerk vind elke sodanige groep toepassings in die omgewingslêer en skep konfigurasies vir almal, wat dit in die ooreenstemmende vouers vind.

In die diensinstellingslêer self einde Kom ons spesifiseer net een parameter vir nou:

spring.application.name: order

Laat ons nou die inprop laat loop, en dit sal die vereiste konfigurasie vir ons diens genereer volgens die pad wat in die eienskappe gespesifiseer word:

Kan kom oor die weg en sonder om 'n inprop te installeer, laai eenvoudig die raamwerkverspreiding af en laat dit vanaf die opdragreël loop.
Hierdie oplossing is geskik vir gebruik op 'n boubediener.

Dit is opmerklik dat die raamwerk perfek verstaan eiendom sintaksis, dit wil sê, gewone eiendomslêers wat saam gebruik kan word in yaml konfigurasies.

Kom ons voeg nog 'n diens by betaling en kompliseer die bestaande een.
В einde:

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

В betaling:

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

Die grootste probleem met hierdie konfigurasies is die teenwoordigheid van 'n groot hoeveelheid kopieer-plak in die diensinstellings. Kom ons kyk hoe die raamwerk sal help om daarvan ontslae te raak. Kom ons begin met die mees voor die hand liggende - die teenwoordigheid van konfigurasie Eureka in die beskrywing van elke mikrodiens. Kom ons skep 'n nuwe gids met die instellingslêer en voeg 'n nuwe konfigurasie daarby:

En kom ons voeg nou die lyn by elkeen van ons projekte #sluit eureka in.

Die raamwerk sal outomaties die eureka-konfigurasie vind en dit na die dienskonfigurasielêers kopieer, terwyl 'n aparte eureka-konfigurasie nie geskep sal word nie, aangesien ons dit nie in die omgewinglêer sal spesifiseer nie dev.yaml. Diens einde:

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

Ons kan ook die databasisinstellings na 'n aparte konfigurasie skuif deur die invoerlyn te verander na #sluit eureka, orakel in.

Dit is opmerklik dat die raamwerk elke verandering naspoor wanneer konfigurasielêers herstel word en dit in 'n spesiale lêer langs die hoofkonfigurasielêer plaas. Die inskrywing in sy logboek lyk soos volg: “Gestoorde 1 eiendom verander na order/diff-toepassing.yaml" Dit laat jou toe om vinnig veranderinge aan groot konfigurasielêers op te spoor.

Die verwydering van algemene dele van die konfigurasie laat jou toe om ontslae te raak van baie onnodige kopieer-plak, maar laat jou nie toe om buigsaam 'n konfigurasie vir verskillende omgewings te skep nie - die eindpunte van ons dienste is uniek en hardgekodeerd, dit is sleg. Kom ons probeer dit verwyder.

'n Goeie oplossing sou wees om alle eindpunte in een konfigurasie te hou waarna ander kan verwys. Vir hierdie doel is ondersteuning vir plekhouers in die raamwerk ingebring. Dit is hoe die konfigurasielêer sal verander Eureka:

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

Kom ons kyk nou hoe hierdie plekhouer werk. Die stelsel vind 'n komponent met die naam endpoints en soek betekenis daarin eurekaip, en vervang dit dan in ons konfigurasie. Maar wat van verskillende omgewings? Om dit te doen, skep 'n instellingslêer in endpoints die volgende tipe application.dev.yaml. Die raamwerk onafhanklik, gebaseer op die lêeruitbreiding, besluit aan watter omgewing hierdie konfigurasie behoort en laai dit:

Dev lêer inhoud:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

Ons kan dieselfde konfigurasie vir die poorte van ons dienste skep:

server.port: ${ports@order}.

Alle belangrike instellings is op een plek, waardeur die waarskynlikheid van foute as gevolg van verstrooide parameters in konfigurasielêers verminder word.

Die raamwerk bied baie gereedgemaakte plekhouers, byvoorbeeld, jy kan die naam van die gids kry waarin die konfigurasielêer geleë is en dit toewys:

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

Danksy dit is dit nie nodig om die toepassingsnaam bykomend in die konfigurasie te spesifiseer nie en dit kan ook in 'n algemene module geplaas word, byvoorbeeld in dieselfde eureka:

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

Die konfigurasielêer einde sal tot een reël verminder word:

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

As ons geen instelling van die ouerkonfigurasie benodig nie, kan ons dit in ons konfigurasie spesifiseer en dit sal tydens generering toegepas word. Dit wil sê, as ons om een ​​of ander rede 'n unieke naam vir die besteldiens benodig, sal ons net die parameter verlaat lente.toepassing.naam.

Kom ons sê jy moet persoonlike loginstellings by die diens voeg, wat in 'n aparte lêer gestoor word, byvoorbeeld, logback.xml. Kom ons skep 'n aparte groep instellings daarvoor:

In die basiese konfigurasie sal ons die raamwerk vertel waar om die aantekeninstellingslêer wat ons benodig te plaas met behulp van 'n plekhouer @ConfigDir:

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

In lêer logback.xml ons konfigureer standaardbylaes, wat op hul beurt ook plekhouers kan bevat wat die raamwerk sal verander tydens die generering van konfigurasies, byvoorbeeld:

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

Deur invoer by dienskonfigurasies te voeg terugskakel, kry ons outomaties gekonfigureerde logging vir elke diens:

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

Dit is tyd om in meer besonderhede kennis te maak met al die beskikbare plekhouers van die raamwerk:

${hierdie@env} - gee die naam van die huidige omgewing terug.
${…@name} — gee die naam van die komponent terug.
${…@configDir} - gee die volle pad terug na die komponent se konfigurasiegids.
${…@resultDir} — gee die volle pad terug na die komponent se bestemmingsgids (die resulterende lêers sal in hierdie gids geplaas word).
${this@configRoot} - gee die volledige pad terug na die wortelgids van die konfigurasiewinkel.

Die stelsel laat jou ook toe om omgewingsveranderlikes te kry, byvoorbeeld die pad na java:
${env@JAVA_HOME}
Óf, aangesien die raamwerk in geskryf is JAVA, kan ons stelselveranderlikes soortgelyk aan die oproep kry System::getProperty gebruik 'n struktuur soos hierdie:
${[e-pos beskerm]}
Dit is die moeite werd om ondersteuning vir die uitbreidingstaal te noem Lente EL. Die volgende uitdrukkings is van toepassing in die konfigurasie:

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

en jy kan plaaslike veranderlikes in konfigurasielêers gebruik deur die uitdrukking te gebruik #var:

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

Die raamwerk is dus 'n taamlik kragtige hulpmiddel vir die fyninstelling en buigsame konfigurasie van mikrodienste. Die raamwerk vervul sy hooftaak perfek - elimineer kopieer-plak in instellings, konsolidering van instellings en, gevolglik, minimalisering van moontlike foute, terwyl dit jou toelaat om konfigurasies maklik te kombineer en vir verskillende omgewings te verander.

As jy belangstel in hierdie raamwerk, beveel ek aan om die amptelike bladsy te besoek en kennis te maak met die volledige dokumentasie, of delf in die bronne hier.

Bron: will.com