Gestione semplice delle configurazioni dei microservizi tramite microconfig.io

Uno dei principali problemi nella progettazione e successiva gestione dei microservizi è la corretta e accurata configurazione delle loro istanze. A mio avviso, un nuovo framework può aiutare in questo. microconfig.io. Esso consente di affrontare in modo piuttosto elegante alcune delle attività di configurazione routinarie delle applicazioni.

Se hai molti microservizi, e ciascuno di essi viene fornito con il proprio file/file di configurazione, c'è una grande probabilità di commettere un errore in uno di essi, che senza la dovuta esperienza e un sistema di registrazione potrebbe essere molto difficile da individuare. L'obiettivo principale del framework è ridurre al minimo i parametri di configurazione duplicati delle istanze, in modo da diminuire la probabilità di aggiungere errori.

Consideriamo un esempio. Supponiamo di avere una semplice applicazione con un file di configurazione yaml. Questo può essere qualsiasi microservizio in qualsiasi linguaggio. Vediamo come il framework può essere applicato a questo servizio.

Ma prima, per maggiore comodità, creiamo un progetto vuoto in Idea IDE, installando precedentemente il plugin microconfig.io:

Stiamo configurando la configurazione di avvio del plugin, è possibile utilizzare la configurazione predefinita, come nello screenshot sopra.

Il nostro servizio si chiama order, quindi nel nuovo progetto creeremo una struttura simile:

Nella cartella con il nome del servizio mettiamo il file di configurazione — application.yaml. Tutti i microservizi vengono eseguiti in un ambiente specifico, quindi, oltre a creare la configurazione del servizio stesso, è necessario descrivere anche l'ambiente: per farlo, creeremo una cartella envs e aggiungeremo al suo interno un file con il nome del nostro ambiente di lavoro. In questo modo, il framework creerà file di configurazione per i servizi nell'ambiente dev, poiché nelle impostazioni del plugin è impostato proprio questo parametro.

La struttura del file dev.yaml sarà piuttosto semplice:

mainorder:
    components:
         - order

Il framework lavora con configurazioni che sono raggruppate. Per il nostro servizio scegliamo un nome per il gruppo mainorder. Il framework trova ciascun gruppo di applicazioni nel file degli ambienti e crea configurazioni per tutti loro, che trova nelle cartelle corrispondenti.

Nel file di configurazione del servizio order indicheremo per ora solo un parametro:

spring.application.name: order

Ora avviamo il plugin, che genererà la configurazione necessaria per il nostro servizio secondo il percorso specificato nelle proprietà:

È possibile fare a meno anche senza installare il plugin, semplicemente scaricando il pacchetto del framework e avviandolo dalla riga di comando.
Questa soluzione è adatta per l'uso su un server di build.

Vale la pena notare che il framework comprende perfettamente property la sintassi, cioè i normali file di proprietà che possono essere utilizzati insieme a yaml configurazioni.

Aggiungiamo un altro servizio payment e contemporaneamente complicheremo quello esistente.
In order:

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

In payment:

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

Il principale problema di queste configurazioni è la presenza di una grande quantità di copiaincolla nelle impostazioni dei servizi. Vediamo come il framework può aiutare a eliminarlo. Iniziamo con la più ovvia: la presenza della configurazione eureka nella descrizione di ogni microservizio. Creiamo una nuova directory con un file di impostazioni e aggiungiamoci una nuova configurazione:

E ora aggiungiamo una riga a ciascuno dei nostri progetti #include eureka.

Il framework troverà automaticamente la configurazione di Eureka e la copierà nei file di configurazione dei servizi, senza creare una configurazione separata poiché non la indicheremo nel file di ambiente. dev.yaml. Servizio order:

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

Possiamo anche spostare le impostazioni del database in una configurazione separata, modificando la riga di importazione in #include eureka, oracle.

Va notato che ogni modifica durante la rigenerazione dei file di configurazione viene tracciata dal framework e registrata in un file speciale accanto al file di configurazione principale. La registrazione nel suo log appare così: “Stored 1 property changes to order/diff-application.yaml”. Questo consente di individuare rapidamente le modifiche in grandi file di configurazione.

Spostare le parti comuni della configurazione aiuta a eliminare molte duplicazioni inutili, ma non consente di creare configurazioni flessibili per diversi ambienti: gli endpoint dei nostri servizi sono unici e hardcoded, il che è un problema. Proviamo a rimuoverlo.

Una buona soluzione sarebbe tenere tutti gli endpoint in un'unica configurazione, cui gli altri potrebbero fare riferimento. Per questo, il framework ha introdotto il supporto per i segnaposto. Ecco come cambierà il file di configurazione. eureka:

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

Ora vediamo come funziona questo segnaposto. Il sistema trova il componente con il nome endpoints e cerca al suo interno il valore eurekaip, dopodiché lo inserisce nella nostra configurazione. Ma come gestire le diverse ambienti? A tal fine, creiamo un file di configurazione in endpoints questo formato application.dev.yaml. Il framework identifica automaticamente, in base all'estensione del file, a quale ambiente appartiene questa configurazione e la carica:

Il contenuto del file dev:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

Possiamo creare la stessa configurazione anche per le porte dei nostri servizi:

server.port: ${ports@order}.

Tutte le impostazioni importanti si trovano in un unico luogo, riducendo così la probabilità di errori dovuti a parametri sparsi nei file di configurazione.

Il framework offre molti segnaposto già pronti, ad esempio, è possibile ottenere il nome della directory in cui si trova il file di configurazione e assegnarlo:

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

Grazie a questo, non è necessario specificare ulteriormente il nome dell'applicazione nella configurazione e può anche essere spostato in un modulo comune, ad esempio, nello stesso eureka:

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

File di configurazione order verrà ridotto a una sola riga:

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

Se qualche impostazione della configurazione principale non è necessaria, possiamo specificarla nella nostra configurazione e sarà questa ad essere applicata durante la generazione. Cioè, se per qualche motivo abbiamo bisogno di un nome univoco per il servizio order, possiamo semplicemente lasciare il parametro spring.application.name.

Supponiamo di dover aggiungere delle impostazioni di logging personalizzate al servizio, che sono memorizzate in un file separato, ad esempio, logback.xml. Creeremo un gruppo separato di impostazioni per esso:

Nella configurazione di base, indicheremo al framework dove posizionare il file di configurazione del logging necessario utilizzando il segnaposto @ConfigDir:

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

Nel file logback.xml configuriamo gli appender standard, che possono a loro volta contenere segnaposto che il framework modificherà durante la generazione dei config, ad esempio:

logs/${this@name}.log

Aggiungendo nelle configurazioni dei servizi l'import logback, otteniamo automaticamente la registrazione configurata per ogni servizio:

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

È giunto il momento di familiarizzare più dettagliatamente con tutti i segnaposto disponibili del framework:

${this@env} — restituisce il nome dell'ambiente corrente.
${…@name} — restituisce il nome del componente.
${…@configDir} — restituisce il percorso completo della directory di configurazione del componente.
${…@resultDir} — restituisce il percorso completo della directory di destinazione del componente (i file ottenuti saranno collocati in questa directory).
${this@configRoot} — restituisce il percorso completo della directory principale del repository di configurazioni.

Inoltre, il sistema consente di ottenere variabili ambientali, come il percorso di java:
${env@JAVA_HOME}
O, poiché il framework è scritto in JAVA, possiamo ottenere variabili di sistema simili alla chiamata System::getProperty usando una costruzione di questo tipo:
${system@os.name}
Vale la pena menzionare il supporto per il linguaggio di espressione Spring EL. Nella configurazione sono applicabili espressioni simili:

connection.timeoutInMs: #{5 * 60 * 1000}
datasource.maximum-pool-size: #{${this@datasource.minimum-pool-size} + 10} 

e si possono utilizzare variabili locali nei file di configurazione tramite l'espressione #var:

#var feedRoot: ${system@user.home}/feed
folder:
 root: ${this@feedRoot}
 success: ${this@feedRoot}/archive
 error: ${this@feedRoot}/error

Pertanto, il framework si presenta come uno strumento molto potente per una configurazione fine e flessibile dei microservizi. Il framework svolge alla perfezione il suo compito principale: eliminare il copincolla nelle configurazioni, consolidare le impostazioni e, di conseguenza, ridurre al minimo le possibili errori, consentendo nel contempo di combinare facilmente le configurazioni e modificarle per diversi ambienti.

Se questo framework ha destato il vostro interesse, vi consiglio di visitare la sua pagina ufficiale e di prendere visione della documentazione completa documentazione, oppure di dare un'occhiata al codice sorgente qui.

Fonte: habr.com