Nachrichten übermitteln mit Message Queues

Asynchron, entkoppelt, effizient – wenn über Message Queues gesprochen wird, werden sie oft mit diesen Worten beschrieben. Oder mit einer Rohrpost verglichen: An einem Ende legt jemand eine Information ein, am anderen Ende holt sich der Empfänger die Information ab, wann er möchte.

Aufgaben entkoppeln, Daten asynchron nutzen

Tatsächlich arbeitet Message Queueing ähnlich, nämlich ebenfalls asynchron: „Informationen werden sozusagen von einem Dienst in eine Pipeline gelegt, aus der sich ein anderes Programmteil, das sich für die Information interessiert, es zu einem anderen Zeitpunkt rausholt“, erklärt Philipp, Softwareentwickler und Geschäftsführer bei cyan.it. Aufgaben werden so voneinander entkoppelt, Codes können unabhängig voneinander die Informationen nutzen.

Mehrere Millionen Daten täglich

Projekte, in denen viele Daten verarbeitet werden, sind prädestiniert für die Integration von Message Queues. „Wir betreuen bei cyan.it Systeme, die mehrere Millionen Messages täglich verarbeiten“, verdeutlicht Philipp die Größenordnungen seiner Projekte mit Message Queues.

Manchmal spricht der Zeitfaktor für Message Queueing: Philipp denkt hier zum Beispiel an Projekte, bei denen aus den abgelegten Daten umfangreiche Reports erstellt werden. Das aufwendige Berechnen der Daten für die Erstellung der Graphen und Charts kann durch Message Queues entkoppelt erfolgen und das Ergebnis zum Beispiel per Mail zugestellt werden. So muss der Software-Anwender nicht vor dem Monitor warten.

Doch auch Lastszenarien sind bei der cyan.it typische Einsatzgebiete für Message Queues: Wenn tausende Geräte laufend Daten produzieren, dann ist es sinnvoll, dass nicht jeder der zigtausend Dateneingänge sofort eine Verarbeitung auslöst. Besser geben die Geräte die Daten erst einmal nur ab, die Berechnung und die Ausgabe erfolgen  – nach vielen Prozessschritten – später.

Fürs Message Queueing sind bei cyan.it Tools wie der Message Broker RabbitMQ oder die Event-Streaming-Plattform Apache Kafka im Einsatz. Beide haben ihre Stärken und typischen Use Cases. „RabbitMQ ist schneller aufzusetzen und gut geeignet für die klassische Aufgabenverteilung. Bei Kafka ist der typische Use Case eher das Event-Streaming“, nennt Philipp eine Überlegung, um das individuell passende Tool zu identifizieren.

In der Cloud geht’s leichter

„Message Queueing hat sich in den vergangenen Jahren intensiver und in vielen Projekten stärker entwickelt“, berichtet Philipp. Seit Microservices gerne eingesetzt werden, werden bei der Softwareentwicklung oft Message Queues von Anfang an mitgedacht. Der Trend zu Cloud-Diensten hat dies unterstützt: Waren vorher für Message Queueing Server nötig, um die sich jemand kümmern musste, was den Aufwand erhöhte, können jetzt Clouddienste dazugebucht werden. „Für Unternehmen, die in der Cloud sind, ist das Tool nun einfacher nutzbar“, bestätigt Philipp.