Was bedeutet „ereignisgesteuert“, und wie schnell ist Echtzeit?
Bei näherem Nachdenken lassen sich viele ereignisgesteuerte Szenarios als solche identifizieren. Viele von ihnen erfordern eine Reaktion in Echtzeit.
Was bedeutet „Echtzeit“?
Eine Reaktion in Echtzeit kann als unmittelbare Antwort beschrieben werden. Stellen Sie sich als Beispiel den Kassierer in einem Café vor, der Sie fragt, was Sie trinken möchten.
Der Kassierer erwartet eine sofortige Antwort oder zumindest eine Antwort ohne größere Verzögerung. Andernfalls würde der Kassierer möglicherweise die Frage nochmal anders stellen oder Sie für unhöflich halten. Eine schnelle Antwort wird also erwartet und gilt als angemessen. Die Zeit für die Antwort kann leicht variieren, wird aber immer noch als Antwort „in Echtzeit“ bezeichnet. Eine Begrüßung sollte daher schnell erfolgen, aber es ist in Ordnung, kurz über Ihre Bestellung nachzudenken, um die Frage von Kassierer*innen zu beantworten.
Wenn Sie dieses Szenario auf Softwaresysteme übertragen, so dreht sich hier alles um Zeitangaben: Antwortzeit, Abschlusszeit, Zugriffszeit, Startzeiten usw. Diese Zeiten werden von dem Benutzer/der Benutzerin oder der zugreifenden Anwendung definiert.
Hinweis
In Echtzeitsystemen werden Aufgaben innerhalb bestimmter Fristen ausgeführt.
Sie sollten sich immer darüber im Klaren sein, was in Ihrem System geschieht. Achten Sie also darauf, die Ausführung entsprechender Aktivitäten wie Protokollierung, Überwachung und Messung der Zeiten nicht zu vergessen.
Wichtig
Legen Sie die Fristen und Zeiten vorher fest, und richten Sie eine nicht blockierende Überwachungslösung zur Kontrolle ein.
Echtzeitgeschwindigkeit bedeutet im Grunde genommen, dass etwas „sehr schnell“ bzw. „sofort“ erfolgt. Wie schnell genau, wird durch das jeweilige Szenario bestimmt.
Ereignisgesteuerte Anwendungen
Bei Click-Ereignissen handelt es sich um ein anderes Konzept. Ereignisgesteuerte Anwendungen verwenden das Prinzip Fire und Forget (Auslösen und Vergessen). Das Ereignis wird also an das nächste System gesendet oder ausgelöst, bei dem es sich um einen anderen Dienst, einen Event Hub, einen Stream oder einen Nachrichtenbroker wie Kafka handeln kann. Auf eine Antwort des nächsten Diensts im System wird nicht unbedingt gewartet. Lose Kopplung wird auf Kosten von letztlicher Konsistenz erzielt, die auf einer anderen Ebene sichergestellt werden muss.
Sehen Sie sich hier die wichtigsten Architekturmuster am Beispiel des Kunden Alex an, der einen Kaffee und einen Cappuccino kaufen möchte, um das Wesen von ereignisgesteuerten Anwendungen besser zu verstehen.
Ereignisbenachrichtigung
„Ereignisbenachrichtigung“ bezeichnet die Benachrichtigung über ein bestimmtes Ereignis oder einen bestimmten Vorfall. Dabei wird jedes Ereignis separat betrachtet. Am Beispiel des Kunden Alex, der einen Kaffee und einen Cappuccino kauft, könnte dieses wie folgt aussehen:
1. Ereignis: Alex kauft einen Kaffee.
2. Ereignis: Alex kauft einen Cappuccino.
Ein Barista müsste genau hinhören, um beide Ereignisse zu erfassen und damit die gesamte Bestellung von Alex entgegenzunehmen. Es könnten aber auch zwei Baristas unabhängig voneinander die Getränke zubereiten und servieren.
Event-Carried State Transfer
Bei Verwendung des Musters „Event-Carried State Transfer“ werden alle benötigten Informationen in einem einzelnen Ereignis gespeichert. Dies ist hilfreich, wenn ein Ereignis verloren gegangen ist oder der Dienst nicht alle Ereignisse überwacht. In unserem Beispiel würden die Ereignisse wie folgt aussehen:
1. Ereignis: Alex kauft einen Kaffee.
2. Ereignis: Alex kauft zusätzlich zum Kaffee einen Cappuccino.
Ein Barista, der nur das zweite Ereignis berücksichtig, könnte ausreichen. Bei zwei Baristas müsste sich der zweite Barista nach dem ersten richten. Die Bestellung könnte gemeinsam serviert werden, der Prozess wäre aber möglicherweise länger als bei einer vollständig unabhängigen Ausführung.
Ereignissourcing
Beim Muster „Event Sourcing“ tritt der Ereignisspeicher in den Mittelpunkt. Wie Sie sehen können, sind die Ereignisse identisch mit denen im ersten Beispiel. Der Barista wird jedoch für dieses Konzept in dem Augenblick wichtig, in dem er ein Ereignis erhält und dann über alle dazugehörigen Ereignisse nachdenkt, um den aktuellen Status aller Aufträge von Alex abzurufen.
Bei der zweiten Bestellung weiß der Barista, dass Alex einen Kaffee bestellt hat, indem er sich an die erste Bestellung erinnert, sowie einen Cappuccino, da das das Getränk ist, das Alex soeben bestellt hat. Das parallele Arbeiten mit einem zweiten Barista ist hingegen nicht so einfach möglich.
Wenn ein Kassierer hinzugefügt wird, der die Bestellungen empfängt und die Getränke serviert, können die Baristas unabhängig arbeiten und die Getränke vorbereiten. Sie müssen nichts über die Kunden wissen. Der Kassierer ist in diesem Szenario der sogenannte Ereignisspeicher, in dem die Ereignisse gespeichert werden. Event Sourcing erhöht demnach zwar die Komplexität, ermöglicht jedoch auch die Entkopplung.
1. Ereignis: Alex kauft einen Kaffee.
Servicekraft: (Erste) Bestellung (für Alex): Kaffee
2. Ereignis: Alex kauft einen Cappuccino.
Servicekraft: (Zweite) Bestellung (für Alex): Cappuccino
Telemetriedaten sind Echtzeitereignisse
Es gibt aber auch weitere Beispiele. Stellen Sie sich ein Szenario vor, in dem Sie ein Kühlsystem betreiben, z. B. für Nahrungsmittel- oder Medikamentenhersteller. Sie müssen jederzeit die Temperatur und andere relevante Daten in Ihrem System kontrollieren und steuern können. Informationen zu den Telemetriedaten sowie eine automatische Steuerung wären entscheidend für Ihren Erfolg. Das Messen der Telemetriedaten alle zwei Sekunden und das anschließende Senden an das Steuerungssystem, in dem die Daten analysiert und verarbeitet werden, sind als ereignisgesteuerte Systeme zu betrachten. Die Daten müssen außerdem in Echtzeit verarbeitet werden, da es entscheidend ist, schnell zu reagieren, um schwerwiegende Konsequenzen für das Unternehmen zu vermeiden.