- Published on
Kafka und Event-Driven Architecture
- Authors
- Name
- Ismail Bay
In diesem Artikel möchte ich eine Einführung in die ereignisgesteuerte Architekturen (Event-Driven Architecture, kurz EDA) geben und kurz über die Vorteile sowie die Herausforderungen aus meinen Erfahrungen in realen Projekten schreiben.
In weiteren Artikeln werde ich tiefer in das Thema einsteigen und ein fiktives Projekt im Bauwesen mithilfe der EDA erstellen.
Was ist Event-Driven Architecture?
Die Event-Driven Architecture ist ein Paradigma, das die Ereignisse innerhalb verteilter Systeme in den Vordergrund stellt. Ereignisse (Events) sind innerhalb eines Systems entstandene Fakten, können Daten tragen und dienen als Auslöser (Notification).
Die Unterschiede zu einer gewöhnlichen Architektur (Request-Response) lassen sich an einem Beispiel darstellen:
Die Baugenossenschaft BayBau AG arbeitet mit Bauunternehmen zusammen und beauftragt diese mit diversen Aufgaben. Für eine vorgesehene Fassadensanierung sollen von diesen Firmen Angebote eingeholt werden.
Remote Procedure Invocation Pattern (RPI)
In einer nach RPI1 entworfenen Systemlandschaft würde eine vereinfacht dargestellte Kommunikation zwischen den Services folgendermaßen ausschauen:
Die synchrone Kommunikation erfolgt über REST bzw. gRPC.
- Im Frontend werden die Daten für einen Auftrag erfasst und abgeschickt
- Das
AuftragService
speichert diese Daten und fordert dasAngebotService
auf, Angebote von Firmen einzuholen - Das
AngebotService
fragt dasFirmaService
ab, holt die notwendigen Firmendaten und erstellt formelle Angebotsanfragen
An dieser Stelle ignorieren wir einfachheitshalber das Notifizieren der Firmen. Sie können in der Plattform einsteigen und sehen ihre Anfragen. - Das
AngebotService
bestätigt das erfolgreiche Erstellen der Angebotsanfragen
Vorteile
- Einfach und vertraut
- Implementierung ist leicht
Nachteile
- stark gekoppelte Services
- Ausfall eines Services bedeutet oft ein Gesamtausfall des Systems
- neue Anforderungen bedeuten Anpassungen an bestehenden Services
Event-Driven Architecture
In der Event-Driven2 Variante kommunizieren die Services über Nachrichten, die in Kafka gespeichert werden, miteinander. Das AuftragService
erstellt ein Event AuftragErfasst
, das dem AngebotService
als eine Art Benachrichtigung dient.
Das Event AuftragErfasst
beinhaltet einige der notwendigen Informationen, z.B. Art der Leistung, Umfang und den Fertigstellungszeitraum. Um die Angebotsanfragen erstellen zu können, fehlen dem AngebotService
noch die notwendigen Daten über die Firmen. Diese Daten werden vom FirmaService
abgefragt. Aber keine Sorge. Das ist nur vorübergehend so gelöst. Durch eine Kundenanforderung wird später auch das FirmaService
notwendigerweise auf Event-Driven umgestellt.
Vorteile
- lose Kopplung
- Ausfall von
AngebotService
hat keine Auswirkungen aufAuftragService
und umgekehrt - einfache Erweiterbarkeit wie wir in einem späteren Blogartikel sehen werden
Nachteile
- höhere Komplexität durch ein Fremdsystem (Kafka)
- Reihenfolge der Event-Kommunikation bei komplexen Systemen
- Integrationstests nicht mehr leicht durchführbar
- Zwischenzeitlich keine Konsistenz der Daten (eventually consistent)
Was sollte ich nun wählen?
Wie bei jedem Paradigma gibt es viele Vorteile aber auch Nachteile. Obwohl EDA in vielen Szenarien vorteilhaft sein kann, ist sie keine universelle Lösung. In manchen Fällen kann die Verwendung von EDA eine unnötige Komplexität und Overhead einführen.
Die Architektur sollte man immer nach voraussichtlichem Mehrwert für Business auswählen. Ein Monolith, der seine Arbeit zuverlässig erledigt und dabei leicht wartbar ist, kann genauso gut sein wie eine Systemlandschaft aus etlichen Microservices, die miteinander über synchrone Schnittstellen kommunizieren und kaum Ausfälle haben.
Betrachtet man allerdings die Daten eines Unternehmens als wertvolle Ressource, wird es notwendig auf Änderungen in Echtzeit zu reagieren, neue Use-Cases aus diesen Daten zu generieren und flexibel zu bleiben, um auf neue Entwicklungen im täglichen Geschäft schnell reagieren zu können.
EDA kann hierbei ihre Stärken ausspielen und einen echten Mehrwert bieten.
Warum so denglisch?
Abgesehen von technischen Fachausdrücken sind wahrscheinlich die Service- und Event-Namen aufgefallen. Dazu findest du im nächsten Artikel einige Informationen und die Begründung dahinter.