Saga-Muster

Eine Saga besteht aus einer Abfolge von lokalen Transaktionen. Jede lokale Transaktion in einer Saga aktualisiert die Datenbank und löst die nächste lokale Transaktion aus. Wenn eine Transaktion fehlschlägt, führt die Saga kompensierende Transaktionen aus, um die von den vorherigen Transaktionen vorgenommenen Datenbankänderungen rückgängig zu machen.

Diese Abfolge von lokalen Transaktionen trägt dazu bei, einen Geschäfts-Workflow zu erreichen, indem Fortsetzungs- und Kompensationsprinzipien verwendet werden. Das Fortsetzungsprinzip entscheidet über die Vorwärtswiederherstellung des Workflows, während das Kompensationsprinzip über die Rückwärtswiederherstellung entscheidet. Wenn die Aktualisierung in irgendeinem Schritt der Transaktion fehlschlägt, veröffentlicht die Saga ein Ereignis, um entweder die Transaktion fortzusetzen (um sie erneut zu versuchen) oder zu kompensieren (um zum vorherigen Datenzustand zurückzukehren). Dadurch wird sichergestellt, dass die Datenintegrität gewahrt bleibt und in allen Datenspeichern konsistent ist.

Wenn ein Benutzer beispielsweise ein Buch bei einem Online-Händler kauft, besteht der Prozess aus einer Abfolge von Transaktionen – wie Auftragserstellung, Inventaraktualisierung, Zahlung und Versand –, die einen Geschäfts-Workflow darstellen. Um diesen Workflow abzuschließen, gibt die verteilte Architektur eine Abfolge von lokalen Transaktionen aus, um eine Bestellung in der Bestelldatenbank zu erstellen, die Inventardatenbank zu aktualisieren und die Zahlungsdatenbank zu aktualisieren. Wenn der Vorgang erfolgreich ist, werden diese Transaktionen nacheinander aufgerufen, um den Geschäfts-Workflows abzuschließen, wie das folgende Diagramm zeigt. Wenn jedoch eine dieser lokalen Transaktionen fehlschlägt, sollte das System in der Lage sein, sich für einen geeigneten nächsten Schritt zu entscheiden, d. h. entweder eine Vorwärts- oder eine Rückwärtswiederherstellung.

Anhand der folgenden beiden Szenarien lässt sich feststellen, ob der nächste Schritt eine Vorwärts- oder eine Rückwärtswiederherstellung sein sollte:

• Fehler auf Plattformebene, bei dem etwas mit der zugrunde liegenden Infrastruktur defekt ist und die Transaktion zum Fehlschlagen bringt. In diesem Fall kann das Saga-Muster eine Vorwärtswiederherstellung durchführen, indem die lokale Transaktion erneut versucht und der Geschäftsprozess fortgesetzt wird.

• Fehler auf Anwendungsebene, bei dem der Zahlungsservice aufgrund einer ungültigen Zahlung fehlschlägt. In diesem Fall kann das Saga-Muster eine Rückwärtswiederherstellung durchführen, indem es eine Ausgleichstransaktion durchführt, um das Inventar und die Bestelldatenbanken zu aktualisieren und ihren vorherigen Status wiederherzustellen.

Das Saga-Muster verwaltet den Geschäfts-Workflow und stellt sicher, dass durch die Vorwärtswiederherstellung ein gewünschter Endzustand erreicht wird. Bei Ausfällen werden die lokalen Transaktionen mithilfe der Rückwärtswiederherstellung rückgängig gemacht, um Probleme mit der Datenkonsistenz zu vermeiden.

Das Saga-Muster hat zwei Varianten: Choreographie und Orchestrierung.

Saga-Choreographie

Das Saga-Choreographiemuster hängt von den Ereignissen ab, die von den Microservices veröffentlicht werden. Die Saga-Teilnehmer (Microservices) abonnieren die Ereignisse und handeln auf der Grundlage der Ereignisauslöser. Beispielsweise gibt der Bestellservice im folgenden Diagramm ein OrderPlaced-Ereignis aus. Der Inventarservice abonniert dieses Ereignis und aktualisiert das Inventar, wenn das OrderPlaced-Ereignis ausgegeben wird. In ähnlicher Weise verhalten sich die teilnehmenden Services auf Grundlage des Kontextes des ausgegebenen Ereignisses.

Das Saga-Choreographiemuster eignet sich, wenn nur wenige Teilnehmer an der Saga beteiligt sind und Sie eine einfache Implementierung benötigen, bei der es keine einzelne Fehlerquelle gibt. Wenn mehr Teilnehmer hinzugefügt werden, wird es schwieriger, die Abhängigkeiten zwischen den Teilnehmern anhand dieses Musters nachzuverfolgen.

Eine ausführliche Übersicht finden Sie im Abschnitt zur Saga-Choreographie dieses Handbuchs.

Saga-Orchestrierung

Das Saga-Orchestrierungsmuster hat einen zentralen Koordinator, der als Orchestrator bezeichnet wird. Der Saga-Orchestrator verwaltet und koordiniert den gesamten Transaktionslebenszyklus. Er ist sich der Reihe von Schritten bewusst, die ausgeführt werden müssen, um die Transaktion abzuschließen. Um einen Schritt auszuführen, sendet er eine Nachricht an den Teilnehmer-Microservice, der den Vorgang ausführen soll. Der Teilnehmer-Microservice schließt den Vorgang ab und sendet eine Nachricht zurück an den Orchestrator. Auf der Grundlage der empfangenen Nachricht entscheidet der Orchestrator, welcher Microservice als Nächstes in der Transaktion ausgeführt werden soll.

Das Saga-Orchestrierungs-Muster eignet sich, wenn es viele Teilnehmer gibt und eine lose Verkoppelung zwischen den Saga-Teilnehmern erforderlich ist. Der Orchestrator kapselt die Komplexität in der Logik ab, indem er die lose Verkoppelung der Teilnehmer sicherstellt. Der Orchestrator kann jedoch zu einem einzelnen Ausfallpunkt werden, da er den gesamten Workflow steuert.

Eine ausführliche Übersicht finden Sie im Abschnitt zur Saga-Orchestrierung dieses Handbuchs.