</TECH NEWS>
NEUESTES VON UNSEREN ENTWICKLERN:

07.06.2018 – von Eike Eschmann|

Kafka – Der Sparhandy Kommunikationsbus (Teil 1)

Während es bei unserem ersten Blogeintrag um die Frontend-Entwicklung und den Einsatz von Angular ging, schauen wir uns nun mal im Backend um: Hier setzen wir systemseitig unter anderem auf Kafka und geben euch im ersten Teil einen Einblick, warum wir uns dafür entschieden haben. Außerdem gewähren wir einen Einblick über den Einsatz von Kafka als Kommunikationsbus.

Die Kommunikationsgrundlagen
Im Zuge der Einführung von Microservices ist die Kommunikation zwischen den Services eines der zentralsten Elemente. Dabei haben wir bei Sparhandy zwei Grundregeln festgelegt, die immer beachtet werden sollten: Zum einen sollen die Microservices nicht direkt voneinander abhängig sein, zum anderen muss die Kommunikation aber „immer” möglich bleiben.

Es wurde also nach einem hochverfügbaren, skalierbaren und performanten System gesucht, das diese Anforderungen erfüllt. Wir haben uns dann im Entwicklerteam letztlich für eine Kombination aus REST und Kafka entschieden.

Entschließt man sich bei der Entwicklung für eine Kombination aus zwei Systemen, geht natürlich nichts ohne klare Definitionen. Bei uns sehen diese wie folgt aus:

Commands werden per REST abgewickelt, um eine synchrone Fehlerbehandlung zu ermöglichen. Ein Command muss eine Änderung auslösen und darf nur an das führende System geschickt werden.

Events werden hingegen von Kafka verwaltet. Das bietet sich an, da Events keiner expliziten synchronen Fehlerbehandlung bedürfen. Ein Event ist immer eine bedeutsame Statusänderung, wird in Kafa publiziert und kann somit von sich interessierenden Services abonniert werden.

Kafka als Kommunikationsbus

Nachrichten gelangen via Producer in Kafka herein und werden von Consumern ausgelesen. Hinter dem Begriff “Kafka” verbergen sich mehrere Abstraktionsebenen. Durch Clustering stehen gleich mehrere Kafka Broker zur Verfügung, die sich mittels Zookeeper organisieren. Die Kafka-Server werden “Broker” genannt, da ihr Zweck die Vermittlung von Nachrichten ist. Des Weiteren muss ein Topic ausgewählt werden, in das die Nachricht geschrieben wird. Topics lassen sich vom Benutzer erstellen und benennen. Ein typischer Topic name wäre “orders”, in dem sich Bestell-Event-Nachrichten wieder fänden.

Topics wiederum sind zwecks Clustering in Partitions aufgeteilt. Somit können extrem große Datenmengen gespeichert werden, die einen einzelnen Node überlasten würden. Die Anzahl der Partitions muss vom Benutzer festgelegt werden. Nachrichten können in Kombination mit dem Topic-Namen und der Partitionsnummer durch den sogenannten Offset genau identifiziert werden. Dieser “Primärschlüssel” inkrementiert automatisch bei jeder eintreffenden Nachricht.

Auf Consumer-Seite kann die Datenflut einfach über eine Consumer Group aufgespalten und somit in mehreren Prozessen gleichzeitig bearbeitet werden. Das obere Limit an Consumern pro Gruppe entspricht der Anzahl an Partitions in dem zu konsumierenden Topic. Zookeeper kommt hier ins Spiel, um die jeweiligen Offsets pro Consumer Group zu persistieren.

Neben der Einfachheit der Themenorganisation erkennt man die von Haus aus eingebauten Clustering- und Parallelisierungsmechanismen. Diese Kombination macht Kafka zum robusten und skalierbaren Kommunikationsbus.



WEITERE SPANNENDE BEITRÄGE



Unternehmen Marken Team Presse Karriere Tech-Blog SH Händler-Shop