Einführung
Wie Sie wissen, verursacht der Übergang von einem Monolithen zu einer Microservice-Architektur eine Reihe von Schwierigkeiten, die sowohl mit dem technischen Teil des Projekts als auch mit dem menschlichen Faktor verbunden sind. Eine der schwierigsten technischen Herausforderungen besteht darin, die Konsistenz in einem verteilten System sicherzustellen .
Letztes Mal haben wir die Ursachen für Konsistenzprobleme in einer Microservice-Architektur, den optimistischen Ansatz für die Konsistenz und die Konsistenz mithilfe eines zweiphasigen Commits erörtert.
Saga-Muster
Saga ist ein Mechanismus zur Sicherstellung der Datenkonsistenz in einer Microservice-Architektur ohne Verwendung verteilter Transaktionen.
Für jeden Systembefehl, der Daten in mehreren Diensten aktualisieren muss, wird eine Saga erstellt. Die Saga ist eine Art "Checkliste", die aus sequentiellen lokalen ACID-Transaktionen besteht, von denen jede Daten in einem Dienst aktualisiert. Eine Ausgleichstransaktion wird angewendet, um Fehler zu behandeln. Solche Transaktionen werden im Falle eines Fehlers auf allen Diensten ausgeführt, auf denen lokale Transaktionen erfolgreich abgeschlossen wurden.
Es gibt verschiedene Arten von Transaktionen in der Saga, bis zu vier:
- Kompensieren - Bricht eine Änderung ab, die durch eine lokale Transaktion vorgenommen wurde.
- Eine Kompensation ist eine Transaktion, die kompensiert (rückgängig gemacht) werden muss, falls nachfolgende Transaktionen fehlschlagen.
- Pivotal - eine Transaktion, die den Erfolg der gesamten Saga bestimmt. Wenn es gelingt, wird die Saga garantiert das Ende erreichen.
- Wiederholbar - geht nach dem Drehpunkt und ist garantiert erfolgreich.
Sie können eine Saga mit Choreografie oder Orchestrierung organisieren.
Bei der choreografischen Saga gibt es keinen speziellen Orchestrator. Am Beispiel des Bestellservices und der Benutzer könnte dies folgendermaßen aussehen: Der Bestellservice empfängt eine Anforderung, erstellt eine Bestellung im Status PENDING und veröffentlicht dann das Ereignis "Bestellung erstellt". Ein Ereignishandler im Benutzerdienst verarbeitet dieses Ereignis, versucht, ein Element zu reservieren, und veröffentlicht das Ergebnis als Ereignis. Der Bestellservice verarbeitet dieses Ereignis und bestätigt oder storniert die Bestellung je nach Leseergebnis.
Die orchestrierte Saga sieht etwas interessanter aus. Am Beispiel der oben genannten Dienste könnte dies folgendermaßen aussehen: Der Bestelldienst empfängt eine Anforderung, erstellt eine Saga, die eine Bestellung im Status PENDING erstellt, und sendet dann einen Befehl zum Reservieren von Waren für den Benutzerdienst. Der Benutzerdienst versucht, das Produkt zu reservieren, und sendet eine Antwortnachricht mit dem Ergebnis. Die Saga genehmigt oder storniert die Bestellung.
Das Saga-Muster ermöglicht es einer Anwendung, die Datenkonsistenz über mehrere Dienste hinweg aufrechtzuerhalten, ohne verteilte Transaktionen (zweiphasige Festschreibungen) zu verwenden und die im vorherigen Artikel beschriebenen Probleme zu vermeiden. Andererseits ist das Programmiermodell sehr kompliziert: Beispielsweise muss der Entwickler für jede Transaktion eine Ausgleichstransaktion schreiben, die die zuvor in der Saga vorgenommenen Änderungen rückgängig macht.
Die Saga ermöglicht es uns, ein ACD-Modell zu erreichen (Atomizität + Konsistenz + Haltbarkeit in ACID-Begriffen), aber wir haben einen Buchstaben verloren. Das Fehlen des Briefes I führt zu den bekannten Problemen der mangelnden Isolation. Dazu gehören: verlorene Updates - eine Saga überschreibt die von einer anderen vorgenommenen Änderungen, ohne sie zu lesen, Dirty Reads - eine Transaktion oder Saga liest unvollendete Updates einer anderen Saga, Fuzzy / nicht wiederholbare Lesevorgänge) - Zwei verschiedene Phasen der Saga lesen dieselben Daten, erzielen jedoch unterschiedliche Ergebnisse, da eine andere Saga eine Änderung vorgenommen hat. Es gibt eine Reihe von Mustern, mit denen Sie bestimmte Anomalien beheben können: semantische Sperren, kommutative Aktualisierungen, pessimistische Darstellung, erneutes Lesen eines Werts, Änderungsdatei und nach Wert.Das Problem der Gewährleistung der Isolation bleibt offen.
Ein weiteres interessantes Problem ist die Unmöglichkeit, die Datenbank atomar zu aktualisieren und eine Nachricht an den Nachrichtenbroker zu senden, um weitere Schritte in der Saga auszulösen.
Fazit
Wir sprachen über Möglichkeiten, eine Saga mithilfe von Choreografie und Orchestrierung zu organisieren, sowie über die Probleme, die dieses Muster mit sich bringt. Als Nächstes werden Möglichkeiten zur Behebung einiger Anomalien und zum transaktionalen Senden von Nachrichten an den Nachrichtenbroker erläutert.
