© Excellent backgrounds/Shutterstock.com
Java Magazin
Entkopplung einzelner Anwendungen in Event-driven Architekturen

Vor- und Nachteile von Kafka und Kinesis

Event-driven-Architekturen sind kein neues Architekturpattern, haben aber - unter anderem durch das Reactive Manifesto - wieder mehr Aufmerksamkeit erfahren. Der Erfolg von LinkedIn, die stetig wachsende Verbreitung von elastischen Ansätzen in der Cloud und immer stärker zunehmende Datenmengen lassen diese Form der Architektur wieder interessanter werden. Doch wie genau kann so etwas mit modernen Komponenten implementiert werden?

Sascha Möllering


Der Vorteil von Event-driven Architekturen besteht in der Entkopplung einzelner Anwendungen durch ein Message-System. Im Falle von LinkedIn wird Apache Kafka [1] als Message Bus für die Entkopplung genutzt. Kafka ist ein System, das auf dem Publish-/Subscribe-Paradigma basiert. Die Besonderheit von Kafka besteht in der Kombination aus Queueing und der Persistierung von Nachrichten. Man kann es sich als Commit Log vorstellen, das über mehrere Server in einem Cluster verteilt ist. Die Nachrichten werden in Topics und Partitions organisiert, wobei ein Topic aus mehreren Partitionen bestehen kann. Jedes Topic kann mehrere Publisher (Produzenten) und Subscriber (Konsumenten) unterstützten. Die Nachrichten innerhalb eines Topics werden innerhalb des Kafka-Clusters nach folgenden Regeln vorgehalten:

für eine bestimmte Zeitspannedie Gesamtanzahl von Nachrichten pro Partitionfür einen bestimmten Key innerhalb einer Nachricht nur die neuesten Nachrichten

Jede Kafka-Partition ist eine geordnete, unveränderliche Sequenz von Nachrichten, in die neue Nachrichten mit der Zeit hinzugefügt werden. Den Nachrichten in einer Partition wird eine eindeutige (sequenzielle) ID zugewiesen, die „Offset“ genannt wird und jede Nachricht innerhalb der Partition eindeutig identifiziert. Im Gegensatz zu anderen Messaging-Systemen müssen sich die Konsumenten selbst um die Verwaltung des Offsets kümmern, was aber auch einen großen Vorteil mit sich bringt: Normalerweise würde ein Konsument den Offset linear immer weiter schieben, um eine Nachricht nach der anderen zu lesen. In diesem Fall kann aber der Offset bewegt und somit die Nachrichten in jeder beliebigen Reihenfolge gelesen werden. Durch diese Logik können beispielsweise Nachrichten mehrfach gelesen werden, falls ein „replay“ von Nachrichten notwendig ist. Der Offset wird dabei in Apache Zookeeper [2] abgelegt. Zookeeper ist ein zentraler Service, in dem Konfigurationen abgelegt werden können. Damit bietet sich die Software als zentraler Bestandteil einer verteilten Architektur an.

Amazon Web Services bietet mit Amazon Kinesis [3] einen ähnlichen Service an, der vollständig verwaltet wird. Bei Kinesis werden die Nachrichten in Streams und Shards organisiert, Streams entsprechen den Topics, Shards den Partitions. Auch bei Kinesis muss der Offset selbst verwaltet werden, Amazon bietet aber mit der so genannten Kinesis Client Library (KCL [4]) eine Bibliothek, die dieses – und viele andere nützliche Features darüber hinaus – für den En...

Java Magazin
Entkopplung einzelner Anwendungen in Event-driven Architekturen

Vor- und Nachteile von Kafka und Kinesis

Event-driven-Architekturen sind kein neues Architekturpattern, haben aber - unter anderem durch das Reactive Manifesto - wieder mehr Aufmerksamkeit erfahren. Der Erfolg von LinkedIn, die stetig wachsende Verbreitung von elastischen Ansätzen in der Cloud und immer stärker zunehmende Datenmengen lassen diese Form der Architektur wieder interessanter werden. Doch wie genau kann so etwas mit modernen Komponenten implementiert werden?

Sascha Möllering


Der Vorteil von Event-driven Architekturen besteht in der Entkopplung einzelner Anwendungen durch ein Message-System. Im Falle von LinkedIn wird Apache Kafka [1] als Message Bus für die Entkopplung genutzt. Kafka ist ein System, das auf dem Publish-/Subscribe-Paradigma basiert. Die Besonderheit von Kafka besteht in der Kombination aus Queueing und der Persistierung von Nachrichten. Man kann es sich als Commit Log vorstellen, das über mehrere Server in einem Cluster verteilt ist. Die Nachrichten werden in Topics und Partitions organisiert, wobei ein Topic aus mehreren Partitionen bestehen kann. Jedes Topic kann mehrere Publisher (Produzenten) und Subscriber (Konsumenten) unterstützten. Die Nachrichten innerhalb eines Topics werden innerhalb des Kafka-Clusters nach folgenden Regeln vorgehalten:

für eine bestimmte Zeitspannedie Gesamtanzahl von Nachrichten pro Partitionfür einen bestimmten Key innerhalb einer Nachricht nur die neuesten Nachrichten

Jede Kafka-Partition ist eine geordnete, unveränderliche Sequenz von Nachrichten, in die neue Nachrichten mit der Zeit hinzugefügt werden. Den Nachrichten in einer Partition wird eine eindeutige (sequenzielle) ID zugewiesen, die „Offset“ genannt wird und jede Nachricht innerhalb der Partition eindeutig identifiziert. Im Gegensatz zu anderen Messaging-Systemen müssen sich die Konsumenten selbst um die Verwaltung des Offsets kümmern, was aber auch einen großen Vorteil mit sich bringt: Normalerweise würde ein Konsument den Offset linear immer weiter schieben, um eine Nachricht nach der anderen zu lesen. In diesem Fall kann aber der Offset bewegt und somit die Nachrichten in jeder beliebigen Reihenfolge gelesen werden. Durch diese Logik können beispielsweise Nachrichten mehrfach gelesen werden, falls ein „replay“ von Nachrichten notwendig ist. Der Offset wird dabei in Apache Zookeeper [2] abgelegt. Zookeeper ist ein zentraler Service, in dem Konfigurationen abgelegt werden können. Damit bietet sich die Software als zentraler Bestandteil einer verteilten Architektur an.

Amazon Web Services bietet mit Amazon Kinesis [3] einen ähnlichen Service an, der vollständig verwaltet wird. Bei Kinesis werden die Nachrichten in Streams und Shards organisiert, Streams entsprechen den Topics, Shards den Partitions. Auch bei Kinesis muss der Offset selbst verwaltet werden, Amazon bietet aber mit der so genannten Kinesis Client Library (KCL [4]) eine Bibliothek, die dieses – und viele andere nützliche Features darüber hinaus – für den En...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang