Eines der Hauptprobleme bei der Entwicklung und dem anschließenden Betrieb von Mikrodiensten ist die kompetente und genaue Abstimmung ihrer Instanzen. Meiner Meinung nach kann das neue
microconfig.io- Framework helfen. Damit können Sie einige der Routineaufgaben beim Einrichten von Anwendungen ganz elegant lösen.
Wenn Sie viele Microservices haben und jeder von ihnen seine eigenen Datei- / Einstellungsdateien enthält, ist es wahrscheinlich, dass in einem von ihnen ein Fehler auftritt, der ohne angemessene Geschicklichkeit und ein Protokollierungssystem sehr schwer zu erfassen sein kann. Die Hauptaufgabe, die das Framework selbst festlegt, besteht darin, doppelte Instanzeinstellungen zu minimieren und dadurch die Wahrscheinlichkeit zu verringern, dass ein Fehler hinzugefügt wird.
Schauen wir uns ein Beispiel an. Angenommen, es gibt eine einfache Anwendung mit einer
Yaml- Konfigurationsdatei. Es kann jeder Microservice in jeder Sprache sein. Mal sehen, wie das Framework auf diesen Service angewendet werden kann.
Zur Vereinfachung erstellen wir zunächst ein leeres Projekt in der Ideen-IDE, indem wir zuerst das Plugin microconfig.io darin installieren:
Wir konfigurieren die Plugin-Startkonfiguration. Sie können die Standardkonfiguration wie im obigen Screenshot verwenden.
Unser Service heißt Bestellung, dann werden wir in einem neuen Projekt eine ähnliche Struktur erstellen:
In den Ordner mit dem Namen des Dienstes legen wir die Konfigurationsdatei -
application.yaml . Alle Microservices werden in einer Umgebung gestartet. Neben der Erstellung der Konfiguration des Dienstes selbst muss auch die Umgebung selbst beschrieben werden. Erstellen Sie dazu den Ordner
envs und fügen Sie eine Datei mit dem Namen unserer Arbeitsumgebung hinzu. Daher erstellt das Framework Konfigurationsdateien für Dienste in der
Entwicklungsumgebung , da dieser Parameter in den Einstellungen im Plugin festgelegt ist.
Die Struktur der Datei
dev.yaml ist recht einfach:
mainorder: components: - order
Das Framework arbeitet mit Konfigurationen, die zusammen gruppiert sind.
Wählen Sie für unseren Service einen Namen für die
Hauptbestellgruppe . Das Framework findet jede solche Gruppe von Anwendungen in der Umgebungsdatei und erstellt Konfigurationen für alle Anwendungen, die es in den entsprechenden Ordnern findet.
In der
Bestelldienst -Einstellungsdatei selbst geben wir bisher nur einen Parameter an:
spring.application.name: order
Führen Sie nun das Plugin aus und es generiert die gewünschte Konfiguration unseres Dienstes für uns gemäß dem in den Eigenschaften angegebenen Pfad:
Sie können auf
die Installation des Plugins verzichten, indem Sie einfach das Distributionskit des Frameworks herunterladen und über die Befehlszeile ausführen.
Diese Lösung ist für die Verwendung auf dem Build-Server geeignet.
Es ist anzumerken, dass das Framework die
Eigenschaftssyntax perfekt versteht,
dh gewöhnliche Eigenschaftendateien, die zusammen in
Yaml- Konfigurationen verwendet werden können.
Fügen Sie einen weiteren
Zahlungsdienst hinzu und komplizieren Sie gleichzeitig den vorhandenen.
In der
Reihenfolge :
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
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 Copy Paste in den Serviceeinstellungen. Mal sehen, wie das Framework dabei hilft, es loszuwerden. Beginnen wir mit dem offensichtlichsten - dem Vorhandensein einer
Eureka- Konfiguration in der Beschreibung jedes Mikrodienstes. Erstellen Sie ein neues Verzeichnis mit der Einstellungsdatei und fügen Sie eine neue Konfiguration hinzu:
Und in jedem unserer Projekte werden wir jetzt die Zeile
#include eureka hinzufügen .
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
dev.yaml- Umgebungsdatei angeben. Serviceauftrag:
#include eureka server.port: 9999 spring.application.name: order db.url: 192.168.0.100
Wir können die Datenbankeinstellungen auch in einer separaten Konfiguration
vornehmen, indem wir die Importzeile in
#include eureka, oracle ändern .
Es ist anzumerken, dass jede Änderung während der Neuerstellung von Konfigurationsdateien das Framework überwacht und in einer speziellen Datei neben der Hauptkonfigurationsdatei ablegt. Der Eintrag in seinem Protokoll sieht folgendermaßen aus: "Gespeicherte 1 Eigenschaft ändert sich in
order / diff-application.yaml ". Auf diese Weise können Sie Änderungen in großen Konfigurationsdateien schnell erkennen.
Durch das Entfernen der allgemeinen Teile der Konfiguration können Sie viele unnötige Kopier- und Einfügevorgänge vermeiden, aber Sie können nicht flexibel eine Konfiguration für verschiedene Umgebungen erstellen. Die Endpunkte unserer Dienste sind eindeutig und fest codiert. Dies ist schlecht. Versuchen wir es zu entfernen.
Eine gute Lösung wäre, alle Endpunkte in einer Konfiguration zu belassen, auf die andere verweisen könnten. Zu diesem Zweck wurde die Unterstützung für Platzhalter in das Framework aufgenommen. So ändert sich die
eureka- Konfigurationsdatei:
client: serviceUrl: defaultZone: http://${endpoints@eurekaip}:6782/eureka/
Nun wollen wir sehen, wie dieser Platzhalter funktioniert. Das System findet eine Komponente mit dem Namen
Endpunkte, sucht darin nach
Eurekaip und ersetzt sie dann in unserer Konfiguration. Aber was ist mit verschiedenen Umgebungen? Erstellen Sie dazu die Einstellungsdatei in
Endpunkten des folgenden Typs
application.dev.yaml . Das Framework entscheidet unabhängig über die Dateierweiterung, zu welcher Umgebung diese Konfiguration gehört, und lädt sie:
Der Inhalt der Entwicklungsdatei:
eurekaip: 192.89.89.111 dbip: 192.168.0.100
Wir können dieselbe Konfiguration für die Ports unserer Dienste erstellen:
server.port: ${ports@order}.
Alle wichtigen Einstellungen befinden sich an einem Ort, wodurch die Wahrscheinlichkeit eines Fehlers aufgrund der verstreuten Parameter in den Konfigurationsdateien verringert wird.
Das Framework bietet viele vorgefertigte Platzhalter. Sie können beispielsweise den Namen des Verzeichnisses abrufen, in dem sich die Konfigurationsdatei befindet, und ihn zuweisen:
#include eureka, oracle server.port: ${ports@order} spring.application.name: ${this@name}
Aus diesem Grund muss der Name der Anwendung in der Konfiguration nicht zusätzlich angegeben werden, und sie kann auch in ein gemeinsames Modul verschoben werden, z. B. in dieselbe Eureka:
client: serviceUrl: defaultZone: http://${endpoints@eurekaip}:6782/eureka/ spring.application.name: ${this@name}
Die
Auftragskonfigurationsdatei wird auf eine Zeile reduziert:
#include eureka, oracle server.port: ${ports@order}
Falls wir keine Einstellung aus der übergeordneten Konfiguration benötigen, können wir diese in unserer Konfiguration angeben und sie wird während der Generierung angewendet. Wenn wir aus irgendeinem Grund einen eindeutigen Namen für den Bestellservice benötigen, lassen Sie einfach den Parameter
spring.application.name .
Angenommen, Sie müssen dem Dienst benutzerdefinierte Protokollierungseinstellungen hinzufügen, die in einer separaten Datei gespeichert sind, z. B.
logback.xml . Erstellen Sie eine separate Gruppe von Einstellungen dafür:
In der Grundkonfiguration geben wir das Framework an, in dem die benötigte Protokollierungseinstellungsdatei mithilfe des
Platzhalters @ConfigDir abgelegt werden soll:
microconfig.template.logback.fromFile: ${logback@configDir}/logback.xml
In der Datei
logback.xml konfigurieren
wir Standard-Appender, die wiederum Platzhalter enthalten können, die das Framework während der Generierung von Konfigurationen ändert, zum Beispiel:
<file>logs/${this@name}.log</file>
Durch Hinzufügen des
Logback- Imports in der Dienstkonfiguration erhalten wir automatisch die konfigurierte Protokollierung für jeden Dienst:
#include eureka, oracle, logback server.port: ${ports@order}
Es ist Zeit, sich mit allen verfügbaren Framework-Platzhaltern 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 (empfangene 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, z. B. den Pfad zu Java:
$ {env @ JAVA_HOME}Da das Framework in
JAVA geschrieben ist , können wir Systemvariablen ähnlich dem Aufruf von
System :: getProperty mit einem Konstrukt wie dem folgenden
abrufen :
${system@os.name}Erwähnenswert ist die Unterstützung für die
Spring EL- Erweiterungssprache. In der Konfiguration gelten ähnliche Ausdrücke:
connection.timeoutInMs: #{5 * 60 * 1000} datasource.maximum-pool-size: #{${this@datasource.minimum-pool-size} + 10}
und Sie können lokale Variablen in Konfigurationsdateien mit dem Ausdruck
#var verwenden:
#var feedRoot: ${system@user.home}/feed folder: root: ${this@feedRoot} success: ${this@feedRoot}/archive error: ${this@feedRoot}/error
Somit ist das Framework ein ziemlich leistungsfähiges Werkzeug für die feine und flexible Konfiguration von Microservices. Das Framework erfüllt seine Hauptaufgabe perfekt - das Eliminieren von Copy-Paste in Einstellungen, das Konsolidieren von Einstellungen und das Minimieren möglicher Fehler, während es einfach ist, Konfigurationen und Änderungen für verschiedene Umgebungen zu kombinieren.
Wenn Sie an diesem Framework interessiert sind, empfehle ich Ihnen, die offizielle Seite zu besuchen und die vollständige
Dokumentation zu lesen oder hier in die Quelle
einzutauchen .