EN

Daten in einer Microservice-Welt

Von Start-up bis Konzern – immer mehr Unternehmen setzen auf Microservice-Architekturen. In der zweiten Lektion der vierteiligen Blogreihe erfährst du, wie Unternehmen mithilfe von Apache Kafka die Kommunikation zwischen ihren Services vereinfachen.

1.06.2023
  • Daten in einer Microservice-Welt

    Anatoly Zelenin

    IT-Trainer und Apache Kafka Experte

Mehr Artikel aus dieser Reihe

Unternehmen – in jeder Größenordnung – setzen vermehrt auf Microservice-Architekturen. Das heißt: Eine bislang große und komplexe Anwendung wird in mehrere Einheiten unterteilt. Diese Microservices sollen ausschließlich über Schnittstellen (kurz API) miteinander kommunizieren.

Die vermeintlichen Vorteile sind offensichtlich.

Unternehmen organisieren ihre Teams fortan in kleineren Einheiten. Diese entwickeln unabhängig voneinander ihre Lösungen. Der Nutzen? Sie können die Ergebnisse schneller ausprobieren und dadurch Fehler früher erkennen.

Ebenso wichtig: Dadurch, dass Teams kleiner sind, verbessert sich üblicherweise die Kommunikation. Bekanntlich steigt mit der Anzahl der Involvierten die Menge der potenziellen Missverständnisse. Ich sag ja: Das Streben nach Microservices ist logisch. Zumindest in der Theorie. Denn genau beim Thema Kommunikation gibt es Probleme.

Was REST oft wirklich bedeutet

Tatsächlich reden bei einem Entwicklungsprojekt nicht nur Menschen miteinander, sondern auch IT-Systeme kommunizieren untereinander. Wir sprechen von: REST. Ausgeschrieben heißt das: Representational State Transfer. Über das HTTP-Protokoll tauschen sich die einzelnen Microservices miteinander aus. Fragen werden gestellt oder beantwortet.

REST heißt, aus dem Englischen übersetzt, aber auch Ruhe. Und das ist leider passend. In klassischen Microservice-Architekturen müssen die Anwenderinnen und Anwender vor allem eines: warten.

Typisch bei REST-Architekturen: Service A ruft B auf, dieser wartet auf C und C braucht zum Antworten die Resultate von D und E. Und währenddessen wartet A

Ein Beispiel:

Service A möchte von Service B eine Antwort auf eine Frage bekommen. Soweit unkompliziert. Das Problem?

B kann sie nicht beantworten, ohne vorher C zu fragen. C braucht wiederum Informationen von D und E für die Antwort. Und A? Wartet und wartet und wartet.

Es kommt noch schlimmer:

Vielleicht hat das Team, welches Service E betreibt, gerade eine neue Version veröffentlicht, die nicht mehr mit Cs Annahmen übereinstimmt. E kann die Anfrage dadurch nicht beantworten. Die Microservice-Architektur ist damit zum Scheitern verurteilt, ehe das Projekt überhaupt begonnen hat.

Wie Kafka Microservice-Architekturen rettet

Die offensichtliche Lösung ist altbekannt. Teams koordinieren ihre Aktivitäten und sprechen fortan alle Änderungen untereinander ab. Das Problem: Die Einheiten bauen damit genau das auf, was sie mit den Microservices eigentlich vermeiden wollten: Abhängigkeiten zwischen den Teams und damit auch zwischen den Services.

Das, was die Arbeit erleichtern sollte, erschwert sie nun. Das kostet Zeit und Geld. Zum Glück gibt es Apache Kafka, das diese Abhängigkeiten auch innerhalb einer Microservice-Architektur deutlich reduzieren kann.

Die Alternative: Services benachrichtigen andere, sobald etwas passiert. So kennt jeder Service jederzeit den aktuellen Stand.

Kafka verzichtet auf das Anfrage-Antwort-Spiel. Stattdessen veröffentlichen unterschiedliche (Micro-)Services permanent ihre Ereignisse. Die Services, die sich für die Informationen interessieren, horchen in Echtzeit auf diese Aktualisierungen und reagieren entsprechend schnell.

Mehr noch: Kafka kann diese Ereignisse in den unterschiedlichen Services auffangen und unternehmensweit verteilen. Man kann sich die Software als effektive und effiziente Drehscheibe für Datenströme vorstellen.

Was Kafka in der Praxis bedeutet

Um es plastischer zu erklären: Wenn du einen Service nutzt, der für Adressen zuständig ist, veröffentlicht dieser die Änderungen in dem Moment, in dem diese Anpassungen vorgenommen wurden.

Noch praxisnaher:

Der Adressservice benachrichtigt andere Services, sobald eine Adresse geändert wird. Der Grußkarten-Service hört auf diese Änderungen und aktualisiert seine lokale Adresstabelle.

Wenn sich ein Grußkarten-Service um den Versand kümmert, kann er dank Kafka auf eine lokale Kopie der relevanten Daten zugreifen. Das Anfragen des Adress-Service entfällt fortan. Verzögerungen durch Downtimes oder Wartungen kannst du dir mithilfe von Kafka sparen – oder zumindest minimieren.

Ein weiterer Vorteil: Das Chaos, das durch die massenhaften Verbindungen der miteinander kommunizierenden Services entsteht, wird durch die Drehscheibe ebenso reduziert.

Die entscheidenden Vorteile von Kafka: Relativ günstig, sicher, effizient

Natürlich gab es Messaging-Systeme schon vor Kafka. Doch die Software Kafka bringt zwei große architekturelle Neuerungen mit sich:

  1. Die Performance und die gleichzeitige Zuverlässigkeit Kafkas ist schwer zu übertreffen. Selbst mit einem kleinen und relativ kostengünstigen Kafka-Cluster, der aus 3 handelsüblichen (Cloud)-Servern besteht, können wir Datendurchsätze von mehreren 100 MBs und Millionen Nachrichten pro Sekunde erreichen. Das Risiko für Datenverluste ist äußerst gering, da Kafka Daten über mehrere Server repliziert und verteilt.

  2. Kafka verschickt die Nachrichten nicht nur zwischen unterschiedlichen Systemen, sondern kann diese Daten aufbewahren. Bei der Einführung eines neuen Service muss dieser die Daten nicht irgendwie “synchronisieren”. Stattdessen kann er alle notwendigen Daten einfach aus Kafka lesen. Danach ist er auf dem gleichen Stand wie alle anderen Services.

Und wenn doch jemand freitags um 16:00 Uhr fehlerhaft deployt, lässt es sich mit Kafka in der Zeit “zurückreisen” und die Ursprungsdaten – vor dem Einführen des Bugs – wiederherstellen. Denn Kafka vergisst nur, wenn wir es wollen.