Et av hovedproblemene i utviklingen og den påfølgende driften av mikrotjenester er den kompetente og nøyaktige konfigurasjonen av deres forekomster. Etter min mening kan et nytt rammeverk hjelpe på dette . Det lar deg løse noen rutinemessige applikasjonskonfigurasjonsoppgaver ganske elegant.
Hvis du har mange mikrotjenester, og hver av dem kommer med sin egen konfigurasjonsfil/filer, så er det stor sannsynlighet for å gjøre en feil i en av dem, som kan være svært vanskelig å fange opp uten riktig dyktighet og et loggsystem. Hovedoppgaven som rammeverket setter for seg selv, er å minimere dupliserte instanskonfigurasjonsparametere, og dermed redusere sannsynligheten for å legge til en feil.
La oss se på et eksempel. La oss si at vi har en enkel applikasjon med en konfigurasjonsfil yaml. Dette kan være hvilken som helst mikrotjeneste på alle språk. La oss se hvordan rammeverket kan brukes på denne tjenesten.
Men først, for større bekvemmelighet, la oss lage et tomt prosjekt i Idea IDE, etter å ha installert microconfig.io-pluginen i den:
Vi setter opp plugin-lanseringskonfigurasjonen, du kan bruke standardkonfigurasjonen, som i skjermbildet ovenfor.
Tjenesten vår kalles ordre, så i et nytt prosjekt vil vi lage en lignende struktur:
Plasser konfigurasjonsfilen i mappen med tjenestenavnet - application.yaml. Alle mikrotjenester lanseres i et slags miljø, så i tillegg til å lage en konfigurasjon for selve tjenesten, er det nødvendig å beskrive selve miljøet: for dette vil vi lage en mappe envs og legg til en fil med navnet på arbeidsmiljøet vårt. Dermed vil rammeverket lage konfigurasjonsfiler for tjenester i miljøet dev, siden denne parameteren er satt i plugin-innstillingene.
Filstruktur dev.yaml det vil være ganske enkelt:
mainorder:
components:
- orderRammeverket fungerer med konfigurasjoner som er gruppert sammen. For vår tjeneste, velg et navn for gruppen hovedordre. Rammeverket finner hver slik gruppe av applikasjoner i miljøfilen og lager konfigurasjoner for dem alle, som det finner i de tilsvarende mappene.
I selve tjenesteinnstillingsfilen rekkefølge La oss spesifisere bare én parameter for nå:
spring.application.name: orderLa oss nå kjøre plugin-en, og den vil generere den nødvendige konfigurasjonen for tjenesten vår i henhold til banen spesifisert i egenskapene:
kan og uten å installere en plugin, bare last ned rammeverksdistribusjonen og kjøre den fra kommandolinjen.
Denne løsningen er egnet for bruk på en byggeserver.
Det er verdt å merke seg at rammeverket forstår perfekt eiendom syntaks, det vil si vanlige eiendomsfiler som kan brukes sammen i yaml konfigurasjoner.
La oss legge til en annen tjeneste betaling og komplisere den eksisterende.
В rekkefølge:
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 konfigurasjonene er tilstedeværelsen av en stor mengde copy-paste i tjenesteinnstillingene. La oss se hvordan rammeverket vil bidra til å bli kvitt det. La oss starte med det mest åpenbare - tilstedeværelsen av konfigurasjon eureka i beskrivelsen av hver mikrotjeneste. La oss lage en ny katalog med innstillingsfilen og legge til en ny konfigurasjon til den:
Og la oss nå legge til linjen til hvert av våre prosjekter #inkluder eureka.
Rammeverket vil automatisk finne eureka-konfigurasjonen og kopiere den til tjenestekonfigurasjonsfilene, mens en egen eureka-konfigurasjon vil ikke bli opprettet, siden vi ikke vil spesifisere den i miljøfilen dev.yaml. Service rekkefølge:
#include eureka
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100Vi kan også flytte databaseinnstillingene til en egen konfigurasjon ved å endre importlinjen til #inkluder eureka, orakel.
Det er verdt å merke seg at rammeverket sporer hver endring ved regenerering av konfigurasjonsfiler og plasserer den i en spesiell fil ved siden av hovedkonfigurasjonsfilen. Oppføringen i loggen ser slik ut: «Lagret 1 egenskap endres til order/diff-application.yaml" Dette lar deg raskt oppdage endringer i store konfigurasjonsfiler.
Fjerning av vanlige deler av konfigurasjonen lar deg bli kvitt mye unødvendig copy-paste, men lar deg ikke fleksibelt lage en konfigurasjon for ulike miljøer – endepunktene til tjenestene våre er unike og hardkodet, dette er dårlig. La oss prøve å fjerne dette.
En god løsning ville være å holde alle endepunkter i én konfigurasjon som andre kan referere til. For dette formålet er det innført støtte for plassholdere i rammeverket. Dette er hvordan konfigurasjonsfilen endres eureka:
client:
serviceUrl:
defaultZone: http://${endpoints@eurekaip}:6782/eureka/La oss nå se hvordan denne plassholderen fungerer. Systemet finner en komponent som heter endepunkter og leter etter mening i det eurekaip, og erstatter den deretter i vår konfigurasjon. Men hva med ulike miljøer? For å gjøre dette, lag en innstillingsfil i endepunkter følgende type application.dev.yaml. Rammeverket uavhengig, basert på filtypen, bestemmer hvilket miljø denne konfigurasjonen tilhører og laster den:
Dev-filinnhold:
eurekaip: 192.89.89.111
dbip: 192.168.0.100Vi kan opprette den samme konfigurasjonen for portene til tjenestene våre:
server.port: ${ports@order}.Alle viktige innstillinger er på ett sted, og reduserer dermed sannsynligheten for feil på grunn av spredte parametere i konfigurasjonsfiler.
Rammeverket gir mange ferdige plassholdere, for eksempel kan du få navnet på katalogen der konfigurasjonsfilen er plassert og tilordne den:
#include eureka, oracle
server.port: ${ports@order}
spring.application.name: ${this@name}Takket være dette er det ikke nødvendig å spesifisere applikasjonsnavnet i tillegg i konfigurasjonen, og det kan også plasseres i en felles modul, for eksempel i samme eureka:
client:
serviceUrl:
defaultZone: http://${endpoints@eurekaip}:6782/eureka/
spring.application.name: ${this@name}Konfigurasjonsfilen rekkefølge vil bli redusert til én linje:
#include eureka, oracle
server.port: ${ports@order}Hvis vi ikke trenger noen innstilling fra den overordnede konfigurasjonen, kan vi spesifisere den i konfigurasjonen vår, og den vil bli brukt under generering. Det vil si at hvis vi av en eller annen grunn trenger et unikt navn for bestillingstjenesten, lar vi bare parameteren stå vår.applikasjonsnavn.
La oss si at du må legge til egendefinerte loggingsinnstillinger til tjenesten, som er lagret i en egen fil, for eksempel, logback.xml. La oss lage en egen gruppe med innstillinger for det:
I den grunnleggende konfigurasjonen forteller vi rammeverket hvor vi skal plassere logginnstillingsfilen vi trenger ved hjelp av en plassholder @ConfigDir:
microconfig.template.logback.fromFile: ${logback@configDir}/logback.xmlI fil logback.xml vi konfigurerer standard vedlegg, som igjen kan inneholde plassholdere som rammeverket vil endre under generering av konfigurasjoner, for eksempel:
<file>logs/${this@name}.log</file>Ved å legge til import til tjenestekonfigurasjoner tilbakekobling, får vi automatisk konfigurert logging for hver tjeneste:
#include eureka, oracle, logback
server.port: ${ports@order}Det er på tide å bli mer detaljert kjent med alle tilgjengelige plassholdere for rammeverket:
${this@env} - returnerer navnet på gjeldende miljø.
${…@name} — returnerer navnet på komponenten.
${…@configDir} — returnerer hele banen til komponentens konfigurasjonskatalog.
${…@resultDir} — returnerer hele banen til komponentens destinasjonskatalog (de resulterende filene vil bli plassert i denne katalogen).
${this@configRoot} — returnerer hele banen til rotkatalogen til konfigurasjonslageret.
Systemet lar deg også få miljøvariabler, for eksempel banen til java:
${env@JAVA_HOME}
Enten siden rammeverket er skrevet inn JAVA, kan vi få systemvariabler som ligner på kallet System::getProperty bruke en struktur som denne:
${[e-postbeskyttet]}
Det er verdt å nevne støtte for utvidelsesspråket Vår EL. Følgende uttrykk gjelder i konfigurasjonen:
connection.timeoutInMs: #{5 * 60 * 1000}
datasource.maximum-pool-size: #{${[email protected]} + 10} og du kan bruke lokale variabler i konfigurasjonsfiler ved å bruke uttrykket #var:
#var feedRoot: ${[email protected]}/feed
folder:
root: ${this@feedRoot}
success: ${this@feedRoot}/archive
error: ${this@feedRoot}/errorDermed er rammeverket et ganske kraftig verktøy for finjustering og fleksibel konfigurasjon av mikrotjenester. Rammeverket oppfyller perfekt hovedoppgaven sin - eliminere copy-paste i innstillinger, konsolidere innstillinger og, som et resultat, minimere mulige feil, samtidig som du enkelt kan kombinere konfigurasjoner og endre dem for forskjellige miljøer.
Hvis du er interessert i dette rammeverket, anbefaler jeg å besøke dens offisielle side og bli kjent med hele , eller grave i kildene .
Kilde: www.habr.com