Hallo zusammen!
Ich habe mit der Übersetzung eines kleinen Buches begonnen:
««,
Autor: Jakub Korab, Verlag: O’Reilly Media, Inc., Veröffentlichungsdatum: Juni 2017, ISBN: 9781492049296.
Aus dem Vorwort des Buches:
«… Dieses Buch wird Sie darin schulen, über Nachrichtenaustauschsysteme nachzudenken, indem es zwei gängige Broker-Technologien vergleicht: Apache ActiveMQ und Apache Kafka. Es werden Anwendungsbeispiele und Entwicklungsanreize vorgestellt, die dazu geführt haben, dass ihre Entwickler völlig unterschiedliche Ansätze für dasselbe Gebiet — den Nachrichtenaustausch zwischen Systemen mit einem vermittelnden 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 für beide Produkte erwerben, wie sie richtig und falsch eingesetzt werden sollten und worauf Sie achten sollten, wenn Sie in Zukunft andere Messaging-Technologien in Betracht ziehen. …»
Bisher übersetzte Teile:
Ich werde die vollständigen Kapitel nach und nach veröffentlichen.
KAPITEL 1
Einführung
Die Inter-System-Nachrichtenaustausch ist eines der am wenigsten verstandenen Gebiete in der IT. Als Entwickler oder Architekt sind Sie möglicherweise gut mit verschiedenen Frameworks und Datenbanken vertraut. Es ist jedoch durchaus möglich, dass Sie nur flüchtige Kenntnisse darüber haben, wie Broker-basierte Nachrichtentechnologien funktionieren. Wenn Sie sich so fühlen, machen Sie sich keine Sorgen, Sie sind nicht allein.
Menschen haben normalerweise nur einen begrenzten Kontakt mit der Nachrichteninfrastruktur. Oftmals verbinden sie sich mit einem System, das vor langer Zeit erstellt wurde, oder laden ein Distributionspaket aus dem Internet herunter, installieren es in der Produktion und beginnen, Code dafür zu schreiben. Nach dem Starten der Infrastruktur in der Produktion können die Ergebnisse uneindeutig sein: Nachrichtenverlust bei Systemausfällen, das Senden funktioniert nicht wie erwartet, oder die Broker „hängen“ Ihre Producer oder senden keine Nachrichten an Ihre Consumers.
Kommt Ihnen das bekannt vor?
Ein häufiges Szenario ist, dass Ihr Nachrichten-Austauschsystem gut funktioniert, bis es plötzlich ausfällt. Diese Phase kann zu einer gewissen Selbstzufriedenheit führen und ein trügerisches Gefühl von Sicherheit erzeugen, was dazu führt, dass Sie weiterhin Code schreiben, der auf falschen Annahmen über das grundlegende Verhalten der Technologie basiert. Wenn etwas schiefgeht, stehen Sie einer unangenehmen Wahrheit gegenüber: Sie haben das grundlegende Verhalten des Produkts oder die Kompromisse, die von den Entwicklern getroffen wurden—wie Leistung versus Zuverlässigkeit oder Transaktionsfähigkeit versus horizontale Skalierbarkeit—nicht wirklich verstanden.
Ohne ein tiefes Verständnis darüber, wie Broker funktionieren, treffen Menschen scheinbar vernünftige Aussagen über ihre Nachrichtenübertragungssysteme, wie zum Beispiel:
- Das System wird niemals Nachrichten verlieren.
- Nachrichten werden sequentiell verarbeitet.
- Das Hinzufügen von Verbrauchern wird das System schneller machen.
- Nachrichten werden nur einmal zugestellt.
Leider basieren einige dieser Aussagen auf Annahmen, die nur unter bestimmten Bedingungen zutreffen, während andere einfach falsch sind.
Dieses Buch lehrt Sie, über brokerbasierte Messaging-Systeme nachzudenken, indem es zwei beliebte Broker-Technologien vergleicht: Apache ActiveMQ und Apache Kafka. Es werden Anwendungsbeispiele und Entwicklungsmotive dargestellt, die dazu führten, dass ihre Entwickler völlig unterschiedliche Ansätze im Bereich des Message Brokerings verfolgten. Wir betrachten diese Technologien von Grund auf und heben den Einfluss verschiedener Designoptionen auf diesem Weg hervor. Sie werden ein tiefes Verständnis für beide Produkte erlangen, begreifen, wie sie verwendet werden sollten und nicht sollten, und lernen, worauf Sie bei der Betrachtung anderer Messaging-Technologien in der Zukunft achten sollten.
Bevor wir beginnen, lassen Sie uns die Grundlagen durchgehen.
Was ist ein Messaging-System und wozu dient es?
Damit zwei Anwendungen miteinander kommunizieren können, müssen sie zunächst eine Schnittstelle definieren. Die Festlegung dieser Schnittstelle umfasst die Auswahl eines Transports oder Protokolls, wie z. B. HTTP, MQTT oder SMTP, sowie die Abstimmung der Nachrichtenformate, die zwischen den Systemen ausgetauscht werden. Dies kann ein strenger Prozess sein, wie die Definition eines XML-Schemas mit Anforderungen an die Payload des Nachrichteninhalts, oder deutlich informeller, etwa ein Abkommen zwischen zwei Entwicklern, dass ein bestimmter Teil der HTTP-Anfrage eine Kunden-ID enthalten wird.
Sofern das Nachrichtenformat und die Reihenfolge des Versands zwischen den Systemen abgestimmt sind, können sie miteinander interagieren, ohne sich um die Implementierung des jeweils anderen Systems kümmern zu müssen. Die internen Abläufe dieser Systeme, wie die verwendete Programmiersprache oder das verwendete 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 voneinander entkoppelt.
Messaging-Systeme sehen in der Regel die Teilnahme eines Vermittlers zwischen zwei Systemen vor, die für die weitere Trennung (Aufteilung) des Senders von dem Empfänger oder den Empfängern interagieren. Dabei ermöglicht das Messaging-System dem Sender, eine Nachricht zu senden, ohne zu wissen, wo sich der Empfänger befindet, ob er aktiv ist oder wie viele Exemplare es gibt.
Betrachten wir einige Analogien zu den Arten von Problemen, die ein Messaging-System löst, und führen wir einige grundlegende Begriffe ein.
Point-to-Point
Alexandra geht zur Post, um Adam ein Paket zu schicken. Sie geht zum Schalter und übergibt dem Mitarbeiter das Paket. Der Mitarbeiter nimmt das Paket entgegen und gibt Alexandra eine Quittung. Adam muss nicht zu Hause sein, wenn das Paket versendet wird. Alexandra ist sich sicher, dass das Paket irgendwann in der Zukunft bei Adam ankommt und kann weiterhin ihren Angelegenheiten nachgehen. Später erhält Adam das Paket.
Das ist ein Beispiel für ein Messaging-Modell Punkt-zu-Punkt. In dieser Zustellung fungiert das Postamt als Verteilmechanismus für Pakete, der garantiert, dass jedes Paket nur einmal zugestellt wird. Die Nutzung des Postamts trennt den Akt des Versendens eines Pakets von der Zustellung.
In klassischen Nachrichtensystemen wird das "Point-to-Point"-Modell durch Warteschlangenrealisieren. Eine Warteschlange fungiert als FIFO-Puffer (First In, First Out), auf den sich ein oder mehrere Verbraucher anmelden können. Jede Nachricht wird nur einem der angemeldeten Verbraucherzugestellt. Warteschlangen versuchen in der Regel, die Nachrichten fair unter den Verbrauchern zu verteilen. Nur ein Verbraucher erhält die betreffende Nachricht.
Auf Warteschlangen wird der Begriff "zuverlässig" angewendet. Zuverlässigkeit Das ist eine Eigenschaft des Dienstes, die garantiert, dass das Nachrichtensystem Nachrichten speichert, wenn keine aktiven Abonnenten vorhanden sind, bis der Verbraucher sich zur Zustellung von Nachrichten bei der Warteschlange anmeldet.
Zuverlässigkeit wird oft mit Persistenz verwechselt. Obwohl diese beiden Begriffe austauschbar sind, erfüllen sie unterschiedliche Funktionen. Persistenz bestimmt, ob eine Nachricht von einem Message Broker in einem Speicher zwischen dem Empfang und der Zustellung an den Verbraucher protokolliert wird. Nachrichten, die in eine Warteschlange gesendet werden, können persistent sein oder auch nicht.
Point-to-Point Messaging wird genutzt, wenn der Anwendungsfall eine einmalige Interaktion mit der Nachricht erfordert. Ein Beispiel dafür ist das Einzahlen von Geld auf ein Konto oder das Aufgeben einer Bestellung für die Lieferung. Später werden wir erörtern, warum ein Messaging-System alleine keine eindeutige Lieferung garantieren kann und warum Warteschlangen bestenfalls eine Zustellgarantie bieten können. mindestens einmal.
Publisher-Subscriber
Gabriella wählt die Konferenznummer. Während sie mit der Konferenz verbunden ist, hört sie alles, was der Sprecher sagt, zusammen mit den anderen Teilnehmern des Anrufs. Wenn sie sich abmeldet, verpasst sie, was gesagt wird. Beim erneuten Verbinden hört sie weiter, was gesagt wird.
Das ist ein Beispiel für ein Messaging-Modell Veröffentlichung-Abonnement. Konferenzschaltungen fungieren als Broadcast-Mechanismus. Die sprechende Person muss sich keine Gedanken darüber machen, wie viele Leute derzeit am Anruf teilnehmen – das System gewährleistet, dass jeder, der sich anschließt, hört, was gesagt wird.
In klassischen Nachrichtenaustauschsystemen wird das „Publish-Subscribe“-Modell über Topicsrealisierte. Ein Topic bietet eine ähnliche Möglichkeit zum Broadcasten wie der Mechanismus der Konferenzschaltung. Wenn eine Nachricht an ein Topic gesendet wird, wird sie an alle abonnierenden Benutzer verteilt..
Topics sind in der Regel nicht zuverlässig (nondurable).Wie ein Zuhörer, der nicht hört, was bei einer Konferenzschaltung gesagt wird, wenn er sich trennt, verpassen die Abonnenten eines Topics alle Nachrichten, die während ihrer Offline-Zeit gesendet werden. Aus diesem Grund kann man sagen, dass Topics eine Zustellungsgarantie bieten, nicht mehr als einmal für jeden Verbraucher.
Messaging types like 'publish-subscribe' are typically used for informational messages, where losing one message isn't crucial. For instance, a topic might transmit temperature readings from a group of sensors once every second. A system that is interested in the current temperature and subscribes to the topic won't worry if it misses a message—another will arrive shortly.
Hybride Modelle
Die Website des Shops platziert Bestellnachrichten in eine 'Nachrichtenschlange'. Der Hauptverbraucher dieser Nachrichten ist das Ausführungssystem. Zudem muss das Auditsystem Kopien dieser Bestellnachrichten für die spätere Nachverfolgung haben. Beide Systeme dürfen Nachrichten nicht verlieren, selbst wenn sie für eine gewisse Zeit nicht verfügbar sind. Die Website sollte nichts über die anderen Systeme wissen.
Anwendungsszenarien erfordern häufig eine Kombination der Nachrichtenübertragungsmodelle "Publish-Subscribe" und "Point-to-Point", zum Beispiel wenn mehrere Systeme eine Kopie einer Nachricht benötigen und sowohl Zuverlässigkeit als auch Persistenz zur Vermeidung von Nachrichtenverlust erforderlich sind.
In solchen Fällen ist ein Ziel (destination) erforderlich (ein allgemeiner Begriff für Warteschlangen und Themen), das die Nachrichten hauptsächlich wie ein Thema verteilt, sodass jede Nachricht an ein einzelnes System gesendet wird, das an diesen Nachrichten interessiert ist. Zudem kann jedes System mehrere Verbraucher bestimmen, die die eingehenden Nachrichten empfangen, was eher wie eine Warteschlange wirkt. Die Leseart in diesem Fall ist - einmal für jede interessierte Partei. Diese hybriden Adressaten erfordern oft Zuverlässigkeit (durability), sodass, wenn ein Verbraucher getrennt ist, die zu diesem Zeitpunkt gesendeten Nachrichten nach der Wiederverbindung des Verbrauchers empfangen werden.
Hybride Modelle sind nicht neu und können in den meisten Nachrichtenaustauschsystemen eingesetzt werden, einschließlich ActiveMQ (über virtuelle oder zusammengesetzte Adressen, die Themen und Warteschlangen kombinieren) sowie Kafka (implizit, als grundlegende Eigenschaft des Designs ihres Adressaten).
Jetzt, da wir einige grundlegende Terminologien und ein Verständnis dafür haben, wofür uns ein Nachrichtenaustauschsystem nützlich sein könnte, lassen Sie uns zu den Details übergehen.
Übersetzung abgeschlossen:
Der nächste übersetzte Abschnitt:
Die Fortsetzung folgt…
Quelle: habr.com
