Microservices. Vereinigung und warum es so wichtig ist. Teil 1 - Konfiguration



    Einleitung


    Guten Tag an alle. Ich bin ein Python-Entwickler in einem Unternehmen, das sich auf integrierte Lösungen zur Automatisierung von Geschäftsprozessen, Lösungen für die Lösung einzelner Probleme, Analyse und Beratung spezialisiert. Meine Aufgaben umfassen die Entwicklung und Pflege der Microservice-Architektur. Und heute möchte ich Ihnen sagen, wie wir gegen Mikrodienste vorgehen und warum die Vereinigung für sie so wichtig ist.

    Es ist kein Geheimnis, dass diese Herangehensweise an die Produktentwicklung den Markt zunehmend erobert. Und je mehr wir in sie eintauchen, desto mehr müssen wir die Grundregeln der Arbeit mit ihnen nicht vergessen. Um unsere Erfahrung im Schreiben von Microservice-Produkten zu strukturieren, wurde beschlossen, eine Reihe von Artikeln zu schreiben, in denen einige Aspekte der Entwicklung für alle Dienste zusammengefasst werden.

    Eine dieser Regeln ist die Vereinheitlichung. In unserem Unternehmen bestehen die meisten Produkte aus einem Haufen verschiedener Sprachen und Technologien. An diesem ganzen Stand muss man sich überlegen, wie man die grundlegenden Prinzipien auf alle Mikrodienste verallgemeinern kann, um sie einfach zu unterstützen, anpassbar zu machen und bequem zu entwickeln. Dies wird in einer Reihe von Artikeln diskutiert.

    Alle interessiert an Fragen unter der Katze.

    Das Problem


    Möglicherweise stoßen Sie bei der Entwicklung eines Dienstes zuerst auf Konfigurationsmethoden. In der Microservice-Architektur wird dieses Problem noch akuter.

    Stellen Sie sich vor, Sie haben ungefähr zwei Dutzend Dienste und müssen in jedem einen Parameter ändern. Deaktivieren Sie beispielsweise die Verwendung von CORS. Da das System aus mehreren Komponenten besteht und auf Mikrodienstleistungen basiert, ist es für die bequeme Verwaltung am besten, einen einheitlichen Ansatz für die Konfiguration aller Module zu verwenden. Daher müssen Sie beim Einrichten jedes Moduls denselben Ansatz verwenden.

    Sie können sagen, dass der Entwickler jedes Dienstes dies tun sollte. Was aber, wenn alle Ihre Konfigurationen in denselben Kubernetes gespeichert sind, auf die nicht alle Entwickler Zugriff haben sollten? Arme DevOps müssen viel Zeit damit verbringen, die Dienste und Methoden ihrer Konfigurationen zu erlernen. Dieser Vorgang wird mit den Aktualisierungsdiensten wiederholt, insbesondere wenn jemand etwas Neues beim Einrichten des Dienstes versuchen möchte. Bei diesem Ansatz wird sich das Team ständig mit der Arbeit mit Konfigs beschäftigen und nicht mit der Entwicklung neuer Funktionen, dem Bearbeiten von Fehlern usw.

    Nur für diesen Fall ist eine gängige Konfigurationsmethode erforderlich, die nicht an eine bestimmte Sprache oder Technologie gebunden ist und die es Ihnen ermöglicht, alle Dienste mit minimalen Unterschieden in der allgemeinen Struktur der Konfiguration anzupassen. Für diese Aufgabe haben wir ein System zur Einrichtung von „Modulen“ (Diensten) mit Hilfe von YAML-Dateien entwickelt, die Möglichkeit, Konfigurationen für verschiedene Stufen (dev / prod / local usw.) zu speichern und das Ganze in verschiedene Blöcke zu unterteilen, die sich auf bestimmte Dinge beziehen.

    Spezifikation


    Sie können viel darüber sagen, wo und wie es verwendet werden kann, aber ich schlage vor, Sie gehen direkt zur Spezifikation dieser Konfigurationsmethode. Die Theorie ist gut, und die Praxis ist noch besser.

    Systemvoraussetzungen


    Beginnen wir mit der Definition unseres Systems und der Anforderungen dafür.
    • Jedes Modul ist eine unabhängige Komponente in einem Container.
    • Wir können Umgebungsvariablen in den Container übergeben.
    • Wir können die Konfiguration NICHT im laufenden Betrieb ändern, ohne den Dienst neu zu starten (Erstellen eines neuen Containers).
    • Alle Fallback-Aktionen (z. B. das Wechseln zur Sicherungsdatenbank) werden außerhalb der Komponente ausgeführt und sind für diese transparent.


    Anforderungen an die Konfigurationsmethode


    Jetzt definieren wir, was wir von unserer Konfigurationsmethode erwarten, um alle Anforderungen zu erfüllen.

    1. Der Typ der Konfigurationsdatei ist YAML der angegebenen Struktur. YAML wurde von uns aus mehreren Gründen ausgewählt:
      • Die Fähigkeit, Kommentare und eine bequeme Struktur im Gegensatz zu JSON zu schreiben
      • Möglichkeit, Arrays im Gegensatz zu ENV zu beschreiben
      • Im Auslieferungszustand können Sie from values.yaml in helm (Kubernetes) einschließen.

    2. Konfigurationsdateien sollten im Konfigurationsbaum merzhitsya sein
    3. Die Konfiguration muss stufenspezifisch sein. Jede Stufe hat ein eigenes vollständiges Set. Es empfiehlt sich, einige Vorbehalte zu klären:
      • Es ist nicht möglich, die Werte von Variablen aus einer anderen Stufe wiederzuverwenden , außer auf der Seite mit den Standardwerten, die für Standardwerte reserviert ist.
      • Beim Laden einer Konfiguration ist es erforderlich, eine rekursive Zusammenführung der Konfigurationsebene aus der angegebenen Stufe über die Standardwerte mit der Priorität der Ebene der angegebenen Stufe vorzunehmen. Werte (Arrays usw.) sollten nicht kombiniert werden.
      • Wenn für eine Stufe mehrere Konfigurationsdateien vorhanden sind, müssen die Schlüssel darin zusammengeführt werden und müssen dementsprechend relativ zueinander eindeutig sein.

    4. Die aktuell verwendete Stufe sollte durch den Wert der Umgebungsvariablen "STAGE" bestimmt werden. Eine Änderung der Arbeitsinstanz des Dienstes wird nicht angenommen.
    5. Der absolute Pfad zum Konfigurationsverzeichnis muss durch den Wert der Umgebungsvariablen CONFIG_PATH festgelegt werden. Der Bequemlichkeit halber ist ein Fallback möglich, wenn eine Variable nicht auf einen bestimmten Standardpfad gesetzt ist, der in der Dokumentation des Moduls angegeben werden muss. In diesem Fall muss der angegebene Pfad relativ zum Stammverzeichnis des Anwendungsverzeichnisses sein.


    Konfigurationsbeispiele


    Angenommen, wir haben einen Dienst, der die Verbindungseinstellungen für Postgres sowie einige Informationen über uns selbst speichern muss.

    Zuerst müssen Sie die Konfiguration für STAGE = Standardwerte definieren. Darin beschreiben wir die allgemeine Struktur und machen die Daten unabhängig von der Bühne.

    Standardeinstellungen


    # configuration/defaults/service.yaml
    defaults:
      version: 1.0.0
      name: "config-example"
    # configuration/defaults/redis.yaml
    defaults:
      redis:
        host: "host"
        db: 0
        port: 6379
        password: "password"


    dev


    # configuration/dev/redis.yaml
    dev:
      redis:
        host: "localhost"
        password: "hard_pwd"


    Die resultierende Konfig


    version: 1.0.0
    name: "config-example"
    redis:
        host: "localhost"
        db: 0
        port: 6379
        password: "hard_pwd"


    Schlussfolgerungen



    Auf diese Weise haben wir das Problem der Konfiguration von Diensten in unserem Zoo gelöst und alles auf einen Blick dargestellt. Dieses Beispiel ist nur ein Ausgangspunkt und kann an die Besonderheiten Ihres Projekts angepasst werden.

    Für diejenigen, die an dieser Konfigurationsmethode in der "bloßen Form" interessiert sind:
    Unsere Pakete für verschiedene Programmiersprachen


    Für die schriftliche Hilfe, danke Roque , SMGladkovskiy

    Jetzt auch beliebt: