Një nga problemet kryesore gjatë zhvillimit dhe operimit të mëvonshëm të mikroshërbjeve është përgatitja e saktë dhe e kujdesshme e instancave të tyre. Mendoj se një framë të ri mund të ndihmojë në këtë, . Ai lejon zgjidhjen elegante të disa detyrave rutinë të konfigurimit të aplikacioneve.
Nëse keni shumë mikroshërbje dhe secili prej tyre vjen me skedarin/skedarët e tij të konfigurimit, ka një probabilitet të madh të bëni një gabim në njërin prej tyre, të cilin pa përvojë dhe një sistem regjistrimi mund ta zbuloni shumë vështirë. Qëllimi kryesor i këtij frami është të minimizojë parametrat e përsëritur të konfigurimit të instancave, duke zvogëluar kështu mundësinë e shtimit të gabimeve.
Le të shohim një shembull. Supozojmë se ka një aplikacion të thjeshtë me një skedar konfigurimi yaml. Mund të jetë çdo mikroshërbje në çdo gjuhë. Le të shohim se si mund të aplikojmë këtë framë në këtë shërbim.
Por së pari, për më shumë lehtësi, le të krijojmë një projekt të zbrazët në Idea IDE, duke instaluar paraprakisht plagin microconfig.io:

Jemi në procesin e konfigurimit të fillimit të plugins, mund të përdorim konfigurimin e paracaktuar, siç është në screenshot-in e mësipërm.
Shërbimi ynë quhet order, kështu që në projektin e ri do të krijojmë një strukturë të ngjashme:

NĂ« dosjen me emrin e shĂ«rbimit vendosim skedarin e konfiguracionit â application.yaml. TĂ« gjitha mikroshĂ«rbimet fillojnĂ« nĂ« njĂ« mjedis tĂ« caktuar, kĂ«shtu qĂ«, pĂ«rveç krijimit tĂ« konfigurimit tĂ« vet shĂ«rbimit, nevojitet tĂ« pĂ«rshkruajmĂ« edhe mjedisin: pĂ«r kĂ«tĂ« do tĂ« krijojmĂ« dosjen envs dhe do tĂ« shtojmĂ« nĂ« tĂ« njĂ« skedar me emrin e mjedisit tonĂ« tĂ« punĂ«s. KĂ«shtu, framework-u do tĂ« krijojĂ« skedarĂ«t e konfigurimit pĂ«r shĂ«rbimet nĂ« mjedisin dev, pasi nĂ« cilĂ«simet e plugin-it Ă«shtĂ« vendosur pikĂ«risht ky parametr.
Struktura e skedarit dev.yaml do të jetë mjaft e thjeshtë:
mainorder:
components:
- orderFramework-u punon me konfigurime që janë të bashkuara në grupe. Për shërbimin tonë do të zgjedhim një emër për grupin mainorder. Framework-u gjen çdo grup të tillë aplikacionesh në skedarin e mjediseve dhe krijon për të gjitha ato konfigurimet që i gjendet në dosjet përkatëse.
Në vetë skedarin e cilësimeve të shërbimit order do të shënojmë për tani vetëm një parametër:
spring.application.name: orderTani do të aktivizojmë plugin-in, dhe ai do të na gjenerojë konfigurimin e nevojshëm të shërbimit tonë në rrugën e specifikuar në pronat:

Mund edhe pa instaluar plugin-in, thjesht duke shkarkuar shpërndarjen e framework-ut dhe duke e ekzekutuar atë nga linja e komandës.
Ky zgjidhje do të jetë e përshtatshme për përdorim në serverin e ndërtimit.
Duhet theksuar se framework-u kupton shumë mirë pronat sintaksën, pra skedarët e zakonshëm të pronave, që mund të përdoren së bashku me yaml konfigurimet.
Le të shtojmë një shërbim tjetër pagesë edhe të komplikuar atë ekzistuesin njëkohësisht.
NĂ« 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.100Në 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.100Problemi kryesor me kĂ«to konfigurime Ă«shtĂ« prania e njĂ« sĂ«rĂ« tĂ« madhe kopipaste nĂ« cilĂ«simet e shĂ«rbimeve. Le tĂ« shohim se si framework-u do tĂ« na ndihmojĂ« tĂ« heqim dorĂ« nga ajo. TĂ« fillojmĂ« me atĂ« mĂ« tĂ« dukshme â prania e konfigurimit eureka nĂ« pĂ«rshkrimin e çdo mikroshĂ«rbimi. Do tĂ« krijojmĂ« njĂ« katalog tĂ« ri me njĂ« skedar cilĂ«simesh dhe do t'i shtojmĂ« njĂ« konfigurim tĂ« ri:

Dhe tani do të shtojmë rreshtin në çdo projekt tonin. #include eureka.
Framwork-u automatikisht do të gjejë konfigurimin e eureka dhe do ta kopjojë atë në skedarët e konfigurimit të shërbimeve, ndërsa një konfigurim i veçantë i eureka nuk do të krijohet, pasi ne nuk do ta citojmë atë në skedarin e ambientit. dev.yaml. Shërbimi order:
#include eureka
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100Gjithashtu mund të nxjerrim cilësimet e bazës së të dhënave në një konfigurim të veçantë, duke ndryshuar linjën e importit në #include eureka, oracle.
Duhet theksuar se çdo ndryshim gjatë rinovimit të skedarëve të konfigurimit framework-u e ndjek dhe e vendos atë në një skedë të veçantë afër skedarit kryesor të konfigurimit. Shënimi në log-un e tij duket si: "Ruajti 1 ndryshim në pronësi në order/diff-application.yaml". Kjo lejon të zbulojmë shpejt ndryshimet në skedarët e mëdhenj të konfigurimit.
Nxjerrja e pjesĂ«ve tĂ« pĂ«rbashkĂ«ta tĂ« konfigurimit lejon eliminimin e shumĂ« kopjeve tĂ« panevojshme, por nuk lejon krijimin fleksibĂ«l tĂ« konfigurimit pĂ«r ambiente tĂ« ndryshme â endpointet e shĂ«rbimeve tona janĂ« unike dhe tĂ« ngurtĂ«, kjo Ă«shtĂ« njĂ« problem. Le tĂ« pĂ«rpiqemi ta heqim kĂ«tĂ«.
Një zgjidhje e mirë do të ishte të mbahen të gjitha endpointet në një konfigurim të vetëm, në të cilin do të mund të referoheshin të tjerët. Për këtë, framework-u ka integruar mbështetje për placeholder-at. Kështu do të ndryshojë skedari i konfigurimit. eureka:
klienti:
shërbimiUrl:
zonaDefault: http://${endpoints@eurekaip}:6782/eureka/Tani le të shohim si funksionon ky placeholder. Sistemi gjen komponentin me emrin endpoints dhe kërkon në të vlerën eurekaip, pastaj e vendos në konfigurimin tonë. Por si të veprojmë me mjediset e ndryshme? Për këtë, do të krijojmë një skedar konfigurimi në endpoints formatin e mëposhtëm application.dev.yaml. Framework-u vetë, nga zgjerimi i skedarit, merr vendimin se për cilin mjedis po i përket kjo konfigurim dhe e ngarkon atë:

Përmbajtja e skedarit dev:
eurekaip: 192.89.89.111
dbip: 192.168.0.100Të njëjtën konfigurim mund ta krijojmë edhe për portet e shërbimeve tona:
server.port: ${ports@order}.Të gjitha cilësimet e rëndësishme ndodhen në një vend, duke reduktuar kështu mundësinë e gabimeve për shkak të parametra të shpërndarë në skedarët e konfigurimit.
Framework-u ofron shumë placeholder-e tashmë të gatshme, për shembull, mund të merrni emrin e dosjes në të cilën ndodhet skedari i konfigurimit dhe ta caktoni atë:
#include eureka, oracle
server.port: ${ports@order}
spring.application.name: ${this@name}Falë kësaj, nuk është e nevojshme të tregoni emrin e aplikacionit në konfigurim dhe gjithashtu mund ta nxirrni në një modul të përgjithshëm, për shembull, në të njëjtën eureka:
klienti:
shërbimiUrl:
zonaDefault: http://${endpoints@eurekaip}:6782/eureka/
emri.aplikacionit.spring: ${this@name}Skedari i konfigurimit order do të shkurtohet në një rresht:
#include eureka, oracle
server.port: ${ports@order}Në rast se ndonjë konfigurim nga konfigurimi prind nuk na nevojitet, ne mund ta specifikojmë atë në konfigurimin tonë dhe kjo do të aplikojë gjatë gjenerimit. Pra, nëse për ndonjë arsye na nevojitet një emër unik për shërbimin order, thjesht lëmë parametrin spring.application.name.
Le të themi se në shërbim ne duhet të shtojmë konfigurime të personalizuara për regjistrimin, të cilat ruhen në një skedë të veçantë, për shembull, logback.xml. Do të krijojmë një grup të veçantë konfigurimesh për të:

Në konfigurimin bazë do të tregojmë për framework-un ku të vendoset skeda jonë e nevojshme për regjistrimin duke përdorur placeholder-in @ConfigDir:
microconfig.template.logback.fromFile: ${logback@configDir}/logback.xmlNë skedar logback.xml konfigurojmë appenders standarde, të cilat gjithashtu mund të përmbajnë placeholder-e, të cilat framework-u do t'i ndryshojë gjatë gjenerimit të konfigurimeve, për shembull:
logs/${this@name}.logDuke shtuar në konfigurimet e shërbimeve importimin logback, ne automatikisht marrim regjistrimin e konfiguruar për çdo shërbim:
#include eureka, oracle, logback
server.port: ${ports@order}Ka ardhur koha të njohim më në detaje të gjitha placeholder-et e disponueshme të framework-ut:
${this@env} â kthen njĂ« emĂ«r tĂ« ambientit aktual.
${âŠ@name} â kthen emrin e komponentit.
${âŠ@configDir} â kthen rrugĂ«n e plotĂ« nĂ« katalogun e konfigurimit tĂ« komponentit.
${âŠ@resultDir} â kthen rrugĂ«n e plotĂ« nĂ« katalogun e vendosjes sĂ« komponentit (skedarĂ«t e marra do tĂ« vendosen nĂ« kĂ«tĂ« katalog).
${this@configRoot} â kthen rrugĂ«n e plotĂ« nĂ« katalogun rrĂ«njĂ«sor tĂ« ruajtjes sĂ« konfigurimeve.
Po ashtu, sistemi lejon marrjen e variablave të ambientit, për shembull rruga ndaj java:
${env@JAVA_HOME}
Ose, pasi që struktura është shkruar në JAVA, mund të marrim variablat sistemorë të ngjashëm me thirrjen System::getProperty nëpërmjet një konstrukti të tillë:
${system@os.name}
Për të përmendur mbështetje për gjuhën e zgjerimeve Spring EL. Në konfigurim aplikohen shprehje të ngjashme:
connection.timeoutInMs: #{5 * 60 * 1000}
datasource.maximum-pool-size: #{${this@datasource.minimum-pool-size} + 10} dhe mund të përdoren variablat lokale në skedarët e konfigurimit përmes shprehjes #var:
#var feedRoot: ${system@user.home}/feed
folder:
root: ${this@feedRoot}
success: ${this@feedRoot}/archive
error: ${this@feedRoot}/errorNĂ« kĂ«tĂ« mĂ«nyrĂ«, ky framework paraqet njĂ« instrument tĂ« fuqishĂ«m pĂ«r konfiguruar me fleksibilitet konfigurimet e mikrosherbimeve. Ai e kryen misionin e tij kryesor â eliminimin e kopjimeve tĂ« panevojshme nĂ« konfigurime, konsolidimin e konfigurimeve dhe si pasojĂ« minimizimin e mundĂ«sive pĂ«r gabime, duke lejuar njĂ«kohĂ«sisht kombinimin lehtĂ« tĂ« konfigurimeve dhe ndryshimin pĂ«r mjedise tĂ« ndryshme.
Nëse jeni të interesuar për këtë framework, ju rekomandoj të vizitoni faqen e tij zyrtare dhe të shihni informacionin e plotë , ose të hidhni një sy në kodin burimor .
Burimi: habr.com
