Gestione semplice delle configurazioni dei microservizi con microconfig.io

Uno dei principali problemi nello sviluppo e successiva gestione dei microservizi è la corretta e attenta configurazione delle loro istanze. In questo, a mio avviso, può aiutare un nuovo framework microconfig.io. Permette di risolvere in modo piuttosto elegante alcune attività di configurazione delle applicazioni.

Se hai molti microservizi e ognuno di essi viene fornito con il proprio file/i file di configurazione, c'è una grande probabilità di commettere un errore in uno di essi, che senza l'adeguata abilità e un sistema di logging potrebbe essere molto complicato da individuare. L'obiettivo principale che si pone il framework è quello di ridurre al minimo i parametri di configurazione duplicati dell'istanza, riducendo così la probabilità di introdurre errori.

Consideriamo un esempio. Supponiamo che ci sia un'applicazione semplice con un file di configurazione yaml. Può essere qualsiasi microservizio in qualsiasi lingua. Vediamo come il framework può essere applicato a questo servizio.

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

Configuriamo la configurazione di avvio del plugin, si può utilizzare la configurazione predefinita, come nello screenshot sopra.

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

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

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

mainorder:
    components:
         - order

Il framework lavora con configurazioni che sono raggruppate in gruppi. Per il nostro servizio scegliamo un nome per il gruppo mainorder. Il framework trova ogni gruppo di applicazioni nel file ambientale e crea per tutte loro le configurazioni che trova nelle rispettive cartelle.

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

spring.application.name: order

Ora avviamo il plugin, e questo genererà la configurazione necessaria del nostro servizio seguendo il percorso specificato nelle proprietà:

Si può fare a meno E senza installare alcun 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 la sintassi delle proprietà, ovvero i normali file di proprietà che possono essere utilizzati insieme a configurazioni. yaml Aggiungiamo un altro servizio

di pagamento e complicheremo allo stesso tempo l'esistente. 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 order:

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

In e complicheremo allo stesso tempo l'esistente.:

Il problema principale di queste configurazioni è la presenza di un gran numero di copia e incolla nelle impostazioni dei servizi. Vediamo come il framework può aiutare a liberarci da questo. Iniziamo con la più ovvia: la presenza della configurazione

eureka nella descrizione di ogni microservizio. Creiamo una nuova cartella con un file di impostazioni e aggiungiamo in essa una nuova configurazione: E in ciascuno dei nostri progetti aggiungiamo ora la riga

Il framework troverà automaticamente la configurazione eureka e la copierà nei file di configurazione dei servizi, senza che venga creata una configurazione eureka separata, poiché non la indicheremo nel file di ambiente #include eureka.

. Servizio dev.yamlPossiamo anche estrarre le impostazioni del database in una configurazione separata, modificando la riga di importazione in order:

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

Vale la pena notare che ogni modifica durante la rigenerazione dei file di configurazione è monitorata dal framework e registrata in un file speciale accanto al file di configurazione principale. La registrazione nel suo log appare così: "Archiviate 1 modifica della proprietà in #include eureka, oracle.

order/diff-application.yaml ". Questo consente di rilevare rapidamente le modifiche in grandi file di configurazione.Esternalizzare le parti comuni della configurazione consente di eliminare molti copia e incolla non necessari, ma non permette di creare configurazioni flessibili per ambienti diversi: gli endpoint dei nostri servizi sono unici e hardcoded, il che è un problema. Proviamo a risolverlo.

Una buona soluzione sarebbe mantenere tutti gli endpoint in un'unica configurazione, alla quale potrebbero fare riferimento le altre. A tal fine, il framework supporta i segnaposto. Ecco come si modificherà il file di configurazione

client: serviceUrl: defaultZone: http://${endpoints@eurekaip}:6782/eureka/ nella descrizione di ogni microservizio. Creiamo una nuova cartella con un file di impostazioni e aggiungiamo in essa una nuova configurazione::

 Ora vediamo come funziona questo segnaposto. Il sistema trova il componente con il nome

endpoints e cerca al suo interno il valore eurekaip eurekaip, dopo di che lo inseriamo nella nostra configurazione. Ma come gestire diversi ambienti? Per questo creiamo un file di impostazioni in e cerca al suo interno il valore questo formato application.dev.yaml. Il framework determina autonomamente, 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 posto, riducendo così la probabilità di errori dovuti a parametri sparsi nei file di configurazione.

Il framework fornisce numerosi placeholder già pronti, ad esempio, possiamo 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 ciò, non è necessario specificare ulteriormente il nome dell'applicazione nella configurazione e può essere anche estratto in un modulo generale, ad esempio, nello stesso eureka:

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

Il file di configurazione order verrà ridotto a una sola riga:

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

Nel caso in cui una qualsiasi impostazione dalla configurazione padre non ci serva, possiamo specificarla nella nostra configurazione e sarà quella a essere applicata durante la generazione. Quindi, se per qualche motivo abbiamo bisogno di un nome unico per il servizio order, possiamo semplicemente lasciare il parametro spring.application.name.

Supponiamo di dover aggiungere impostazioni di logging personalizzate, che sono memorizzate in un file separato, per esempio, logback.xml. Creiamo per esso un gruppo di impostazioni separato:

Nella configurazione di base indichiamo al framework dove posizionare il necessario file di impostazioni di logging utilizzando il placeholder @ConfigDir:

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

Nel file logback.xml configuriamo gli appenders standard, che possono anche contenere placeholder, che il framework modificherà durante la generazione delle configurazioni, ad esempio:

logs/${this@name}.log

Aggiungendo nella configurazione dei servizi l'import logback, otteniamo automaticamente il logging configurato per ogni servizio:

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

È giunto il momento di esaminare più a fondo tutti i placeholder 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 cartella di destinazione del componente (i file ricevuti verranno posizionati in questa cartella).
${this@configRoot} — restituisce il percorso completo della cartella radice del deposito delle configurazioni.

Inoltre, il sistema consente di ottenere variabili di ambiente, ad esempio il percorso di java:
${env@JAVA_HOME}
Oppure, dato che il framework è scritto in JAVA, possiamo ottenere variabili di sistema simili alla chiamata System::getProperty utilizzando una struttura di questo tipo:
${system@os.name}
Vale la pena menzionare il supporto per il linguaggio di estensione Spring EL. In 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 espressioni. #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 piuttosto potente per la fine e flessibile configurazione delle configurazioni dei microservizi. Il framework svolge perfettamente il suo compito principale: eliminare il codice duplicato nelle impostazioni, consolidare le configurazioni e di conseguenza ridurre al minimo gli errori possibili, consentendo al contempo di combinare facilmente le configurazioni e modificarle per ambienti diversi.

Se sei interessato a questo framework, ti consiglio di visitare la sua pagina ufficiale e di familiarizzare con la completa documentazione, o di esplorare il codice sorgente. qui.

Fonte: habr.com