Lengvai valdykite mikro paslaugų konfigūracijas naudodami microconfig.io

Viena iš pagrindinių mikropaslaugų kūrimo ir tolesnio veikimo problemų yra kompetentinga ir tiksli jų egzempliorių konfigūracija. Mano nuomone, tai gali padėti nauja sistema microconfig.io. Tai leidžia gana elegantiškai išspręsti kai kurias įprastas programos konfigūravimo užduotis.

Jei turite daug mikropaslaugų ir kiekviena iš jų yra su savo konfigūracijos failu / failais, tada yra didelė tikimybė, kad vienoje iš jų bus padaryta klaida, kurią gali būti labai sunku pastebėti be reikiamų įgūdžių ir registravimo sistemos. Pagrindinė užduotis, kurią sau nustato sistema, yra sumažinti pasikartojančius egzempliorių konfigūracijos parametrus, taip sumažinant klaidos pridėjimo tikimybę.

Pažiūrėkime į pavyzdį. Tarkime, kad turime paprastą programą su konfigūracijos failu yaml. Tai gali būti bet kokia mikro paslauga bet kuria kalba. Pažiūrėkime, kaip sistemą galima pritaikyti šiai paslaugai.

Tačiau pirmiausia, kad būtų patogiau, sukurkime tuščią projektą Idea IDE, jame įdiegę microconfig.io papildinį:

Mes nustatėme papildinio paleidimo konfigūraciją, galite naudoti numatytąją konfigūraciją, kaip parodyta aukščiau esančioje ekrano kopijoje.

Mūsų paslauga vadinama tvarka, tada naujame projekte sukursime panašią struktūrą:

Įdėkite konfigūracijos failą į aplanką su paslaugos pavadinimu - aplikacija.yaml. Visos mikropaslaugos paleidžiamos tam tikroje aplinkoje, todėl, be pačios paslaugos konfigūracijos sukūrimo, būtina aprašyti ir pačią aplinką: tam sukursime aplanką aprėpia ir pridėkite prie jo failą su mūsų darbo aplinkos pavadinimu. Taigi sistema sukurs paslaugų konfigūracijos failus aplinkoje dev, nes šis parametras nustatytas papildinio nustatymuose.

Failo struktūra dev.yaml bus gana paprasta:

mainorder:
    components:
         - order

Sistema veikia su konfigūracijomis, kurios yra sugrupuotos. Mūsų paslaugai pasirinkite grupės pavadinimą pagrindinis ordas. Karkasas suranda kiekvieną tokią programų grupę aplinkos faile ir sukuria visų jų konfigūracijas, kurias randa atitinkamuose aplankuose.

Pačiame paslaugos nustatymų faile kad Kol kas nurodykime tik vieną parametrą:

spring.application.name: order

Dabar paleiskite papildinį ir jis sugeneruos reikiamą konfigūraciją mūsų paslaugai pagal ypatybėse nurodytą kelią:

galima susitvarkyti ir neįdiegę papildinio, tiesiog atsisiųskite karkaso paskirstymą ir paleiskite jį iš komandinės eilutės.
Šis sprendimas tinkamas naudoti kūrimo serveryje.

Verta paminėti, kad sistema puikiai supranta nuosavybė sintaksė, tai yra įprasti nuosavybės failai, kuriuos galima naudoti kartu yaml konfigūracijos.

Pridėkime dar vieną paslaugą mokėjimas ir apsunkinti esamą.
В kad:

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

В mokėjimas:

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

Pagrindinė šių konfigūracijų problema yra tai, kad paslaugos nustatymuose yra daug kopijavimo ir įklijavimo. Pažiūrėkime, kaip sistema padės jo atsikratyti. Pradėkime nuo akivaizdžiausio - konfigūracijos buvimo eureka kiekvienos mikropaslaugos aprašyme. Sukurkime naują katalogą su nustatymų failu ir pridėkime prie jo naują konfigūraciją:

O dabar pridėkime eilutę prie kiekvieno mūsų projekto #įtraukti eureką.

Sistema automatiškai suras eureka konfigūraciją ir nukopijuos ją į paslaugos konfigūracijos failus, o atskira eureka konfigūracija nebus sukurta, nes jos nenurodysime aplinkos faile dev.yaml. Aptarnavimas kad:

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

Taip pat galime perkelti duomenų bazės nustatymus į atskirą konfigūraciją, pakeisdami importo eilutę į #įtraukti eureką, orakulą.

Verta paminėti, kad kiekvieną pakeitimą regeneruojant konfigūracijos failus seka sistema ir įdedamas į specialų failą šalia pagrindinio konfigūracijos failo. Įrašas jo žurnale atrodo taip: „Išsaugota 1 savybė pasikeičia į order/diff-application.yaml“ Tai leidžia greitai aptikti didelių konfigūracijos failų pakeitimus.

Įprastų konfigūracijos dalių pašalinimas leidžia atsikratyti daug nereikalingo kopijavimo-įklijavimo, tačiau neleidžia lanksčiai kurti konfigūracijos skirtingoms aplinkoms – mūsų paslaugų galiniai taškai yra unikalūs ir užkoduoti, tai yra blogai. Pabandykime tai pašalinti.

Geras sprendimas būtų išlaikyti visus galinius taškus vienoje konfigūracijoje, kurią gali nurodyti kiti. Šiuo tikslu į sistemą įtraukta vietos rezervavimo ženklų parama. Taip pasikeis konfigūracijos failas eureka:

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

Dabar pažiūrėkime, kaip veikia šis vietos rezervavimo ženklas. Sistema suranda komponentą pavadinimu galutiniai taškai ir ieško joje prasmės eurekaip, tada pakeičia jį į mūsų konfigūraciją. Bet kaip su skirtingomis aplinkomis? Norėdami tai padaryti, sukurkite nustatymų failą galutiniai taškai tokio tipo application.dev.yaml. Sistema savarankiškai, remdamasi failo plėtiniu, nusprendžia, kuriai aplinkai priklauso ši konfigūracija, ir įkelia ją:

Kūrėjo failo turinys:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

Tą pačią konfigūraciją galime sukurti savo paslaugų prievadams:

server.port: ${ports@order}.

Visi svarbūs nustatymai yra vienoje vietoje, todėl sumažėja klaidų tikimybė dėl išsibarsčiusių parametrų konfigūracijos failuose.

Sistemoje yra daug paruoštų vietos rezervavimo ženklų, pavyzdžiui, galite gauti katalogo, kuriame yra konfigūracijos failas, pavadinimą ir jam priskirti:

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

Dėl šios priežasties konfigūracijoje nereikia papildomai nurodyti programos pavadinimo, be to, jis gali būti dedamas į bendrą modulį, pavyzdžiui, toje pačioje eurekoje:

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

Konfigūracijos failas kad bus sumažintas iki vienos eilutės:

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

Jei mums nereikia jokių pirminės konfigūracijos nustatymų, galime jį nurodyti savo konfigūracijoje ir jis bus pritaikytas generuojant. Tai yra, jei dėl kokių nors priežasčių mums reikia unikalaus užsakymo paslaugos pavadinimo, mes tiesiog paliksime parametrą pavasario.paraiškos.pavadinimas.

Tarkime, kad prie paslaugos reikia pridėti pasirinktinius registravimo nustatymus, kurie saugomi atskirame faile, pvz., logback.xml. Sukurkime atskirą nustatymų grupę:

Pagrindinėje konfigūracijoje nurodysime sistemą, kur įdėti reikalingą registravimo nustatymų failą, naudodami rezervuotąją vietą @ConfigDir:

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

Byloje logback.xml konfigūruojame standartinius priedus, kuriuose taip pat gali būti vietos rezervavimo ženklų, kuriuos sistema pakeis generuojant konfigūracijas, pavyzdžiui:

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

Pridedant importą prie paslaugų konfigūracijų atsijungimas, automatiškai gauname sukonfigūruotą registravimą kiekvienai paslaugai:

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

Atėjo laikas išsamiau susipažinti su visais turimais sistemos rezervavimo ženklais:

${this@env} - grąžina esamos aplinkos pavadinimą.
${…@name} — grąžina komponento pavadinimą.
${…@configDir} — grąžina visą kelią į komponento konfigūracijos katalogą.
${…@resultDir} — grąžina visą kelią į komponento paskirties katalogą (gautieji failai bus patalpinti į šį katalogą).
${this@configRoot} — grąžina visą kelią į konfigūracijos saugyklos šakninį katalogą.

Sistema taip pat leidžia gauti aplinkos kintamuosius, pavyzdžiui, kelią į java:
${env@JAVA_HOME}
Arba, nes sistema parašyta JAVA, galime gauti sistemos kintamuosius, panašius į skambutį Sistema::getProperty naudojant tokią struktūrą:
${[apsaugotas el. paštu]}
Verta paminėti plėtinio kalbos palaikymą Pavasaris EL. Konfigūracijoje taikomos šios išraiškos:

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

o vietinius kintamuosius galite naudoti konfigūracijos failuose naudodami išraišką #var:

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

Taigi sistema yra gana galingas mikropaslaugų koregavimo ir lanksčios konfigūracijos įrankis. Karkasas puikiai atlieka savo pagrindinę užduotį - nustatymuose pašalina kopijavimo ir įklijavimo funkciją, sujungia nustatymus ir dėl to sumažina galimas klaidas, tuo pačiu leidžiant lengvai derinti konfigūracijas ir keisti jas skirtingoms aplinkoms.

Jei jus domina šis karkasas, rekomenduoju apsilankyti oficialiame jos puslapyje ir susipažinti su visa informacija dokumentacija, arba pasinerkite į šaltinius čia.

Šaltinis: www.habr.com