Verstehen von Nachrichtenbrokern. Mechanismen der Nachrichtenübertragung durch ActiveMQ und Kafka. Kapitel 1

Hallo zusammen!

Ich habe mit der Übersetzung eines kleinen Buches begonnen:
«Understanding Message Brokers«,
Autor: Jakub Korab, Verlag: O’Reilly Media, Inc., Erscheinungsdatum: Juni 2017, ISBN: 9781492049296.

Aus der Einleitung des Buches:
«… Dieses Buch wird Ihnen beibringen, über Systeme zum Austausch von Nachrichten über Broker nachzudenken, indem zwei beliebte Broker-Technologien, Apache ActiveMQ und Apache Kafka, verglichen und gegenübergestellt werden. Es werden Anwendungsbeispiele und Entwicklungsimpulse dargelegt, die dazu führten, dass deren Entwickler völlig unterschiedliche Ansätze im selben Bereich — dem Nachrichtenaustausch zwischen Systemen mit einem vermittelnden Broker — verfolgten. Wir werden diese Technologien von Grund auf untersuchen und die Auswirkungen verschiedener Designoptionen auf diesem Weg herausarbeiten. Sie werden ein tiefes Verständnis für beide Produkte erlangen, wissen, wie sie zu nutzen sind und wie nicht, und verstehen, worauf zu achten ist, wenn Sie in Zukunft andere Technologien für den Nachrichtenaustausch betrachten. …»

Bis jetzt übersetzte Teile:
Kapitel 1. Einführung
Kapitel 3. Kafka

Ich werde die fertigen Kapitel nach und nach veröffentlichen.

KAPITEL 1

Einführung

Der intersystemliche Nachrichtenaustausch ist eines der am wenigsten verstandenen Bereiche der IT. Als Entwickler oder Architekt sind Sie möglicherweise gut mit verschiedenen Frameworks und Datenbanken vertraut. Es ist jedoch sehr wahrscheinlich, dass Sie nur flüchtig mit dem Funktionsweise von brokerbasierten Nachrichtenaustauschtechnologien vertraut sind. Wenn Sie sich so fühlen, brauchen Sie sich keine Sorgen zu machen, Sie sind in guter Gesellschaft.

Die Menschen haben normalerweise nur sehr begrenzten Kontakt mit der Messaging-Infrastruktur. Oft wird auf ein System zugegriffen, das lange Zeit zuvor erstellt wurde, oder es wird ein Distributionspaket aus dem Internet heruntergeladen, installiert in der PROD und daraufhin beginnt man, Code dafür zu schreiben. Nach dem Start der Infrastruktur in der PROD können die Ergebnisse uneindeutig sein: Nachrichtenverlust bei Ausfällen, das Senden funktioniert nicht so, wie Sie es erwartet haben, oder die Broker 'hängen' Ihre Producer oder senden keine Nachrichten an Ihre Consumer.

Klingt bekannt?

Ein verbreitetes Szenario ist, dass Ihr Messaging-Code eine Zeit lang hervorragend funktioniert. Bis er plötzlich ausfällt. Diese Phase schürt die Wachsamkeit und vermittelt ein falsches Sicherheitsgefühl, was zu noch mehr Code führt, der auf falschen Vorstellungen über das grundlegende Verhalten der Technologie basiert. Wenn etwas nicht mehr funktioniert, stehen Sie der unangenehmen Wahrheit gegenüber: Sie haben das grundlegende Verhalten des Produkts oder die Kompromisse, die die Autoren getroffen haben, nicht wirklich verstanden, wie beispielsweise Leistung gegen Zuverlässigkeit oder Transaktionalität gegen horizontale Skalierbarkeit.

Ohne ein tiefes Verständnis dafür, wie Broker arbeiten, treffen Menschen scheinbar vernünftige Behauptungen über ihre Messaging-Systeme, wie zum Beispiel:

• Das System wird niemals Nachrichten verlieren.
• Nachrichten werden sequenziell verarbeitet.
• Die Hinzufügung von Consumer wird das System schneller machen.
• Nachrichten werden nur einmal zugestellt.

Leider basieren einige dieser Behauptungen auf Annahmen, die nur unter bestimmten Umständen gelten, während andere einfach falsch sind.

Dieses Buch wird Ihnen beibringen, über Messaging-Systeme auf Basis von Brokern nachzudenken, indem es zwei beliebte Broker-Technologien vergleicht und gegenüberstellt: Apache ActiveMQ und Apache Kafka. Hier werden Anwendungsbeispiele und Entwicklungsanreize dargestellt, die dazu geführt haben, dass ihre Entwickler völlig unterschiedliche Ansätze im gleichen Bereich – Messaging zwischen Systemen mit einem zwischengeschalteten Broker – gewählt haben. Wir werden diese Technologien von Grund auf betrachten und den Einfluss verschiedener Designoptionen auf diesem Weg hervorheben. Sie werden ein tiefes Verständnis beider Produkte gewinnen, verstehen, wie sie eingesetzt werden sollten und wie nicht, und lernen, worauf Sie bei der Prüfung anderer Messaging-Technologien in der Zukunft achten sollten.

Bevor wir beginnen, lassen Sie uns die Grundlagen durchgehen.

Was ist ein Messaging-System und wozu wird es benötigt?

Damit zwei Anwendungen miteinander kommunizieren können, müssen sie zunächst eine Schnittstelle definieren. Die Definition dieser Schnittstelle umfasst die Auswahl eines Transport- oder Protokolls, wie HTTP, MQTT oder SMTP, und die Abstimmung der Nachrichtenformate, über die die Systeme kommunizieren werden. Dies kann ein strenger Prozess sein, wie die Definition eines XML-Schemas mit Anforderungen an die Payload-Kosten der Nachricht, oder es kann viel weniger formell sein, wie eine Vereinbarung zwischen zwei Entwicklern, dass ein bestimmter Teil der HTTP-Anfrage eine Client-ID enthalten wird.

Sobald das Nachrichtenformat und die Reihenfolge des Versands zwischen den Systemen abgestimmt sind, können sie miteinander interagieren, ohne sich um die Implementierung des anderen Systems kümmern zu müssen. Die inneren Abläufe dieser Systeme, wie Programmiersprache oder verwendeter Framework, können sich im Laufe der Zeit ändern. Solange der Vertrag selbst aufrechterhalten wird, kann die Interaktion ohne Änderungen auf der anderen Seite fortgesetzt werden. Diese beiden Systeme sind durch diese Schnittstelle effektiv entkoppelt.

Nachrichtenaustauschszenarien sehen typischerweise einen Vermittler zwischen zwei Systemen vor, die interagieren, um den Sender von einem oder mehreren Empfängern weiter zu entkoppeln. Dabei ermöglicht das Nachrichtensystem dem Sender, eine Nachricht zu senden, ohne zu wissen, wo sich der Empfänger befindet, ob dieser aktiv ist oder wie viele Instanzen es gibt.

Betrachten wir einige Analogien zu den Arten von Problemen, die ein Nachrichtenaustauschsystem löst, und führen wir einige grundlegende Begriffe ein.

Punkt-zu-Punkt

Alexandra geht zur Post, um Adam ein Paket zu senden. Sie tritt an den Schalter heran und übergibt dem Angestellten das Paket. Der Angestellte nimmt das Paket entgegen und gibt Alexandra eine Quittung. Adam muss zum Zeitpunkt des Versands des Pakets nicht zu Hause sein. Alexandra ist zuversichtlich, dass das Paket irgendwann in der Zukunft an Adam geliefert wird und kann ihre anderen Geschäfte fortsetzen. Später erhält Adam das Paket.

Dies ist ein Beispiel für ein Nachrichtenaustauschmodell punkt-zu-punkt. Das Postamt fungiert hier als Mechanismus zur Verteilung von Paketen und gewährleistet, dass jedes Paket genau einmal zugestellt wird. Der Einsatz des Postamtes trennt den Akt des Versendens des Pakets von der Zustellung des Pakets.
In klassischen Messaging-Systemen wird das «Point-to-Point»-Modell durch Warteschlangenimplementiert. Eine Warteschlange fungiert als FIFO-Puffer (First In, First Out), auf den sich ein oder mehrere Verbraucher abonnieren können. Jede Nachricht wird nur einem der abonnierten Verbraucherzueingestellt. Warteschlangen versuchen normalerweise, die Nachrichten gerecht zwischen den Verbrauchern zu verteilen. Nur ein Verbraucher erhält die betreffende Nachricht.

Auf Warteschlangen wird der Begriff «zuverlässig» («durable») angewendet. Zuverlässigkeit Dies ist eine Eigenschaft des Services, die garantiert, dass das Messaging-System Nachrichten speichert, solange keine aktiven Abonnenten vorhanden sind, bis ein Verbraucher sich für die Zustellung von Nachrichten anmeldet.

Zuverlässigkeit wird oft mit Persistenz verwechselt, und obwohl diese beiden Begriffe austauschbar sind, erfüllen sie unterschiedliche Funktionen. Die Persistenz definiert, ob das Messaging-System eine Nachricht in irgendeiner Art von Speicher zwischen dem Empfang und der Zustellung an den Verbraucher aufzeichnet. Nachrichten, die in eine Warteschlange gesendet werden, können persistent oder nicht persistent sein.
Das Point-to-Point-Messaging wird verwendet, wenn der Anwendungsfall eine einmalige Verarbeitung der Nachricht erfordert. Ein Beispiel wäre die Einzahlung von Geld auf ein Konto oder die Ausführung einer Lieferbestellung. Wir werden später besprechen, warum das Messaging-System allein nicht in der Lage ist, einmalige Zustellung zu gewährleisten und warum Warteschlangen bestenfalls eine Zustellgarantie bieten können mindestens einmal.

Publisher-Subscriber

Gabriella wählt die Konferenznummer. Solange sie mit der Konferenz verbunden ist, hört sie alles, was der Sprecher sagt, zusammen mit den anderen Teilnehmern des Anrufs. Wenn sie sich trennt, verpasst sie alles, was gesagt wird. Wenn sie sich erneut verbindet, hört sie erneut, was gesagt wird.

Dies ist ein Beispiel für ein Nachrichtenaustauschmodell Publish-Subscribe. Die Konferenzschaltung fungiert als Broadcast-Mechanismus. Die sprechende Person kümmert sich nicht darum, wie viele Personen derzeit an dem Anruf teilnehmen — das System stellt sicher, dass jeder, der gerade verbunden ist, hört, was gesagt wird.
In klassischen Messaging-Systemen wird das Messaging-Modell «Publish-Subscribe» durch Themen. Das Topic bietet denselben Broadcasting-Mechanismus wie die Konferenzschaltung. Wenn eine Nachricht an das Topic gesendet wird, wird sie verteilt an alle abonnierenden Benutzer.

Topics sind in der Regel nicht zuverlässig (nondurable). Wie ein Zuhörer, der nicht hört, was während eines Konferenzanrufs gesagt wird, wenn der Zuhörer sich abmeldet, verpassen Topic-Abonnenten alle Nachrichten, die in dem Moment gesendet werden, wo sie offline sind. Aus diesem Grund kann gesagt werden, dass Topics eine Zustellgarantie bieten, nicht mehr als einmal für jeden Verbraucher.

Messaging-Modelle vom Typ „Veröffentlichung-Abonnement“ werden normalerweise verwendet, wenn die Nachrichten informativen Charakter haben und der Verlust einer Nachricht nicht besonders bedeutsam ist. Zum Beispiel kann ein Topic Temperaturdaten von einer Gruppe von Sensoren einmal pro Sekunde übertragen. Ein System, das an der aktuellen Temperatur interessiert ist und sich auf das Topic abonniert hat, wird sich nicht sorgen, wenn es eine Nachricht verpasst – eine weitere wird in Kürze gesendet.

Hybride Modelle

Die Website des Shops stellt Nachrichten über Bestellungen in eine „Nachrichtenschlange“. Der Hauptverbraucher dieser Nachrichten ist das Ausführungssystem. Darüber hinaus muss das Auditsystem Kopien dieser Bestellnachrichten für die nachträgliche Nachverfolgung haben. Beide Systeme dürfen keine Nachrichten verpassen, auch wenn die Systeme selbst für eine gewisse Zeit nicht verfügbar sind. Die Website muss keine Kenntnisse über andere Systeme haben.

Einsatzszenarien erfordern häufig eine Kombination der Messaging-Modelle „Veröffentlichung-Abonnement“ und „Punkt-zu-Punkt“, zum Beispiel wenn mehrere Systeme eine Kopie der Nachricht benötigen und sowohl Zuverlässigkeit als auch Persistenz erforderlich sind, um den Verlust einer Nachricht zu verhindern.

In diesen Fällen ist ein Empfänger (destination) erforderlich (allgemeiner Begriff für Warteschlangen und Topics), der die Nachrichten hauptsächlich wie ein Topic verteilt, sodass jede Nachricht an ein separates System gesendet wird, das an diesen Nachrichten interessiert ist, aber auch, wo jedes System mehrere Verbraucher bestimmen kann, die eingehende Nachrichten empfangen, was eher einer Warteschlange ähnelt. Die Art des Lesens in diesem Fall ist einmal für jede interessierte Partei. Diese hybriden Adressaten verlangen oft nach Zuverlässigkeit (Durability), sodass, wenn der Verbraucher sich trennt, die zu diesem Zeitpunkt gesendeten Nachrichten nach der Wiederverbindung des Verbrauchers angenommen werden.

Hybride Modelle sind nicht neu und können in den meisten Nachrichtenaustauschsystemen angewendet werden, einschließlich sowohl ActiveMQ (über virtuelle oder zusammengesetzte Adressaten, die Themen und Warteschlangen kombinieren) als auch Kafka (implizit als grundlegende Eigenschaft des Designs ihres Adressaten).

Jetzt, da wir einige grundlegende Begriffe und das Verständnis dafür haben, wofür wir ein Nachrichtenaustauschsystem benötigen könnten, lassen Sie uns zu den Details übergehen.

Übersetzung von: tele.gg/middle_java

Der nächste übersetzte Teil: Kapitel 3. Kafka

Fortsetzung folgt…

Quelle: habr.com