Was ist ereignisgesteuerte Architektur?
Die ereignisgesteuerte Architektur (EDA) ist ein Integrationsmodell, das wichtige „Ereignisse“ in einem Unternehmen – wie eine Transaktion oder einen abgebrochenen Einkauf – erkennt und in Echtzeit darauf reagiert.
Überblick über die ereignisgesteuerte Architektur
Fast jedes Ereignis in einem Unternehmen ist zeitkritisch. Wenn ein Kunde einen Online-Kauf tätigt, ein Sensor eine drohende Störung anzeigt, ein Aktienkurs fällt oder eine Sicherheitsverletzung festgestellt wird, müssen sofort Maßnahmen ergriffen werden. Hier kommt eine ereignisgesteuerte Architektur (Event-Driven Architecture, EDA) ins Spiel. Eine EDA ist in der Lage, Ereignisse zu erstellen, zu erkennen und auf sie zu reagieren. Auf ihrer Basis können Unternehmen alle Aspekte vom Kundenerlebnis bis hin zur betrieblichen Effizienz und Agilität verbessern.
Was ist ein Ereignis?
Zuerst einige Grundlagen. Ein Ereignis ist jede Aktion oder Statusänderung, die für ein Unternehmen von Bedeutung ist. Zum Beispiel, wenn jemand mit einer Kreditkarte bezahlt, für einen Flug eincheckt oder ein Passwort zurücksetzt – oder wenn der Bestand in einem Lager aktualisiert wird. In jedem Unternehmen, egal aus welcher Branche, finden ständig Ereignisse statt. Unternehmen werden „ereignisgesteuert“, wenn sie Ereignisse erfassen und auf sie reagieren können, sobald sie eintreten.
Was ist eine ereignisgesteuerte Architektur?
Eine ereignisgesteuerte Architektur (Event-Driven Architecture, EDA) ist ein Integrationsmodell zur Veröffentlichung, Erfassung, Verarbeitung und Reaktion auf Ereignisse in verteilten Systemen in Echtzeit. Wenn in einer Anwendung ein Ereignis eintritt, wird automatisch eine Nachricht an alle anderen Anwendungen gesendet, die davon wissen müssen, sodass diese darauf reagieren können.
Ereignisbasierte Architekturen sind entkoppelt, d. h. die Anwendungen müssen sich nicht gegenseitig kennen, um Informationen auszutauschen und Aufgaben zu erledigen. Ereignisinformationen oder Nachrichten können frei und automatisch zwischen Anwendungen fließen. Daher ist das EDA-Modell viel schneller als das traditionelle Request/Response-Modell, bei dem eine Anwendung die spezifischen Informationen, die sie benötigt, von einer anderen anfordern und die Antwort abwarten muss, bevor sie mit der nächsten Aufgabe fortfahren kann. Auch aufgrund der entkoppelten Natur einer EDA gilt sie weithin als Best Practice für die Kommunikation von Microservices.
Wie funktioniert eine EDA?
In einer ereignisgesteuerten Architektur fungieren Anwendungen als Ereignisproduzenten (Anwendungen, die Ereignisse erzeugen oder erfassen) oder als Ereignisverbraucher (Anwendungen, die Ereignisse verarbeiten und darauf reagieren). Produzenten übermitteln Ereignisse in Echtzeit an Verbraucher über einen Broker, auch als nachrichtenorientierte Middleware bezeichnet. Die Verbraucher können dann das Ereignis verarbeiten und weitere Aktionen, Workflows oder eigene Ereignisse auslösen.
In einer sehr einfachen Architektur – wenn es einen einzigen Produzenten und einen einzigen Verbraucher gibt, die direkt miteinander kommunizieren – können Broker optional sein. In den meisten Unternehmen gibt es jedoch mehrere Quellen, die Ereignisse an mehrere Verbraucher senden, sodass ein Broker oder sogar ein Netzwerk von Brokern (auch als „Event Mesh“ bezeichnet) erforderlich ist. Wenn ein Broker oder ein Event Mesh verwendet wird, entsteht eine „lose Kopplung“ von Anwendungen.
Muster einer ereignisgesteuerten Architektur
Es gibt zwei Hauptmuster für die Übertragung von Ereignissen in einer ereignisgesteuerten Architektur: Publish/Subscribe und Event Streaming.
Publish/Subscribe (auch bekannt als „Pub/Sub“): Mit Pub/Sub abonnieren Ereignisverbraucher Nachrichten und Kanäle, die von Ereignisproduzenten veröffentlicht werden. Wenn ein Ereignis veröffentlicht wird, wird es über einen Broker direkt an alle Abonnenten gesendet. Um Doppelungen zu vermeiden, können Ereignisse nicht wiedergegeben oder abgerufen werden, nachdem sie verarbeitet wurden – sie werden vom Broker gelöscht.
Event Streaming: Beim Event Streaming veröffentlichen die Produzenten ganze Ströme von Ereignissen an einen Broker. Die Verbraucher abonnieren den Stream und können jeden Teil des Streams lesen, wobei sie nur die für sie relevanten Ereignisse verarbeiten. Bei diesem Muster werden die Ereignisse vom Broker gespeichert, auch nachdem sie verarbeitet wurden.
Drei Ansätze zur Ereignisverarbeitung
Es gibt drei verschiedene Ansätze zur Verarbeitung von Ereignissen, sobald sie einen Verbraucher erreichen: einfache Ereignisverarbeitung, komplexe Ereignisverarbeitung und Event-Stream-Verarbeitung.
- Einfache Ereignisverarbeitung: Verbraucher verarbeiten jedes Ereignis, sobald es eintrifft.
- Komplexe Ereignisverarbeitung: Verbraucher verarbeiten eine Reihe von Ereignissen, um Muster zu erkennen und auf der Grundlage des Ergebnisses Aktionen durchzuführen.
- Event-Stream-Verarbeitung: Verbraucher verarbeiten einen permanenten Datenstrom (dynamische Daten) in Echtzeit über eine Daten-Streaming-Plattform und reagieren entsprechend darauf.
Unternehmen wählen ihren Ansatz für die Ereignisverarbeitung auf der Grundlage ihrer individuellen Bedürfnisse und Anwendungsfälle.
Anwendungsfälle und Beispiele für eine ereignisgesteuerte Architektur
Es gibt viele verschiedene Anwendungsfälle für ereignisgesteuerte Architekturen in allen Branchen – vom Bankwesen bis zum Einzelhandel. Hier sehen Sie ein Beispiel aus der Gastronomie:
Ein Student bestellt über eine Lieferdienst-App, z. B. Uber Eats, eine Pizza. Die App erfasst seine grundlegenden Informationen (Name, Adresse, Zahlungsinformationen und Auftrag) und veröffentlicht das Ereignis „Pizzabestellung“.
Die Pizzeria abonniert das Ereignis, führt den Auftrag aus und veröffentlicht ein eigenes Ereignis „Auftrag fertig“, das an den Lieferdienst zurückgesendet wird.
Der Lieferservice weist dann einen Fahrer zu, plant eine Ankunftszeit und benachrichtigt den Kunden, dass seine Pizza unterwegs ist.
Ein EDA-Beispiel aus dem E-Commerce:
Ein Online-Käufer gibt seine Kreditkartendaten auf einer E-Commerce-Website ein, die das Ereignis „Zahlung erfolgt“ veröffentlicht.
Das Zahlungssystem abonniert das Ereignis, verarbeitet die Zahlung und gibt ein eigenes Ereignis „Zahlung verarbeitet“ aus, das den Erfolg oder Misserfolg anzeigt – und leitet es an die Benutzungsoberfläche der Website zurück.
Die Benutzungsoberfläche zeigt dem Kunden den Zahlungsstatus an und fordert ihn zu weiteren Schritten auf.
Hier einige weitere EDA-Beispiele:
Ein Online-Käufer klickt auf ein Produkt und das System reagiert, indem es Produktempfehlungen auf der Grundlage ähnlicher Artikel erstellt.
Ein Kunde reicht einen Scheck bei einer Bank ein und das System verbucht die Einzahlung automatisch auf seinem Konto.
Ein Einzelhändler überprüft globale Transaktionen auf Betrug und meldet verdächtige Käufe an das Kreditkartenunternehmen.
Ein Hersteller, der das Streaming von IoT-Daten seiner Geräte überwacht, wird auf potenzielle Wartungsprobleme oder Ausfälle aufmerksam gemacht.
Vorteile einer ereignisgesteuerten Architektur
Die Vorteile einer ereignisgesteuerten Architektur sind vielfältig. Die drei wichtigsten sind:
- Echtzeit-Workflows und Reaktionsfähigkeit. Eine EDA kann Ereignisse überwachen und schnell auf deren Auftreten reagieren, oft unter Verwendung von Robotic Process Automation (RPA), um Workflows zu beschleunigen und nächste Schritte in Echtzeit auszulösen. Dies ist vor allem in Zeiten hoher Nachfrage wichtig, z. B. bei großen Verkaufsveranstaltungen oder an Feiertagen. Diese Reaktionsfähigkeit kann auch auf alltägliche (d. h. nicht zu Spitzenzeiten stattfindende) Workflows angewandt werden, um alle Bereiche von der Automatisierung der Lieferkette bis zur Betrugserkennung zu verbessern.
- Asynchrone Nachrichtenübermittlung. Anwendungen in einer EDA kommunizieren asynchron, d. h., Produzenten veröffentlichen Ereignismeldungen, ohne darauf zu warten, dass Verbraucher sie empfangen. Dadurch können die Anwendungen nicht nur ohne Wartezeit zu anderen Aufgaben übergehen, sondern es wird auch die Integration vereinfacht.
- Entkopplung und lose Kopplung. Die Anwendungen in einer EDA sind entkoppelt oder lose gekoppelt und nicht von der Verfügbarkeit anderer Anwendungen abhängig. Sie können unabhängig voneinander aktualisiert, getestet und eingesetzt werden. Sie können auch unabhängig voneinander fehlschlagen, sodass die Architektur stabiler und beständiger ist als herkömmliche Modelle. Durch die Entkopplung ist es außerdem einfach, bei Bedarf zusätzliche Publisher und Verbraucher zu ergänzen, sodass Code nicht bei jeder Änderung neu geschrieben werden muss.
Fazit
Ein Event Mesh bietet Bereitstellungsoptionen über verschiedene Hyperscaler und in privaten Cloud-Umgebungen. Es kann so konfiguriert werden, dass es ein verteiltes Netz von Ereignis-Brokern bildet, die in Umgebungen in privaten oder öffentlichen Clouds eingesetzt werden. Ein Event Mesh bietet einen vollständigen Satz von Ereignisservices, einschließlich Ereignisstreaming, Ereignismanagement und ‑überwachung, sowie erweiterte Funktionen wie dynamisches Nachrichtenrouting und detaillierte Filterung.
Mehr über die Event-Mesh-Funktionen von SAP erfahren
Optimieren Sie Ihre Anwendungen mit der ereignisbasierten Architektur der SAP Integration Suite.
Innovative Ideen, die inspirieren
Registrieren Sie sich für interessante und relevante Informationen zu Business Intelligence.