Et af hovedproblemerne i udviklingen og den efterfølgende drift af mikrotjenester er den kompetente og nøjagtige konfiguration af deres instanser. Det kan efter min mening en ny ramme hjælpe med . Det giver dig mulighed for at løse nogle rutinemæssige applikationskonfigurationsopgaver ganske elegant.
Hvis du har mange mikrotjenester, og hver af dem kommer med sin egen konfigurationsfil/filer, så er der stor sandsynlighed for at lave en fejl i en af dem, hvilket kan være meget svært at fange uden ordentlig dygtighed og et logningssystem. Den vigtigste opgave, som rammen sætter for sig selv, er at minimere duplikerede instanskonfigurationsparametre og derved reducere sandsynligheden for at tilføje en fejl.
Lad os se på et eksempel. Lad os sige, at vi har et simpelt program med en konfigurationsfil yaml. Dette kan være enhver mikrotjeneste på ethvert sprog. Lad os se, hvordan rammen kan anvendes på denne tjeneste.
Men lad os først, for større bekvemmelighed, oprette et tomt projekt i Idea IDE efter at have installeret microconfig.io plugin i det:
Vi opsætter plugin-lanceringskonfigurationen, du kan bruge standardkonfigurationen, som i skærmbilledet ovenfor.
Vores service kaldes ordre, så i et nyt projekt vil vi skabe en lignende struktur:
Placer konfigurationsfilen i mappen med tjenestenavnet - application.yaml. Alle mikrotjenester lanceres i en eller anden form for miljø, så ud over at oprette en konfiguration til selve tjenesten, er det nødvendigt at beskrive selve miljøet: til dette vil vi oprette en mappe envs og tilføje en fil til den med navnet på vores arbejdsmiljø. Rammerne vil således skabe konfigurationsfiler til tjenester i miljøet dev, da denne parameter er indstillet i plugin-indstillingerne.
Filstruktur dev.yaml det vil være ret simpelt:
mainorder:
components:
- orderRammen fungerer med konfigurationer, der er grupperet sammen. Til vores service skal du vælge et navn til gruppen hovedordre. Frameworket finder hver sådan gruppe af applikationer i miljøfilen og opretter konfigurationer for dem alle, som det finder i de tilsvarende mapper.
I selve tjenesteindstillingsfilen ordrer Lad os kun angive én parameter for nu:
spring.application.name: orderLad os nu køre pluginnet, og det vil generere den nødvendige konfiguration til vores tjeneste i henhold til stien angivet i egenskaberne:
kan og uden at installere et plugin, skal du blot downloade rammedistributionen og køre den fra kommandolinjen.
Denne løsning er velegnet til brug på en build-server.
Det er værd at bemærke, at rammen forstår perfekt ejendom syntaks, det vil sige almindelige egenskabsfiler, der kan bruges sammen i yaml konfigurationer.
Lad os tilføje en anden tjeneste betaling og komplicere den eksisterende.
В ordrer:
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В betaling:
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.100Hovedproblemet med disse konfigurationer er tilstedeværelsen af en stor mængde copy-paste i tjenesteindstillingerne. Lad os se, hvordan rammerne hjælper med at slippe af med det. Lad os starte med det mest åbenlyse - tilstedeværelsen af konfiguration eureka i beskrivelsen af hver mikrotjeneste. Lad os oprette en ny mappe med indstillingsfilen og tilføje en ny konfiguration til den:
Og lad os nu tilføje linjen til hvert af vores projekter #inkluder eureka.
Frameworket vil automatisk finde eureka-konfigurationen og kopiere den til service-konfigurationsfilerne, mens en separat eureka-konfiguration ikke vil blive oprettet, da vi ikke vil specificere den i miljøfilen dev.yaml. Service ordrer:
#include eureka
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100Vi kan også flytte databaseindstillingerne til en separat konfiguration ved at ændre importlinjen til #inkluder eureka, orakel.
Det er værd at bemærke, at rammeværket sporer hver ændring, når konfigurationsfilerne regenereres, og placerer dem i en speciel fil ved siden af hovedkonfigurationsfilen. Indtastningen i dens log ser således ud: "Lagret 1 ejendom ændres til ordre/diff-applikation.yaml" Dette giver dig mulighed for hurtigt at opdage ændringer af store konfigurationsfiler.
Fjernelse af fælles dele af konfigurationen giver dig mulighed for at slippe af med en masse unødvendig copy-paste, men giver dig ikke mulighed for fleksibelt at skabe en konfiguration til forskellige miljøer - endepunkterne for vores tjenester er unikke og hårdkodede, det er dårligt. Lad os prøve at fjerne dette.
En god løsning ville være at holde alle endepunkter i én konfiguration, som andre kan referere til. Til dette formål er der indført støtte til pladsholdere i rammen. Sådan ændres konfigurationsfilen eureka:
client:
serviceUrl:
defaultZone: http://${endpoints@eurekaip}:6782/eureka/Lad os nu se, hvordan denne pladsholder fungerer. Systemet finder en komponent med navn endpoints og leder efter mening i det eurekaip, og erstatter det derefter i vores konfiguration. Men hvad med forskellige miljøer? For at gøre dette skal du oprette en indstillingsfil i endpoints følgende type application.dev.yaml. Rammerne bestemmer uafhængigt, baseret på filtypenavnet, hvilket miljø denne konfiguration tilhører og indlæser den:
Dev fil indhold:
eurekaip: 192.89.89.111
dbip: 192.168.0.100Vi kan oprette den samme konfiguration for portene i vores tjenester:
server.port: ${ports@order}.Alle vigtige indstillinger er samlet ét sted, hvilket reducerer sandsynligheden for fejl på grund af spredte parametre i konfigurationsfiler.
Rammen giver mange færdige pladsholdere, for eksempel kan du få navnet på den mappe, hvori konfigurationsfilen er placeret, og tildele den:
#include eureka, oracle
server.port: ${ports@order}
spring.application.name: ${this@name}Takket være dette er der ikke behov for yderligere at angive applikationsnavnet i konfigurationen, og det kan også placeres i et fælles modul, for eksempel i samme eureka:
client:
serviceUrl:
defaultZone: http://${endpoints@eurekaip}:6782/eureka/
spring.application.name: ${this@name}Konfigurationsfilen ordrer reduceres til én linje:
#include eureka, oracle
server.port: ${ports@order}Hvis vi ikke har brug for nogen indstilling fra den overordnede konfiguration, kan vi angive den i vores konfiguration, og den vil blive anvendt under generering. Det vil sige, at hvis vi af en eller anden grund har brug for et unikt navn til ordreservicen, forlader vi bare parameteren spring.application.name.
Lad os sige, at du skal tilføje brugerdefinerede logningsindstillinger til tjenesten, som er gemt i en separat fil, f.eks. logback.xml. Lad os oprette en separat gruppe indstillinger for det:
I den grundlæggende konfiguration fortæller vi rammen, hvor vi skal placere logindstillingsfilen, vi har brug for ved hjælp af en pladsholder @ConfigDir:
microconfig.template.logback.fromFile: ${logback@configDir}/logback.xmlI fil logback.xml vi konfigurerer standardtilføjelser, som igen kan indeholde pladsholdere, som rammerne vil ændre under genereringen af konfigurationer, for eksempel:
<file>logs/${this@name}.log</file>Ved at tilføje import til tjenestekonfigurationer log tilbage, får vi automatisk konfigureret logning for hver tjeneste:
#include eureka, oracle, logback
server.port: ${ports@order}Det er tid til at blive mere detaljeret bekendt med alle de tilgængelige pladsholdere i rammen:
${this@env} - returnerer navnet på det aktuelle miljø.
${…@name} — returnerer navnet på komponenten.
${...@configDir} — returnerer den fulde sti til komponentens konfigurationsmappe.
${…@resultDir} — returnerer den fulde sti til komponentens destinationsmappe (de resulterende filer vil blive placeret i denne mappe).
${this@configRoot} — returnerer den fulde sti til rodbiblioteket i konfigurationslagret.
Systemet giver dig også mulighed for at få miljøvariabler, for eksempel stien til java:
${env@JAVA_HOME}
Enten, da rammen er skrevet ind JAVA, kan vi få systemvariabler svarende til opkaldet System::getProperty ved at bruge en struktur som denne:
${[e-mail beskyttet]}
Det er værd at nævne understøttelse af udvidelsessproget Forår EL. Følgende udtryk er anvendelige i konfigurationen:
connection.timeoutInMs: #{5 * 60 * 1000}
datasource.maximum-pool-size: #{${[email protected]} + 10} og du kan bruge lokale variabler i konfigurationsfiler ved hjælp af udtrykket #var:
#var feedRoot: ${[email protected]}/feed
folder:
root: ${this@feedRoot}
success: ${this@feedRoot}/archive
error: ${this@feedRoot}/errorRammerne er således et ret kraftfuldt værktøj til finjustering og fleksibel konfiguration af mikrotjenester. Rammerne opfylder perfekt sin hovedopgave - at eliminere copy-paste i indstillinger, konsolidere indstillinger og som et resultat minimere mulige fejl, samtidig med at du nemt kan kombinere konfigurationer og ændre dem til forskellige miljøer.
Hvis du er interesseret i denne ramme, anbefaler jeg at besøge dens officielle side og stifte bekendtskab med det fulde , eller grave i kilderne .
Kilde: www.habr.com