Rakenduse microconfig.io abil saate hõlpsalt hallata mikroteenuste konfiguratsioone

Üks peamisi probleeme mikroteenuste arendamisel ja hilisemal toimimisel on nende eksemplaride pädev ja täpne seadistamine. Minu arvates võib uus raamistik selles osas aidata microconfig.io. See võimaldab teil üsna elegantselt lahendada mõned rutiinsed rakenduse seadistamise ülesanded.

Kui teil on palju mikroteenuseid ja igaühega neist on kaasas oma konfiguratsioonifail/-failid, siis on suur tõenäosus, et ühes neist tekib viga, mida ilma korralike oskuste ja logimissüsteemita võib olla väga raske tabada. Peamine ülesanne, mille raamistik endale seab, on minimeerida eksemplari dubleerivaid konfiguratsiooniparameetreid, vähendades sellega vea lisamise tõenäosust.

Vaatame näidet. Oletame, et meil on konfiguratsioonifailiga lihtne rakendus yaml. See võib olla mis tahes mikroteenus mis tahes keeles. Vaatame, kuidas raamistikku sellele teenusele rakendada.

Kuid esmalt loome suurema mugavuse huvides Idea IDE-s tühja projekti pärast pistikprogrammi microconfig.io installimist:

Seadistasime pistikprogrammi käivitamise konfiguratsiooni, saate kasutada vaikekonfiguratsiooni, nagu ülaltoodud ekraanipildil.

Meie teenust nimetatakse tellimuseks, siis loome uues projektis sarnase struktuuri:

Asetage konfiguratsioonifail teenuse nimega kausta - rakendus.yaml. Kõik mikroteenused käivitatakse mingis keskkonnas, nii et lisaks teenuse enda konfiguratsiooni loomisele on vaja kirjeldada keskkonda ennast: selleks loome kausta ümbritseb ja lisage sellele fail meie töökeskkonna nimega. Seega loob raamistik keskkonnas olevate teenuste jaoks konfiguratsioonifailid Dev, kuna see parameeter on määratud pistikprogrammi seadetes.

Faili struktuur dev.yaml see saab olema üsna lihtne:

mainorder:
    components:
         - order

Raamistik töötab koos rühmitatud konfiguratsioonidega. Meie teenuse jaoks valige grupile nimi peatellimus. Raamistik leiab iga sellise rakenduste rühma keskkonnafailist ja loob nende kõigi jaoks konfiguratsioonid, mille leiab vastavatest kaustadest.

Teenuse seadete failis endas et Määrame praegu ainult ühe parameetri:

spring.application.name: order

Nüüd käivitame pistikprogrammi ja see genereerib meie teenuse jaoks vajaliku konfiguratsiooni vastavalt atribuutides määratud teele:

Kas läbi saama ja ilma pistikprogrammi installimata laadige lihtsalt alla raamistiku distributsioon ja käivitage see käsurealt.
See lahendus sobib kasutamiseks ehitusserveris.

Väärib märkimist, et raamistik mõistab suurepäraselt kinnisvara süntaks, st tavalised atribuudifailid, mida saab koos kasutada yaml konfiguratsioonid.

Lisame veel ühe teenuse makse ja olemasolevat keerulisemaks muuta.
В et:

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

В makse:

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

Nende konfiguratsioonide peamine probleem on suure hulga kopeerimis-kleebi olemasolu teenuse seadetes. Vaatame, kuidas raamistik aitab sellest lahti saada. Alustame kõige ilmsemast - konfiguratsiooni olemasolust eureka iga mikroteenuse kirjelduses. Loome seadete failiga uue kataloogi ja lisame sellele uue konfiguratsiooni:

Ja nüüd lisame rea igale meie projektile #include eureka.

Raamistik leiab automaatselt eureka konfiguratsiooni ja kopeerib selle teenuse konfiguratsioonifailidesse, samas kui eraldi eureka konfiguratsiooni ei looda, kuna me ei määra seda keskkonnafailis dev.yaml. Teenindus et:

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

Samuti saame andmebaasi sätted teisaldada eraldi konfiguratsiooni, muutes impordirea väärtuseks #include eureka, oracle.

Väärib märkimist, et raamistik jälgib konfiguratsioonifailide taasloomisel iga muudatust ja paigutab selle põhikonfiguratsioonifaili kõrvale spetsiaalsesse faili. Selle logi kirje näeb välja selline: „Salvestatud 1 atribuut muutub order/diff-application.yaml" See võimaldab teil kiiresti tuvastada suurte konfiguratsioonifailide muudatusi.

Konfiguratsiooni tavaosade eemaldamine võimaldab vabaneda paljudest tarbetutest kopeerimis-kleebimisest, kuid ei võimalda paindlikult luua konfiguratsiooni erinevatele keskkondadele - meie teenuste lõpp-punktid on ainulaadsed ja kõvasti kodeeritud, see on halb. Proovime selle eemaldada.

Hea lahendus oleks hoida kõik lõpp-punktid ühes konfiguratsioonis, millele teised saavad viidata. Sel eesmärgil on raamistikku sisse viidud kohahoidjate tugi. Nii muutub konfiguratsioonifail eureka:

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

Nüüd vaatame, kuidas see kohatäide töötab. Süsteem leiab komponendi nimega lõpp-punktid ja otsib selles tähendust eurekaipja seejärel asendab selle meie konfiguratsiooniga. Aga kuidas on lood erinevate keskkondadega? Selleks looge seadete fail lõpp-punktid järgmist tüüpi application.dev.yaml. Raamistik otsustab faililaiendi põhjal iseseisvalt, millisesse keskkonda see konfiguratsioon kuulub, ja laadib selle:

Arendusfaili sisu:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

Saame luua sama konfiguratsiooni oma teenuste portide jaoks:

server.port: ${ports@order}.

Kõik olulised sätted on ühes kohas, vähendades sellega konfiguratsioonifailide hajutatud parameetrite tõttu tekkivate vigade tõenäosust.

Raamistik pakub palju valmis kohahoidjaid, näiteks saate hankida kataloogi nime, milles konfiguratsioonifail asub, ja määrata selle:

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

Tänu sellele ei ole vaja konfiguratsioonis rakenduse nime täiendavalt määrata ja selle saab paigutada ka ühisesse moodulisse, näiteks samasse eurekasse:

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

Konfiguratsioonifail et vähendatakse ühele reale:

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

Kui me ei vaja põhikonfiguratsioonist mingeid sätteid, saame selle oma konfiguratsioonis määrata ja seda rakendatakse genereerimise ajal. See tähendab, et kui vajame mingil põhjusel tellimisteenusele ainulaadset nime, jätame parameetri lihtsalt alles kevad.rakenduse.nimi.

Oletame, et peate teenusele lisama kohandatud logimisseaded, mis salvestatakse eraldi faili, näiteks logback.xml. Loome selle jaoks eraldi seadete rühma:

Põhikonfiguratsioonis ütleme raamistikule kohahoidja abil, kuhu paigutada vajalik logisätete fail @ConfigDir:

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

Failis logback.xml konfigureerime standardsed lisandid, mis omakorda võivad sisaldada ka kohahoidjaid, mida raamistik konfiguratsioonide genereerimise käigus muudab, näiteks:

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

Lisades teenuse konfiguratsioonidele impordi tagasilogimine, saame automaatselt iga teenuse jaoks konfigureeritud logimise:

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

On aeg tutvuda üksikasjalikumalt kõigi raamistiku saadaolevate kohahoidjatega:

${this@env} - tagastab praeguse keskkonna nime.
${…@name} — tagastab komponendi nime.
${...@configDir} — tagastab täieliku tee komponendi konfiguratsioonikataloogi.
${…@resultDir} — tagastab täieliku tee komponendi sihtkataloogi (saadud failid paigutatakse sellesse kataloogi).
${this@configRoot} — tagastab täieliku tee konfiguratsioonisalve juurkataloogi.

Süsteem võimaldab teil hankida ka keskkonnamuutujaid, näiteks tee java juurde:
${env@JAVA_HOME}
Mõlemad, kuna raamistik on sisse kirjutatud JAVA, saame kõnega sarnased süsteemimuutujad Süsteem::getProperty kasutades sellist struktuuri:
${[meiliga kaitstud]}
Mainimist väärib laienduskeele tugi Kevad EL. Konfiguratsioonis on rakendatavad järgmised väljendid:

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

ja avaldist kasutades saate konfiguratsioonifailides kasutada kohalikke muutujaid #var:

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

Seega on raamistik üsna võimas tööriist mikroteenuste peenhäälestamiseks ja paindlikuks seadistamiseks. Raamistik täidab suurepäraselt oma põhiülesannet - seadetes kopeerimise ja kleepimise välistamine, sätete konsolideerimine ja selle tulemusena võimalike vigade minimeerimine, võimaldades samal ajal konfiguratsioone hõlpsalt kombineerida ja erinevate keskkondade jaoks muuta.

Kui olete selle raamistiku vastu huvitatud, soovitan külastada selle ametlikku lehte ja tutvuda täismahuga dokumentatsioonvõi uurige allikaid siin.

Allikas: www.habr.com