Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Ereignis-Sourcing-Muster
Das Ereignis-Sourcing-Muster wird in der Regel mit verwendet, CQRS-Muster um Lese- und Schreib-Workloads zu entkoppeln und Leistung, Skalierbarkeit und Sicherheit zu optimieren. Daten werden als eine Reihe von Ereignissen gespeichert, anstatt Datenspeicher direkt zu aktualisieren. Microservices wiederholen Ereignisse aus einem Ereignisspeicher, um den entsprechenden Status ihrer eigenen Datenspeicher zu berechnen. Das Muster bietet Einblick in den aktuellen Zustand der Anwendung und zusätzlichen Kontext dafür, wie die Anwendung in diesen Zustand gekommen ist. Das Ereignis-Sourcing-Muster funktioniert effektiv mit dem CQRS-Muster, da Daten für ein bestimmtes Ereignis reproduziert werden können, auch wenn die Befehls- und Abfragedatenspeicher unterschiedliche Schemata haben.
Durch Auswahl dieses Musters können Sie den Status der Anwendung jederzeit identifizieren und rekonstruieren. Dies erzeugt einen persistenten Audit-Trail und erleichtert das Debuggen. Daten werden jedoch letztendlich konsistent und dies ist für einige Anwendungsfälle möglicherweise nicht angemessen.
Dieses Muster kann entweder mithilfe von Amazon Kinesis Data Streams oder Amazon implementiert werden EventBridge.
Implementierung von Amazon Kinesis Data Streams
In der folgenden Abbildung ist Kinesis Data Streams die Hauptkomponente eines zentralen Ereignisspeichers. Der Ereignisspeicher erfasst Anwendungsänderungen als Ereignisse und behält sie auf Amazon Simple Storage Service (Amazon S3) bei.
Der Workflow besteht aus folgenden Schritten:
-
Wenn bei den Microservices „/withdraw“ oder „/credit“ eine Änderung des Ereignisstatus auftritt, veröffentlichen sie ein Ereignis, indem sie eine Nachricht in Kinesis Data Streams schreiben.
-
Andere Microservices wie „/balance“ oder „/creditLimit“ lesen eine Kopie der Nachricht, filtern sie nach Relevanz und leiten sie zur weiteren Verarbeitung weiter.
Amazon- EventBridge Implementierung
Die Architektur in der folgenden Abbildung verwendet EventBridge. EventBridge ist ein Serverless-Service, der Ereignisse verwendet, um Anwendungskomponenten zu verbinden, was es Ihnen erleichtert, skalierbare, ereignisgesteuerte Anwendungen zu erstellen. Bei der ereignisgesteuerten Architektur werden lose gekoppelte Softwaresysteme erstellt, die zusammenarbeiten, indem sie Ereignisse ausgeben und darauf reagieren. EventBridge bietet einen Standard-Event-Bus für Ereignisse, die von -AWSServices veröffentlicht werden, und Sie können auch einen benutzerdefinierten Event Bus für domainspezifische Buses erstellen.
Der Workflow besteht aus folgenden Schritten:
-
„OrderPlaced“-Ereignisse werden vom Microservice „Bestellungen“ im benutzerdefinierten Event Bus veröffentlicht.
-
Microservices, die nach der Bestellung Maßnahmen ergreifen müssen, z. B. der Microservice „/route“, werden durch Regeln und Ziele initiiert.
-
Diese Microservices generieren eine Route, um die Bestellung an den Kunden zu senden und ein „RouteCreated“-Ereignis auszugeben.
-
Microservices, die weitere Maßnahmen ergreifen müssen, werden auch durch das Ereignis „RouteCreated“ initiiert.
-
Ereignisse werden an ein Ereignisarchiv gesendet (z. B. EventBridge archivieren), sodass sie bei Bedarf zur erneuten Verarbeitung wiedergegeben werden können.
-
Ereignisse der historischen Reihenfolge werden bei Bedarf zur erneuten Verarbeitung an eine neue Amazon SQS-Warteschlange (Wiederholungswarteschlange) gesendet.
-
Wenn Ziele nicht initiiert werden, werden die betroffenen Ereignisse zur weiteren Analyse und erneuten Verarbeitung in eine Warteschlange für unzustellbare Nachrichten (DLQ) gestellt.
Sie sollten erwägen, dieses Muster zu verwenden, wenn:
-
Ereignisse werden verwendet, um den Status der Anwendung vollständig neu zu erstellen.
-
Sie müssen Ereignisse im System wiederholen und der Status einer Anwendung kann jederzeit bestimmt werden.
-
Sie möchten in der Lage sein, bestimmte Ereignisse rückgängig zu machen, ohne mit einem leeren Anwendungsstatus beginnen zu müssen.
-
Ihr System benötigt einen Stream von Ereignissen, die einfach serialisiert werden können, um ein automatisiertes Protokoll zu erstellen.
-
Ihr System erfordert hohe Lesevorgänge, ist jedoch leicht bei Schreibvorgängen; hohe Lesevorgänge können an eine speicherinterne Datenbank weitergeleitet werden, die mit dem Ereignis-Stream aktualisiert wird.
Wichtig
Wenn Sie das Ereignis-Sourcing-Muster verwenden, müssen Sie bereitstellen, Saga Muster um die Datenkonsistenz über Microservices hinweg aufrechtzuerhalten.
