Micro-Services und Datenreplikation

Ich erstelle eine neue Anwendung und habe über die Architektur von Mikrodiensten gelesen. Die Architektur selbst ist aus Sicht der Entwicklung, Bereitstellung und des Lebenszyklusmanagements sehr sinnvoll. Es stellte sich jedoch die Frage, wie mit Stammdaten umgegangen werden soll.

Zum Beispiel habe ich 2 Apps - sagen wir Sales App und eine Ticketing App. Angenommen, beide Apps sind als eigene Mikrodienste erstellt. Wenn diese beiden Apps bereitgestellt werden (vorausgesetzt, sie werden separat bereitgestellt, dh Sales verwendet MongoDB und Ticketing verwendet MariaDB), müssen sie jedoch Zugriff auf dieselben Stammdateninstanzen haben, z. B. Accounts, Products. Dies würde bedeuten, dass es eine Eigentümer-App für eine bestimmte Stammdatenentität (z. B. für Konten, bei der es sich möglicherweise um die Verkaufs-App handelt) und eine interessierte Partei (z. B. für die Ticketing-App müssen Informationen zu Konten vorliegen) gibt.

Dies kann auf verschiedene Arten erreicht werden: - Datenreplikation vom Master zum Interessenten - Synchrones Lesen vom Interessenten zum Master (Synchronisierungsabhängigkeit wird vom Modell der Mikrodienstarchitektur nicht empfohlen) - Eigenes zentralisiertes Repository

Auch innerhalb von Accounts kann es einen Kernteil geben, der sowohl für den Verkauf als auch für das Ticketing gilt (z. B. Kontoname, Adresse usw.). Einige Aspekte des Kontos sind möglicherweise NUR für den Verkauf und andere NUR für das Ticketing relevant.

Irgendwelche Gedanken / Best Practices / Meinungen zu einer der oben genannten Optionen?

Ich war Teil eines Teams, das erfolgreich eine Microservices-Architektur mithilfe eines Servicebusses erstellt hat.

Anfänglich glaubten wir, dass Microservices und eine ereignisgesteuerte Architektur es uns ermöglichen würden , die zugrunde liegende Ball-of-Mud-Datenbank für gemeinsame Daten zu reparieren.

Was wir gelernt haben, war, dass Microservices und eine ereignisgesteuerte Architektur es erforderlich machten, die zugrunde liegende Ball-of-Mud-Datenbank für gemeinsame Daten loszuwerden.

Ich glaube, dass es unglaublich schwierig ist, gemeinsam genutzte Daten mit Microservices zu verarbeiten - für mich ist es unglaublich schwierig. Ich empfehle , so dass keine Dienste sehen jeweils andere Daten. Wenn Sie es nicht abfragen können, können Sie nicht versehentlich eine Abhängigkeit einführen.

Wenn Sie tun , Daten austauschen, sicherlich nur ein Service kann je einen Rekord OWN; Es ist der einzige Dienst, der in den Datensatz schreibt, und alle anderen Benutzer mit denselben Daten sollten nur Lesezugriff haben.

Leider führt selbst diese kleine verwaltete Menge an Freigaben zu einer erheblichen Kopplung zwischen Ihren Diensten. Was ist, wenn ein Dienst die Daten nicht in dieser Form haben möchte? Vielleicht will es eine Aggregation. Veranlassen Sie Ihren "Eigentümer / Schreib" -Dienst, aggregierte Daten zugunsten eines anderen Dienstes zu schreiben? Ich würde nicht raten.

Was ist, wenn der Eigentümer die Daten in einer anderen Form beibehalten möchte? Dann muss jeder Leserservice aktualisiert werden. Das ist ein Alptraum für die Instandhaltung.

Die beste Lösung war eine signifikante Vervielfältigung und Denormalisierung unserer Daten. Micro Services unterhielt eigene Kopien der Daten, die sie betreuten.

Nachrichten wurden häufig mit genügend Begleitdaten veröffentlicht, um sie zu verarbeiten.

Sie könnten sich beispielsweise vorstellen, dass ein Postversanddienst Änderungen an einer Kundenadresse nachverfolgen muss, falls er etwas posten muss. Wenn Ihre Nachricht "Artikel zum Versand bereit" jedoch die Zieladresse als Teil der Nachrichtendaten enthält, muss der Versanddienst die sich ändernden Adressen in Bezug auf Kunden überhaupt nicht mehr nachverfolgen. Nur Adressen zu bestimmten Zeitpunkten, die sich auf Artikel beziehen, wenn diese versendet werden.

Ich kann nicht vorschlagen, wie man Lösungen mit synchronisierten Daten erstellt. Unsere Datenlösungen basieren auf der Idee der "eventuellen Konsistenz".

Wenn ein Kunde seine Adresse aktualisiert, verarbeitet der Adressdienst den anfänglichen Befehl von der Benutzeroberfläche. Sobald ihre Daten korrekt sind, veröffentlicht sie eine Veranstaltung, um alle anderen interessierten Dienste über "Kundenadresse aktualisiert" zu informieren - mit der vollständigen Adresse als Daten. Diese Dienste aktualisieren ihre eigenen Datenspeicher mit den Teilen der Daten, die ihnen wichtig sind.

Die Idee ist, dass ein Dienst jedes Mal, wenn er eine wichtige Aktion ausführen muss, eine Kopie der Informationen haben sollte, die aktuell genug ist, um korrekt zu handeln, entweder unabhängig nachverfolgt oder als Teil der Nachricht, auf die er antwortet.

Gemeinsame Datenspeicherung würde gegen die Microservice-Architektur verstoßen. Der Punkt ist, wenn es Konten gibt, sollte es einen Dienst geben, der sie verwaltet, und es sollte keine andere Möglichkeit geben, mit diesen Konten zu interagieren, als den Dienst gründlich zu durchlaufen. Ihre Microservices wären nicht unabhängig, wenn sie gemeinsamen Speicher hätten und Änderungen am Speichermechanismus, der Validierung oder andere Einschränkungen in beiden Services implementiert werden müssten. In der Praxis passiert dies nie und führt bald dazu, dass beide Anwendungen vor ernsthaften Änderungen bewahrt werden.

Verwenden Sie daher einen Dienst als einzige Möglichkeit, auf Ihre Daten zuzugreifen, z. B. Konten. Es kann vorkommen, dass für die Implementierung einer Funktion in einem anderen Dienst eine Änderung des Kontodienstes erforderlich ist. Dies ist in Ordnung. Denken Sie daran, dass die für einen Dienst spezifische Logik in diesem Dienst enthalten sein sollte und dass so wenig spezifisches Material wie möglich in den Microservice "Accounts" aufgenommen werden sollte.

müssen Zugriff auf dieselben Stammdateninstanzen haben, z. B. Konten, Produkte

Nicht das gleiche. Jeder Mikrodienst sollte eine eigene Zuordnung für Konten, Produkte usw. vornehmen. Wir gehen davon aus, dass jeder Mikrodienst eine andere Arbeitsweise mit den Entitäten hat.

In Domain Driven Design ist dies häufig der Fall, wenn jeder begrenzte Kontext (in derselben App!) Dieselbe Entität auf unterschiedliche Weise abbilden kann.

Wenn Sie weitere Informationen benötigen, empfehle ich das Buch Erstellen von Microservices: Entwerfen feinkörniger Systeme

Haben Sie das Konzept von Gerüstaufzeichnungen auf der Grundlage eines Master-Sets in Betracht gezogen?

Beispielsweise verwaltet ein Mikrodienst Konten und der andere Produkte. Ein Dritter kann für seinen domänenspezifischen Zweck Aufzeichnungen von beiden aufbewahren.