Meine Blog-Beiträge

Was ist Event Driven Design ?

Was ist Event Driven Design ?


Das Event Driven Design-Modell ist ein beliebtes verteiltes synchrones Architekturmodell, das zur Erstellung hochskalierbarer Anwendungen verwendet wird. Es ist auch sehr anpassungsfähig und kann sowohl für kleine Anwendungen als auch für große, komplexe Anwendungen verwendet werden. Die ereignisgesteuerte Architektur besteht aus stark analysierten, einzweckübergreifenden Ereignisbehandlungskomponenten, die Ereignisse synchron übernehmen und verarbeiten.

Geeignet für Anwendungen oder Systeme, die Ereignisse über lose verbundene Softwarekomponenten und -dienste hinweg beleben. Ein ereignisgesteuertes System besteht in der Regel aus Ereignisemittern (oder Agenten), Ereigniskonsumenten (oder Empfängern) und Ereigniskanälen.

In ereignisgesteuerten Systemen werden Ereignisse auf verschiedenen Systemen verarbeitet, es ist sehr schwierig, die Atomizität aufrechtzuerhalten. Dinge, die als atomarer Prozess gemeinsam erledigt werden müssen, sollten Teil eines einzigen Systems sein. EDA ist fehlerbeständig, da es horizontal skalierbar ist und Komponenten lose verbunden sind und unabhängig voneinander skaliert werden können.

Es gibt vier am häufigsten verwendete Muster in ereignisorientierter Architektur.

  • Ereignisbenachrichtigung

In diesem Modell sendet ein System Ereignismeldungen, um andere Systeme über eine Änderung in der Domäne zu informieren. Das Quellsystem kümmert sich nicht viel um die Antwort. Wenn Sie nicht auf eine Antwort warten oder eine Antwort haben, ist sie in der Regel nicht direkt. Dies bietet eine geringe Verbindung zwischen verschiedenen Systemen.

Dieses Modell ist einfach und einfach einzurichten, kann jedoch schwierig zu debuggen und zu ändern sein, wenn die Ereignisberichterstattung durch verschiedene Systeme geleitet wird. In diesem Modell enthält das Ereignis minimale Informationen, und manchmal müssen sie sich bei der Verarbeitung des Ereignisses an den Absender wenden, um weitere Informationen zu erhalten.

  • Ereignis verschobener Zustandstransfer

In diesem Modell enthält ein Ereignis alle Details, die ein System zum Behandeln des Ereignisses benötigt, und jedes System speichert eine eigene Kopie der Daten. Wenn Sie nicht aus der Ferne nach Informationen suchen, kann das System die Latenz reduzieren und seine eigene Kopie der Daten aktualisieren. In diesem Modell gibt es verschiedene Kopien derselben Daten, was zu einem bestimmten Zeitpunkt zu systemweiten Dateninkonsistenzen führen kann.

  • Event-Schweißen

In Event Sourcing EDA speichern wir jede Änderung des Zustands als Ereignis im Event-Store, so dass wir das Ereignis jederzeit in der Zukunft erneut verarbeiten können, um den Integritätszustand neu zu erstellen. Der Event-Store wird zur Hauptquelle der Wahrheit. Das beste Beispiel dafür ist ein Versionskontrollsystem.

Das ereignisinduzierte System bietet eine leistungsstarke Steuerungsfunktion für das System, aber manchmal kann es schwierig sein, den Zustand neu zu erstellen, wenn es mit einigen externen Systemen verbunden ist.

  • CQRS (Befehlsabfrage-Haftungstrennung)

Befehlsabfrageverantwortungsanalysemodelle verwenden unterschiedliche Datenstrukturen zum Lesen und Schreiben von Informationen. CQRS kann auf Systemen verwendet werden, auf denen kein Ereignis vorhanden ist, aber es wird am häufigsten in Kombination mit den oben genannten Modellen verwendet.

Ich hoffe, es ist ein erläuternder Artikel.



Diesen Artikel teilen


Kommentare (0)

Kommentar