Event Driven Streaming Architektur
Was wir bisher zu dem Thema veröffentlicht haben finden Sie hier:
Teil 1 - Teil 2 - Teil 3 - zu Model Driven Transformation for Streaming Applications
In diesem aktuellen Beitrag beschreiben wir den technischen Rahmen für die Software-Entwicklung – die Software Architektur.
Die Challenge/Vision:
Für das erfolgreiche Design der Software Architektur sind neben den nicht-funktionalen Anforderungen unter anderem auch funktionale Anforderungen, wie das Datenaufkommen, die bestehenden oder zukünftigen Geschäftsprozesse, sowie der Systemkontext wichtige Architekturtreiber. Für die hier vorgestellte Software Architektur sind folgende funktionale Anforderungen definiert worden:
- Unterstützung von komplexen, ereignisorientierten (even-driven) Geschäftsprozessen
- near-realtime Verarbeitung von Event- bzw. Datenströmen
- Anbindung von REST-Services
- Synchrone und asynchrone Kommunikation
- Lose Kopplung von Komponenten
- Unterstützung von Datentransformationen
Unsere Lösung:
Zwei wesentliche Faktoren bei den oben aufgezählten funktionalen Anforderungen sind die Events und die Services mit synchroner und asynchroner Kommunikation. Damit steht der Fokus zum einen auf die ereignisgesteuerte und zum anderen auf die serviceorientierte Architektur unter Berücksichtigung des Data Streamings.
Als skalierbare, hochperformante Event/Data Streaming Plattform ist Apache Kafka gesetzt. Aus mehreren Gründen: Skalierbarkeit, Performance, Fehlertoleranz und Entkopplung. Durch Apache Kafka ist es möglich Eventströme von Drittsystemen problemlos zu empfangen, schnell zu verarbeiten und weiterzuleiten.
Ein Event wird von einem Event-Producer in einen Event-Channel eingespeist damit es von einer Consumer-Applikation verarbeitet werden kann. Kennzeichen des event-driven Ansatzes ist es, dass die Producer-Applikation nicht erwartet, dass die Consumer-Applikation „sofort“ reagiert, also blockiert ist, solange die Consumer-Applikation nicht reagiert (asynchrone statt synchroner Kommunikation). In vielen Geschäftsprozessen erwartet eine Producer-Applikation jedoch früher oder später eine Antwort (Bestätigung und/oder Rückweisung des gesendeten Events) und muss darauf reagieren. Die Antwort ist also selbst wieder ein Event, dass von der ursprünglichen Consumer-Applikation an die ursprüngliche Producer-Applikation geht. Aufgrund der Asynchronität kann hierbei nicht von einer echten Real-Time-Antwort gesprochen werden, jedoch kann bei geeigneter Konfiguration des Regelwerks eine schnelle Antwort erwartet werden (near-realtime). Es sind natürlich auch Anwendungsszenarien denkbar, bei den mehr als eine Applikation im Spiel ist.
Gerade durch die Digitalisierung kommen zunehmend komplexere Prozesse ins Spiel, bei denen eine Vielzahl von Applikationen (Microservices, Sensoren, horizontal und vertikale integrierte Systeme, etc.) zusammenspielen, so dass ein Event durch eine ganze Kette von Applikationen verarbeitet werden bzw. Applikationen aus einem Event Nachfolgeevents generieren und diese weitergeben. Die Consumer werden gleichzeitig wieder zu Producer. Die Events selbst können zudem aus komplexen Daten bestehen. Diese Daten, größtenteils mit gleicher fachlicher Bedeutung, können von verschiedenen Applikationen unterschiedlich interpretiert und dargestellt werden. Es ergibt sich also die Notwendigkeit die Daten, je nach Verwendungsszenario, zu transformieren.
Für die Software Architektur sind nun folgende Komponenten identifiziert:
- Producer-Applikation (Spring-Framework, REST-Service)
- Consumer-Applikation mit Datenbank (Spring-Framework, REST-Service)
- Streaming Plattform (Apache Kafka)
- Transformation-Applikation (StreamMapper)
Die Schnittstellen und somit auch die Kommunikation zwischen den einzelnen Komponenten sind maßgeblich von den Vorgaben und dem Regelwerk der Streaming Plattform abhängig. In Abbildung 1 wird das Zusammenspiel der Komponenten nun deutlich gemacht.
Detailliertere Einblicke in die einzelnen Komponenten und das Zusammenspiel zwischen diesen, sowie die dazugehörige Modellierung erhalten Sie in den nachfolgenden Blogbeiträgen.
Weiterlesen:
Im folgenden Blog-Beitrag wird es um die Modellierung der Eingangs- und Ausgangs-Datenstrukturen sowie um die Daten-Transformation gehen.
MID Blog Newsletter abonnieren