Nachdem ich ein bisschen recherchiert hatte, stieß ich auf diesen Artikel, aus dem ich einige Zitate herausgezogen habe, die meiner Meinung nach hilfreich für das sind, was ich erreichen möchte (und für zukünftige Leser). Dies bietet eine Möglichkeit, ein reaktives Programmiermodell über ein imperatives Programmiermodell zu übernehmen.
Event-Sourcing
Die Idee dabei ist, den Statusübergang jeder Anwendung in Form eines unveränderlichen Ereignisses darzustellen. Ereignisse werden dann in einem Protokoll oder Journal gespeichert, sobald sie auftreten (auch als "Ereignisspeicher" bezeichnet). Sie können auch auf unbestimmte Zeit abgefragt und gespeichert werden, um darzustellen, wie sich der Status der Anwendung im Laufe der Zeit insgesamt entwickelt hat.
Dies trägt dazu bei, dass, wenn ein Mikrodienst ausfällt, andere Ereignisse, die für ihn relevant sind, veröffentlicht werden und Ereignisse beispielsweise von anderen Instanzen dieses Mikrodiensts verbraucht werden, auf den dieser Mikrodienst beim erneuten Aufrufen Bezug nehmen kann event store, um alle abzurufen Ereignisse, die es während der Periode verpasste, in der es unterging.
Apache Kafka als Event Broker
Erwägen Sie die Verwendung von Apache Kafka, das Tausende von Ereignissen pro Sekunde speichern und versenden kann und über integrierte Replikations- und Fehlertoleranzmechanismen verfügt. Es verfügt über einen permanenten Speicher mit Ereignissen, die auf unbestimmte Zeit auf der Festplatte gespeichert und zu jedem Zeitpunkt (jedoch nicht entfernt) aus dem Topic (Kafkas ausgefallene Warteschlange), an den sie übermittelt wurden, konsumiert werden können.
Den Ereignissen werden dann Offsets zugewiesen, die sie innerhalb des Themas eindeutig identifizieren. Kafka kann die Offsets selbst verwalten und auf einfache Weise "höchstens einmal" oder "mindestens einmal" Übermittlungssemantik bereitstellen. Sie können jedoch auch ausgehandelt werden, wenn ein Ereigniskonsument einem Thema beitritt Dies ermöglicht es Microservices, Ereignisse von jedem beliebigen Ort aus zu konsumieren - in der Regel von dem Ort an, an dem der Konsument aufgehört hat. Wenn der zuletzt verbrauchte Ereignisversatz im lokalen Speicher des Dienstes transaktionell beibehalten wird, wenn der Verwendungszweck "erfolgreich abgeschlossen" ist, kann dieser Versatz leicht verwendet werden, um eine "genau einmalige" Ereignisübermittlungssemantik zu erzielen.
Wenn sich Verbraucher bei Kafka identifizieren, zeichnet Kafka auf, welche Nachrichten an welchen Verbraucher übermittelt wurden, damit er sie nicht erneut bereitstellt.
Sagas
Bei komplexeren Anwendungsfällen, bei denen die Kommunikation zwischen verschiedenen Diensten tatsächlich erforderlich ist, muss die Verantwortung für die Ausführung des Anwendungsfalls klar erkannt werden. Der Anwendungsfall ist dezentralisiert und wird erst dann beendet, wenn alle beteiligten Dienste ihre Aufgabe als erfolgreich abgeschlossen anerkennen. Andernfalls muss der gesamte Anwendungsfall fehlschlagen Korrekturmaßnahmen müssen ausgelöst werden, um einen ungültigen lokalen Status zurückzusetzen.
Dies ist, wenn die Saga ins Spiel kommt. Eine Saga ist eine Folge lokaler Transaktionen. Jede lokale Transaktion aktualisiert die Datenbank und veröffentlicht eine Nachricht oder ein Ereignis, um die nächste lokale Transaktion in der Saga auszulösen. Wenn eine lokale Transaktion fehlschlägt, weil sie gegen eine Geschäftsregel verstößt, führt die Saga eine Reihe von Ausgleichstransaktionen aus, die die durch die vorhergehenden lokalen Transaktionen vorgenommenen Änderungen rückgängig machen. Lesen Sie dies für weitere Informationen.