Heute richten wir unser Augenmerk auf den Layer “App Definition and Development”. Ein Teil davon ist “Streaming & Messaging”. Neben dem Service Mesh und dem Service Proxy ist dies die dritte Komponente, die die Systemarchitektur eures Application Stacks stark beeinflussen kann.
Was ist eine Message Queue?
Eine Message Queue dient zur asynchronen Verarbeitung von Nachrichten zwischen einzelnen Diensten. Das unterstützt den generellen Ansatz von Microservice-Architekturen und damit auch containerisierte Applikationen. Sie trennt Systeme, die den Arbeitsablauf durch das Warten auf eine Antwort oder Verarbeiten von Daten. So können viele Anfragen nacheinander abgearbeitet oder lange Verarbeitungsschritte separiert werden.
Besonders zu Beginn der Entwicklung weg von monolithischen Anwendungen, kann sie als erster Anlaufpunkt dienen, um neue Features kleinteiliger aufzusetzen und dennoch mit bestehenden Systemen kommunizieren zu lassen.
Wann ein Message Stream Sinn ergibt
Während Message Queues also zwei Komponenten voneinander trennen und Nachrichten annehmen und aktiv weiterleiten, wird bei einem Message Stream das Ereignis der Datenbereitstellung in den Vordergrund gestellt. Eine direkte Kommunikationsbeziehung zwischen den zwei Komponenten ist dabei nicht mehr ausgeschlossen. Die meisten Tools kombinieren dabei aber das Speichern von Daten und die Verarbeitung der Ereignisse, um den Vorteil der Trennung beizubehalten. Das bedeutet, wenn eine Komponente ihre Daten an den Message Stream übergibt, werden sie ebendort veröffentlicht und der initiale Prozess ist abgeschlossen. Andere Microservices können dann auf diesen Stream zugreifen und die Daten abholen. Die Datenweiterleitung erfolgt also passiv aus Sicht des Message Streams.
Damit verringert sich logischerweise die Zeit, die eine einzelne Komponente benötigt eine Aufgabe abzuschließen. Es existieren dann zwar zwei Aufgaben, anstatt einer, können dadurch aber in den meisten Fällen mehr Anfragen verarbeiten. Zusätzlich ist es möglich, jede einzelne Komponente individuell zu skalieren, anstatt des kompletten Setups. Man spart also mit der erhöhten Komplexität Ressourcen.
Die Tool-Vielfalt ermöglicht dabei verschiedene Herangehensweisen.
In der Praxis sind Message Queues und Message Streams nicht so hart getrennt wie in ihren Definitionen. Die Ansätze gehen Hand in Hand und werden auch in der Umsetzung zusammengefasst.
Erst die Queue, dann der Stream
Entscheidend für die Toolwahl ist schlussendlich die Aufgabe. Wenn man das Prinzip der Message Queue in den Fokus stellen möchte, bieten sich Tools wie RabbitMQ an. Diese sind als Allzweckwerkzeug am besten bei übersichtlichen Mengen an Nachrichten gut geeignet. Dadurch können besonders langwierige Arbeitsschritte voneinander getrennt werden. Hierbei sollten mehrere, voneinander unabhängige Instanzen eingeplant werden.
Ist Message Streaming im Fokus, was besonders bei redundanten Setups eine wichtige Rolle spielt, bieten sich Applikationen wie Kafka an. Diese sind auf eine hohe Menge an Nachrichten und Ereignisse ausgelegt. Nachrichten und Ereignisse anzunehmen und vorzuhalten ist der Hauptfokus in diesem Umfeld. Dabei wird die Applikation als Plattform angenommen und funktioniert besonders gut in größeren, kombinierten Instanzen.
Wenn man die Datenverarbeitung in den Vordergrund stellt, ergibt sich ein Sonderfall der übrigens auch abgedeckt wird. Flink bietet eine Laufzeit für Micro-Batches, die zur Verarbeitung genutzt werden kann, bevor sie Nachrichten zur Verfügung stellt.
Streng genommen vereint das zwar zwei Aufgaben – das Annehmen bzw. Weiterleiten von Nachrichten und beispielsweise deren Analyse – kann so aber zusätzliche Aufgaben übernehmen, ohne das Layer Streaming & Messaging gänzlich zu verlassen.
Aber ist das schon alles?
Das interessante an Message Streams ist nicht nur die Trennung von Arbeitsschritten. Mithilfe des ereignisorientierten Ansatzes lassen sich nun einige andere Aspekte leichter realisieren. Dabei sind Serverless Tasks besonders spannend. Durch die Umwandlung von Nachrichten in Ereignisse wird es möglich, selbst das Starten von Servern davon abhängig zu machen, ob und wieviele Ereignisse vorliegen. Und das bringt uns zu einer der nächsten auf Kubernetes unterstützten Art: Der “Function as a Service”. Diesem Thema nehmen wir uns aber gern in einem anderen Blogbeitrag an.
Kubernetes ist für viele immer noch neu und es gibt mehr als genug Dinge zu lernen. Deswegen bleiben wir als SysEleven auch hier bei unserem Credo: Solltet ihr Fragen haben oder bei der Entscheidung Hilfe benötigen, helfen wir euch gern weiter. Wir haben für alle Fragen den richtigen Ansatz. Schreibt uns einfach!
