Ein Message Broker ist eine Software, die die Kommunikation zwischen Systemen übernehmen kann. Er führt eine nachrichtenbasierte Kommunikation ein. Alle Nachrichten in einem Message-Broker-Kommunikationssystem haben beziehungsweise sollten ein definiertes Format aufweisen, damit alle Akteure in dem System sie verstehen können. Sein Hauptzweck besteht darin, eingehende Nachrichten von Anwendungen entgegenzunehmen und an Zielsysteme weiterzuleiten. Er entkoppelt so die verschiedenen Endpunkte voneinander und führt eine zusätzliche Ebene der Indirektion ein. Dafür bauen viele Message Broker sogenannte Queues auf, sprich Warteschlangen, in denen eingehende Nachrichten gespeichert werden.

Ein Message Broker wird oft für ein inhalts- und themenbasiertes Nachrichten-Routing genutzt, beispielsweise auf Basis des Publish-Subscribe-Prinzips. Dabei erfüllt ein System die Rolle des Publishers. Es stellt also eine Information zur Verfügung. Andere Systeme agieren jeweils als Subscriber und erhalten diese Information. Das Ganze ähnelt dem Vorgang eines Newsletter-Versands: Menschen können einen Newsletter abonnieren. Wenn der Publisher in seinem Versandsystem auf Senden drückt, geht der Newsletter an alle Subscriber. Dabei wird die Nachricht im E-Mail-Postfach der Empfänger gespeichert, bis diese ihn lesen, beziehungsweise sogar darüber hinaus. Neben dem Pub-Sub-Prinzip gibt es weitere mögliche Mechanismen der Datendistribution, beispielsweise Point-to-Point Messaging.

Dieses Problem löst ein Message Broker
In einer beispielhaften Systemlandschaft könnte es folgendermaßen aussehen: In System A gibt es eine Änderung im Datensatz. Die Systeme B, C und D müssen daraufhin ebenfalls Änderungen vornehmen. Für System B kein Problem, es ist online, kann die Information aufnehmen und entsprechend reagieren. System C kann dies jedoch gerade nicht, da es überlastet ist. Traditionelle Schnittstellen über HTTP können hier zu Problemen führen. Durch die direkte Kommunikation zwischen Client und Server kann es sein, dass eine Nachrichtenübertragung fehlschlägt, da das empfangende System nicht erreichbar ist. Der Sender weiß daraufhin nicht, ob die Nachricht angekommen ist und sendet sie eventuell erneut. Ein Beispiel ist ein Kauf im Onlineshop: Der Shop sendet die Nachricht des Kaufs an das Fulfillment, die Übertragung wird unterbrochen, der Shop sendet erneut, aber beide Nachrichten sind verarbeitet worden. Zwei Abbuchungen werden getätigt und zwei Pakete versandt, obwohl nur ein Stück gekauft wurde.

Die Vorteile eines Message Brokers
Eines der fundamentalen Theoreme des Software Engineerings, dass David J. Wheeler zugeschrieben wird, sagt:

"We can solve any problem by introducing an extra level of indirection."
"Wir können jedes Problem lösen, indem wir eine zusätzliche Indirektionsebene einführen."

Einen Message Broker zwischen zwei Systeme zu schalten, ändert eigentlich erstmal nur den Kommunikationskanal zwischen diesen. Frei nach David Wheeler fügt der Message Broker jedoch eine weitere Ebene der Indirektion hinzu, um die Kommunikation auf eine einheitliche Basis zu stellen. Der Message Broker dreht dabei die Abhängigkeiten um (Dependency-Inversion-Prinzip): Das Quellsystem ist nicht mehr dafür zuständig, sicherzustellen, dass die Nachricht ankommt. Stattdessen muss das Zielsystem dafür sorgen, die Nachricht zu erhalten. Der Sender braucht nichts über die Empfänger zu wissen, kann also komplett entkoppelt von ihnen aufgesetzt werden. Dadurch lässt sich die IT-Landschaft auch einfacher horizontal skalieren.

Ein Message Broker sorgt dank seiner Queues zudem für Persistenz. Er kann – je nach Anbieter – Nachrichten sehr lange in diesen vorhalten. Diese Speicherung stellt sicher, dass keine Informationen verloren gehen. Der Message Broker hält die Nachricht vor, bis das empfangende System aufnahmebereit ist.

Durch das Verschieben der Abhängigkeit kann ein System zudem die Last, mit der es Informationen aufnimmt, selbst steuern. So ist ein asynchrones Abarbeiten von Informationen möglich. Außerdem können durch paralleles Abarbeiten von Nachrichten auch sehr hohe Datendurchsätze erzielt werden. Gerade diese parallele Struktur, Informationen zu verarbeiten, schätzen Entwickler an einem Message Broker, da sich so hochperformante Systeme erstellen lassen.

Mehr Komplexität durch Cluster und Replika
Durch den Message Broker fügen Administratoren eine weitere Komponente in ihre IT-Landschaft hinzu, was natürlich die Systemkomplexität erhöht. Die Verwaltung nimmt zu, Debugging-Probleme können schwerer zu bewältigen sein. Ein umfangreiches Logging in den angeschlossenen Systemen sollte in Betracht gezogen werden, um die Nachvollziehbarkeit der Nachrichtenverarbeitung sicherstellen zu können. Wenn die IT hochverfügbar sein muss, gibt es zudem mehrere Herausforderungen: Der Message Broker dient als Kanal zur Datenübertragung in Systemen. Dadurch entstehen Probleme, wenn dieser Kanal kurzzeitig nicht verfügbar ist. Hier gilt es, ein intensives Monitoring zu betreiben, um Probleme schnell erkennen zu können. Auch ist die Skalierbarkeit zu beachten. Zudem: Was passiert, wenn der Message Broker geupdatet werden soll? Entscheidend ist hier, wie der Message Broker im System aufgesetzt ist.

Ist das Unternehmen auf ausfallsichere Hochverfügbarkeit bedacht, bietet sich ein Cluster an. In einem Cluster mit mehreren Knoten lässt sich ein Knoten nach dem anderen entkoppeln, updaten und dann wieder hinzufügen. So wird ein reibungsloser Betrieb sichergestellt. Dies ist jedoch administrativ sehr aufwendig. Mit dem Aufsetzen eines Clusters kommen zudem Performance-Einbußen, da sichergestellt werden muss, dass eingespeiste Daten auf allen Knoten zu jedem Zeitpunkt zur Verfügung stehen. Auf der anderen Seite können in einem Cluster große Datenmengen besser zwischengespeichert und natürlich auch verarbeitet werden, da sich die Last auf die Knoten im Cluster verteilen lässt. Es gibt verschiedene Softwareansätze für die Cluster-Bereitstellung. Unternehmen müssen sich fragen, welcher Message Broker mit welchen Features der Richtige für sie ist. Auch die Stabilität des Brokers ist entscheidend.

Etwas weniger komplex ist ein Primary-/Replica-Betrieb. Hier werden nur zwei Systeme aufgesetzt. Ein Hauptsystem und ein Replika, das bereitsteht, falls das Primary ausfällt. Auch hier lassen sich die Systeme nacheinander updaten, ohne dass es zu Ausfallzeiten kommt. Jedoch ist dieser Aufbau nicht hochausfallsicher.

Natürlich gibt es auch den Fall, in dem nur eine Instanz eingesetzt ist. Wenn diese ausfällt oder geupdatet wird, kommt der Betrieb (kurzzeitig) zum Stillstand. Es ist eine Kosten-Nutzen-Rechnung für Unternehmen: Wenn die entstehenden Probleme durch einen kurzzeitigen Ausfall des Systems im Gegensatz zu den Aufwänden einer Primary/Replica- oder einer Cluster-Lösung nur minimal ausfallen, dann ist ein Betrieb auch mit nur einer Instanz möglich. Entscheidend sind die Ziele und die Einschätzung der Aufwände: Eine langfristige Pflege eines Clusters ist aufwendig. Auf der anderen Seite stoßen Single-Instance-Lösungen irgendwann an ihre Kapazitätsgrenzen, gerade wenn es um Systeme mit hohen Datenmengen geht.

Einsatzszenario eines Message Brokers im Unternehmen
Ein Szenario könnte so aussehen: Das E-Commerce Shopsystem des Unternehmens schickt eine Nachricht "Artikel X wurde verkauft" an den Message Broker. Dieser leitet die Nachricht nun an alle Systeme des Unternehmens weiter, die diese Art der Information "subscribed" haben. Die Logistik erhält die Nachricht und leitet den Versand ein, die Buchhaltung kümmert sich um alle transaktionalen Vorgänge. Das ERP-System war kurzzeitig nicht online, da es upgedatet wurde. Nach dem Update erhält es die Nachricht ebenfalls, die Nachricht ist nicht verloren gegangen, da der Message Broker sie zwischengespeichert hat.

Das ERP erkennt nun, dass die Anzahl des Artikels auf Null gesunken ist und schickt diese Information wiederum an den Message Broker. Dieser verteilt die Nachricht an das E-Commerce-System, da der Artikel jetzt nicht mehr verkauft werden kann. Die Nachricht wird mit dem Warenlager-System abgeglichen und der Einkauf wird informiert, um Ware oder Materialien neu zu bestellen. Diese und viele weitere Komponenten können dazukommen, ohne dass die Schnittstellen anderer Systeme verändert werden müssen. Alle schicken ihre Nachrichten einfach an den Message Broker, der sich um die Verteilung der Informationen kümmert.

Fazit
Der Einsatz eines Message Brokers als Kommunikationstool macht für viele Anwendungsfälle von IT-Administratoren Sinn. Durch die Umkehrung der Abhängigkeiten wird eine Entkopplung der Akteure in der IT-Infrastruktur geschaffen. Durch das Entkoppeln der Kommunikation zwischen verschiedenen Systemen in der IT vereinfacht er zudem die horizontale Skalierbarkeit. Wie eine solche Struktur dann genau aufzusetzen ist, sei es als Cluster-, Primary/Replica- oder Single-Lösung, müssen Administratoren je nach Anforderungen und Ressourcen entscheiden.

ln/Thomas Kühnel, Co-CTO bei Turbine Kreuzberg