Könnyen kezelheti a mikroszolgáltatási konfigurációkat a microconfig.io segítségével

A mikroszolgáltatások fejlesztésének és későbbi működtetésének egyik fő problémája a példányok hozzáértő és pontos konfigurálása. Véleményem szerint egy új keretrendszer segíthet ezen microconfig.io. Lehetővé teszi néhány rutin alkalmazáskonfigurációs feladat meglehetősen elegáns megoldását.

Ha sok mikroszolgáltatásod van, és mindegyikhez saját konfigurációs fájl/fájl tartozik, akkor nagy a valószínűsége annak, hogy valamelyikben hibát követ el, amit megfelelő szakértelem és naplózó rendszer nélkül nagyon nehéz elkapni. A keretrendszer fő feladata, hogy minimalizálja a duplikált példánykonfigurációs paramétereket, ezáltal csökkentve a hiba hozzáadásának valószínűségét.

Nézzünk egy példát. Tegyük fel, hogy van egy egyszerű alkalmazásunk konfigurációs fájllal yaml. Ez lehet bármilyen mikroszolgáltatás bármilyen nyelven. Nézzük meg, hogyan alkalmazható a keretrendszer erre a szolgáltatásra.

De először a nagyobb kényelem érdekében hozzunk létre egy üres projektet az Idea IDE-ben, miután telepítettük a microconfig.io beépülő modult:

Beállítjuk a plugin indító konfigurációját, használhatja az alapértelmezett konfigurációt, mint a fenti képernyőképen.

Szolgáltatásunk a rend neve, majd egy új projektben hasonló struktúrát hozunk létre:

Helyezze a konfigurációs fájlt a szolgáltatásnévvel rendelkező mappába - alkalmazás.yaml. Minden mikroszolgáltatás elindul valamilyen környezetben, így a szolgáltatás konfigurációjának elkészítése mellett magát a környezetet is le kell írni: ehhez készítünk egy mappát envs és adjunk hozzá egy fájlt a munkakörnyezetünk nevével. Így a keretrendszer konfigurációs fájlokat hoz létre a környezetben lévő szolgáltatásokhoz dev, mivel ez a paraméter a bővítmény beállításaiban van beállítva.

Fájlszerkezet dev.yaml elég egyszerű lesz:

mainorder:
    components:
         - order

A keretrendszer csoportosított konfigurációkkal működik. Szolgáltatásunkhoz válasszon nevet a csoportnak főrend. A keretrendszer minden ilyen alkalmazáscsoportot megkeres a környezetfájlban, és mindegyikhez konfigurációt hoz létre, amelyeket a megfelelő mappákban talál meg.

Magában a szolgáltatásbeállítási fájlban érdekében Egyelőre csak egy paramétert adjunk meg:

spring.application.name: order

Most futtassuk a beépülő modult, és a tulajdonságokban megadott elérési út szerint generálja a szolgáltatásunkhoz szükséges konfigurációt:

képes összejönni és bővítmény telepítése nélkül egyszerűen letöltheti a keretrendszer disztribúcióját, és futtathatja azt a parancssorból.
Ez a megoldás build szerveren való használatra alkalmas.

Érdemes megjegyezni, hogy a keret tökéletesen megérti ingatlan szintaxis, vagyis a szokásos tulajdonságfájlok, amelyekben együtt használhatók yaml konfigurációk.

Adjunk hozzá még egy szolgáltatást fizetés és bonyolítja a meglévőt.
В érdekében:

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

В fizetés:

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

A fő probléma ezekkel a konfigurációkkal a nagy mennyiségű másolás-beillesztés jelenléte a szolgáltatási beállításokban. Lássuk, hogyan segít a keret megszabadulni tőle. Kezdjük a legnyilvánvalóbbal - a konfiguráció jelenlétével eureka az egyes mikroszolgáltatások leírásában. Hozzunk létre egy új könyvtárat a beállítási fájllal, és adjunk hozzá egy új konfigurációt:

És most adjuk hozzá a sort minden projektünkhöz #include eureka.

A keretrendszer automatikusan megkeresi az eureka konfigurációt és bemásolja a szolgáltatás konfigurációs fájljaiba, míg külön eureka konfiguráció nem jön létre, mivel azt nem adjuk meg a környezetfájlban dev.yaml. Szolgáltatás érdekében:

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

Az adatbázis-beállításokat külön konfigurációba is áthelyezhetjük, ha az importálási sort a következőre változtatjuk #include eureka, oracle.

Érdemes megjegyezni, hogy a keretrendszer minden változást nyomon követ a konfigurációs fájlok újragenerálásakor, és egy speciális fájlba helyezi a fő konfigurációs fájl mellett. A bejegyzés a naplójában így néz ki: „A Tárolt 1 tulajdonság megváltozik a következőre: order/diff-application.yaml" Ez lehetővé teszi a nagy konfigurációs fájlok változásainak gyors észlelését.

A konfiguráció gyakori részeinek eltávolítása lehetővé teszi, hogy megszabaduljon sok felesleges másolástól-beillesztéstől, de nem teszi lehetővé a különböző környezetekhez való rugalmas konfiguráció létrehozását - szolgáltatásaink végpontjai egyediek és kemény kódolásúak, ez rossz. Próbáljuk meg ezt eltávolítani.

Jó megoldás az lenne, ha az összes végpontot egy konfigurációban tartanák, amelyre mások hivatkozhatnak. Ebből a célból a helyőrzők támogatása került be a keretbe. Így fog megváltozni a konfigurációs fájl eureka:

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

Most pedig nézzük meg, hogyan működik ez a helyőrző. A rendszer talál egy komponenst végpontok és értelmet keres benne eurekaip, majd behelyettesíti a konfigurációnkba. De mi a helyzet a különböző környezetekkel? Ehhez hozzon létre egy beállítási fájlt végpontok a következő típus application.dev.yaml. A keretrendszer a fájlkiterjesztés alapján önállóan dönti el, hogy ez a konfiguráció melyik környezethez tartozik, és betölti:

A fejlesztői fájl tartalma:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

Szolgáltatásaink portjaihoz ugyanazt a konfigurációt tudjuk létrehozni:

server.port: ${ports@order}.

Minden fontos beállítás egy helyen található, ezáltal csökkentve a konfigurációs fájlok szétszórt paraméterei miatti hibák valószínűségét.

A keretrendszer számos kész helyőrzővel rendelkezik, például megkaphatja annak a könyvtárnak a nevét, amelyben a konfigurációs fájl található, és hozzárendelheti:

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

Ennek köszönhetően nincs szükség az alkalmazásnév további megadására a konfigurációban, és elhelyezhető egy közös modulban is, például ugyanabban a eurekában:

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

A konfigurációs fájl érdekében egy sorra csökken:

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

Ha nincs szükségünk semmilyen beállításra a szülőkonfigurációból, akkor azt megadhatjuk a konfigurációnkban, és ez a generálás során kerül alkalmazásra. Vagyis ha valamilyen oknál fogva egyedi névre van szükségünk a rendelési szolgáltatáshoz, akkor csak hagyjuk a paramétert tavaszi.alkalmazás.név.

Tegyük fel, hogy egyéni naplózási beállításokat kell hozzáadnia a szolgáltatáshoz, amelyek egy külön fájlban vannak tárolva, pl. logback.xml. Hozzunk létre egy külön beállításcsoportot hozzá:

Az alapkonfigurációban helyőrzővel megmondjuk a keretrendszernek, hogy hova helyezzük el a szükséges naplózási beállításokat @ConfigDir:

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

Fájlban logback.xml szabványos hozzáfűzőket konfigurálunk, amelyek viszont olyan helyőrzőket is tartalmazhatnak, amelyeket a keret megváltoztat a konfigurációk generálása során, például:

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

Importálás hozzáadásával a szolgáltatáskonfigurációkhoz logback, automatikusan megkapjuk a konfigurált naplózást minden egyes szolgáltatáshoz:

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

Itt az ideje, hogy részletesebben megismerkedjünk a keretrendszer összes elérhető helyőrzőjével:

${this@env} - az aktuális környezet nevét adja vissza.
${…@name} — az összetevő nevét adja vissza.
${...@configDir} — visszaadja az összetevő konfigurációs könyvtárának teljes elérési útját.
${…@resultDir} — visszaadja az összetevő célkönyvtárának teljes elérési útját (az eredményül kapott fájlok ebbe a könyvtárba kerülnek).
${this@configRoot} — visszaadja a konfigurációs tároló gyökérkönyvtárának teljes elérési útját.

A rendszer lehetővé teszi környezeti változók beszerzését is, például a java elérési útját:
${env@JAVA_HOME}
Akármelyik, mivel a keretrendszer bele van írva JAVA, a híváshoz hasonló rendszerváltozókat kaphatunk System::getProperty ehhez hasonló szerkezetet használva:
${[e-mail védett]}
Érdemes megemlíteni a kiterjesztési nyelv támogatását Tavasz EL. A következő kifejezések alkalmazhatók a konfigurációban:

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

és helyi változókat használhat a konfigurációs fájlokban a kifejezés használatával #var:

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

Így a keretrendszer meglehetősen hatékony eszköz a mikroszolgáltatások finomhangolására és rugalmas konfigurálására. A keretrendszer tökéletesen teljesíti fő feladatát - kiküszöböli a másolás-beillesztést a beállításokban, konszolidálja a beállításokat, és ennek eredményeként minimalizálja a lehetséges hibákat, miközben lehetővé teszi a konfigurációk egyszerű kombinálását és módosítását a különböző környezetekhez.

Ha érdekli ez a keret, annak ajánlom, hogy látogassa meg hivatalos oldalát és ismerkedjen meg a teljességgel dokumentáció, vagy ássunk bele a forrásokba itt.

Forrás: will.com