Was ist eine ereignisgesteuerte Architektur?

Die ereignisgesteuerte Architektur ist ein Integrationsmodell, das auf der Veröffentlichung, Erfassung, Verarbeitung und Speicherung (oder Permanenz) von Ereignissen basiert. Insbesondere, wenn eine Anwendung oder ein Service eine Aktion durchführt oder eine Änderung vornimmt, über die eine andere Anwendung oder ein anderer Service unterrichtet sein möchte, veröffentlicht er bzw. sie ein Ereignis – einen Datensatz dieser Aktion oder Änderung – den eine andere Anwendung oder ein anderer Service konsumieren und verarbeiten kann, um ihrer- bzw. seinerseits eine oder mehrere Aktionen durchzuführen.

Eine ereignisgesteuerte Architektur ermöglicht eine lose Kopplung zwischen verbundenen Anwendungen und Services. Sie können miteinander kommunizieren, indem sie Ereignisse veröffentlichen und konsumieren, ohne etwas voneinander zu wissen, außer dem Ereignisformat. Dieses Modell bietet erhebliche Vorteile gegenüber einer Anfrage/Antwort-Architektur (oder einem Integrationsmodell), bei der eine Anwendung oder ein Service spezifische Informationen von einer anderen spezifischen Anwendung oder einem anderen spezifischen Service anfordern muss, der die spezifische Anfrage erwartet.

Die ereignisgesteuerte Architektur maximiert das Potenzial cloudnativer Anwendungen und ermöglicht leistungsstarke Anwendungstechnologien wie Echtzeit-Analysen und Entscheidungshilfe.

In einer ereignisgesteuerten Architektur fungieren die Anwendungen als Ereignisproduzenten oder Ereigniskonsumenten (und oft auch als beides).

Ein Ereignisproduzent überträgt ein Ereignis in Form einer Nachricht an einen Broker oder eine andere Form von Ereignisrouter, wo die chronologische Reihenfolge des Ereignisses im Verhältnis zu anderen Ereignissen beibehalten wird. Ein Ereigniskonsument nimmt die Nachricht in Echtzeit (wenn sie auftritt) oder zu einem beliebigen anderen Zeitpunkt auf und verarbeitet die Nachricht, um eine andere Aktion, einen Workflow oder ein eigenes Ereignis auszulösen.

In einem einfachen Beispiel könnte ein Banking-Service ein Ereignis „Einzahlung“ übermitteln, das ein anderer Service in der Bank lesen und beantworten würde, indem er eine Einzahlung auf den Kontoauszug des Kunden schreibt. Aber ereignisgesteuerte Integrationen können auch Echtzeitreaktionen auslösen, die auf der komplexen Analyse riesiger Datenmengen beruhen, z. B. wenn das „Ereignis“ eines Kunden, der auf einer E-Commerce-Website auf ein Produkt klickt, sofortige Produktempfehlungen auf der Grundlage der Einkäufe anderer Kunden generiert.

Es gibt zwei grundlegende Modelle für die Übermittlung von Ereignissen in einer ereignisgesteuerten Architektur.

Ereignisübermittlung oder Publish/Subscribe

Bei der Ereignisübermittlung oder dem Publish/Subscribe-Modell abonnieren die Ereigniskonsumenten eine oder mehrere Klassen von Nachrichten, die von Ereignisproduzenten veröffentlicht werden. Wenn ein Ereignisproduzent ein Ereignis veröffentlicht, wird die Nachricht direkt an alle Abonnenten (Subscribers) gesendet, die sie konsumieren möchten.

In der Regel kümmert sich ein Nachrichtenbroker um die Übertragung von Ereignisnachrichten zwischen Publisher und Subscriber. Der Broker empfängt jede Ereignisnachricht, übersetzt sie gegebenenfalls, behält ihre Reihenfolge im Verhältnis zu anderen Nachrichten bei, stellt sie den Abonnenten (Subscribers) zum Konsum zur Verfügung und löscht sie dann, sobald sie konsumiert wurden (sodass sie nicht erneut konsumiert werden können).

Streaming von Ereignissen

Beim Ereignis-Streaming-Modell veröffentlichen die Ereignisproduzenten Ereignisströme an einen Makler. Ereigniskonsumenten abonnieren die Streams, aber anstatt jedes Ereignis zu empfangen und zu lesen, sobald es veröffentlicht wird, können die Konsumenten an jedem beliebigen Punkt in jeden Stream einsteigen und nur die Ereignisse lesen, die sie lesen möchten. Der entscheidende Unterschied besteht darin, dass die Ereignisse beim Makler verbleiben, auch wenn die Konsumenten sie erhalten haben.

Eine Daten-Streaming-Plattform wie Apache Kafka verwaltet die Protokollierung und Übertragung enormer Mengen von Ereignissen bei sehr hohem Durchsatz (buchstäblich Billionen von Ereignisdatensätzen pro Tag, in Echtzeit, ohne Durchsatzverzögerung). Eine Streaming-Plattform bietet bestimmte Eigenschaften, die ein Nachrichtenmakler nicht hat:

• Ereignispersistenz: Da Konsumenten Ereignisse jederzeit nach ihrer Veröffentlichung lesen können, sind Ereignis-Streaming-Datensätze persistent – sie werden für eine konfigurierbare Zeitspanne aufrechterhalten, die von Sekundenbruchteilen bis zeitlich unbegrenzt reicht. Dadurch können Ereignis-Streaming-Anwendungen sowohl Verlaufs- als auch Echtzeitdaten verarbeiten.
  
  
• Verarbeitung komplexer Ereignisse: Wie die Ereignisübermittlung kann auch das Ereignis-Streaming für eine einfache Ereignisverarbeitung verwendet werden, bei der jedes veröffentlichte Ereignis die Übertragung und Verarbeitung durch einen oder mehrere spezifische Konsumenten auslöst. Sie kann aber auch für eine komplexe Ereignisverarbeitung eingesetzt werden, bei der Ereigniskonsumenten ganze Serien von Ereignissen verarbeiten und auf der Grundlage des Ergebnisses Aktionen durchführen.

Im Vergleich zur Anfrage/Antwort-Anwendungsarchitektur bietet die ereignisgesteuerte Architektur mehrere Vorteile und Möglichkeiten für Entwickler und Unternehmen:

Leistungsstarke Echtzeitreaktion und -analyse: Ereignis-Streaming ermöglicht Anwendungen, die auf sich ändernde Geschäftssituationen sofort reagieren und Vorhersagen und Entscheidungen auf der Grundlage aller verfügbaren aktuellen und Verlaufsdaten in Echtzeit treffen. Dies bietet Vorteile in einer Vielzahl von Bereichen – von der Verarbeitung von Datenströmen, die von unzähligen IoT-Geräten erzeugt werden, über die Vorhersage und Abwehr von Sicherheitsbedrohungen im Handumdrehen bis hin zur Automatisierung von Lieferketten für optimale Effizienz.

Fehlertoleranz, Skalierbarkeit, vereinfachte Verwaltung, Vielseitigkeit und andere Vorteile der losen Kopplung: Anwendungen und Komponenten in einem ereignisgesteuerten Artikel sind nicht von der Verfügbarkeit der anderen abhängig. Sie können unabhängig voneinander aktualisiert, getestet und bereitgestellt werden, ohne dass der Service unterbrochen wird, und wenn eine Komponente ausfällt, kann eine Sicherungskopie online zur Verfügung gestellt werden. Die Ereignispersistenz ermöglicht die „Wiederholung“ vergangener Ereignisse, was bei der Wiederherstellung von Daten oder Funktionen im Falle eines Ausfalls des Ereigniskonsumenten hilfreich sein kann. Komponenten können einfach und unabhängig voneinander über das Netz skaliert werden und Entwickler können Anwendungen und Systeme durch Hinzufügen und Entfernen von Ereignisproduzenten und -konsumenten überarbeiten oder erweitern.

Asynchrone Nachrichtenübermittlung: Die ereignisgesteuerte Architektur ermöglicht es den Komponenten, asynchron zu kommunizieren – die Produzenten veröffentlichen Ereignisnachrichten nach ihrem eigenen Zeitplan, ohne darauf zu warten, dass die Konsumenten sie empfangen (oder ohne überhaupt zu wissen, ob die Konsumenten sie empfangen haben). Dies vereinfacht nicht nur die Integration, sondern verbessert auch das Anwendungserlebnis für die Benutzer. Ein Benutzer, der eine Aufgabe in einer Komponente abschließt, kann ohne Wartezeit zur nächsten Aufgabe übergehen, unabhängig von nachgelagerten Integrationen zwischen dieser Komponente und anderen im System.

Bei Mikroservices – einer cloudnativen Anwendungsarchitektur – werden aus lose verbundenen, unabhängig bereitstellbaren Services Anwendungen zusammengestellt. Die Hauptvorteile von Mikroservices sind im Wesentlichen die Vorteile der losen Kopplung – einfache Verwaltung, Flexibilität bei der Bereitstellung, unabhängige Skalierbarkeit und Fehlertoleranz.

Es überrascht nicht, dass eine ereignisgesteuerte Architektur weithin als bewährtes Verfahren für die Implementierung von Mikroservices gilt. Mikroservices können über REST-APIs miteinander kommunizieren. REST, ein Anfrage/Antwort-Integrationsmodell, hebt jedoch viele der Vorteile der lose gekoppelten Mikroservices-Architektur wieder auf, indem es eine synchrone, eng verbundene Integration zwischen den  Mikroservices erzwingt.