Die Geheimnisse Von Message-Queues in Der Praxis
Über Microservice-Systeme wird viel gesprochen. Message-Queues spielen in diesen eine große Rolle, kommen in der Diskussion jedoch selten vor.
Dr. Matthias Boldt - Über Cloud-Software und Cloud-Computing unter der Verwendung von Microservices wird viel geschrieben und thematisiert. Innerhalb der für diese Systeme notwendigen Architekturen spielen Message-Queues eine zentrale Rolle. In der allgemeinen Diskussion werden sie jedoch selten behandelt - doppelt zu Unrecht, denn es gibt “Geheimnisse”, die man erst in einem praktischen Einsatz lüften kann.
Mit modernen Software-Systemen verhält es sich genauso wie mit Kochrezepten: Man kann nicht einfach alle Zutaten zusammenrühren und hoffen, das Resultat schmeckt dann schon. Nehmen wir zum Beispiel eine Zitronenspeise. Für deren Zubereitung muss man zwischendurch ein kleines Kunststück aus Eischnee und Gelatine vollbringen. Bei Cloud-Anwendungen ist es ebenso, ganz besonders bei solchen, in denen Microservices zur Anwendung gebracht werden sollen. Natürlich ohne Eischnee, dafür mit Message-Queues.
Welche Rolle spielen Message-Queues?
In einem System, das nach dem Microservices-Architecture-Pattern konstruiert ist, sind viele unterschiedliche Service-Module für die Verarbeitung der Daten zuständig. Diese müssen in der richtigen/gewünschten Reihenfolge verschaltet werden. Hier können Message-Queues zum Einsatz kommen. Sie verbinden dann nicht nur die einzelnen Microservices, sondern übermitteln auch die Daten zwischen diesen.
Message-Queues sind natürlich nur eine mögliche Art und Weise der Vermittlung von Nachrichten zwischen den Verarbeitungseinheiten eines Cloud-Software-Systems. Sie bieten jedoch viele Vorteile zum Beispiel gegenüber der Nutzung simpler REST-Calls, die die Services untereinander austauschen.
Wofür werden Message-Queues genutzt?
Natürlich ist der Transport von Nachrichten und Daten zwischen verschiedenen Services die wichtigste Aufgabe einer Message-Queue. Es lassen sich jedoch auch andere Ziele mit dieser Technik umsetzen, die eine “saubere” Architektur des gesamten Systems unterstützen. Eine kleine Auswahl dieser Ziele hier zum Verständnis:
Abstraktion vom allgemeinen Ablauf
Ein oft gewünschter Zusatznutzen ist die Trennung der Verantwortlichkeiten (das sogenannte “Separation of Concerns”). In Kombination von Message-Queues und einer Workflow-Steuerung für die Verarbeitungsabläufe innerhalb des Cloud-Systems, kann diese Trennung umgesetzt werden. So werden die einzelnen, verarbeitenden Services nicht mit dem Wissen über die Existenz anderer Services und den Gesamtablauf belastet/überfrachtet. Das hat außerdem noch einen weiteren, positiven Effekt: Die verarbeitenden Services können schnell und einfach in neuen Workflows auf andere Arten miteinander verknüpft werden. Somit wird ein universeller Einsatz der Services möglich.
asynchrone Entkopplung der Services
Die einzelnen Module/Services eines Software-Systems benötigen unterschiedliche Zeiten für die Verarbeitung von Daten. In vielen Fällen ist es nicht erwünscht, dass Teile eines Systems auf die Fertigstellung einer von ihnen beauftragten Verarbeitung warten und in dieser Zeit blockiert sind, d.h. keine weiteren Aufträge ausführen können. Mit Message-Queues kann ein solcher asynchroner “fire-and-forget”-Modus umgesetzt werden. Ist der Auftrag als Message in der Queue abgelegt, ist für den beauftragenden Modul alle Arbeit getan und er ist frei für weitere Aufgaben.
punktuelle Skalierung
Microservices-Systeme können (im Gegensatz zu klassischen, monolithischen Systemen) ganz gezielt in einzelnen Teilen/Funktionsgruppen/Services skalieren. So können exakt an den Stellen, wo ein erhöhter Bedarf besteht, weitere Services gestartet und an der Verarbeitung der Daten beteiligt werden. Die Nutzer erleben somit keine zeitliche Verzögerung in der Fertigstellung ihrer Arbeitsaufträge, obwohl die Last für das System gestiegen ist. Diese Last kann auf viele unterschiedliche Arten gemessen werden. Mittels des Einsatzes einer Message-Queue ergibt sich eine elegante Lösung, die gleichzeitig noch die Verteilung der Arbeiten an die neue gestarteten Services übernimmt. Über die Messung über Länge einer Queue steht zu jedem Zeitpunkt ein extrem verlässliches Signal über die Belastung des Systems zur Verfügung. Es kann hervorragend für ein up- und down-scaling der gekoppelten Services genutzt werden.
Ist jedes Message-Queue-System passend?
Für den Einsatz in der produktiven Praxis stehen heute eine Vielzahl an Message-Queue-Systemen zur Verfügung. Es ergibt sich also die Qual der Wahl. Gut beraten ist, wer sich im Vorfeld eine Liste an Kriterien erstellt, nach denen er das Feld der Kandidaten eingrenzen möchte. Nachfolgend sollen einige dieser Kriterien genannt und erläutert werden:
Technologie/Framework
Wird die von der Message-Queue verwandte Basis-Technologie (z.B. Programmiersprache, Framework, …) bereits vom Entwicklungs- und Betriebsteam genutzt? Sind Kenntnisse darüber vorhanden, oder müssen diese erst durch Schulungen und Weiterbildungen aufgebaut werden? Die Antworten auf diese Fragen beeinflussen entscheidend die Kosten insgesamt und die ramp-up-Phase des Projektes. Neu ist aufregend und interessant, jedoch ist es oft auch teuer.
Client-Bibliothek
Eine Message-Queue muss als Software-Bestandteil mit dem bestehenden Systemteilen verbunden werden. Dies geschieht im Normalfall über die Nutzung von Client-Bibliotheken, welche die kommunikativen Abläufe kapseln und als handliche Funktionen zur Verfügung stellen. Solche Bibliotheken gilt es für die im bestehenden System verwendete Programmiersprache zu finden. Diese sollte gut gepflegt sein und von einer größeren Community genutzt werden. Das beugt Überraschungen in der Zukunft vor.
Gibt es keine dieser Bibliotheken, kann natürlich ein Adapter für das von der Message-Queue genutzte Kommunikationsprotokoll im eigenen Unternehmen entwickelt werden. Das ist in den meisten Fällen nicht kompliziert, benötigt jedoch zusätzliche Zeit, schlägt sich also negativ auf die ramp-up-Phase des Projektes nieder … von den Kosten ganz zu schweigen.
Message-Schemata
Die von Message-Queue-Systemen umgesetzten Abläufe sind durchaus sehr verschieden. Es gibt viele unterschiedliche Schemata/Pattern, die jeweils für spezielle Aufgaben eingesetzt werden können. Das “System der Wahl” muss natürlich die Messaging-Pattern umsetzen können, die in Ihrem bestehenden Software-System genutzt werden können. Hier lohnt sich also eine detaillierte Analyse, um nicht nicht während der Umstellung auf unlösbare Probleme zu stoßen. In diesem Falle müsste man noch einmal beginnen und ein großer Teil der bisherigen Arbeiten wäre “Schrott” … kein schöner Gedanke.
Größe der Datenblöcke
Die Menge der zu übertragenden Daten und die Größe der Datenblöcke sollte eine wesentliche Rolle bei der Auswahl spielen. Message-Queues sind in vielen Fällen nur als “Briefträger” gedacht. Mit “Paketen” haben sie oft Probleme. Sollen größere Datenmengen mit den Messages übertragen werden, schränkt das die Auswahl ein. Leider sind in diesem Fall auch praktische Experimente notwendig, um die Auswirkungen auf die Geschwindigkeit der Vermittlung zu testen.
Messages pro Sekunde
Geschwindigkeit ist keine Hexerei, auch bei Message-Queue-Systemen nicht. Diese sind am Ende auch nur Software und keine Magie. Da sind dann die Geschwindigkeit der Datenübermittlung und verarbeitbare Datenmenge sehr entscheidende Kriterien für eine Auswahl.
Am Ende ist es auch bei der Auswahl eines Message-Queue-Systems wie im richtigen Leben: Nur ein praktischer Versuch kann dabei helfen, die richtige Lösung zu finden.
sense.AI.tion hat die Erfahrungen
sense.AI.tion hat praktische Erfahrungen mit dem Einsatz von Message-Queues in Cloud-Software-Systemen gesammelt. Wir können bei der Auswahl und Integration eines solchen Bestandteils in bestehende Software-Systeme helfen … und das onshore … vom Rande Berlins … nah und kompetent. Wir geben unsere Erfahrungen gern weiter.