Event Driven Architecture

In diesem Artikel möchte ich eine kurze Einführung in Event Driven Architecture geben. Ich stelle eine Referenz-Architektur und ein Praxisbeispiel vor.

Einführung

Event Driven Architecture (EDA) ist ein Architekturstil, der im Gegensatz zu Service Oriented Architecture (SOA), auf den Versand von Nachrichten (Informationen) und nicht auf den Aufruf von Services (Funktionen) beruht. Oder anders gesagt, bei SOA geht es um Commands (Ich sage was passieren soll, z.B. „Ändere die Adresse„), bei EDA geht es um Events (Ich sage was passiert ist, z.B. „Die Adresse hat sich geändert„).

Dieses einfache „Ich sage was passiert ist“ anstatt „Ich sage was passieren soll“ führt zu einer Verlagerung der Verantwortlichkeit vom Sender zum Empfänger.
Beispiel: Bei einer Bestellung muss die Kreditkarte geprüft werden. Dazu bietet ein Credit-Komponente eine Funktionalität an um die Kreditkarte zu prüfen.
In einer SOA bietet die Credit-Komponente einen Service (Command) an „verifiyCreditCard„.

SOA vs EDA
SOA vs EDA

In einer EDA empfängt die Credit-Komponente ein Event „OrderReceived„.
In der SOA ist somit der Sender verantwortlich zu entscheiden, was passieren soll und er muss eine bestimmte Funktion aufrufen. In der EDA informiert der Sender nur über ein eingetretenes Ereignis, die Entscheidung was passieren soll, trifft der Empfänger. Dem Sender ist das egal, er muss kein Wissen darüber haben, was gemacht werden muss und wer die Aktion ausführt. Somit führt eine EDA zu einer stärkeren Entkopplung als eine SOA. Über das Thema Entkopplung gehe ich im Artikel    lose Kopplung von Systemen weiter ins Detail.

Eine EDA ist aber mehr als nur der einfache Austausch von Informationen über Events. Gregor Hohpe beschreibt in seinem Artikel „programming without a call stack“ die folgenden Kerneigenschaften einer EDA [1]:

  • Broadcast Communications
    Systeme senden Events an alle interessierten Systeme. Mehr als ein System kann auf ein Event reagieren und es verarbeiten. Dies wird über publish / subscribe Mechanismen erreicht.
  • Timeliness
    Systeme publizieren Events sobald sie auftreten. Sie speichern sie nicht lokal und warten auf einen Verarbeitungs-Zyklus wie ein nächtlicher Batch.
  • Asynchrony
    Das publizierende System wartet nicht auf die Verarbeitung des Events im empfangenden System / Systeme.
  • Fine Grained Events
    Systeme publizieren eher einzelne kleine Events anstelle eines großen aggregierten Events. Dies kann durch physikalische Begebenheiten des Netzwerkes begrenzt sein.
  • Ontology
    Das gesamte EDA System definiert eine Nomenklatur mit der die Events klassifiziert werden. Dies erfolgt typischerweise über Hierarchien. Empfänger können in einzelnen Events oder ganzen Kategorien interessiert sein.
  • Complex Event Processing (CEP)
    Das EDA System versteht und überwacht die Beziehungen von Events. Events können aggregiert werden zu höherwertige Events oder ein Event wird durch ein anderes ausgelöst.

Complex Event Processing (CEP) ist ein sehr wesentliches Kernelement einer EDA. Darüber wird die Fachlichkeit einer EDA beschrieben. Einzelne kleine, technisch orientierte Events, lassen sich fachlich verknüpfen und daraus neue höherwertige Events erzeugen.
Beispiel 1: Kontaktschleifen in einer Strasse senden ein Event sobald ein Fahrzeug über die Kontaktschleife fährt. Über diese vielen kleinen Events kann die Verkehrssituation abgeleitet und ein fachlich höherwertiges Stau-Event publiziert werden.
Beispiel 2: Eine Kreditkarten-Zahlung löst ein Event aus. Wird dieses Event vom gleichen Kunden, innerhalb von 1 Stunde, aus Frankfurt und aus Sydney empfangen, liegt ein Kreditkartenbetrug vor und ein entsprechendes Alarm-Event kann ausgelöst werden.

Architektur

Die Referenz-Architektur einer EDA sieht drei Schichten vor [2]:

  1. Monitoring
    Hier erfolgt der technische Zugriff auf die Ereignisquellen (In-Adapter) und die Transformation der proprietären Ereignis-Objekte in ein standardisiertes Format mit dem die nachgelagerten Schichten arbeiten können.
    Zudem werden die Events einem Cleaning-Schritt unterzogen (Ereigniskonsistenz).  Fehlerhafte oder doppelte Ereignisse werden aussortiert oder korrigiert.
  2. Ereignisverarbeitung
    Hier erfolgt die regelbasierte Verarbeitung der Events (Complex Event Processing). Events werden über Filter aussortiert, durch Content-Enrichment mit notwendigen Informationen angereichert und durch eine Ereignissynthese zu neuen und höherwertigen Events zusammengefasst.
  3. Ereignisbehandlung
    Hier erfolgt die Behandlung der höherwertigen Ereignisse. Es werden, auf Basis von Events, Services von operativen Systemen aufgerufen bzw. die Systeme reagieren auf die Ereignisse oder es werden Ereignisse visualisiert.
EDA Referenz-Architektur
EDA Referenz-Architektur

Je nach Größe eines EDA Systems macht es Sinn die einzelnen Komponenten zu verteilen und so ein Event Processing Network (EPN) aufzubauen. So kann es verschiedene, unabhängige Event-Monitore geben, die Events über Event-Channels senden. Die Ereignisverarbeitung erfolgt durch Event Processing Agents (EPA), die ebenfalls verteilt sind. Die Aufgabenaufteilung der EPAs kann auf Basis von fachlichen Event-Gruppen erfolgen, oder auf Basis von Aufgaben. Somit kann eine Pipeline mit dedizierte EPAs für Filter, Transformation und Synthese aufgebaut werden. Auch die Ereignisbehandlung kann durch verschiedene Systeme erfolgen die auf Events reagieren.

Praxisbeispiel

Service Monitoring
Service Monitoring

Am Beispiel eines Service-Monitorings möchte ich eine EDA praktisch aufzeigen. In einer SOA soll das Verhalten und die Nutzung von Services überwacht werden. Der Verantwortliche für Services soll darüber informiert werden, wie oft seine Services aufgerufen werden und ob sie die vereinbarten SLAs (Service Level Agreements) einhalten.

Um die Anforderungen zu erfüllen publiziert ein Service folgende Events:

  • Request-Event
    Sobald er aufgerufen wird, also der Request beim Service eingeht. Das Event enthält den Timestamp des Requests, eine eindeutige TraceID für diesen Service-Request, sowie den Namen bzw. eine ID des Service.
  • Response-Event
    Sobald der Service die Response zum Consumer sendet. Das Event enthält den Timestamp der Response, die eindeutige TraceID des dazugehörigen Service-Request, sowie den Name bzw. eine ID des Service.

Die Events können direkt als Message gesendet oder in ein Log-File geschrieben werden.
Die drei Schichten der Referenz-Architektur erfüllen im Beispiel folgende Aufgaben:

  1. Monitoring
    Überwacht die Log-Files und erzeugt auf Basis der Log-Einträge entsprechende standardisierte Events. Werden die Events vom Service bereits über ein Messaging System gesendet können sie hier transformiert werden, falls sie noch nicht dem Standardformat entsprechen.
    Die Monitoring-Schicht stellt die Events über einen Event-Channel der Ereignisverarbeitung zur Verfügung.
  2. Ereignisverarbeitung
    Reagiert auf die Events Request-Event und Response-Event. Liest aus einer Datenbank die im SLA definierten Antwortzeiten zu einem Service (diese können aus Performancegründen gecached werden). Bei einem Request-Event wartet die Ereignisverarbeitung auf das eintreffen des zugehörigen Response-Events. Die Korrelation erfolgt über die TraceID.
    Über die Timestamps in den Events wird die Antwortzeit des Service berechnet. Ist diese kleiner als die im SLA definierte wird ein Service-Success-Event erzeugt. Ist sie größer wird ein Service-Slow-Event erzeugt. Kommt kein Response-Event in einer definierten Zeit, wird ein Service-Timeout-Event erzeugt.
    Zusätzlich wird geprüft, ob eine bestimmte Anzahl von Service-Slow-Events bzw. Service-Timeout-Events zu einem Service in einem definierten Zeitfenster auftreten. In diesem Fall liegt ein Problem im Service-Provider vor und es wird ein Service-Problem-Event erzeugt.
    Die Ereignisverarbeitung-Schicht stellt die abgeleiteten Events über einen Event-Channel der Ereignisbehandlung zur Verfügung.
  3. Ereignisbehandlung
    Reagiert auf die Events Service-Success-Event, Service-Slow-Event, Service-Timeout-Event und Service-Problem-Event.
    In einem Dashboard werden die Events visualisiert damit der Service-Verantwortliche den „Gesundheitszustand“ des Services sehen kann.
    In einer Datenbank werden die Events gespeichert um die Historie anzeigen zu können.
    Ein weiteres System sendet bei einem Service-Problem-Event eine E-Mail an den Verantwortlichen. Ein drittes bei Service-Slow-Event, Service-Timeout-Event und Service-Problem-Event eine Nachricht über Twitter.

In diesem Beispiel ist deutlich zu sehen, wie aus zwei einfachen, technisch orientierten Events (Request-Event und Response-Event) fachlich höherwertige Events erzeugt werden. Diese fachliche Aufwertung ist einer der wesentlichen Mehrwerte einer EDA. Der Phantasie sind hier keine Grenzen gesetzt. Die Events können weiter Verknüpft werden. So kann ein Big-Problem-Event erzeugt werden, wenn zu mehreren Services ein Service-Problem-Event erzeugt wurde.
Ein weiterer Vorteil ist die starke Entkopplung der Systeme. Der Service, also die Event-Quelle, protokolliert nur die eingehenden Requests und Responses. Wer was damit macht spielt für ihn keine Rolle. Auch weitere Verknüpfungen der Events haben keine Auswirkung auf die Event-Quelle (sofern diese nicht weitere Informationen mit den Events liefern soll). Die Systeme in der Ereignisbehandlung sind ebenfalls völlig entkoppelt von den Ereignisquellen. Es spielt keine Rolle, wo die Events herkommen und wie sie erstellt wurden.

Produkte

Complex Event Processing ist, wie der Name schon sagt, eine komplexe Sache. Es ist nicht zielführend die Regeln und Algorithmen von Hand selbst zu programmieren. Es gibt Produkte die einem die Basisarbeit abnehmen.

In der Ereignisverarbeitung sollten die Regeln deklarativ erstellt werden. Als Open Source Produkte sind hier Esper und Apache Spark zu erwähnen. Esper ist ein einfaches, Java basiertes System, das als JAR-File zur Verfügung steht und in eigene Anwendungen integriert werden kann. Die API ist einfach und intuitiv nutzbar. Apache Spark ist eine Lösung für sehr großes Datenvolumen und für die Verarbeitung von Massendaten.

In der Ereignisbehandlung bietet sich, insbesondere für die Visualisierung, vert.x an. Webbasierte Dashboards können über den push-Mechanismus von vert.x die Events in nahezu Echtzeit anzeigen.

Als Messaging System muss, für den Event-Versand, nicht zwingend ein „großes“ Messaging Produkt genutzt werden. Insbesondere bei einer großen Zahl von Events, ist eine schlanke Lösung zu bevorzugen. Hier bietet sich Apache Kafka an.

weiterführende Informationen

Wann sollte man eine EDA einsetzen und taugt diese nur für Monitoring-Systeme? Eine EDA und das Senden von Events ist ein sehr interessanter Ansatz, der allerdings eine ganz andere Denkweise voraussetzt, als bei einer klassischen SOA und dem Aufruf von Funktionen. Wann genau die EDA Sinn macht möchte ich in einem Folgeartikel beleuchten.

Folgende Quellen stellen weiter führende Informationen zur Verfügung und waren auch für mich die Inspiration für das Thema.

One Reply to “Event Driven Architecture”

  1. Pingback: SOA und EDA | discoveration

Schreibe einen Kommentar

Anmelden um einen Kommentar abzugeben.

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*