Was ist eine ereignisgesteuerte Architektur?

Sie ermöglicht es Teams, Systemereignisse zu identifizieren (im Grunde jede Änderung oder Aktion, die innerhalb des Systems auftritt) und in Echtzeit (oder nahezu in Echtzeit) darauf zu reagieren.

Die Verbreitung von EDAs in cloudnativen Umgebungen stellt eine deutliche Abwendung von traditionellen Rechenarchitekturen dar, die sich auf die Speicherung statischer Daten in Repositories wie Data Lakes (wie bei serviceorientierten Architekturen) konzentrieren, hin zu einem dynamischen Ansatz, der Daten in der Architektur trackt. Daten sind in einem ereignisgesteuerten System immer noch wertvoll, aber EDAs betonen die rechtzeitige Reaktion auf Ereignisse und erkennen an, dass der Wert eines Ereignisses im Laufe der Zeit abnehmen kann.

In einer ereignisgesteuerten Architektur senden Ereignisproduzenten (wie Microservices, APIs und IoT) Echtzeit-Ereignisbenachrichtigungen an Ereigniskonsumenten, die dann bestimmte Verarbeitungsroutinen aktivieren. Wenn Netflix beispielsweise eine neue Originalserie veröffentlicht, warten mehrere EDA-Dienste auf die Veröffentlichungsbenachrichtigung, die eine Kette an Updates auslöst, um die Benutzer zu informieren.

Einer der Hauptvorteile einer ereignisgesteuerten Architektur ist die entkoppelte Beziehung zwischen Front-End- und Backend-Komponenten, die es Systemen ermöglicht, Informationen zu teilen, ohne voneinander zu wissen. Produzenten können Ereignisse senden, ohne zu wissen, welcher Konsument sie erhält, und Konsumenten können Ereignisse empfangen, ohne Anforderungen an Produzenten zu senden. Mit anderen Worten: EDAs ermöglichen es Systemen, unabhängig zu arbeiten und Ereignisse asynchron zu verarbeiten.

Moderne, zukunftsorientierte Unternehmen haben einen großen digitalen Fußabdruck, und die Echtzeitfunktionalität eines ereignisgesteuerten Systems ermöglicht es Unternehmen, die Betriebsbereitschaft ohne Leerlauf aufrechtzuerhalten und schnell auf Ereignismeldungen zu reagieren. So helfen EDAs Unternehmen, eine Reihe von organisatorischen Prozessen zu automatisieren – von der Optimierung der Lieferkette bis zur proaktiven Identifizierung von Qualitätsproblemen – und letztendlich sowohl ihren Umsatz als auch ihr Ergebnis zu verbessern.

Beim Event Streaming geht es um den unbegrenzten, sequentiellen Fluss von Datensätzen in Echtzeit, genannt „Events“, grundlegende Datenstrukturen, die jedes Ereignis im System oder in der Umgebung aufzeichnen. Beispiele für solche Änderungen sind, wenn ein Benutzer auf einer E-Commerce-Website einen Artikel in seinen Warenkorb legt, ein Passwort zurücksetzt oder der Status einer Anwendung ändert. Es ist ein Begriff, der sich im Wesentlichen auf jeden Datenpunkt im System bezieht. Daher ist ein „Stream“ (auch Datenstrom oder Streaming-Daten genannt) die kontinuierliche Bereitstellung dieser Ereignisse.

Jedes Ereignis umfasst in der Regel einen Schlüssel, der das Ereignis oder die Entität, auf die es sich bezieht, identifiziert, einen Wert, der die eigentlichen Daten des Ereignisses enthält, einen Zeitstempel, der angibt, wann das Ereignis aufgetreten ist oder aufgezeichnet wurde, und manchmal Metadaten über die Datenquelle, die Schemaversion oder ein anderes Attribut. Sie können entweder Daten zum Zustand enthalten (z. B. den gekauften Artikel, den Preis und eine Lieferadresse) oder als Identifikatoren dienen (z. B. eine Versandbenachrichtigung).

Mit Hilfe spezialisierter Stream-Processing-Engines können Ereignisse innerhalb eines Streams einige verschiedene Prozesse durchlaufen. „Aggregationen“ führen Datenberechnungen durch, wie z. B. Mittelwerte, Summen und Standardabweichungen. Durch „Ingestion“ werden Streaming-Daten in Datenbanken aufgenommen. Die Analyseverarbeitung nutzt Muster in Streaming-Daten, um zukünftige Ereignisse vorherzusagen, und die Anreicherungsverarbeitung kombiniert Datenpunkte mit anderen Datenquellen, um Kontext und Bedeutung zu schaffen.

Ereignisse sind oft mit Geschäftsvorgängen oder Prozessen der Benutzernavigation verbunden und lösen in der Regel eine andere Aktion, einen Prozess oder eine Reihe von Ereignissen aus. Nehmen wir als Beispiel das Online-Banking. Wenn ein Benutzer auf „Transfer“ klickt, um Geld von einem Bankkonto an ein anderes zu senden, werden die Gelder vom Konto des Absenders abgehoben und dem Bankkonto des Empfängers hinzugefügt, E-Mail- oder SMS-Benachrichtigungen werden an eine der beiden Parteien (oder an beide) gesendet, und falls erforderlich, werden Sicherheits- und Betrugspräventionsprotokolle bereitgestellt.

Neben Ereignissen verlassen sich EDAs auf drei Hauptkomponenten, um Ereignisdaten durch die Architektur zu verschieben.

• Ereignisproduzenten (oder -Publisher): Produzenten sind sozusagen die Quelle, sie generieren Ereignisse und senden sie an das übrige Systems. Ein Publisher kann eine Benutzerschnittstelle, ein Sensor, ein Dienst oder ein anderes System sein, das in der Lage ist, eine Zustandsänderung zu erkennen oder zu erzeugen, die für andere Teile des Systems von Interesse ist. Obwohl Produzenten für das Erstellen von Ereignissen verantwortlich sind, haben sie keine Ereignisverarbeitungsfunktion.

• Ereignisverbraucher (oder Abonnenten): Verbraucher übernehmen die Aufgaben der Ereignisverarbeitung in einer EDA. Sie hören auf Ereigniskanälen und reagieren, wenn ein interessantes Ereignis veröffentlicht wird. Die Reaktion kann viele Formen annehmen, einschließlich der Aktualisierung einer Datenbank, des Auslösens eines nachgelagerten Prozesses oder einfach der Protokollierung von Informationen.

• Ereignis-Router (oder Ereignis-Orchestratoren): Router oder Orchestratoren sind die Broker, die die Front-End-Ereignisproduzenten von den Back-End-Ereigniskonsumenten entkoppeln. Sie dienen als Kanäle, durch die Ereignisse geliefert werden, und gewährleisten die Übertragung, ohne dass eine direkte Verbindung zwischen den Entitäten erforderlich ist. Router können auf konventionellen Komponenten (nachrichtenorientierte Middleware, wie z. B. SaaS) basieren und nützlich in einer Reihe von Messaging-Systemen (Nachrichtenwarteschlangen, Publish/Abonnieren-Modelle, Event Streams, und mehr) sein.

In einer EDA fungieren ereignisgesteuerte Anwendungen als Produzenten oder Konsumenten (und manchmal sogar als beides).

Wenn eine App oder ein Dienst eine Aktion ausführt, von der eine andere App oder ein anderer Dienst wissen möchte, veröffentlicht sie ein neues Ereignis – eine Aufzeichnung dieser Aktion oder Änderung –, die ein anderer Service nutzen und verarbeiten kann, um andere Aktionen auszuführen.

Der Ereignisproduzent überträgt das Ereignis dann – in Form einer Nachricht – an einen Broker oder eine andere Art von Ereignisrouter, der die chronologische Reihenfolge des Ereignisses im Verhältnis zu anderen Ereignissen beibehält. Ein Ereigniskonsument nimmt die Nachricht in Echtzeit auf – wie sie auftritt – oder zu einem späteren relevanten Zeitpunkt – und verarbeitet sie, um eine weitere Aktion, einen Workflow oder ein eigenes Ereignis auszulösen.

Beispiel: Ein Bankservice könnte ein „Einzahlungsereignis“ übermitteln, das ein anderer Bankservice verarbeiten und darauf reagieren würde, indem er eine Einzahlung auf den Kontoauszug des Kunden schreibt.

Ereignisgesteuerte Integrationen können aber auch Echtzeit-Reaktionen auslösen, die auf komplexen Analysen riesiger Datenmengen basieren, z. B. wenn ein Kunde auf einer E-Commerce-Website auf ein Produkt klickt und das System sofortige Produktempfehlungen generiert, die auf den Einkäufen anderer Kunden basieren.

Die ereignisgesteuerte Architektur maximiert das Potenzial von cloudnativen Anwendungen und ermöglicht leistungsstarke App-Technologien wie Echtzeitanalyse und Entscheidungsunterstützung. Insgesamt ersetzen sie die traditionelle „Request/Response“-Architektur, bei der eine App bestimmte Informationen von einer anderen App anfordern und auf eine Antwort warten muss, bevor sie mit der nächsten Aufgabe fortfahren.

„EDAs“ sind jedoch ein Begriff, der mehrere Architekturmuster umfasst, die alle für unterschiedliche Zwecke nützlich sein können:

Im Pub/Sub-Modell, das durch eine Eins-zu-Viele-Abhängigkeit zwischen Objekten und eine entkoppelte, asynchrone Beziehung zwischen Verleger (Ereignisproduzent) und Konsument definiert ist, muss der Verleger nichts über die Abonnenten wissen. Er veröffentlicht das Ereignis einfach auf einem gemeinsam genutzten Ereigniskanal, wo Abonnenten zuhören und unabhängig und in Echtzeit auf das Ereignis reagieren.

Normalerweise übernimmt ein Nachrichtenbroker (Router) die Übertragung von Ereignisnachrichten zwischen Herausgebern und Abonnenten. Der Broker empfängt jede Ereignisnachricht, transformiert sie (falls erforderlich), behält ihre Reihenfolge in Bezug auf andere Nachrichten bei, stellt sie den Abonnenten zur Nutzung zur Verfügung und löscht sie dann, wenn sie konsumiert wurde (sodass sie nicht noch einmal konsumiert werden kann).

Pub/Sub-Messaging-Muster eignen sich ideal für Unternehmen mit einer großen Codebase und für die Verteilung von Informationen an mehrere Verbraucher (z. B. für Benachrichtigungssysteme und Echtzeit-Datenfeeds).

Wie Pub/Sub entkoppelt Event Streaming Herausgeber und Konsumenten, um eine asynchrone Kommunikation zu ermöglichen. Im Event-Streaming-Modell benötigen die Event-Konsumenten jedoch keine Abonnements für die Streams. Stattdessen veröffentlichen die Produzenten Ströme von Ereignissen in einem Brokerprotokoll, und Konsumenten können an jedem Punkt in jeden Stream einsteigen und Ausgewähltes konsumieren (anstatt jedes veröffentlichte Ereignis zu empfangen und zu konsumieren).

Im Gegensatz zu Pub/Sub behalten Event-Streaming-Broker die Ereignisse jedoch auch dann bei, wenn die Verbraucher sie empfangen haben.

Da Konsumenten Events jederzeit nach ihrer Veröffentlichung verarbeiten können, sind Event-Streaming-Datensätze persistent. Das bedeutet, dass sie für einen konfigurierbaren Zeitraum aufbewahrt werden (von Bruchteilen einer Sekunde bis zu einer Ewigkeit). Nutzer können jederzeit auf den Stream zugreifen, um aktuelle Nachrichten zu lesen, eine Reihe von Nachrichten vom letzten Zugriff auf den Stream in Batches zu verarbeiten oder relevante Nachrichten aus der jüngsten Vergangenheit zu verweisen.

Event-Streaming-Technologien (wie Apache Kafka, Amazon Web Services (AWS) Kinesis und IBM Event Automation umfassen ebenfalls zwei Modelle: das Pull-Modell (bei dem Broker nur dann Verbraucherdaten senden, wenn Verbraucher angeben, dass sie für Ereignisse offen sind) und das Push-Modell (bei dem die Geschäftslogik des Brokers bestimmt, welche Verbraucher Ereignisse erhalten).

Event-Streaming-Muster sind am nützlichsten für Apps, die sowohl Echtzeit-Event-Aktualisierungen als auch Zugriff auf vergangene Events benötigen (z. B. Betrugserkennung für Finanzinstitute).

Zusätzlich zu den beiden primären EDA-Architekturmustern steuern drei Entwurfsmuster, wie Ereignisse verarbeitet werden, sobald sie den Abonnenten erreichen.

• Einfache Ereignisverarbeitung: Verbraucher verarbeiten Ereignisse genau so, wie sie von den Herausgebern empfangen werden, und lösen sofortige Aktionen aus.

• Event Stream Processing (ESP): wo Datenstreaming Plattformen Ereignisse aufnehmen und eine Pipeline zu Stream-Prozessoren aufbauen, die den Stream dann verarbeiten und transformieren.
  
  
• Verarbeitung komplexer Ereignisse (Complex Event Processing, CEP): Hier verarbeiten Verbraucher eine Reihe von Ereignissen, um Trends und Muster in den Daten zu erkennen.

Alle drei Verarbeitungsmuster (von vielen) können sowohl in Publish/Abonnieren- als auch in Event-Streaming-Architekturmustern verwendet werden, aber ESP ist (natürlich) am häufigsten im Event-Streaming-Architekturmuster.

EDAs können für Unternehmen, die in einer Vielzahl von Branchen tätig sind, nützlich sein, aber sie sind besonders wertvoll für Unternehmen mit großen, komplexen IT-Umgebungen.

Unternehmen, die beispielsweise Systeme integrieren möchten, die in verschiedenen Technologie-Stacks ausgeführt werden, können die Entkopplungs-Funktionen ereignisgesteuerter Architekturen nutzen, um Ereignisdaten systemunabhängig zu halten und die Interoperabilität zu verbessern. Multinationale Unternehmen können eine EDA verwenden, um Systeme über Konten und Regionen hinweg zu koordinieren, was eine unabhängige Skalierung verschiedener Teile der Architektur erleichtert. Und für Unternehmen, die Systeme betreiben, die jeweils unterschiedliche Teile eines Ereignisses verarbeiten, können die Fan-Out-Funktionen von EDAs Ereignisse an jeden Verbraucher weiterleiten – ohne neuen Code zu benötigen –, um sie systemweit parallel zu verarbeiten.

Im E-Commerce kann eine ereignisgesteuerte Architektur Ereignisse in Echtzeit filtern und weiterleiten, um sicherzustellen, dass sie nur an Abonnenten weitergeleitet werden, die an ihren Daten interessiert sind. Neue Käufe gehen direkt an die Verbraucher, die Bestellungen bearbeiten, Probleme mit Bestellungen werden direkt an den Kundenservice weitergeleitet und so weiter.

Ereignisgesteuerte Architekturen werden immer wichtiger, damit heutige Unternehmen mit dem Markt Schritt halten können und zukunftsorientiert bleiben. Tatsächlich planen 26 % der Unternehmen die Einführung von EDAs, um Geschäftsanforderungen zu erfüllen, zusätzlich zu den fast 37 % der Unternehmen, die dies bereits getan haben. ¹ Und es wird erwartet, dass sich die EDA-Softwarebranche bis 2027 verdoppeln wird – auf mehr als 16,5 Milliarden US-Dollar^{Umsatz. 2} 

Jeden Tag ziehen Tausende von Geschäftsereignissen durch jeden Teil eines Unternehmens, und diese Ereignisse liefern eine Fülle von Informationen über die Vorgänge in einem Unternehmen zu jedem Zeitpunkt. Ohne die richtige Technologie sind viele Unternehmen jedoch nicht in der Lage, diese Daten zu verarbeiten und zu nutzen, um fundierte Entscheidungen über ihre Kunden, Produkte oder ihr Geschäft zu treffen.

Hier werden EDA-Plattformen von unschätzbarem Wert eingesetzt, da sie eine Automatisierung mit hohem Durchsatz und geringe Latenz ermöglichen und fortschrittliche Tools für eine Reihe von Anwendungsfallen bereitstellen, darunter:

Ereignisgesteuerte Architekturen nutzen Geschäftsereignisse, indem sie es Benutzern ermöglichen, aufkommende Situationen zu erkennen, in Echtzeit zu handeln, Entscheidungsfindung zu automatisieren und das Umsatzpotenzial zu maximieren. EDA kann Unternehmen auch dabei helfen, ihr Wachstum aufrechtzuerhalten und zu beschleunigen, indem sie Folgendes bietet:

EDAs ermöglichen die Erweiterung von Systemen, indem weitere Instanzen von Diensten hinzugefügt werden, um höhere Workloads zu bewältigen.

EDAs ermöglichen es Komponenten, asynchron zu kommunizieren; Produzenten veröffentlichen Ereignisnachrichten nach ihrem eigenen Zeitplan, ohne darauf zu warten, dass Konsumenten sie empfangen (oder überhaupt zu wissen, ob Konsumenten sie empfangen haben), was sowohl die Integration als auch die Benutzererfahrung vereinfacht.

Dienste können unabhängig voneinander hinzugefügt, entfernt oder geändert werden, was die flexible Entwicklung und die Bereitstellung erleichtert.

EDAs sind zeitlich und synchronisiert entkoppelt, sodass Ereignisproduzenten und -konsumenten über Ereignisse (und nicht durch direkte API-Aufrufe) miteinander interagieren, was die Abhängigkeiten verringert und die Ausfallsicherheit des Systems insgesamt erhöht.

EDA ist von Natur aus für die Verarbeitung und Reaktion in Echtzeit konzipiert, was es Teams ermöglicht, proaktiver zu reagieren und intelligentere Maßnahmen und Automatisierungen zu ermöglichen.