Lihtne mikroteenuste konfiguratsioonide haldamine microconfig.io abil

Üks peamisi probleeme mikroteenuste väljatöötamisel ja edasises kasutamises on nende instantside korralik ja hoolikas seadistamine. Arvan, et uue raamistikuga saab sellel osas palju aidata. microconfig.io. See võimaldab üsna elegantselt lahendada mõned rakenduste seadistamise rutiinsed ülesanded.

Kui teil on palju mikroteenuseid, millest igaühel on oma seadistusefailid, on väga suur tõenäosus, et teete ühes neist vea, mida ilma piisava oskuse ja logimisüsteemita võib olla väga keeruline avastada. Raamistiku peamine ülesanne on vähendada instantsi seadistuse dubleerivate parameetrite arvu, vähendades seeläbi vea lisamise tõenäosust.

Vaatame näitena. Oletame, et meil on lihtne rakendus koos konfiguratsioonifailiga yaml. See võib olla ükskõik milline mikroteenus, mis on kirjutatud mis tahes keeles. Vaatame, kuidas saab seda raamistikku rakendada sellele teenusele.

Kuid kõigepealt loome Idea IDE-s tühja projekti, pärast microconfig.io plugina paigaldamist:

Seame plugina käivitamise konfiguratsiooni, saab kasutada vaike konfiguratsiooni, nagu ülaltoodud ekraanipildil.

Meie teenus nimega order, siis loome uues projektis sarnase struktuuri:

Seadmega nimega kaustas asetame konfiguratsioonifaili — application.yaml. Kõik mikroteenused käivitatakse mingis keskkonnas, seega lisaks teenuse enda konfiguratsioonifaili loomisele on vaja kirjeldada keskkonda: selleks loome kausta envs ja lisame sinna faili, mille nimi on meie töö keskkonna nimi. Nii loob raamistik konfiguratsioonifaile teenustele keskkonnas dev, kuna plugina seadetes on määratud just see parameeter.

Faili struktuur dev.yaml oleks üsna lihtne:

mainorder:
    components:
         - order

Raamistik töötab seadistustega, mis on ühendatud rühmadeks. Meie teenuse jaoks valime grupi nime mainorder. Raamistik leiab iga sellise rakenduste grupi keskkonna failist ja loob neile konfiguratsioonid, mis asuvad vastavates kaustades.

Oma teenuse seadistusfailis order märkime esialgu ainult ühe parameetri:

spring.application.name: order

Nüüd käivitame plugina ja see genereerib meie teenuse vajalikud konfiguratsioonid esitatud teede põhjal:

Saame ilma hakkama ja ilma plugina installimist, lihtsalt laadides alla raamistikku ja käivitades seda käsurealt.
Selline lahendus sobib ehitusserverile kasutamiseks.

Tuleb märkida, et raamistik mõistab suurepäraselt property süntaksit, mis tähendab tavalisi property faile, mida saab koos kasutada yaml konfiguratsioonidega.

Lisame veel ühe teenuse payment ja keerukaks olemasolevat.
Uues order:

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

Uues payment:

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

Peamine probleem nende konfiguratsioonide juures on suur hulk kopeerimist ja kleepimist teenuste seadetes. Vaatame, kuidas raamistik aitab selle probleemiga toime tulla. Alustame kõige ilmsemast - konfiguratsiooni olemasolust eureka iga mikroteenuse kirjelduse juures. Loome uue katalooge seadistusfailiga ja lisame sinna uue konfiguratsiooni:

Ja iga meie projekti lisame nüüd rea #include eureka.

Raamistik leiab automaatselt konfiguratsiooni eureka ja kopeerib selle teenuste konfiguratsioonifailidesse, samas eraldi konfiguratsiooni eureka ei luleta, kuna me ei näita seda keskkonna failis. dev.yaml. Teenus order:

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

Samuti saame andmebaasi seadistused välja tuua eraldi konfiguratsiooni, muutes impordi rea #include eureka, oracle.

Tuleb märkida, et iga muudatuse korral jälgib raamistik konfiguratsioonifailide regeneratsiooni ja paneb need peamise seadistuse faili kõrvale eraldi faili. Logis näeb kirje välja selline: “Salvestati 1 atribuut muudatus order/diff-application.yaml”. See võimaldab kiiresti avastada muudatusi suurtes konfiguratsioonifailides.

Üldiste konfiguratsiooniosade välja toomine võimaldab vabaneda suurest hulgast tarbetust kopeerimisest, kuid ei võimalda paindlikult luua konfiguratsiooni erinevate keskkondade jaoks - meie teenuste lõpp-punktid on ainsad ja kõvasti kodeeritud, see on halb. Proovime seda eemaldada.

Hea lahendus oleks hoida kõik lõpp-punktid ühes ainus konfiguratsioonis, millele saaksid viidata teised. Selle jaoks on raamistikku integreeritud plaanide toe. Nii muutub konfiguratsioonifail eureka:

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

Nüüd vaatame, kuidas see plaan toimib. Süsteem leiab komponendi nimega endpoints ja otsib sellest väärtust eurekaip, see, it inserts into our configuration. But how to deal with different environments? To address this, we'll create a settings file in endpoints the following format application.dev.yaml. The framework automatically decides which environment this configuration belongs to based on the file extension and loads it:

Contents of the dev file:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

We can create the same configuration for the ports of our services:

server.port: ${ports@order}.

All important settings are located in one place, thus reducing the likelihood of errors due to scattered parameters across configuration files.

The framework provides many ready-made placeholders, for example, you can get the name of the directory where the configuration file is located and assign it:

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

As a result, there's no need to specify the application name in the configuration, and it can also be extracted into a common module, for example, into Eureka itself:

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

The configuration file order will be reduced to one line:

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

If any setting from the parent configuration is not needed, we can specify it in our configuration, and that will be applied during generation. That is, if for some reason we need a unique name for the order service, we simply leave the parameter spring.application.name.

Let's say we need to add customized logging settings, which are stored in a separate file, for example, logback.xml. We'll create a separate group of settings for it:

In the basic configuration, we will specify to the framework where to place the necessary logging settings file using the placeholder @ConfigDir:

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

Failis logback.xml Configuring standard appenders, which can also contain placeholders, which the framework will replace during config generation, for example:

logs/${this@name}.log

By adding imports in the configuration of services logback, we automatically get configured logging for each service:

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

It's time to learn more about all available placeholders in the framework:

${this@env} — returns the name of the current environment.
${…@name} — returns the name of the component.
${…@configDir} — returns the full path to the config directory of the component.
${…@resultDir} — tagastab täispika tee sihtkausta (saadud failid paigutatakse sellesse kausta).
${this@configRoot} — tagastab täispika tee konfiguratsioonide salvestuskausta.

Süsteem võimaldab ka saada keskkonnamuutujate, näiteks java tee:
${env@JAVA_HOME}
Või, kuna raamistik on kirjutatud JAVA, saame saada süsteemi muutujad sarnaste kõnede abil System::getProperty kasutades sellist konstruktsiooni:
${system@os.name}
Tasub mainida laienduskeele toetust Spring EL. Konfiguratsioonis kehtivad sarnased väljendid:

connection.timeoutInMs: #{5 * 60 * 1000}
datasource.maximum-pool-size: #{${this@datasource.minimum-pool-size} + 10} 

ja kohalikke muutujaid saab kasutada konfiguratsioonifailides väljendi kaudu. #var:

#var feedRoot: ${system@user.home}/feed
folder:
 root: ${this@feedRoot}
 success: ${this@feedRoot}/archive
 error: ${this@feedRoot}/error

Nii et raamistik on üsna võimas tööriist mikroteenuste konfiguratsioonide peenus ja paindlikkus. Raamistik täidab oma põhifunktsiooni hästi — taandab kopeerimist konfiguratsioonides, konsolideerib seadeid ja vähendab seeläbi võimalikke vigu, võimaldades samal ajal lihtsat kombinatsiooni ja kohandamist erinevatesse keskkondadesse.

Kui see raamistik teid huvitab, soovitan külastada selle ametlikku lehte ja tutvuda täieliku Microsofti dokumentatsioonile. Ainus tähelepanek — Ubuntu distributsiooni oleme juba alla laadinud ja installime selle järgmises etapis. Peaaegu kogu seadistamine seisneb Windowsi Linuxi alamsüsteemi ja Virtuaalmasinate platvormi täiendavate komponentide lubamises ning seejärel arvuti seadete muutuste rakendamiseks taaskäivitamises:, või kaevuda allikakoode. siit.

Allikas: habr.com