Messaging-Systeme im Überblick

Heutzutage müssen Informationen in Echtzeit verfügbar sein. Dies erfordert ein einfaches, zuverlässiges und schnelles Routing von Daten von und zu mehreren Empfängern. Messaging-Lösungen müssen dabei grundlegende Probleme lösen:

• Netzwerke sind bandbreitenbegrenzt und müssen je nach Anwendungsfall nicht stabil sein
• Daten müssen über ein oder mehrere Netzwerke von einem Knoten auf einen anderen übertragen werden, wobei Netzwerfehler und Unterbrüche zu berücksichtigen sind
• Es müssen Informationen zwischen Systemen übertragen, die unterschiedliche Programmiersprachen, Betriebsplattformen und Datenformate verwenden. Eine Messaging-Lösung muss in der Lage sein, mit all diesen verschiedenen Technologien zusammenzuarbeiten
• Eine Messaging-Lösung muss mit den Änderungen in den Anwendungen, mit denen sie verbunden ist, Schritt halten. Sie sollte auch die Abhängigkeiten eines Systems von einem anderen System minimieren, indem eine lose Kopplung zwischen Anwendungen verwendet wird
• Eine Messaging-Lösung muss zumeist hochverfügbar sein
• Eine Messaging-Lösung muss mit zunehmender Nutzer/Knoten-Anzahl skalieren können und dabei trotzdem effizient und kostengünstig betreibbar sein
• Die kommunizierten Daten müssen dabei sicher übertragen werden und gegen ungewünschten Zugriff geschützt werden.

Zur Lösung dieser und weiterer Herausforderungen haben sich in den letzten Jahren diverse hochentwickelte Technologien und Systeme etabliert. Diese Aufstellung soll Ihnen einen groben Überblick über die gängigsten Vertreter geben und dabei folgende Fragen beantworten: Was sind explizite Vorteile und prädestinierte Anwendungsfälle der jeweiligen Technologie.

Apache Kafka

Apache Kafka ist eine Open Source-Plattform für verteiltes Event-Streaming. Die ursprünglich von LinkedIn entwickelte Software dürfte eine der meistverbreiteten und bekanntesten Technologien im Umfeld der Messaging-Systeme sein. Unter der Haube ist Kafka nichts anderes als ein verteiltes Transaktionslog, das alle einkommenden Nachrichten verteilt persistiert. Daten werden dabei von sogenannten „Producern“ ins System eingebracht und können von „Consumern“ gelesen werden. Nachrichten werden dabei von den Producern an bestimmte Topics – „Postadressen“ wenn man so will – geschickt, die wiederum von den Consumern abboniert werden können. Neue Nachrichten werden an das Ende des Topics angehängt und mit hochgezählter Nummer versehen. Ein Topic kann dabei in mehrere Partitionen unterteilt werden, die dann wiederum hochverfügbar und skalierbar über mehrere Nodes hinweg repliziert werden können. Kafka stellt somit eine sehr fortschrittliche Möglichkeit dar, Daten hochverfügbar und skalierbar mit hohem Durchsatz zwischen Systemen auszutauschen. Der Nachrichtentransfer kann dabei garantiert werden. Mit seinen mittlerweile unzähligen Client-Libraries kann Kafka mit einer Vielzahl an Systemen kommunizieren und Daten austauschen. Daneben bietet Apache Kafka mit KSQL und Kafka Streams eine eingebaute Streaming-Engine zur Verfügung, die Echtzeit-Streaming-Analytics ermöglicht.

Vorteile von Apache Kafka sind:

• Hochverfügbarkeit
• Hohes Maß an Skalierbarkeit
• Hoher Datendurchsatz und geringe Latenz
• Viele Client Libraries
• Großes Ökosystem
• Eingebautes Stream Processing
• Hochverfügbarer, verteilter, permanenter Nachrichtenspeicher

Nachteile von Apache Kafka:

• Recht komplexer Betrieb und hoher Ressourcenverbrauch
• Clients benötigen eine verhältnismäßig stabile Netzwerkverbindung
• Schwierig, mehr als 10.000 Topics zu verwalten

Mögliche Anwendungsfälle für Apache Kafka:

• IoT/IIoT und Smart Manufacturing: Durch die Möglichkeit, hohe Datendurchsätze sicher und garantiert and Drittsystem weiterzugeben ist Apache Kafka aus einer IIoT oder Smart Manufacturing-Plattform nicht wegzudenken
• Banking: Auch das Finanzwesen profitiert von dem hohen Maß an Verfügbarkeit und Skalierbarkeit der Apache Kafka Platform
• Microservice Kommunikation: Moderne IT-Architekturen setzen auf viele kleine, in sich geschlossene Microservices. Diese Services müssen miteinander kommunizieren. Während bei kleineren Systemen eine direkte Service-Kommunikation via beispielsweise REST noch möglich ist, bedürfen große Installationen einer skalierbareren und besser betreibbaren Lösung. Kafka bietet hier eine Möglichkeit, die Kommunikation zu abstrahieren und die Microservices voneinander zu entkoppeln.
• Enterprise IT Kommunikation: Kafka ist in der Lage den kompletten Kommunikationslayer aller unternehmensinternen IT-Systeme zu übernehmen. Dies ermöglicht die schlanke, skalierbare Verbindung tausender IT-Systeme

MQTT

MQTT ist ein offener ISO-Standard, ein Publish-Subscribe-Protokoll, das Nachrichten über einen Server/Broker von und zu Clients überträgt. MQTT ist dabei einer der de-facto Standards für die Kommunikation von IoT-Geräten. Es zeichnet sich durch seine schlanke Implementierung, Fehlertoleranz und durch seine in hohem Maße asynchrone Kommunikation aus – was speziell in den netzwerkteschnisch herausfordernden IIoT-Szenaren relevant ist. MQTT stellt darüber hinaus spezielle, fürs Internet of Things wichtige Funktionalitäten wie Quality of Service, Last Will Statements und Keep Alive zur Verfügung. Und nicht zuletzt erlaubt MQTT aufgrund seiner geradlinigen Implementierung mehrere Millionen verbundener Clients.

Vorteile von MQTT:

• Optimiert für den Austausch kleiner Nachrichten in hoher Anzahl
• Features spezifisch für IIoT: QoS, Last Will, Keep Alive, Retained messages
• Einfache Implementierung, sehr schmales Protokoll
• Geringer Ressourcenverbrauch, kann auch auf sehr kleinen Geräten installiert werden
• Erlaubt mehrere Millionen Topics und mehrere Millionen Clients pro MQTT Server (Broker)

Nachteile von MQTT:

• Skalierbarkeit und Hochverfügbarkeit hängt von der Broker/Server-Implementierung ab
• Skaliert generell nicht gut für große Nachrichten
• Kein skalierbarer und hochverfügbarer Persistenz-Layer

Anwendungsfälle MQTT:

• MQTT kommt immer dann zum Einsatz, wenn sehr viele Clients am Nachrichtenaustausch beteiligt sind, die wiederum auch nur wenig Rechenleistung zur Verfügung stellen können. Somit ist IoT der prominenteste Vertreter der MQTT Anwendungen.

RabbitMQ/AMQP

RabbitMQ ist eine Open-Source nachrichtenorientierte Technologie, die den AMQP-Messaging-Standard implementiert. Zu den Funktionen gehören Message-Quees, Austausch, Routing und Messaging mit geringer Latenz. RabbitMQ wurde in Erlang geschrieben und wird von Pivotal Software, einem Teil von VMware, entwickelt und kommerziell unterstützt.

(Anmerkung: RabbitMQ bietet mittlerweile via Plugins auch die Möglichkeit über andere Protokolle – wie MQTT – zu kommunizieren)

Die Funktionsweise von RabbitMQ lässt sich einfach zusammenfassen: Es entkoppelt Sender und Empfänger unter Zuhilfenahme einer Message-Queue. Der große Vorteil dabei: Der Nachrichtenproduzent muss dabei nicht auf den Empfang (und gar Verarbeitung) der Nachricht warten. Er legt sie einfach in die Message-Queue und kann dabei mit anderen Arbeiten fortfahren. RabbitMQ übernimmt dabei den garantierten Transport der Nachricht.

Auch der konsumierende Client kann sich dabei für die Abarbeitung „Zeit lassen“ – RabbitMQ speichert die Nachrichten dabei, bis der Client die Verarbeitung übernehmen kann.

Vorteile von RabbitMQ/AMQP:

• Neutralität gegenüber Plattform und Hersteller
• Sehr geringer Footprint und Ressourcenverbrauch
• Flexibilität bei der Steuerung von Messaging-Kompromissen/ Aktives Managen von bottlenecks
• Einfaches Entkoppeln von Systemen

Nachteile von RabbitMQ:

• Nicht auf Langzeit-Persistenz von Daten ausgelegt
• Optimiert für kleine Nachrichten – schlechte Skalierbarkeit bei großen Datenpaketen

Anwendungsgebiete:

• Entkopplung von IT Systemen bei geringem Ressourcenverbrauch
• Entschärfen von Messaging-Bottlenecks

Apache Pulsar

Apache Pulsar ist ein verteiltes Open Source-Messaging-System. Ursprünglich als Message Queue konzipiert, wurde es in den letzten Versionen um Event-Streaming-Funktionen erweitert. Pulsar verwendet Apache BookKeeper für seine Speicherebene, ein ursprünglich von Yahoo erstelltes Projekt zur skalierbaren, fehlertoleranten Speicherung von Daten, optimiert für Relatime-Anwendungen. Apache Pulsar teilt dabei Eigenschaften mit Kafka und RabbitMQ. Apache Pulsar ist ein stark von der Community betriebenes Projekt.

Apache Pulsar bietet gegenüber beispielsweise Apache Kafka einige Vorteile:

• Kombination aus Message Queue und Event Streaming System
• Stateless Brokers erleichtern die Skalierung, den Betrieb und das Setup
• Verhältnismäßig einfache, built-in Geo-Replication Mechanismen
• Performanter, hochverfügbarer persistenter Speicher

Nachteile von Apache Pulsar

• Langzeitspeicherung von Daten ist teuer
• Sowohl das feature-set der Message Queue als auch das feature-set der Streaming-Funktionalitäten ist geringer als jene von spezialisierten Tools wie AMQP und Kafka
• Kein Stream Processing im Sinne von Analytics
• Geringere Verbreitung als sowohl Apache Kafka als auch RabbitMQ

Die Einsatzgebiete von Apache Pulsar überschneiden sich deutlich mit jenen von Apache Kafka.

HTTP

HTTP ist seit 1991 im Einsatz und bietet aufgrund seiner Historie eine große Anzahl an Entwicklerressourcen und Libraries. Das Protokoll ist bei Entwicklern somit sehr beliebt und kommt häufig in Inter-Service-Kommunikationen zum Einsatz. HTTP ist dabei textbasiert und verwendet einen recht großen Protokollheader, was seinen Einsatz bei datenbegrenzten und auch ressourcenbegrenzten Systemen nachteilig beeinflusst.

Das Protokoll erlaubt darüber hinaus eine 1 zu 1 Kommunikation jedoch keine 1 zu N Kommunikation.

Vorteile von HTTP

• Sehr viele Entwicklungshilfen und Bibliotheken
• Sehr ausgereift
• Einfach zu erlernen
• Sehr robust

Nachteile von HTTP

• Hoher Protokolloverhead
• Textbasiert und damit ineffizient
• Keine 1 zu N Kommunikation möglich
• Nur Client zu Server Kommunikation (WebSockets und Long-Polling erlauben auch Server zu Client Kommunikation, bedeuten aber zusätzlichen Implementierungs-Overhead)

Anwendungsfälle von HTTP

• Download von großen Datenmengen an den Client (Firmware Updates)
• Kommunikation zwischen Microservices
• REST APIs

WebSockets

WebSockets ist ein Kommunikationsprotokoll, das Vollduplex-Kommunikationskanäle über eine einzelne TCP-Verbindung bereitstellt. WebSocket bietet einen bidirektionalen Vollduplex-Kommunikationskanal, der über HTTP über eine einzelne TCP/IP-Socket-Verbindung ausgeführt wird. Im Kern vereinfacht das WebSocket-Protokoll die Übertragung von Nachrichten zwischen Client und Server.

Das Protokoll erbt die Vorteile von HTTP und erlaubt das effiziente Kommunizieren vom Server zu den Clients.

Anwendungsfälle von WebSockets:

• Bidirektionale Server-Client-Kommunikation
• „Echtzeit-Kommunikation“: o Steuerung von IIoT-Geräten über eine Serverkomponente o Chats in Online-Spielen

CoAP

Das Constrained Application Protocol (CoAP) ist ein spezielles Internetanwendungsprotokoll für eingeschränkte Geräte. Es wurde von HTTP inspiriert, setzt jedoch auf UDP anstatt TCP/IP auf.

CoAP wurde dabei auf effizienten Datentransfer optimiert und reduziert dabei den Protokollheader drastisch.

Vorteile von CoAP:

• Effizient und leichtgewichtig
• Vergleichbar mit HTTP (Wird häufig als "HTTP für IoT" bezeichnet)

Nachteile von CoAP:

• Weniger Entwicklungsressourcen als http
• Keine 1 zu N Kommunikation
• Nur Cleint zu Server Kommunikation

Enterprise Service Bus

Ein Enterprise Service Bus (ESB) ist eine Messaging-Middleware, die zum Aufbau einer SOA (Service Oriented Architecture) Architektur verwendet wird.

Bei SOA werden high-level Geschäftsprozesse durch niederwertigere IT-Prozesse ausgeführt. Datenbanken, Web Server und andere IT-Systeme werden dabei in Services gekapselt und je nach Anforderung des high-level Geschäftsprozesses miteinander verbunden. SOA soll somit die flexible Wiederverwendung von IT-Services fördern und somit die Übersichtlichkeit verbessern und langfristig Kosten senken.

Ein Enterprise Service Bus stellt dabei im Wesentlichen die Funktionen zur Verbindung der Services zu höherwertigen Geschäftsprozessen zur Verfügung. Eine ESB-Implementierung kann dabei hochverfügbar und auch skalierbar sein. Ein ESB setzt somit die IT-Systeme ähnlich einem Puzzle zu einem Geschäftsprozess zusammen

Entgegen aller in diesem Artikel beschriebenen Technologien ist jeder ESB individuell. Es gibt keine Standardisierung über die verschiedenen ESB-Technologie-Anbieter.

Vorteile von ESB (und SOA):

• Skaliert Datenströme von IT Services
• Häufig hochverfügbarer Datentransfer
• Entkoppelt IT-Systeme
• Erweiterbar mit zusätzlichen Services

Nachteile von ESB

• Starre „Verdrahtung“ von Services
• Die Schnittstellen aller Services müssen dem ESB-Standard entsprechen. Es geht somit ein hoher Aufwand mit der Implementierung und Harmonisierung von Schnittstellen einher
• Hoher manueller Aufwand zur Erstellung der „Routing-Definitionen“
• Geringe Transparenz der ESB-Implementierung
• Schwierige Fehlersuche aufgrund der hohen API-Anforderungen geringen Kommunikationstransparenz im ESB

Das Anwendungsgebiet eines ESB ist streng mit dem Aufbau einer SOA verbunden. Eine SOA wiederum soll die skalierbare Umsetzung von Geschäftsprozessen mittels IT-Systemen fördern.