Menaxhoni me lehtësi konfigurimet e mikroshërbimeve me microconfig.io

Një nga sfidat kryesore në zhvillimin dhe më pas funksionimin e mikroshërbimeve është konfigurimi i duhur dhe i saktë i instancave të tyre. Sipas mendimit tim, një kornizë e re mund të ndihmojë me këtë. microconfig.ioJu lejon të zgjidhni disa detyra rutinë të konfigurimit të aplikacionit në mënyrë mjaft elegante.

Nëse keni shumë mikroshërbime, secila me skedarin/skedarët e vet të konfigurimit, ekziston një rrezik i lartë për të futur një gabim në njërën prej tyre, i cili mund të jetë shumë i vështirë për t'u kapur pa trajnimin e duhur dhe një sistem regjistrimi. Qëllimi kryesor i kornizës është të minimizojë parametrat e konfigurimit të instancave të dyfishta, duke zvogëluar kështu mundësinë e futjes së gabimeve.

Le të shohim një shembull. Le të supozojmë se ekziston një aplikacion i thjeshtë me një skedar konfigurimi. yamlKy mund të jetë çdo mikroshërbim në çdo gjuhë. Le të shohim se si mund të zbatohet framework-u në këtë shërbim.

Por së pari, për lehtësi më të madhe, le të krijojmë një projekt bosh në Idea IDE, pasi të kemi instaluar më parë plugin-in microconfig.io:

Ne konfigurojmë konfigurimin e nisjes së shtojcës; mund të përdorni konfigurimin e parazgjedhur, si në pamjen e ekranit më sipër.

Shërbimi ynë quhet porosi, kështu që në një projekt të ri do të krijojmë një strukturë të ngjashme:

Vendosni skedarin e konfigurimit në dosjen me emrin e shërbimit - aplikacion.yamlTë gjitha mikroserviset funksionojnë në një lloj mjedisi, kështu që përveç krijimit të vetë konfigurimit të shërbimit, duhet të përshkruajmë vetë mjedisin: për këtë, do të krijojmë një dosje zarfa dhe shtoni një skedar me emrin e mjedisit tonë të punës. Në këtë mënyrë, framework-u do të krijojë skedarë konfigurimi për shërbimet në mjedis. dev, meqenëse ky parametër është vendosur në cilësimet e plugin-it.

Struktura e skedarit dev.yaml do të jetë mjaft e thjeshtë:

mainorder:
    components:
         - order

Korniza funksionon me konfigurime që janë të grupuara së bashku. Për shërbimin tonë, le të zgjedhim një emër grupi. porosia kryesoreKorniza gjen çdo grup të tillë aplikacionesh në skedarin e mjedisit dhe krijon konfigurime për të gjitha ato, të cilat i gjen në dosjet përkatëse.

Në vetë skedarin e cilësimeve të shërbimit Për Le të specifikojmë vetëm një parametër për momentin:

spring.application.name: order

Tani le ta hapim plugin-in, dhe ai do të gjenerojë konfigurimin e kërkuar për shërbimin tonë në rrugën e specifikuar në vetitë:

mund ia dal mbanë dhe pa instaluar ndonjë plugin, thjesht shkarkoni shpërndarjen e framework-ut dhe ekzekutojeni atë nga rreshti i komandës.
Kjo zgjidhje është e përshtatshme për t’u përdorur në një server ndërtimi.

Vlen të përmendet se korniza e kupton në mënyrë të përkryer pronë sintaksë, domethënë, skedarë të rregullt të vetive që mund të përdoren së bashku në yaml konfigurime.

Le të shtojmë edhe një shërbim tjetër pagesë dhe ta ndërlikojnë atë ekzistues në të njëjtën kohë.
В Për:

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

В pagesë:

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

Problemi kryesor me këto konfigurime është sasia e madhe e kopjimit dhe ngjitjes në cilësimet e shërbimit. Le të shohim se si framework-u mund të ndihmojë në eliminimin e kësaj. Le të fillojmë me më të dukshmen: praninë e konfigurimit. Eureka në përshkrimin e secilit mikroservis. Le të krijojmë një drejtori të re me një skedar cilësimesh dhe të shtojmë një konfigurim të ri në të:

Dhe tani do t'i shtojmë një rresht secilit prej projekteve tona. #përfshi eurekën.

Korniza do të gjejë automatikisht konfigurimin eureka-s dhe do ta kopjojë atë në skedarët e konfigurimit të shërbimit, por një konfigurim i veçantë eureka nuk do të krijohet pasi ne nuk e specifikojmë atë në skedarin e mjedisit. dev.yamlShërbim Për:

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

Gjithashtu mund t'i zhvendosim cilësimet e bazës së të dhënave në një konfigurim të veçantë duke ndryshuar rreshtin e importimit në #përfshij eurekën, orakullin.

Vlen të përmendet se framework gjurmon çdo ndryshim të bërë gjatë rigjenerimit të skedarëve të konfigurimit dhe e vendos atë në një skedar të veçantë pranë skedarit kryesor të konfigurimit. Hyrja në regjistrin e tij duket kështu: "Prona e ruajtur 1 ndryshon në order/diff-application.yamlKjo ju lejon të zbuloni shpejt ndryshimet në skedarët e mëdhenj të konfigurimit.

Heqja e pjesëve të përbashkëta të konfigurimit eliminon shumë kopjim-ngjitje të panevojshme, por nuk lejon konfigurim fleksibël për mjedise të ndryshme - pikat fundore të shërbimeve tona janë me një skaj dhe të koduara fort, gjë që është keq. Le të përpiqemi ta eliminojmë këtë.

Një zgjidhje e mirë është që të gjitha pikat fundore të mbahen në një konfigurim të vetëm që të tjerët mund t'i referohen. Për këtë qëllim, korniza ka zbatuar mbështetje për mbajtësit e vendeve. Ja se si do të ndryshonte skedari i konfigurimit. Eureka:

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

Tani le të shohim se si funksionon ky vendmbajtës. Sistemi gjen një komponent të quajtur pikat përfundimtare dhe kërkon kuptim në të eurokaip, dhe pastaj e fut atë në konfigurimin tonë. Po mjediset e ndryshme? Për këtë, le të krijojmë një skedar cilësimesh në pikat përfundimtare të llojit të mëposhtëm application.dev.yamlKorniza në mënyrë të pavarur, bazuar në zgjerimin e skedarit, vendos se cilit mjedis i përket një konfigurim i caktuar dhe e ngarkon atë:

Përmbajtja e skedarit të zhvillimit:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

Ne mund të krijojmë të njëjtën konfigurim për portet e shërbimeve tona:

server.port: ${ports@order}.

Të gjitha cilësimet e rëndësishme janë të vendosura në një vend, duke zvogëluar kështu mundësinë e gabimeve për shkak të shpërndarjes së parametrave nëpër skedarët e konfigurimit.

Korniza ofron shumë vendmbajtës të gatshëm, për shembull, mund të merrni emrin e drejtorisë ku ndodhet skedari i konfigurimit dhe ta caktoni atë:

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

Falë kësaj, nuk ka nevojë të specifikoni shtesë emrin e aplikacionit në konfigurim, dhe ai gjithashtu mund të zhvendoset në një modul të përbashkët, për shembull, në të njëjtën eureka:

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

Skedari i konfigurimit Për do të reduktohet në një rresht:

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

Nëse nuk na duhet një cilësim nga konfigurimi prind, mund ta specifikojmë atë në konfigurimin tonë dhe do të zbatohet gjatë gjenerimit. Pra, nëse për ndonjë arsye na duhet një emër unik për shërbimin e porosisë, thjesht do ta lëmë parametrin. spring.application.name.

Le të themi se duhet të shtoni cilësime të personalizuara të regjistrimit në shërbim, të cilat ruhen në një skedar të veçantë, për shembull, logback.xmlLe të krijojmë një grup të veçantë cilësimesh për të:

Në konfigurimin bazë, ne do t'i tregojmë kornizës se ku duhet të vendosë skedarin e kërkuar të cilësimeve të regjistrimit duke përdorur një vendmbajtës. @ConfigDir:

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

Në dosje logback.xml Ne konfigurojmë shtojcat standarde, të cilat nga ana tjetër mund të përmbajnë edhe vendmbajtës që korniza do të ndryshojë gjatë gjenerimit të konfigurimit, për shembull:

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

Shtimi i importit në konfigurimet e shërbimit logback, ne marrim automatikisht regjistrimin e konfiguruar për secilin shërbim:

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

Është koha të hedhim një vështrim më të afërt në të gjithë mbajtësit e vendeve të disponueshëm të kornizës:

${this@env} — kthen emrin e mjedisit aktual.
${…@name} — kthen emrin e komponentit.
${…@configDir} — kthen rrugën e plotë për në drejtorinë e konfigurimit të komponentit.
${…@resultDir} — kthen rrugën e plotë për në drejtorinë e destinacionit të komponentit (skedarët që rezultojnë do të vendosen në këtë drejtori).
${this@configRoot} — kthen rrugën e plotë për në drejtorinë rrënjë të ruajtjes së konfigurimit.

Sistemi gjithashtu ju lejon të merrni variabla mjedisi, të tilla si rruga për në Java:
${env@JAVA_HOME}
Ose, meqenëse korniza është shkruar në JAVA, mund të marrim variabla sistemi të ngjashme me thirrjen System::getProperty duke përdorur një ndërtim të këtij lloji:
${system@os.name}
Vlen të përmendet mbështetja e gjuhës së zgjerimit Pranvera ELShprehjet e mëposhtme janë të zbatueshme në konfigurim:

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

dhe mund të përdorni variabla lokale në skedarët e konfigurimit duke përdorur shprehjen #var:

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

Kështu, framework-u është një mjet mjaft i fuqishëm për rregullimin e imët dhe konfigurimet fleksibile të mikroshërbimeve. Framework-u përmbush në mënyrë të përkryer qëllimin e tij kryesor - eliminimin e konfigurimeve të kopjimit dhe ngjitjes, konsolidimin e cilësimeve dhe, si rezultat, minimizimin e gabimeve të mundshme - duke lejuar kombinime të lehta konfigurimi dhe personalizim për mjedise të ndryshme.

Nëse jeni të interesuar për këtë kornizë, ju rekomandoj të vizitoni faqen e saj zyrtare dhe të njiheni me të plotë. dokumentacionin, ose gërmoni në kodin burimor këtu.

Burimi: www.habr.com