Was ist Event Driven Design?

Das Event Driven Design-Modell ist ein beliebtes verteiltes asynchrones 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 asynchron aufnehmen und verarbeiten.

Geeignet für Anwendungen oder Systeme, die Ereignisse zwischen lose verbundenen Softwarekomponenten und Diensten übertragen. Ein ereignisgesteuertes System besteht in der Regel aus Ereignisemittern (oder Agenten), Ereigniskonsumenten (oder Empfängern) und Ereigniskanälen.

In ereignisgesteuerten Systemen werden Ereignisse in verschiedenen Systemen behandelt, es ist sehr schwierig, die Atomizität aufrechtzuerhalten. Was als atomarer Prozess gemeinsam getan werden muss, muss Teil eines einzigen Systems sein. Die EDA ist fehlerbeständig, da sie horizontal skalierbar ist und Komponenten lose verbunden sind und unabhängig 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 sehr um die Reaktion. Wenn Sie keine Antwort erwarten oder eine Antwort haben, geschieht dies in der Regel nicht direkt. Dies gewährleistet eine geringe Verbindung zwischen verschiedenen Systemen.

Dieses Modell ist einfach und einfach zu installieren, aber es kann schwierig sein, Ereignisberichte zu debuggen und zu ändern, wenn es verschiedene Systeme durchläuft. In diesem Modell enthält das Ereignis minimale Informationen, und manchmal müssen sie sich bei der Verarbeitung des Ereignisses an den Absender mit weiteren Informationen wenden.

  • Ereignisverschobene Statusübertragung

In diesem Modell enthält ein Ereignis alle Details, die ein System zum Behandeln des Ereignisses benötigt, und jedes System speichert seine eigene Kopie der Daten. Durch die nicht remotee Suche nach Informationen 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.

  • AktivitätSschweiß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 reproverarbeiten können, um den Integritätsstatus neu zu erstellen. Der Event-Store wird zur Hauptquelle der Wahrheit. Das beste Beispiel dafür ist ein Versionskontrollsystem.

Das ereignisgenerierte System bietet dem System eine starke Steuerungsfähigkeit, aber manchmal kann es schwierig sein, den Status neu zu erstellen, wenn er von einigen externen Systemen abhängt.

  • 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, wird aber am häufigsten in Kombination mit den oben genannten Modellen verwendet.

Ich hoffe, es ist ein erläuternder Artikel.

  Zitat

KARABAY A, 2020 . Was ist Event Driven Design ?,

https://www.karabayyazilim.com/blog/diger/event-driven-design-nedir-2020-10-10-102614

(Zugriff am 10. Oktober 2020).


  Diesen Beitrag teilen

Kommentare (0)

Kommentar

Abonnieren
Melden Sie sich für den E-Mail-Newsletter an, um als Erster über meine Blogbeiträge Bescheid zu wissen