Kafka – Schuko Steckdose der Versicherungs-IT?
Lose gekoppelte Systeme sind seit den 70ern des letzten Jahrtausends hehres Ziel vieler IT-Architekturen. Ansätze dazu haben wir schon in diversen Projekten erlebt: CORBA, RMI, SOAP, ReST und so weiter. Ist das Ganze auch noch asynchron, wird es direkt komplexer. Trotzdem bleibt die Technologieauswahl von Message Oriented Middleware mit IBM WebSphere MQ, RabbitMQ, Apache ActiveMQ und Co.immer noch mannigfaltig und mit iPaaS kommt ein neuer Kandidat hinzu. Kurzum: Der Standard ist noch nicht gefunden.
Apache Kafka
Mit Apache Kafka – Franz Kafka diente als Namenspate – tritt bereits seit 2011 eine Open Source, Community-driven, verteilte und hoch verfügbare Event-Streaming-Plattform in den Fokus der IT-Architekten. Können wir hiermit die Mainframe-basierte IT der Versicherungswirtschaft modernisieren?
Projekt Phönix
Im letzten Jahr startete das Projekt Phönix. Mit unserem Kunden haben wir uns der Herausforderung gestellt, nicht nur ein neues Bestandssystem mit Faktor IPM und eine neue Angebot-/Antragsstrecke mit Faktor IOS zu etablieren, sondern auch einen verteilten, asynchronen Ansatz zu wählen, um Systeme miteinander zu koppeln.
Schuko…
Wie komme ich zum Titel des Blogs? Der leitende IT-Architekt hat in seinen Ausführungen ein Bild geprägt, dass ich sehr passend finde und hier nennen möchte: „Man kann in einem Haushalt den Toaster, die Kaffeemaschine usw. fest an das Stromnetz verlöten – das geht gut, solange man den Toaster nicht austauschen muss; wir wollen mit Phönix besser werden und Steckdosen verbauen!“
So entsteht das Architekturbild: Die Systemlandschaft sieht Micro-Services vor, die miteinander über Kafka (unsere Schuko-Steckdose) soweit möglich asynchron kommunizieren. Das ist unser gewählter „Standard“ bzw. unser Standard-Integrationsmuster und Abweichungen hiervon müssen begründet werden.
Wenn man sich für eine Technik entscheidet, dann gibt es immer ein Für und Wider. Entscheidet man sich trotzdem, dann ist gut zu dokumentieren (bspw. https://arc42.de/template), warum man sich bspw. dafür entschlossen hat oder welche Alternativoptionen existieren.
Um in der Analogie zu bleichen: sind da 230V oder 150V drauf.
In der Architekturentscheidung für das Projekt Phönix ist zu lesen: Wir nutzen JSON, definieren Datentransferobjekte und führen ein einfache Versionierung durch Paketnamen durch. Die Alternative mit Apache Avro (3) wird oft bevorzugt, da man hierbei ein sehr optimiertes Datenformat hat. Avro benötigt jedoch zusätzlich eine Schemaregistratur, die wir im „Scope“ des Projektes nicht einführen wollten.
Faktor Zehn Suite
Die Faktor Zehn Versicherung Suite hat eine reiche Sammlung an Funktionsbausteinen. Das hat mir schon immer sehr gut gefallen, nämlich den schmalen Grad zu gehen, zwischen a) wirklich nutzbare Bausteine anzubieten und b) nicht zu sehr vorschreiben, wie Prozesse aussehen oder gar dem Kunden fertige Anwendungen aufzuzwingen. So macht die Suite keine Annahmen über die anzubindenden Systeme und bietet abstrakte Schnittstellen (Java Interfaces) und viele Erweiterungspunkte (Spezialisierungen, Listener, etc.) an.
Die Philosophie geht im Projekt Phönix einmal mehr auf: In Faktor IPM werden Bearbeitungen und Aktionen modelliert. Hier kann man neben dem Verhalten der Historisierung und verschiedenste Einstellungen auch Lifecycle-Listener anhängen, die uns mögliche Erweiterungspunkte anbieten.
Konfiguration
Die Bestandsverwaltung Faktor IPM ist zum jetzigen Stand eine JEE-Anwendung.
Wenn man es richtigmachen will, spricht ein JEE-Container nur über verwaltete (ge-managed-e) Ressourcen mit der Umwelt. Daher wäre es gut, wenn die Verbindung zum Kafka-System, also die Verbindung zu den (Plural!) Kafka-Brokern als eine Container-Ressource bereitgestellt und injiziert werden könnte (CDI, @Inject).
Auf der Suche nach Implementierungen findet man zwei Anlaufstellen: Payara Cloud Connectors (1) und ein Paper der IBM (2). Zu letzterem konnte ich keinen lauffähigen Code entnehmen, während der Payara-Kafka-Connector mit ein paar Anpassungen in einem WildFly Server läuft und über
@Resource(lookup = "java:/KafkaConnectionFactory") KafkaConnectionFactory factory
1 | @Resource(lookup = "java:/KafkaConnectionFactory") KafkaConnectionFactory factory |
JEE mit Kafka spricht.
Fire&Forget
Wir haben einige Szenarien, bei denen wir mit dem Schreiben in ein Kafka-Topic fertig sind – also ein Fire&Forget. Da Kafka keine Nachrichten verliert, ist das ein gut nutzbares Vorgehen. Allerdings gibt es auch hier die Chance, dass die Kafka-Nachricht von den Konsumenten einfach nicht verarbeitet werden kann (poision message). Wir richten hierfür Dead-Letter-Topics DLT ein.
Transaktionen – geht oder geht doch nicht?
J
JEE-Server verwaltete Verbindungen können ungemein helfen. Hat man schon einmal in einem echten Projekt mehrere Datenbanken und eine JMS-Verbindung in einer „Einheit“ aktualisieren müssen, freut man sich, dass verteilte Transaktionen, XA-Transactions/Two-Phase-Commit, existieren.
Wir haben an einigen Stellen genau diese Anforderungen. Faktor IPM erzeugt Aufträge für die Beitragszahlung, die (Folge)Sollstellung. Das Ganze passiert als JEE-Batch in Faktor IPM und mit seiner Datenbank.
Unserer Projektphilosophie folgend werden diese Beitragszahlungen nun über Kafka auf die Reise geschickt, um im Inkassosystem weiterverarbeitet zu werden. Die ersten Tests zeigen leider, dass es keine gemeinsame Transaktionsklammer für das IPM-Datenbank-Update und das Senden der Nachricht nach Kafka gibt. Nachdem alles überprüft wurde, also XA-Datasource, Transaktionssteuerung im JEE-Batch, Commit-Size, mindestens drei Kafka Broker laufen, usw. weist der Quellcode des Payara-Projekts, dass der Connector nicht XA-fähig ist.
Wir entschieden uns, uns dem Problem zu stellen und definieren als Lösung: im Kafka Topic steht die Wahrheit; alle anderen Beteiligten müssen kompensieren. Eine XA-Transaktion ist jetzt keine Option mehr, aber wir müssen sicherstellen, dass die jeweilige Nachricht einmalig in Kafka angekommen ist und repliziert wurde (Kafka-Transaktion).
Im Fehlerfall können wir hier auch dafür sorgen, dass durch ein Rollback-Kommando nicht in die IPM-Datenbank geschrieben wird. Leider können wir nicht sicherstellen, dass im „happy case“ der Datenbank-Commit funktioniert (wohl eher ein akademisches als reales Problem). Hier kann ein Schiefstand zwischen Datenbank und Kafka entstehen. Wir haben entscheiden, dass der Datenbestand in Kafka die Wahrheit darstellt. „Wahrheit“ bedeutet in unserem Kontext, dass eine Nachricht bereits einmal nach Kafka geschrieben wurde (ein Einzug wurde beauftragt). Kafka-Nachrichten haben einen Schlüssel und einen Wert. Für unseren Anwendungsfall, in dem ein Batchlauf einen identifizierbaren Datensatz erzeugt, können wir genau diesen Schlüssel (key) verwenden. Die Kombination aus Batchlauf-ID und Nachrichten-ID identifiziert eindeutig die Nachricht im Kafka-Topic. Schlägt nun unser Batch aus technischen Gründen fehl und wird neu gestartet, können wir feststellen, dass die erzeugte Nachricht bereits in Kafka verfügbar ist und so nur die Datenbankaktualisierung durchführen.
Damit haben wir für die Projektzwecke eine hinreichend robuste Lösung. Wer weiter recherchiert, kommt vielleicht auf diesen Link von Microservices.io und findet einen noch eleganteren Weg. Auch hier bietet die Faktor Zehn Suite Möglichkeiten mit der
de.faktorzehn.ipm.core.model.externalsystems.ExternalSystemNotification,
1 | de.faktorzehn.ipm.core.model.externalsystems.ExternalSystemNotification, |
die leicht aktiviert werden können. Allerdings muss hier zusätzlich ein Prozess implementiert werden (der Message Relay), der die ExternalSystemNotification in Kafka-Nachrichten überführt.
Betrachtung nach Produktionsgang
Dank des unermüdlichen Einsatzes des gesamten Projektteams sind wir am 15.10.2020 produktiv gegangen (4). Wir haben so ziemlich alle Fallstricke erlebt: fehlende oder falsche Verbindungskonfigurationen, mangelnde Erfahrung mit den Werkzeugen, APIs falsch genutzt. Kurzum: Wir haben eine sehr steile Lernkurve hinter uns. Nach nun mehr als zwei Monaten können wir doch sagen, dass die architektonischen Ziele erreicht sind, die lose Kopplung über Kafka trägt und der Normalbetrieb stellt sich mehr und mehr ein.
Wir haben die ersten Steckdosen verteilt und so den Weg für eine neue IT-Linie bereitet. Aus Entwicklersicht fühlt sich alles gut an. Nun bleibt abzuwarten, wie die Architektur in der Zukunft trägt, welche neuen Ströme aufkommen, wie der Betrieb mit den neuen Konzepten warm wird.
Zum Autor
Carsten arbeitet seit Januar 2019 bei der Faktor Zehn und ist als Entwickler, Architekt und Berater sowohl in Kundenprojekten als auch der Produktentwicklung zu Hause.
Sollten wir Euer Interesse geweckt haben oder Ihr möchtet weitere Informationen erhalten, dann wendet Euch gerne an get2know(at)faktorzehn.de.
Euer Faktor Zehn-Team
(1)
https://github.com/payara/Cloud-Connectors
(2)
(3)
http://avro.apache.org/docs/current/
(4)
