Was ist ereignisgesteuerte Architektur? Modelle, Beispiele und Anwendungen

Unternehmen verlassen sich auf verschiedene Technologien und Werkzeuge, um ihr Geschäft effektiv zu betreiben.

Dennoch können diese schnell veraltet sein, was zu Leistungsverschlechterungen, erhöhten Kosten und Risikobelastungen sowie Sicherheitsbedrohungen führt. Es ist nicht schwer zu erkennen, wie altmodische, monolithische Architekturen oft die Modernisierung Ihres Unternehmens behindern.

Eine Möglichkeit, die Agilität und Skalierbarkeit Ihrer IT-Infrastruktur zu verbessern, besteht darin, eine ereignisgesteuerte Architektur einzusetzen. In einer ereignisgesteuerten Architektur werden Systeme um Ereignisse herum aufgebaut, die Nachrichten sind, die anzeigen, dass etwas passiert ist. Dies ermöglicht es, Systeme zu bauen, die schnell auf Veränderungen in ihrer Umgebung reagieren, wodurch sie agiler und anpassungsfähiger werden.

Die meisten ereignisgesteuerten Systeme verwenden Nachrichtenwarteschlangen-Software, um zwischen verschiedenen Systemen zu kommunizieren und Echtzeitkommunikation auf einer einzigen Ebene zu ermöglichen.

Das ereignisgesteuerte Architekturprozessmuster ersetzt das herkömmliche "Anfrage/Antwort"-Design, bei dem Dienste auf eine Antwort warten mussten, bevor sie zur nächsten Aktivität übergehen konnten. Es bietet auch Echtzeit-Datenanalysen zu Benutzerverhalten, Geschäftsprozessen und Betrieb.

Ereignisse steuern den Fluss der ereignisgesteuerten Architektur, die darauf ausgelegt ist, auf Ereignisse zu reagieren oder Operationen als Reaktion auf ein Ereignis durchzuführen.

Was bedeutet es, ereignisgesteuert zu sein?

Ereignisse sind Instanzen von Aktionen. Sie treten auf, wenn etwas innerhalb oder außerhalb Ihres Unternehmens passiert. Diese Aktivitäten können einen Verbraucherkauf, eine Lagerbestandsaktualisierung, einen versuchten Datenverstoß oder eine Statusänderung für eine Anwendung umfassen.

Da viele Ereignisse zeitkritisch oder geschäftskritisch für den Betrieb sind, möchten Unternehmen ihre Infrastrukturen um das Sammeln und Reagieren auf solche Ereignisse herum gestalten. Das Unternehmen wird als ereignisgesteuert bezeichnet, wenn Ereignisse eine Reaktion des Unternehmens hervorrufen. Im modernen Zeitalter werden Ereignisse von IT-Systemen verarbeitet, die Ereignisse basierend auf voreingestellter Logik sammeln, analysieren und darauf reagieren.

Ereignisgesteuerte Architekturen werden auch als kollaborativ asynchrone Architekturen bezeichnet, da sie auf asynchroner Nachrichtenübermittlung zwischen den verschiedenen Teilen eines Systems mit Echtzeitantworten beruhen. Jetzt wechseln Systeme wie Banken und Telemetrie zum ereigniszentrierten Modell, bei dem sie beginnen, Daten im Transit zu sammeln und darauf basierend auf Ereignissen zu reagieren.

Schauen wir uns ein Beispiel für eine ereignisgesteuerte Architektur im Bankwesen an. Die Zahlung erfolgt an einem bestimmten Ort. In diesem Fall reagiert die ereignisgesteuerte Architektur schneller und genauer auf diese Anfrage als der traditionelle Anfrage/Antwort-Ansatz, der erfordert, dass Sie auf eine Antwort warten, bevor Sie mit Ihrer Transaktion fortfahren.

Dies fügt reichhaltige Funktionen hinzu, wie Betrugswarnungen und Sicherheitsschichten, die Kunden vor Cyberdieben schützen.

Bedeutung von ereignisgesteuerten Systemen

Hoher Durchsatz, Skalierbarkeit und Agilität sind Schlüsselmerkmale der heutigen digitalen Marktführer, von denen viele Mikroservices und ereignisgesteuerte Architekturen übernommen haben.

Monolithische IT-Infrastrukturen verlassen sich auf synchrone Kommunikation, bei der zwei Programme direkt interagieren, meist über Application Programming Interfaces (APIs). Andererseits ist asynchrone Kommunikation ereignisgesteuert, was es mehreren Anwendungen ermöglicht, gleichzeitig und schnell in Echtzeit zu interagieren. EDA ist oft die effektivste Methode, um asynchrone ereignisgesteuerte Anwendungsinteraktion zu ermöglichen.

Unternehmen, die ereignisgesteuerte Architekturen nutzen, können die Vorteile skalierbarer und robuster Echtzeitkommunikation mit Nachrichtenwarteschlangen genießen. Viele strategische Projekte können davon profitieren, einschließlich des Internet der Dinge (IoT), E-Commerce, Datenintegration über Systeme hinweg sowie Erkennung von Betrug am Rande und im Finanzwesen.

Ereignisgesteuerte vs. traditionelle Architektur

Ereignisgesteuerte und traditionelle Architekturen unterscheiden sich grundlegend in Kommunikations- und Systemdesignansätzen. EDA verlässt sich auf asynchrone Kommunikation, bei der Ereignisse Interaktionen zwischen lose gekoppelten Komponenten auslösen, was Echtzeitreaktionsfähigkeit und hohe Skalierbarkeit ermöglicht. Dies macht es ideal für komplexe, verteilte Systeme wie IoT, Echtzeitanalysen und Betrugserkennung im Finanzwesen.

Im Gegensatz dazu folgt die traditionelle Architektur einem Anfrage-Antwort-Modell, das direkte Interaktionen zwischen eng gekoppelten Komponenten beinhaltet. Während es einfacher ist, für einfache Workflows wie transaktionale Systeme zu implementieren, kämpfen synchrone Architekturen oft mit Latenz und Skalierbarkeit in verteilten Umgebungen.

Die Wahl zwischen diesen Ansätzen hängt von den Anforderungen des Systems ab. EDA wird für dynamische, skalierbare und widerstandsfähige Systeme bevorzugt, während traditionelle Architekturen für Anwendungen mit einfacheren, vorhersehbaren Kommunikationsmustern geeignet sind.

Wie funktioniert eine ereignisgesteuerte Architektur?

Ein ereignisgesteuertes Architektur-Muster hilft bei der Entwicklung und Bereitstellung von Anwendungen und Systemen, die Ereignisse zwischen lose gekoppelten Systemkomponenten und Diensten übertragen. Eine ereignisgesteuerte Infrastruktur hat drei Hauptkomponenten:

1. Ereignisproduzenten, auch bekannt als Ereignisemittenten und Agenten
2. Ereigniskonsumenten oder Senken
3. Broker oder Kanal

Ein Ereignisproduzent überwacht oder erkennt ein Ereignis und wandelt es in eine Nachricht um. Nachdem ein Ereignis erkannt wurde, sendet der Produzent die Nachricht über Ereigniskanäle an den Konsumenten. Der Produzent kennt die Konsumenten des Ereignisses nicht und wird nie das Ergebnis des Ereignisses erfahren.

Ereigniskonsumenten sind dafür verantwortlich, eine Reaktion auszulösen, wenn ein Ereignis eintritt. Ein Ereigniskonsument kann eine vollständige Antwort geben oder nicht. Zum Beispiel könnte der Konsument dafür verantwortlich sein, das Ereignis zu filtern, zu verarbeiten und an die nächste Komponente (normalerweise Ereignis-Streaming-Plattformen) weiterzuleiten oder eine eigenständige Antwort auf ein Ereignis zu bieten.

Die Ereignisverarbeitungsplattform bestimmt die geeignete Reaktion auf ein Ereignis und überträgt die Aktivität an die relevanten Konsumenten, wo das Ergebnis des Ereignisses sichtbar ist.

Die ereignisgesteuerte Architektur fördert die lose Kopplung von Anwendungen durch einen Ereignisbroker, ähnlich einem Nachrichtenbroker, der Ereignisse von Produzenten zu Konsumenten weiterleitet. Diese Broker können mit nachrichtenorientierter Middleware implementiert werden, um sicherzustellen, dass Apps und Geräte die Quelle oder das Ziel der Daten nicht kennen müssen. Während lose Kopplung Herausforderungen mit sich bringt, verbessert sie die Flexibilität und Skalierbarkeit erheblich.

In EDA werden Ereignisse gesendet, ohne eine Antwort zu erwarten, abgesehen von einer Bestätigung durch den Ereignisbroker. Diese Entkopplung stellt sicher, dass Sender und Empfänger unabhängig voneinander arbeiten.

Direkte Verbindungen zwischen Produzenten und Konsumenten können die Notwendigkeit eines Brokers umgehen, wie z. B. ein Produzent, der direkt mit einer Datenbank interagiert, um Ereignisse zur Analyse zu speichern. In den meisten Setups erzeugen jedoch mehrere Ereignisemittenten verschiedene Ereignisse, wobei eine oder mehrere Senken sie verarbeiten.

Ereignisgesteuerte Architekturmodelle

Ein EDA-Muster spezifiziert, wie Ereignisproduzenten, -konsumenten und -broker miteinander interagieren. Es gibt zwei Hauptmuster der ereignisgesteuerten Architektur: Publisher/Subscriber und Event Streaming.

Publisher/Subscriber-Architektur

Diese auf Nachrichtenwarteschlangen basierende Architektur hängt von Abonnements von Ereignisströmen zur Kommunikation ab. Der Ereignisrouter in einer Publisher/Subscriber-Architektur (dem Pub/Sub-Modell) zeichnet Kundenabonnements für Ereigniskanäle auf. Dieses Modell sendet Benachrichtigungen an Abonnenten, die benachrichtigt werden müssen, wenn ein Ereignis eintritt oder veröffentlicht wird.

Da Ereignisse nicht wiedergegeben werden können, kann ein Konsument, der sich nach dem Eintreten eines Ereignisses abonniert, es später nicht mehr abrufen. Ab diesem Moment erhält der Konsument neue Ereignisse. ActiveMQ und RabbitMQ sind zwei bekannte Broker für das Pub/Sub-Modell.

Event Streaming Architektur

Event Streaming geht über das abonnementsbasierte Modell hinaus. Diese Technik speichert Ereignisse in einem Protokoll, auf das alle Konsumenten zugreifen können, um wichtige Ereignisse zu entdecken. Konsumenten können von jedem Bereich des Streams lesen und frühere Ereignisse erneut abspielen.

Apache Kafka ist eine bekannte Stream-Verarbeitungslösung. Viele Unternehmen wählen Kafka, weil es eine etablierte und robuste Lösung ist. Als industrielle Standard-Stream-Verarbeitungsplattform hat Kafka eine breite Benutzerbasis, eine unterstützende Community und ein fortschrittliches Toolset.

Andere Plattformen bieten eine Mischung aus Stream- und Pub/Sub-Verarbeitung oder ihre eigene Lösung. Pulsar, ein neues Apache-Produkt, ist eine Open-Source, funktionsreiche Pub/Sub-Messaging-Plattform, die sowohl Streams als auch Ereigniswarteschlangen erleichtert, alles mit außergewöhnlich hoher Geschwindigkeit.

NATS ist ein Pub/Sub-Messaging-System, das "synthetisches" Queueing verwendet. NATS, oder neural autonomic transport system, ist darauf ausgelegt, kurze, häufige Kommunikationen zu liefern. Es bietet hervorragende Leistung und reduzierte Latenz. Allerdings betrachtet NATS einige Datenlecks als akzeptabel und stellt die Leistung über Lieferzusagen.

Beispiel für eine ereignisgesteuerte Architektur

Nachfolgend ein Beispiel für einen ereignisgesteuerten Ansatz für eine E-Commerce-Website. Diese Architektur ermöglicht es der Website, auf Updates aus mehreren Quellen während hoher Nachfrage zu reagieren, ohne das System zu stören oder Ressourcen übermäßig bereitzustellen.

Betrachten wir, wie ein Online-Händler eine ereignisgesteuerte Architektur verwenden könnte. Kunden stehen kurz davor, online auszuchecken, und die Eingabe ihrer Zahlungsinformationen auf einer E-Commerce-Plattform ist eine häufige und entscheidende Aktion. Die Benutzeroberfläche (UI) erzeugt das Ereignis "Zahlung eingereicht" mit Kreditkarteninformationen, und der Ereignisrouter weiß, dass er die Ereignisbenachrichtigung basierend auf den Metadaten des Ereignisses an den Zahlungsdienst weiterleiten muss.

Nach Erhalt der Benachrichtigung verarbeitet der Zahlungsdienst das Ereignis und erstellt ein neues "Zahlung verarbeitet"-Ereignis, das den Erfolg oder Misserfolg des Vorgangs anzeigt.

Der Ereignisrouter gibt Informationen an die UI zurück, zeigt den Status des Verbrauchers an und fordert ihn auf, vordefinierte Aktionen auszuführen. Wenn eine Zahlung fehlschlägt, kann die UI beispielsweise das Formular erneut öffnen, um die Details zu korrigieren. Wenn die Zahlung jedoch erfolgreich ist, bietet die UI die endgültigen Bestellinformationen und das voraussichtliche Lieferdatum.

Weder die Front-End-Site noch die Back-End-Dienste sind sich der Existenz ihrer Gegenstücke bewusst. Sie abonnieren die Ereignisse "Zahlung eingereicht" und "Zahlung verarbeitet", die der Ereignisrouter verwaltet.

Anwendungsfälle für ereignisgesteuerte Architekturen

Unternehmen setzen auf EDA, um Systeme zu schaffen, die eine Vielzahl von Anwendungsfällen erfüllen. Die beliebtesten könnten umfassen:

• Echtzeitüberwachung: Systeme können Ereignisse erzeugen, wenn sich ihre Zustände ändern, sodass Unternehmen nach Unregelmäßigkeiten und verdächtigem Verhalten suchen können.
• Datenreplikation: Ein einzelnes Ereignis kann von zahlreichen Diensten verwendet werden, die Datenreplikation in ihre Datenbanken benötigen.
• Redundanz: Wenn ein Dienst nicht verfügbar ist, können Ereignisse im Router gespeichert werden, bis der Dienst bereit ist, das Ereignis zu konsumieren.
• Parallele Verarbeitung: Ein einzelnes Ereignis kann mehrere Prozesse initiieren und asynchron ausgeführt werden.
• Interoperabilität: Ereignisse können unabhängig von der Sprache, in der Anwendungen erstellt werden, gespeichert und verteilt werden.
• Mikroservices: EDA wird häufig mit Mikroservices integriert, um Daten effektiv zwischen entkoppelten Prozessen im großen Maßstab zu übertragen.

Vorteile einer ereignisgesteuerten Architektur

EDA vereinfacht die Entwicklung eines flexiblen Systems, das auf Veränderungen reagiert und Echtzeitentscheidungen trifft. Schauen wir uns einige Möglichkeiten an, wie sich eine ereignisgesteuerte Architektur nützlich macht.

• Lose Kopplung: Dienste müssen sich nicht mehr der Existenz anderer Systeme bewusst sein, um zu interagieren. Sie müssen sich der Ereignisse bewusst sein, aber der Broker verteilt die entsprechenden Ereignisse an die richtigen Systeme. Dies führt zu sehr lose gekoppelten Mikroservices, die einfach anzupassen, zu testen und bereitzustellen sind.
• Unveränderlichkeit: Da Ereignisse nach ihrer Erstellung nicht mehr geändert werden können, muss sich niemand Sorgen machen, dass jemand anderes ihren Inhalt später ändert.
• Reduzierte Kosten: Ereignisgesteuerte Architekturen sind push-basiert, sodass alles geschieht, sobald das Ereignis im Broker erscheint. Benutzer müssen nicht für kontinuierliches Abfragen zahlen, um nach einem Ereignis zu suchen. Dies führt zu weniger Netzwerkbandbreitennutzung, geringerem CPU-Verbrauch und weniger SSL/TLS-Handshakes.
• Fehlertoleranz: Wenn ein Konsument plötzlich aufhört zu arbeiten oder ein Ereignis nicht verarbeiten kann, betrachtet der Ereignisbroker es nicht als erfolgreich verarbeitet. Das Ereignis geht nicht verloren; vielmehr wird es von einer anderen Konsumenteninstanz erneut konsumiert oder erneut verarbeitet, wenn der Konsument verfügbar ist.
• Echtzeit: Ein ereignisgesteuertes Design bietet unvergleichliche Echtzeit-Sichtbarkeit in alles, was im System passiert. Die Fähigkeit, dieses Wissen zu konsumieren, Erkenntnisse in Echtzeit zu gewinnen und Entscheidungen zu automatisieren, ist so einfach wie das Hinzufügen von Konsumenten zu aktuellen Ereignissen. Das Hinzufügen von Echtzeitfunktionen zu alternativen Architekturen ist möglich, erfordert jedoch zusätzlichen Aufwand, neue Tools und Änderungen an bestehenden Komponenten.
• Skalierbarkeit: Ein einzelnes Ereignis kann genutzt werden, um zahlreiche Aktionen für verschiedene Konsumenten zu aktivieren, was parallele Auftragsausführung und bessere Leistung ermöglicht. Sie müssen die Logik für jeden Dienst oder jedes System nicht ändern, sodass Sie den Tech-Stack leicht an neue Anforderungen oder Bedürfnisse anpassen können.
• Wiederherstellung: Wenn Sie einen Ereignisbroker verwenden, der kontinuierliche und widerstandsfähige Ereignisströme bietet, können Sie vergangene Ereignisse "wiedergeben", um fehlende Arbeiten wiederherzustellen oder die Konfiguration des Systems zu rekonstruieren.

Herausforderungen einer ereignisgesteuerten Architektur

Nachdem wir alle Vorteile der ereignisgesteuerten Infrastruktur behandelt haben, lassen Sie uns ihre Einschränkungen untersuchen. Einige dieser Kompromisse existieren in alternativen Designansätzen, wie der Entwicklung von REST-Mikroservices, aber sie werden in einem ereignisgesteuerten Design verstärkt.

• Komplexität: Entkopplung beseitigt die Notwendigkeit für Abhängigkeitsverfolgung und andere Hindernisse für ein Mikroservices-Modell. Die Last unabhängiger Dienste besteht darin, dass es schwieriger wird, den Fortschritt von Ereignissen über viele Anwendungen hinweg zu verstehen, im Gegensatz zu direkter Abhängigkeit, bei der die Beziehungen klarer sind.
• Synchrone Flows: Da Ereignisse asynchron sind, kämpft dieses Paradigma damit, synchrone Aktivitäten zu unterstützen, wenn das Ergebnis der Aktionen innerhalb desselben Anfrage-Antwort-Bereichs gesendet werden sollte.
• Ereignisdesign: Das Design von Ereignissen ist schwierig. Da jeder Konsument das Ereignis abonnieren kann, muss es wiederverwendbar sein, was die Anpassung opfert. Gleichzeitig kann das Design nicht so allgemein sein, dass der Zweck unklar wird.
• Entwicklung von Ereignissen: Da sich Systeme im Laufe der Zeit entwickeln, müssen Ereignisse Schritt halten, um die sich ändernden Eigenschaften des Systems zu berücksichtigen. Das Aktualisieren von Ereignissen, ohne andere Mikroservices zu beeinträchtigen, kann schwierig sein, insbesondere in einem verteilten Szenario, in dem Teams nicht mit den Personen in Kontakt stehen, die die von ihnen erstellten Ereignisse verarbeiten.

Skalieren Sie Ihre Infrastruktur für den Erfolg

Ereignisgesteuerte Architekturen stapeln Dienste auf einer einzigen Transaktionsebene. Dieser Ansatz ermöglicht es Unternehmen, Probleme zu erkennen, schnell auf Lösungen zu reagieren und dynamische Geschäftsprozesse schneller zu unterstützen.

Daten, Daten überall. Holen Sie sich Ereignisstromverarbeitungssoftware, um Ihnen zu helfen, Geschäftsdaten im Transit zu verstehen und zu verarbeiten.

Der Artikel wurde ursprünglich 2022 veröffentlicht. Er wurde mit neuen Informationen aktualisiert.