Një nga problemet kryesore gjatë zhvillimit dhe përveç operimit të mikroshërbimeve është konfigurimi i saktë dhe i kujdesshëm i instancave të tyre. Këtu, sipas mendimit tim, mund të ndihmojë një framework të ri . Ai lejon të zgjidhni në mënyrë elegante disa detyra rutinë të konfigurimit të aplikacioneve.
Nëse keni shumë mikroshërbime dhe secili prej tyre vjen me skedarin/ska e tij të konfigurimit, atëherë ka një probabilitet të madh për të bërë një gabim në një prej tyre, të cilin pa përvojë dhe sistem regjistrimi mund të jetë shumë e vështirë ta kapni. Detyra kryesore që ka për qëllim framework-u është të minimizojë parametrat e përsëritur të konfigurimit të instancës, duke reduktuar kështu probabilitetin e shtimit të një gabimi.
Le të shqyrtojmë një shembull. Supozoni se ka një aplikacion të thjeshtë me një skedar konfigurimi yaml. Ky mund të jetë çdo mikroshërbim në çdo gjuhë. Le të shohim se si mund të aplikohet framework-u në këtë shërbim.
Por më parë, për më shumë lehtësi, le të krijojmë një projekt bosh në Idea IDE, duke instaluar paraprakisht plugin-in microconfig.io:
Konfiguroni konfigurimin e nisjes së pluginit, mund të përdorni konfigurimin e parazgjedhur, siç është në pamjen e sipërme.
Shërbimi ynë quhet order, kështu që në projektin e ri le të krijojmë një strukturë të tillë:
NĂ« dosjen me emrin e shĂ«rbimit vendosim skedarin e konfigurimit â application.yaml. TĂ« gjithĂ« mikroshĂ«rbimet ekzekutohen nĂ« njĂ« ambient, kĂ«shtu qĂ«, pĂ«rveç krijimit tĂ« konfigut tĂ« shĂ«rbimit vetĂ«, duhet tĂ« pĂ«rshkruajmĂ« edhe ambientin: pĂ«r kĂ«tĂ«, le tĂ« krijojmĂ« njĂ« dosje envs dhe tĂ« shtojmĂ« nĂ« tĂ« njĂ« skedar me emrin e ambientit tonĂ« tĂ« punĂ«s. NĂ« kĂ«tĂ« mĂ«nyrĂ«, framework-u do tĂ« krijojĂ« skedarĂ«t e konfigurimit pĂ«r shĂ«rbimet nĂ« ambientin dev, pasi nĂ« cilĂ«simet e pluginit Ă«shtĂ« pĂ«rcaktuar ky parametr.
Struktura e skedarit dev.yaml do të jetë mjaft e thjeshtë:
mainorder:
components:
- orderFramework-u punon me konfigurimet, të cilat janë të grupuara në grupe. Për shërbimin tonë le të zgjjedhim një emër për grupin mainorder. Framework-u gjen çdo grup të tillë aplikacionesh në skedarin e ambientit dhe krijon konfigurime për të gjithë ato që gjen në dosjet përkatëse.
Në vetë skedarin e konfigurimit të shërbimit order le të përcaktojmë për momentin vetëm një parametr:
spring.application.name: orderTani le të ekzekutojmë plug-in-in, dhe ai do të na gjenerojë konfigurimin e nevojshëm të shërbimit tonë sipas rrugës të caktuar në pronat:
Mund të dhe pa instaluar ndonjë plugin, thjesht duke shkarkuar distribucionin e kornizës dhe duke e nisur atë nga linja e komandës.
Ky zgjidhje është e përshtatshme për përdorim në serverin e ndërtimit.
Duhet theksuar se korniza e kupton shkëlqyeshëm property sintaksën, domethënë skedarët e zakonshëm të property, të cilët mund të përdoren së bashku me yaml konfigurimet.
Shtojmë një shërbim tjetër payment dhe e inkurajojmë njëkohësisht atë ekzistues.
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Ă« 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.100Problemi kryesor i kĂ«tyre konfigurimeve Ă«shtĂ« prania e njĂ« numri tĂ« madh kopipaste nĂ« konfigurimet e shĂ«rbimeve. Le tĂ« shohim se si korniza na ndihmon tĂ« shpĂ«tojmĂ« prej saj. TĂ« fillojmĂ« me atĂ« mĂ« tĂ« dukshme â prania e konfigurimit eureka nĂ« pĂ«rshkrimin e çdo mikroshĂ«rbimi. TĂ« krijojmĂ« njĂ« katalog tĂ« ri me njĂ« skedar konfigurimi dhe tĂ« shtojmĂ« nĂ« tĂ« njĂ« konfigurim tĂ« ri:
Dhe në çdo një nga projektet tona tani do të shtojmë rreshtin #include eureka.
Korniza automatikisht do të gjejë konfigurimin e eureka dhe do ta kopjojë atë në skedarët konfigurues të shërbimeve, duke mos krijuar kështu një konfigurim të veçantë eureka, pasi nuk do ta përcaktojmë atë në skedarin e mjedisit dev.yaml. Shërbimi order:
#include eureka
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100Gjithashtu mund të nxjerrim konfigurimet e bazës së të dhënave në një konfigurim të veçantë, duke e ndryshuar rreshtin e importit në #include eureka, oracle.
Duhet theksuar se çdo ndryshim gjatĂ« ripĂ«rpunimit tĂ« skedarĂ«ve konfigurues korniza e ndjek dhe e vendos nĂ« njĂ« skedĂ« tĂ« veçantĂ« pranĂ« skedarit kryesor tĂ« konfigurimit. ShĂ«nimi nĂ« logun e tij duket kĂ«shtu: âRuajtĂ«n 1 ndryshim tĂ« pronĂ«s nĂ« order/diff-application.yamlâ. Kjo lejon zbulimin e shpejtĂ« tĂ« ndryshimeve nĂ« skedarĂ«t e mĂ«dhenj tĂ« konfigurimit.
Nxjerrja e pjesĂ«ve tĂ« zakonshme tĂ« konfigurimit lejon shpĂ«timin nga shumĂ« kopipaste tĂ« panevojshme, por nuk lejon krijimin fleksibĂ«l tĂ« konfigurimeve pĂ«r mjedise tĂ« ndryshme â endpointet e shĂ«rbimeve tona janĂ« unike dhe tĂ« ngurtĂ«, kjo Ă«shtĂ« e keqe. Le tĂ« provojmĂ« ta heqim kĂ«tĂ«.
Një zgjidhje e mirë do të ishte të mbaheshin të gjitha endpointet në një konfigurim të vetëm, në të cilin mund të referohen të tjerët. Për këtë, korniza ka integruar mbështetje për placeholders. Këtu si do të ndryshojë skedari i konfigurimit eureka:
client:
serviceUrl:
defaultZone: http://${endpoints@eurekaip}:6782/eureka/Tani le tĂ« shikojmĂ« se si funksionon ky placeholder. Sistemi gjen komponentin me emrin endpoints dhe kĂ«rkon aty vlerĂ«n eurekaip, pasi ai fut nĂ« konfigurimin tonĂ«. Por si duhet 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. Ăadra vetĂ«, sipas zgjerimit tĂ« skedarit, merr vendim se pĂ«r cilin mjedis Ă«shtĂ« kjo konfigurim dhe e ngarkon atĂ«:
PĂ«rmbajtja e skedarit dev:
eurekaip: 192.89.89.111
dbip: 192.168.0.100Ne mund të krijojmë një konfigurim të tillë edhe për portat e shërbimeve tona:
server.port: ${ports@order}.Të gjitha cilësimet e rëndësishme janë në një vend, duke e zvogëluar kështu mundësinë e gabimeve për shkak të parametrave të shpërndarë në skedarët e konfigurimit.
Ăadra ofron shumĂ« plaseholder tĂ« gatshme, pĂ«r shembull, mund tĂ« merrni emrin e direktorisĂ« ku ndodhet skedari i konfigurimit dhe ta caktoni:
#include eureka, oracle
server.port: ${ports@order}
spring.application.name: ${this@name}Kështu, nuk është e nevojshme të caktoni emrin e aplikacionit në konfigurim dhe gjithashtu mund ta nxirrni atë në një modul të përbashkët, për shembull, në të njëjtin eureka:
client:
serviceUrl:
defaultZone: http://${endpoints@eurekaip}:6782/eureka/
spring.application.name: ${this@name}Skedari i konfigurimit order do të shkurtuar në një rresht:
#include eureka, oracle
server.port: ${ports@order}Në rastin kur ndonjë cilësim nga konfigurimi i prindit nuk na nevojitet, mund ta caktojmë atë në konfigurimin tonë dhe ajo do të zbatohet gjatë gjenerimit. Pra, nëse për ndonjë arsye na nevojitet një emër unik për shërbimin order, thjesht do ta lëmë parametrin spring.application.name.
Le të themi, në shërbim është e nevojshme të shtoni cilësime të personalizuara të regjistrimit, të cilat ruajtohen në një skedar të veçantë, për shembull, logback.xml. Të krijojmë një grup të veçantë konfigurimesh për të:
Në konfigurimin bazë do të caktojmë çadrës se ku të vendosë skedarin tonë të nevojshëm të konfigurimit të regjistrimit me ndihmën e plaseholderit @ConfigDir:
microconfig.template.logback.fromFile: ${logback@configDir}/logback.xmlNë skedar logback.xml konfigurojmë appenders standarde, të cilat gjithashtu mund të përmbajnë plaseholder, të cilat çadra do t'i ndryshojë gjatë gjenerimit të konfigurlimeve, për shembull:
logs/${this@name}.logDuke shtuar në konfigurimet e shërbimeve importin logback, automatikisht marrim regjistrim të konfiguruar për çdo shërbim:
#include eureka, oracle, logback
server.port: ${ports@order}Ka ardhur koha për t'u njohur më në detaje me të gjitha plaseholderat e disponueshëm të çadrës:
${this@env} â kthehet emri i mjedisit aktual.
${âŠ@name} â kthehet emri i komponentit.
${âŠ@configDir} â kthen rrugĂ«n e plotĂ« nĂ« katalogun e komponentit config.
${âŠ@resultDir} kthen jep rrugĂ«n e plotĂ« pĂ«r katalogun e destinacionit tĂ« komponentit (katalogu ku do tĂ« vendosen skedarĂ«t e pranuar).
${this@configRoot} kthen rrugën e plotë për katalogun e rrënjës së depozitës së konfigurimeve.
Gjithashtu, sistemi lejon marrjen e variablave të mjedisit, për shembull rruga në java:
${env@JAVA_HOME}
Ose, pasi struktura është shkruar në JAVA, mund të marrim variablat sistemorë të ngjashme me thirrjen System::getProperty nëpërmjet një ndërtese të tillë:
${system@os.name}
Duhet përmendur mbështetja për gjuhën e zgjerimeve Spring EL. Në konfigurim përdoren shprehje të ngjashme:
connection.timeoutInMs: #{5 * 60 * 1000}
datasource.maximum-pool-size: #{${this@datasource.minimum-pool-size} + 10} dhe mund të përdoren variabla 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}/errorKĂ«shtu, struktura paraqet njĂ« instrument tĂ« fuqishĂ«m pĂ«r konfigurimin e hollĂ«sishĂ«m dhe fleksibĂ«l tĂ« mikroshĂ«rbimeve. Struktura e realizon mjaft mirĂ« detyrĂ«n e saj kryesore â eliminimin e kopjeve nĂ« konfigurime, bashkimin e konfigurimeve dhe si pasojĂ« minimizimin e mundĂ«sive pĂ«r gabime, ndĂ«rkohĂ« qĂ« lejon lehtĂ«sisht kombinimin e konfigurimeve dhe ndryshimin pĂ«r mjedise tĂ« ndryshme.
Nëse jeni të interesuar për këtë strukturë, rekomandoj të vizitoni faqen e saj zyrtare dhe të njiheni me të gjithë , ose të hulumtoni në kodin burimor .
Burimi: habr.com
