Hallitse helposti mikropalvelukokoonpanoja microconfig.io:lla

Yksi mikropalvelujen kehittämisen ja myöhemmän toiminnan suurimmista ongelmista on niiden pätevä ja tarkka konfigurointi. Mielestäni uusi kehys voi auttaa tässä microconfig.io. Sen avulla voit ratkaista joitain rutiinisovellusten konfigurointitehtäviä melko tyylikkäästi.

Jos sinulla on useita mikropalveluita, ja jokaisessa niistä on oma asetustiedosto/-tiedostot, on suuri todennäköisyys, että johonkin niistä tulee virhe, jota voi olla erittäin vaikea havaita ilman asianmukaista taitoa ja lokijärjestelmää. Päätehtävä, jonka kehys asettaa itselleen, on minimoida päällekkäiset ilmentymän kokoonpanoparametrit, mikä vähentää virheen lisäämisen todennäköisyyttä.

Katsotaanpa esimerkkiä. Oletetaan, että meillä on yksinkertainen sovellus, jossa on asetustiedosto yaml. Tämä voi olla mikä tahansa mikropalvelu millä tahansa kielellä. Katsotaan kuinka puitteet voidaan soveltaa tähän palveluun.

Mutta ensin, mukavuuden vuoksi, luodaan tyhjä projekti Idea IDE:ssä, kun siihen on asennettu microconfig.io-laajennus:

Määritimme laajennuksen käynnistysasetukset, voit käyttää oletuskokoonpanoa, kuten yllä olevassa kuvakaappauksessa.

Palvelumme on nimeltään tilaus, sitten uudessa projektissa luomme samanlaisen rakenteen:

Sijoita asetustiedosto kansioon palvelun nimellä - application.yaml. Kaikki mikropalvelut käynnistetään jonkinlaisessa ympäristössä, joten itse palvelulle määrityksen luomisen lisäksi on tarpeen kuvata itse ympäristö: tätä varten luomme kansion envs ja lisää siihen tiedosto työympäristömme nimellä. Siten kehys luo konfiguraatiotiedostoja palveluille ympäristössä dev, koska tämä parametri on asetettu laajennuksen asetuksissa.

Tiedoston rakenne dev.yaml se tulee olemaan melko yksinkertaista:

mainorder:
    components:
         - order

Kehys toimii kokoonpanojen kanssa, jotka on ryhmitelty yhteen. Valitse palveluamme varten ryhmälle nimi päätilaus. Viitekehys löytää jokaisen tällaisen sovellusryhmän ympäristötiedostosta ja luo niille kaikille kokoonpanot, jotka se löytää vastaavista kansioista.

Itse palveluasetustiedostossa tilata Määritetään nyt vain yksi parametri:

spring.application.name: order

Suoritetaan nyt laajennus, ja se luo palvelullemme tarvittavat asetukset ominaisuuksissa määritetyn polun mukaisesti:

voida tulla toimeen ja asentamatta laajennusta, lataa vain kehysjakelu ja suorita se komentoriviltä.
Tämä ratkaisu sopii käytettäväksi koontipalvelimella.

On syytä huomata, että kehys ymmärtää täydellisesti omaisuus syntaksi, eli tavalliset ominaisuustiedostot, joita voidaan käyttää yhdessä yaml kokoonpanot.

Lisätään toinen palvelu maksu ja monimutkaista nykyistä.
В tilata:

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

В maksu:

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

Suurin ongelma näissä kokoonpanoissa on suuri määrä kopioi-liitä palveluasetuksissa. Katsotaan kuinka kehys auttaa pääsemään eroon siitä. Aloitetaan ilmeisimmästä - kokoonpanon läsnäolosta eureka kunkin mikropalvelun kuvauksessa. Luodaan uusi hakemisto asetustiedostolla ja lisätään siihen uusi kokoonpano:

Ja nyt lisätään rivi jokaiseen projektiimme #sisällytä eureka.

Kehys löytää automaattisesti eureka-määrityksen ja kopioi sen palvelun asetustiedostoihin, mutta erillistä eureka-konfiguraatiota ei luoda, koska emme määritä sitä ympäristötiedostossa dev.yaml. Palvelu tilata:

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

Voimme myös siirtää tietokannan asetukset erilliseen kokoonpanoon muuttamalla tuontirivin muotoon #sisältää eureka, oraakkeli.

On syytä huomata, että kehys seuraa jokaista muutosta luodessaan uudelleen asetustiedostoja ja sijoittaa ne erityiseen tiedostoon pääasetustiedoston viereen. Sen lokimerkintä näyttää tältä: "Tallennettu 1 ominaisuus muuttuu muotoon order/diff-application.yaml" Tämän avulla voit nopeasti havaita muutokset suuriin asetustiedostoihin.

Kokoonpanon yleisten osien poistaminen päästää eroon suuresta määrästä turhaa kopiointia, mutta ei mahdollista joustavasti konfiguraatioiden luomista eri ympäristöihin - palveluidemme päätepisteet ovat ainutlaatuisia ja kovakoodattuja, tämä on huono. Yritetään poistaa tämä.

Hyvä ratkaisu olisi pitää kaikki päätepisteet yhdessä kokoonpanossa, johon muut voivat viitata. Tätä tarkoitusta varten viitekehykseen on lisätty tuki paikkamerkkien käyttöön. Näin asetustiedosto muuttuu eureka:

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

Katsotaan nyt, miten tämä paikkamerkki toimii. Järjestelmä löytää komponentin nimeltä päätepisteet ja etsii siinä merkitystä eurekaip, ja korvaa sen sitten kokoonpanoomme. Mutta entä erilaiset ympäristöt? Voit tehdä tämän luomalla asetustiedoston päätepisteet seuraavaa tyyppiä application.dev.yaml. Kehys päättää itsenäisesti tiedostopäätteen perusteella mihin ympäristöön tämä kokoonpano kuuluu ja lataa sen:

Kehittäjätiedoston sisältö:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

Voimme luoda saman kokoonpanon palveluidemme porteille:

server.port: ${ports@order}.

Kaikki tärkeät asetukset ovat yhdessä paikassa, mikä vähentää konfiguraatiotiedostojen hajallaan olevien parametrien aiheuttamien virheiden todennäköisyyttä.

Kehys sisältää monia valmiita paikkamerkkejä, esimerkiksi voit saada hakemiston nimen, jossa asetustiedosto sijaitsee, ja määrittää sen:

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

Tämän ansiosta sovelluksen nimeä ei tarvitse erikseen määrittää konfiguraatiossa ja se voidaan sijoittaa myös yhteiseen moduuliin, esimerkiksi samaan eurekaan:

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

Asetustiedosto tilata vähennetään yhdeksi riviksi:

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

Jos emme tarvitse mitään asetusta ylätason kokoonpanosta, voimme määrittää sen asetuksissamme ja sitä käytetään luomisen aikana. Eli jos jostain syystä tarvitsemme yksilöllisen nimen tilauspalvelulle, jätämme parametrin kevät.sovelluksen.nimi.

Oletetaan, että sinun täytyy lisätä palveluun mukautettuja lokiasetuksia, jotka tallennetaan erilliseen tiedostoon, esim. logback.xml. Luodaan sille erillinen asetusryhmä:

Peruskokoonpanossa kerromme viitekehykselle paikkamerkin avulla, minne tarvitsemme lokiasetustiedoston sijoittaa @ConfigDir:

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

Tiedostossa logback.xml konfiguroimme vakioliitteitä, jotka puolestaan ​​voivat sisältää myös paikkamerkkejä, joita kehys muuttaa asetusten luomisen aikana, esimerkiksi:

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

Lisäämällä tuonti palvelukonfiguraatioihin takaisin, saamme automaattisesti määritetyt lokitiedot jokaiselle palvelulle:

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

On aika tutustua tarkemmin kaikkiin kehyksen käytettävissä oleviin paikkamerkkeihin:

${this@env} - palauttaa nykyisen ympäristön nimen.
${…@name} — palauttaa komponentin nimen.
${…@configDir} — palauttaa koko polun komponentin konfigurointihakemistoon.
${…@resultDir} — palauttaa koko polun komponentin kohdehakemistoon (tuloksena olevat tiedostot sijoitetaan tähän hakemistoon).
${this@configRoot} — palauttaa koko polun kokoonpanosäilön juurihakemistoon.

Järjestelmän avulla voit myös saada ympäristömuuttujia, esimerkiksi polun javaan:
${env@JAVA_HOME}
Joko, koska kehys on kirjoitettu JAVA, voimme saada puhelun kaltaisia ​​järjestelmämuuttujia Järjestelmä::getProperty käyttämällä tällaista rakennetta:
${[sähköposti suojattu]}
On syytä mainita tuki laajennuskielelle Kevät EL. Seuraavat lausekkeet ovat käytettävissä kokoonpanossa:

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

ja voit käyttää paikallisia muuttujia määritystiedostoissa lausekkeen avulla #var:

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

Näin ollen kehys on melko tehokas työkalu mikropalvelujen hienosäätöön ja joustavaan konfigurointiin. Kehys täyttää täydellisesti päätehtävänsä - eliminoi kopioinnin ja liittämisen asetuksista, konsolidoi asetukset ja sen seurauksena minimoi mahdolliset virheet, samalla kun voit helposti yhdistää määrityksiä ja muuttaa niitä eri ympäristöissä.

Jos olet kiinnostunut tästä kehyksestä, suosittelen vierailemaan sen virallisella sivulla ja tutustumaan koko sisältöön dokumentointitai kaivaa lähteitä täällä.

Lähde: will.com