Was ist eine ereignisgesteuerte Architektur?
Die ereignisgesteuerte Architektur (Event-driven Architecture, EDA) ist ein Software-Designmuster, mit der eine Organisation, „Ereignisse“ oder wichtige Geschäftsmomente (wie Transaktion, Besuch vor Ort, Abbruch des Warenkorbs usw.) zu erkennen und in Echtzeit oder echtzeitnah darauf zu reagieren. Dieses Muster ersetzt die traditionelle „Anfrage/Antwort“ -Architektur, in der Dienste auf eine Antwort warten müssten, bevor sie zur nächsten Aufgabe übergehen könnten. Der Fluss der ereignisgesteuerten Architektur wird von Ereignissen ausgeführt und ist so entwickelt, auf sie zu reagieren oder als Reaktion auf ein Ereignis eine Aktion auszuführen.
Die ereignisgesteuerte Architektur wird oft als „asynchrone“ Kommunikation bezeichnet. Das bedeutet, dass der Absender und der Empfänger nicht darauf warten müssen, dass sie mit ihrer nächsten Aufgabe fortfahren. Systeme sind nicht von dieser einen Nachricht abhängig. Zum Beispiel gilt ein Telefonanruf als synchron oder mehr im Sinne der traditionellen „Anfrage/Antwort“-Architektur. Jemand ruft Sie an und bittet Sie, etwas zu tun. Der Antragsteller wartet, während der Antwortsender die Aufgabe erledigt, und dann legen beide Parteien auf. Ein asynchrones Beispiel wäre Textnachrichten. Sie senden eine Nachricht und wissen in einigen Fällen nicht einmal, an wen Sie sie senden oder ob jemand zuhört, aber Sie warten nicht auf eine Antwort.
Die Evolution der ereignisgesteuerten Architektur
In den letzten Jahren gab es einen Übergang von der Fokussierung auf gespeicherte Daten (serviceorientierte Architektur) bis hin zur Fokussierung auf Ereignisse (Event-driven Architecture). Wir befinden uns in einem Übergang von der Sammlung von Daten und Data Lakes, um uns auf Daten in der Übertragung zu konzentrieren und sie im Auge zu behalten, während sie sich von einem Ort zum anderen bewegen. Traditionell arbeiten die meisten Systeme in dem, was Sie sich als datenzentrisches Modell vorstellen können, bei dem die Daten die Quelle der Wahrheit sind. Die Umstellung auf die ereignisgesteuerte Architektur bedeutet, von einem datenzentrierten Modell zu einem ereigniszentrierten Modell zu wechseln. Im ereigniszentrierten Modell sind Daten immer noch wichtig, aber die Ereignisse werden zur wichtigsten Komponente. Während im serviceorientierten Modell die höchste Priorität darin bestand, sicherzustellen, dass Sie keine Daten verlieren. Bei der ereignisgesteuerten Architektur besteht die Priorität darin, sicherzustellen, dass Sie auf Ereignisse reagieren, während sie eintreten. Weil es ein Gesetz gibt, das die Renditen bei Ereignissen abnimmt, sind sie weniger wertvoll, je älter sie werden. Heute werden jedoch serviceorientierte Architektur und ereignisgesteuerte Architektur oft zusammen verwendet.
Die ereignisgesteuerte Architektur verwendet oft eine Protokoll-Analogie, um die Dinge im Auge zu behalten. Datenspezialisten sprechen über Ereignisse als unveränderliche Dinge, die passiert sind. Wenn Sie dann herausfinden möchten, was in der Vergangenheit passiert ist, können Sie zurückgehen und das Protokoll erneut abspielen. Während Sie sich im datenzentrierten Modell hauptsächlich auf den Zustand der Daten konzentrieren, so wie er derzeit ist. Und dann verwenden Datenspezialisten die letzte Analogie bei der Beschreibung des Unterschieds zwischen datenzentrierten und ereignisorientierten Architekturen, dass sie sie oft zwischen einem Informationsrepository und einem Nervensystem vergleichen, das Nachrichten im Unternehmen transportiert.
Wenn Sie eine ereignisgesteuerte Architektur verwenden, haben Sie Ereignisproduzenten, die Ereignisbenachrichtigungen generieren und senden, und Sie haben möglicherweise einen oder mehrere Konsumenten eines Ereignisses, bei dem der Empfang des Ereignisses die Verarbeitungslogik auslöst. Nehmen wir zum Beispiel an, Netflix hat gerade einen neuen Film hochgeladen. Es könnte mehrere Anwendungen geben, die auf diese Benachrichtigung warten oder warten, die dann ihre eigenen internen Systeme dazu veranlassen, ihre eigenen Informationen über dieses Ereignis an ihre Benutzer zu veröffentlichen. Dies unterscheidet sich von herkömmlichen Nachrichten mit Anfragen dadurch, dass Anwendungen noch ausgeführt werden, und obwohl sie möglicherweise auf dieses Ereignis hören, sind sie nicht gelähmt, während sie darauf warten. Und sie können antworten, wenn die Nachricht veröffentlicht wird. Somit können viele Services gleichzeitig ausgeführt werden.
Was ist ein Ereignis?
Ein Ereignis wird als eine Änderung des Zustands eines wichtigen Geschäftssystems definiert. Zum Beispiel kauft jemand ein Produkt, jemand anderes checkt für einen Flug ein oder ein Bus kommt irgendwo zu spät an an. Und wenn man darüber nachdenkt, gibt es überall Ereignisse und finden ständig statt, egal in welcher Branche. Sie sind in jedem Unternehmen allgegenwärtig. Dazu gehört alles, was eine Nachricht erstellt, indem es erstellt, veröffentlicht, erkannt oder konsumiert wird. Das gilt als Ereignis. Das Ereignis ist von der Nachricht, getrennt, denn während das Ereignis das Eintreten ist, ist die Nachricht die reisende Benachrichtigung, die das Ereignis weitergibt. In der ereignisgesteuerten Architektur wird ein Ereignis wahrscheinlich eine oder mehrere Aktionen oder Prozesse als Reaktion auf sein Auftreten auslösen. Ein Beispiel für ein Ereignis könnte Folgendes sein:
- Bitte um das Zurücksetzen eines Passworts
- Ein angekommenes Paket wurde an seinen Zielort geliefert
- Ein Lebensmittellager aktualisiert sein Inventar
- Ein unbefugter Zugriffsversuch wurde verweigert
Jedes dieser Ereignisse wird wahrscheinlich eine oder mehrere Aktionen oder Prozesse als Reaktion auslösen. Eine Antwort könnte einfach darin bestehen, das Ereignis zu Überwachungszwecken zu protokollieren. Andere könnten sein:
- Es wird eine E-Mail zum Zurücksetzen des Passworts an den Kunden gesendet
- Das Verkaufsticket ist geschlossen
- Es wird eine Bestellung für mehr Salat (oder welche Materialien ausgehen) aufgegeben
- Ein Konto ist gesperrt und das Sicherheitspersonal wird benachrichtigt
Bei der ereignisgesteuerten Architektur erfasst das System beim Senden einer Ereignisbenachrichtigung, dass etwas passiert ist, wie eine Zustandsänderung aufgetreten ist, und wartet darauf, die Antwort an jeden zu senden, der es anfordert, wann immer er sie anfordert. Die Anwendung, die diese Nachricht erhalten hat, kann entweder antworten oder warten, bis die Statusänderung eingetreten ist, auf die sie wartet.
Anwendungen, die auf einer ereignisgesteuerten Architektur basieren, ermöglichen agilere, skalierbarere, kontextbezogene und reaktionsschnelle digitale Geschäftsanwendungen.
Wie funktioniert die ereignisgesteuerte Architektur?
Die Komponenten einer ereignisgesteuerten Architektur können drei Teile umfassen: Hersteller, Konsument, Broker. Der Broker kann optional sein, insbesondere wenn Sie einen einzelnen Produzenten und einen einzelnen Verbraucher haben, die in direkter Kommunikation miteinander stehen und der Hersteller die Ereignisse nur an den Konsumenten sendet. Ein Beispiel wäre ein Hersteller, der nur an eine Datenbank oder ein Data Warehouse sendet, sodass die Ereignisse erfasst und zur Analyse gespeichert werden. Am häufigsten haben Sie in Unternehmen mehrere Quellen, die alle Arten von Veranstaltungen mit einem oder mehreren Konsumenten versenden, die an einigen oder allen dieser Ereignisse interessiert sind.
Sehen wir uns ein Beispiel an. Wenn Sie ein Einzelhändler sind, sammeln Sie möglicherweise alle Einkäufe, die in all Ihren Geschäften auf der ganzen Welt stattfinden. Diese speisen sie in Ihre ereignisgesteuerte Architektur ein, die auf Betrug achtet, sendet sie an einen Kreditkartenverarbeiter oder alle Aktionen, die als nächstes stattfinden müssen. Für einen Hersteller haben Sie alle Arten von Daten, die von Ihrem Gerät stammen, die Ihnen Fakten wie Temperatur und Druck mitteilen, damit Sie diese Ereignisse in Echtzeit überwachen und Maßnahmen wie die Vorhersage von Fehlern oder Planwartungen ergreifen können, je nachdem, was die Daten Ihnen sagen.