Verwalten Sie Microservice-Konfigurationen ganz einfach mit microconfig.io

Eines der Hauptprobleme bei der Entwicklung und dem anschließenden Betrieb von Microservices ist die kompetente und genaue Konfiguration ihrer Instanzen. Meiner Meinung nach kann ein neues Framework dabei helfen microconfig.io. Damit können Sie einige routinemäßige Anwendungskonfigurationsaufgaben ganz elegant lösen.

Wenn Sie über viele Microservices verfügen und jeder von ihnen über eine eigene Konfigurationsdatei/-dateien verfügt, besteht eine hohe Wahrscheinlichkeit, dass in einem von ihnen ein Fehler auftritt, der ohne entsprechende Kenntnisse und ein Protokollierungssystem sehr schwer zu erkennen sein kann. Die Hauptaufgabe, die sich das Framework stellt, besteht darin, doppelte Instanzkonfigurationsparameter zu minimieren und so die Wahrscheinlichkeit des Hinzufügens eines Fehlers zu verringern.

Schauen wir uns ein Beispiel an. Nehmen wir an, wir haben eine einfache Anwendung mit einer Konfigurationsdatei YAML. Dies kann ein beliebiger Microservice in jeder Sprache sein. Sehen wir uns an, wie das Framework auf diesen Dienst angewendet werden kann.

Der Einfachheit halber erstellen wir jedoch zunächst ein leeres Projekt in Idea IDE, nachdem wir das microconfig.io-Plugin darin installiert haben:

Verwalten Sie Microservice-Konfigurationen ganz einfach mit microconfig.io

Wir richten die Plugin-Startkonfiguration ein; Sie können die Standardkonfiguration verwenden, wie im Screenshot oben.

Unser Service heißt Bestellung, dann werden wir in einem neuen Projekt eine ähnliche Struktur erstellen:

Verwalten Sie Microservice-Konfigurationen ganz einfach mit microconfig.io

Platzieren Sie die Konfigurationsdatei im Ordner mit dem Dienstnamen – application.yaml. Alle Microservices werden in einer bestimmten Umgebung gestartet. Daher ist es nicht nur erforderlich, eine Konfiguration für den Dienst selbst zu erstellen, sondern auch die Umgebung selbst zu beschreiben: Dazu erstellen wir einen Ordner envs und fügen Sie eine Datei mit dem Namen unserer Arbeitsumgebung hinzu. Daher erstellt das Framework Konfigurationsdateien für Dienste in der Umgebung dev, da dieser Parameter in den Plugin-Einstellungen festgelegt wird.

Dateistruktur dev.yaml es wird ganz einfach sein:

mainorder:
    components:
         - order

Das Framework arbeitet mit Konfigurationen, die gruppiert sind. Wählen Sie für unseren Service einen Namen für die Gruppe Hauptbestellung. Das Framework findet jede dieser Anwendungsgruppen in der Umgebungsdatei und erstellt für alle Konfigurationen, die es in den entsprechenden Ordnern findet.

In der Diensteinstellungsdatei selbst Auftrag Lassen Sie uns vorerst nur einen Parameter angeben:

spring.application.name: order

Lassen Sie uns nun das Plugin ausführen und es generiert die erforderliche Konfiguration für unseren Dienst gemäß dem in den Eigenschaften angegebenen Pfad:

Verwalten Sie Microservice-Konfigurationen ganz einfach mit microconfig.io

Man kann Komm durch Und ohne ein Plugin zu installieren, laden Sie einfach die Framework-Distribution herunter und führen Sie sie über die Befehlszeile aus.
Diese Lösung ist für den Einsatz auf einem Build-Server geeignet.

Es ist erwähnenswert, dass das Framework perfekt verstanden wird Resorts Syntax, d. h. gewöhnliche Eigenschaftendateien, die zusammen verwendet werden können YAML Konfigurationen.

Fügen wir einen weiteren Dienst hinzu Zahlung und das Bestehende komplizieren.
В Auftrag:

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

В Zahlung:

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

Das Hauptproblem bei diesen Konfigurationen ist das Vorhandensein einer großen Menge an Kopier- und Einfügevorgängen in den Diensteinstellungen. Mal sehen, wie das Framework dabei hilft, es loszuwerden. Beginnen wir mit dem Offensichtlichsten – dem Vorhandensein von Konfiguration Heureka in der Beschreibung jedes Microservices. Erstellen wir ein neues Verzeichnis mit der Einstellungsdatei und fügen wir eine neue Konfiguration hinzu:

Verwalten Sie Microservice-Konfigurationen ganz einfach mit microconfig.io

Und jetzt fügen wir die Zeile zu jedem unserer Projekte hinzu #include eureka.

Das Framework findet die Eureka-Konfiguration automatisch und kopiert sie in die Dienstkonfigurationsdateien, während keine separate Eureka-Konfiguration erstellt wird, da wir sie nicht in der Umgebungsdatei angeben dev.yaml. Service Auftrag:

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

Wir können die Datenbankeinstellungen auch in eine separate Konfiguration verschieben, indem wir die Importzeile in ändern #include eureka, Orakel.

Es ist erwähnenswert, dass das Framework jede Änderung beim Neugenerieren von Konfigurationsdateien verfolgt und sie in einer speziellen Datei neben der Hauptkonfigurationsdatei ablegt. Der Eintrag im Protokoll sieht folgendermaßen aus: „Gespeicherte 1 Eigenschaftsänderungen an order/diff-application.yaml" Dadurch können Sie Änderungen an großen Konfigurationsdateien schnell erkennen.

Durch das Entfernen gemeinsamer Teile der Konfiguration können Sie eine Menge unnötiges Kopieren und Einfügen vermeiden, können jedoch nicht flexibel eine Konfiguration für verschiedene Umgebungen erstellen – die Endpunkte unserer Dienste sind einzeln und fest codiert, das ist schlecht. Versuchen wir, dies zu entfernen.

Eine gute Lösung wäre, alle Endpunkte in einer Konfiguration zu belassen, auf die andere verweisen können. Zu diesem Zweck wurde die Unterstützung von Platzhaltern in das Framework eingeführt. Auf diese Weise ändert sich die Konfigurationsdatei Heureka:

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

Sehen wir uns nun an, wie dieser Platzhalter funktioniert. Das System findet eine Komponente mit dem Namen Endpunkte und sucht darin nach einem Sinn eurekaipund ersetzt es dann in unserer Konfiguration. Aber wie sieht es mit unterschiedlichen Umgebungen aus? Erstellen Sie dazu eine Einstellungsdatei in Endpunkte folgender Typ application.dev.yaml. Das Framework entscheidet selbstständig anhand der Dateierweiterung, zu welcher Umgebung diese Konfiguration gehört und lädt sie:

Verwalten Sie Microservice-Konfigurationen ganz einfach mit microconfig.io

Inhalt der Dev-Datei:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

Wir können die gleiche Konfiguration für die Ports unserer Dienste erstellen:

server.port: ${ports@order}.

Alle wichtigen Einstellungen befinden sich an einem Ort, wodurch die Wahrscheinlichkeit von Fehlern aufgrund verstreuter Parameter in Konfigurationsdateien verringert wird.

Das Framework stellt viele vorgefertigte Platzhalter zur Verfügung, man kann sich beispielsweise den Namen des Verzeichnisses, in dem sich die Konfigurationsdatei befindet, holen und zuweisen:

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

Dadurch muss der Anwendungsname nicht zusätzlich in der Konfiguration angegeben werden und er kann auch in einem gemeinsamen Modul platziert werden, beispielsweise im selben Eureka:

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

Die Konfigurationsdatei Auftrag wird auf eine Zeile reduziert:

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

Wenn wir keine Einstellung aus der übergeordneten Konfiguration benötigen, können wir diese in unserer Konfiguration angeben und sie wird bei der Generierung angewendet. Das heißt, wenn wir aus irgendeinem Grund einen eindeutigen Namen für den Bestelldienst benötigen, belassen wir den Parameter einfach spring.application.name.

Nehmen wir an, Sie müssen dem Dienst benutzerdefinierte Protokollierungseinstellungen hinzufügen, die beispielsweise in einer separaten Datei gespeichert werden: logback.xml. Erstellen wir dafür eine separate Gruppe von Einstellungen:

Verwalten Sie Microservice-Konfigurationen ganz einfach mit microconfig.io

In der Grundkonfiguration teilen wir dem Framework mithilfe eines Platzhalters mit, wo die von uns benötigte Datei mit den Protokollierungseinstellungen abgelegt werden soll @ConfigDir:

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

Im Ordner logback.xml Wir konfigurieren Standard-Appender, die wiederum auch Platzhalter enthalten können, die das Framework während der Generierung von Configs ändert, zum Beispiel:

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

Durch Hinzufügen von Import zu Dienstkonfigurationen Wieder anmelden, erhalten wir automatisch die konfigurierte Protokollierung für jeden Dienst:

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

Es ist an der Zeit, sich mit allen verfügbaren Platzhaltern des Frameworks genauer vertraut zu machen:

${this@env} - gibt den Namen der aktuellen Umgebung zurück.
${…@name} – gibt den Namen der Komponente zurück.
${…@configDir} – gibt den vollständigen Pfad zum Konfigurationsverzeichnis der Komponente zurück.
${…@resultDir} – gibt den vollständigen Pfad zum Zielverzeichnis der Komponente zurück (die resultierenden Dateien werden in diesem Verzeichnis abgelegt).
${this@configRoot} – gibt den vollständigen Pfad zum Stammverzeichnis des Konfigurationsspeichers zurück.

Das System ermöglicht es Ihnen auch, Umgebungsvariablen abzurufen, beispielsweise den Pfad zu Java:
${env@JAVA_HOME}
Entweder, da das Framework eingeschrieben ist JAVA, können wir Systemvariablen ähnlich dem Aufruf erhalten System::getProperty mit einer Struktur wie dieser:
${[E-Mail geschützt] }
Erwähnenswert ist die Unterstützung der Erweiterungssprache Frühling EL. In der Konfiguration gelten folgende Ausdrücke:

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

und Sie können mithilfe des Ausdrucks lokale Variablen in Konfigurationsdateien verwenden #var:

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

Somit ist das Framework ein recht leistungsfähiges Werkzeug zur Feinabstimmung und flexiblen Konfiguration von Microservices. Das Framework erfüllt perfekt seine Hauptaufgabe – das Kopieren und Einfügen in Einstellungen zu eliminieren, Einstellungen zu konsolidieren und dadurch mögliche Fehler zu minimieren, während es Ihnen ermöglicht, Konfigurationen einfach zu kombinieren und für verschiedene Umgebungen zu ändern.

Wenn Sie an diesem Framework interessiert sind, empfehle ich Ihnen, die offizielle Seite zu besuchen und sich mit dem vollständigen Inhalt vertraut zu machen Dokumentation, oder stöbern Sie in den Quellen hier.

Source: habr.com

Kommentar hinzufügen