Hantera enkelt mikrotjänstkonfigurationer med microconfig.io

Ett av huvudproblemen i utvecklingen och efterföljande drift av mikrotjänster är den kompetenta och korrekta konfigurationen av deras instanser. Enligt min mening kan ett nytt ramverk hjälpa till med detta microconfig.io. Det låter dig lösa vissa rutinmässiga applikationskonfigurationsuppgifter ganska elegant.

Om du har många mikrotjänster, och var och en av dem kommer med sin egen konfigurationsfil/filer, så är det stor sannolikhet att du gör ett fel i en av dem, vilket kan vara mycket svårt att fånga utan rätt skicklighet och ett loggningssystem. Huvuduppgiften som ramverket sätter för sig själv är att minimera dubbletter av instanskonfigurationsparametrar, och därigenom minska sannolikheten för att ett fel läggs till.

Låt oss titta på ett exempel. Låt oss säga att vi har en enkel applikation med en konfigurationsfil jaml. Detta kan vara vilken mikrotjänst som helst på vilket språk som helst. Låt oss se hur ramverket kan tillämpas på den här tjänsten.

Men först, för större bekvämlighet, låt oss skapa ett tomt projekt i Idea IDE, efter att ha installerat plugin-programmet microconfig.io i det:

Vi ställer in plugin-startkonfigurationen, du kan använda standardkonfigurationen, som i skärmdumpen ovan.

Vår tjänst kallas order, sedan i ett nytt projekt kommer vi att skapa en liknande struktur:

Placera konfigurationsfilen i mappen med tjänstens namn - application.yaml. Alla mikrotjänster lanseras i någon form av miljö, så förutom att skapa en konfiguration för själva tjänsten är det nödvändigt att beskriva själva miljön: för detta skapar vi en mapp envs och lägg till en fil med namnet på vår arbetsmiljö. Således kommer ramverket att skapa konfigurationsfiler för tjänster i miljön dev, eftersom denna parameter är inställd i plugin-inställningarna.

Filstruktur dev.yaml det blir ganska enkelt:

mainorder:
    components:
         - order

Ramverket fungerar med konfigurationer som är grupperade. För vår tjänst, välj ett namn för gruppen huvudorder. Ramverket hittar varje sådan grupp av applikationer i miljöfilen och skapar konfigurationer för dem alla, som det hittar i motsvarande mappar.

I själva tjänstens inställningsfil beställa Låt oss bara specificera en parameter för tillfället:

spring.application.name: order

Låt oss nu köra plugin-programmet, och det kommer att generera den nödvändiga konfigurationen för vår tjänst enligt sökvägen som anges i egenskaperna:

Can klara sig och utan att installera ett plugin, ladda ner ramdistributionen och kör den från kommandoraden.
Denna lösning är lämplig för användning på en byggserver.

Det är värt att notera att ramverket förstår perfekt egenskapen syntax, det vill säga vanliga egenskapsfiler som kan användas tillsammans i jaml konfigurationer.

Låt oss lägga till en annan tjänst betalning och komplicera den befintliga.
В beställa:

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

В betalning:

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

Huvudproblemet med dessa konfigurationer är närvaron av en stor mängd copy-paste i tjänstinställningarna. Låt oss se hur ramverket hjälper till att bli av med det. Låt oss börja med det mest uppenbara - närvaron av konfiguration eureka i beskrivningen av varje mikrotjänst. Låt oss skapa en ny katalog med inställningsfilen och lägga till en ny konfiguration till den:

Och låt oss nu lägga till raden till vart och ett av våra projekt #inkludera eureka.

Ramverket kommer automatiskt att hitta eureka-konfigurationen och kopiera den till tjänstens konfigurationsfiler, medan en separat eureka-konfiguration inte kommer att skapas, eftersom vi inte kommer att specificera den i miljöfilen dev.yaml. Service beställa:

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

Vi kan också flytta databasinställningarna till en separat konfiguration genom att ändra importraden till #inkludera eureka, orakel.

Det är värt att notera att ramverket spårar varje ändring vid regenerering av konfigurationsfiler och placerar den i en speciell fil bredvid huvudkonfigurationsfilen. Posten i dess logg ser ut så här: "Lagrad 1 egenskap ändras till order/diff-application.yaml" Detta gör att du snabbt kan upptäcka ändringar i stora konfigurationsfiler.

Att ta bort gemensamma delar av konfigurationen gör att du kan bli av med en massa onödig copy-paste, men tillåter dig inte att flexibelt skapa en konfiguration för olika miljöer – ändpunkterna för våra tjänster är unika och hårdkodade, detta är dåligt. Låt oss försöka ta bort detta.

En bra lösning skulle vara att behålla alla slutpunkter i en konfiguration som andra kan referera till. För detta ändamål har stöd för platshållare införts i ramverket. Så här kommer konfigurationsfilen att ändras eureka:

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

Låt oss nu se hur denna platshållare fungerar. Systemet hittar en komponent som heter endpoints och letar efter mening i det eurekaip, och sedan ersätter den i vår konfiguration. Men hur är det med olika miljöer? För att göra detta, skapa en inställningsfil i endpoints följande typ application.dev.yaml. Ramverket bestämmer oberoende, baserat på filtillägget, vilken miljö den här konfigurationen tillhör och laddar den:

Dev filinnehåll:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

Vi kan skapa samma konfiguration för portarna för våra tjänster:

server.port: ${ports@order}.

Alla viktiga inställningar finns på ett ställe, vilket minskar sannolikheten för fel på grund av spridda parametrar i konfigurationsfiler.

Ramverket tillhandahåller många färdiga platshållare, till exempel kan du få namnet på katalogen där konfigurationsfilen finns och tilldela den:

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

Tack vare detta finns det inget behov av att ytterligare ange applikationsnamnet i konfigurationen och det kan också placeras i en gemensam modul, till exempel i samma eureka:

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

Konfigurationsfilen beställa kommer att reduceras till en rad:

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

Om vi ​​inte behöver någon inställning från den överordnade konfigurationen kan vi specificera den i vår konfiguration och den kommer att tillämpas under genereringen. Det vill säga, om vi av någon anledning behöver ett unikt namn för beställningstjänsten, lämnar vi bara parametern vår.applikationsnamn.

Låt oss säga att du behöver lägga till anpassade loggningsinställningar till tjänsten, som lagras i en separat fil, till exempel, logback.xml. Låt oss skapa en separat grupp med inställningar för det:

I den grundläggande konfigurationen kommer vi att berätta för ramverket var vi ska placera loggningsinställningsfilen vi behöver med hjälp av en platshållare @ConfigDir:

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

I fil logback.xml vi konfigurerar standardtillägg, som i sin tur också kan innehålla platshållare som ramverket kommer att ändras under genereringen av konfigurationer, till exempel:

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

Genom att lägga till import till tjänstkonfigurationer logga tillbaka, får vi automatiskt konfigurerad loggning för varje tjänst:

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

Det är dags att bekanta sig mer i detalj med alla tillgängliga platshållare för ramverket:

${this@env} - returnerar namnet på den aktuella miljön.
${…@name} — returnerar namnet på komponenten.
${...@configDir} — returnerar hela sökvägen till komponentens konfigurationskatalog.
${…@resultDir} — returnerar hela sökvägen till komponentens målkatalog (de resulterande filerna kommer att placeras i denna katalog).
${this@configRoot} — returnerar den fullständiga sökvägen till rotkatalogen för konfigurationsarkivet.

Systemet låter dig också få miljövariabler, till exempel sökvägen till java:
${env@JAVA_HOME}
Antingen eftersom ramverket är skrivet i JAVA, kan vi få systemvariabler som liknar anropet System::getProperty använder en struktur som denna:
${[e-postskyddad]}
Det är värt att nämna stöd för tilläggsspråket Spring EL. Följande uttryck är tillämpliga i konfigurationen:

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

och du kan använda lokala variabler i konfigurationsfiler med hjälp av uttrycket #var:

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

Ramverket är alltså ett ganska kraftfullt verktyg för finjustering och flexibel konfiguration av mikrotjänster. Ramverket uppfyller perfekt sin huvuduppgift - eliminera copy-paste i inställningar, konsolidera inställningar och, som ett resultat, minimera möjliga fel, samtidigt som du enkelt kan kombinera konfigurationer och ändra dem för olika miljöer.

Om du är intresserad av detta ramverk rekommenderar jag att du besöker dess officiella sida och bekantar dig med hela dokumentation, eller gräv i källorna här.

Källa: will.com