Mikroteenuste konfiguratsioonide lihtne haldamine microconfig.io abil

Üks peamisi probleeme mikroteenuste arendamisel ja hilisemal kasutamisel on nende instantside õige ja täpne seadistamine. Minu arvates võib sellele aidata uus raamistik microconfig.io. See võimaldab elegantsemalt lahendada teatud rutiinsed rakenduste seadistamise ülesanded.

Kui teil on palju mikroteenuseid ja igaühel neist on oma seadistusfail(e), siis on tõenäoliselt, et teete ükskõik milles vea, mida ilma piisava oskuse ja logimise süsteemita on väga raske tuvastada. Raamistiku peamine ülesanne on vähendada dubleeritud instantsi seadistusparameetreid, seeläbi vähendades vea tekkimise võimalust.

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

Kuid kõigepealt loome Idea IDE-s tühja projekti, installides sinna eelnevalt microconfig.io pistikprogrammi:

Seame plugina käivitamiseks vajalik konfiguratsioon, kasutades vaikevalikuid, nagu ülaltoodud ekraanipildil.

Meie teenus kannab nime order, seega loome uues projektis sarnase struktuuri:

Kopeerime teenuse nime kandva kausta konfiguratsioonifaili — application.yaml. Kõik mikroteenused käivitatakse mingis keskkonnas, seega lisaks teenuse konfiguratsiooni loomisele on vajalik ka keskkonna defineerimine: selleks loome kausta envs ja lisame sellesse faili, mis kannab meie töökeskkonna nime. Seega loob raamistik konfiguratsioonifailid teenuste jaoks keskkonnas dev, kuna plugina seadistustes on määratud just see parameeter.

Faili struktuur dev.yaml oleb üsna lihtne:

mainorder:
    components:
         - order

Raamistik töötab konfiguratsioonidega, mis on rühmitatud gruppidesse. Meie teenuse jaoks valime grupi nime mainorder. Raamistik leiab iga sellise grupi rakendused keskkonnafailist ja loob neile konfiguratsioonid, mida ta vastavatest kaustadest leiab.

Teenuse seadistusfailis order määrame esialgu ainult ühe parameetri:

spring.application.name: order

Nüüd aktiveerime plugina, mis genereerib meie teenuse jaoks vajalikud seadistused antud omaduste teel:

Saame ka toime ilma plugina paigaldamiseta, lihtsalt allalaadides raamistiku distributsiooni ja käivitades selle käsurealt.
Selline lahendus sobib kokku kogumise serveris kasutamiseks.

Oluline on märkida, et raamistiku on suurepärane mõista property süntaksit, see tähendab tavalisi property faile, mida saab kasutada koos yaml konfiguratsioonidega.

Lisame veel ühe teenuse payment ja keerukust olemasolevast samal ajal.
V 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

V 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

Nende konfiguratsioonide peamine probleem on suur kogus kopeerimist teenuste seadistustes. Vaatame, kuidas raamistiku aitab seda vältida. Alustame kõige ilmsemast — konfiguratsioonist eureka iga mikroteenuse kirjelduse puhul. Loome uue kaustu seadistuste failiga ja lisame sinna uue seadistuse:

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

Raamistiku automaatselt leidub eureka konfiguratsioon ja kopeerib selle teenuste konfiguratsioonifailidesse, samas ei luheta eraldi eureka konfiguratsiooni, kuna me ei määratle seda keskkonnafailis. dev.yaml. Teenus order:

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

Samuti saame andmebaasi seaded eraldi konfiguratsiooni välja tuua, muutes impordirea. #include eureka, oracle.

Oluline on märkida, et iga muudatus, kui raamistik genereerib konfiguratsioonifailid uuesti, jälgib ja salvestab eraldi faili põhifaili kõrval. Sissekanne selle logis näeb välja järgmine: "Salvestatud 1 omaduse muudatus order/diff-application.yaml". See võimaldab kiiresti avastada muudatusi suurtes konfiguratsioonifailides.

Ühisosa konfiguratsiooni välja toomine võimaldab vältida liigset kopeerimist, kuid ei võimalda paindlikult luua konfiguratsiooni erinevate keskkondade jaoks — meie teenuste lõpp-punktid on ainulaadsed ja kõvasti kodeeritud, mis on halb. Proovime seda kõrvaldada.

Hea lahendus on hoida kõik lõpp-punktid ühes konfiguratsioonis, millele võiksid viidata teised. Selleks on raamistikku inteeritud tugiteenuste toetamine. Nii muutub konfiguratsioonifail. eureka:

 klient:
   teenuseUrl:
     vaikeala: http://${endpoints@eurekaip}:6782/eureka/

Nüüd vaatame, kuidas see määrang töötab. Süsteem leiab komponendi nimega endpoints ja otsib sealt väärtust eurekaip, pärast mida sisestab selle meie konfiguratsiooni. Kuidas aga erinevate keskkondadega? Selleks loome seadistuste faili, mille sisu on endpoints järgnev application.dev.yaml. Raamistik otsustab ise faili laiuse põhjal, mille keskkonnaga see konfiguratsioon seondub, ja laadib selle sisse:

dev faili sisu:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

Sama konfiguratsiooni saame luua ka meie teenuste sadamate jaoks:

server.port: ${ports@order}.

Kõik olulised seaded on ühes kohas, vähendades seeläbi vea tekkimise tõenäosust, kui parameetrid on hajutatud konfiguratsioonifailides.

Raamistik pakub mitmeid juba valmis määranguid, näiteks saab kätte faili konfiguratsiooni direktoriumi nime ja määrata selle:

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

Selle tõttu ei ole vaja eraldi märkida rakenduse nime konfiguratsioonis, vaid selle saab ka ühte üldmoduuli viia, näiteks samasse eureka:

klient:
   teenuseUrl:
     vaikeala: http://${endpoints@eurekaip}:6782/eureka/
 spring.application.name: ${this@name}

Konfiguratsioonifail order lühendab ühe reale:

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

Kui mõni seade vanematest seadistustest pole vajalik, saame selle määrata meie konfiguratsioonis ja just see rakendatakse genereerimisel. See tähendab, et kui meil on mingil põhjusel vaja unikaalset nime teenusele order, jätame lihtsalt parameetri spring.application.name.

Oletame, et teenusele tuleb lisada kohandatud logimiseseaded, mis salvestatakse eraldi faili, näiteks logback.xml. Loome selle jaoks eraldi seadistuste rühma:

Põhikonstruktsioonis määrame raamistikule, kuhu paigutada vajalik logimisfail, kasutades placeholder'i @ConfigDir:

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

Failis logback.xml konfigureerime standardsed appenderid, mis võivad samuti sisaldada placeholder'e, mida raamistik muudab konfiguratsioonide genereerimise ajal, näiteks:

logs/${this@name}.log

Lisades teenuste konfiguratsioonidesse importi logback, saame automaatselt seadistatud logimise igale teenusele:

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

On aeg tutvuda lähemalt kõigi raamistiku poolt pakutavate placeholder'itega:

${this@env} — tagastab praeguse keskkonna nime.
${…@name} — tagastab komponendi nime.
${…@configDir} — tagastab komponendi config katalooge kogu tee.
${…@resultDir} — tagastab komponendi sihtkatalooge kogu tee (saadud failid paigutatakse sellesse katalooge).
${this@configRoot} — tagastab konfigureerimise baas katalooge kogu tee.

Samuti võimaldab süsteem saada keskkonnavariatsioone, näiteks java tee:
${env@JAVA_HOME}
Või kuna raamistik on kirjutatud JAVA, saame süsteemi muutujaid sarnase üleskutsega saada System::getProperty sellise konstruktsiooni abil:
${system@os.name}
Tasub mainida laienduste keele toetust Spring EL. Konfiguratsioonis kehtivad sarnased väljendid:

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

ja saab kasutada lokaalvariatsioone konfiguratsioonifailides väljendite abil. #var:

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

Nii on raamistik üsna võimas tööriist mikroteenuste konfigureerimise peeneks ja paindlikuks kohandamiseks. Raamistik täidab oma põhiülesannet suurepäraselt — etteteatamata kopeerimise vältimine seadistustes, seadistuste koondamine ning seepärast võimalike vigade minimeerimine, võimaldades samal ajal konfigureerimiste hõlpsat kombineerimist ja nende muutmist erinevate keskkondade jaoks.

Kui see raamistik teid huvitab, soovitan külastada selle ametlikku lehte ja tutvuda täieliku dokumentatsiooniga, või uurida lähtekoodis siin.

Allikas: habr.com