Hallo an alle!
Ich habe angefangen, ein kleines Buch zu übersetzen:
««
Autor: Jakub Korab, Herausgeber: O'Reilly Media, Inc., Erscheinungsdatum: Juni 2017, ISBN: 9781492049296.
Aus der Einleitung zum Buch:
"... In diesem Buch erfahren Sie, wie Sie über Broker-Messaging-Systeme denken und zwei beliebte Broker-Technologien vergleichen und gegenüberstellen: Apache ActiveMQ und Apache Kafka. Es werden die Anwendungsfälle und Entwicklungsanreize skizziert, die ihre Entwickler dazu veranlasst haben, sehr unterschiedliche Ansätze für denselben Bereich zu verfolgen – die Nachrichtenübermittlung zwischen Systemen mit einem zwischengeschalteten Broker. Wir werden diese Technologien von Grund auf betrachten und dabei die Auswirkungen verschiedener Designentscheidungen hervorheben. Sie erhalten ein tiefes Verständnis für beide Produkte, ein Verständnis dafür, wie sie verwendet werden sollten und was nicht, und ein Verständnis dafür, worauf Sie achten müssen, wenn Sie in Zukunft über andere Messaging-Technologien nachdenken ... »
Bisher übersetzte Teile:
Ich werde fertige Kapitel veröffentlichen, sobald sie übersetzt sind.
P "P> RђR'Rђ 1
Einführung
System-zu-System-Messaging ist einer der am wenigsten verstandenen Bereiche der IT. Als Entwickler oder Architekt sind Sie möglicherweise mit verschiedenen Frameworks und Datenbanken bestens vertraut. Es ist jedoch wahrscheinlich, dass Sie nur ansatzweise mit der Funktionsweise von Broker-basierten Messaging-Technologien vertraut sind. Wenn Sie sich so fühlen, machen Sie sich keine Sorgen, Sie sind in guter Gesellschaft.
Menschen haben normalerweise nur sehr begrenzten Kontakt mit der Messaging-Infrastruktur. Sie stellen häufig eine Verbindung zu einem vor langer Zeit erstellten System her oder laden eine Distribution aus dem Internet herunter, installieren sie im PROM und beginnen mit dem Schreiben von Code dafür. Nach dem Ausführen der Infrastruktur im PROM können die Ergebnisse gemischt sein: Nachrichten gehen aufgrund von Fehlern verloren, der Versand funktioniert nicht wie erwartet, oder Broker „hängen“ Ihre Produzenten an oder senden keine Nachrichten an Ihre Verbraucher.
Klingt vertraut?
Ein häufiges Szenario ist, dass Ihr Nachrichtencode vorerst hervorragend funktioniert. Bis es nicht mehr funktioniert. Diese Zeit wiegt einen in einem falschen Sicherheitsgefühl und führt zu mehr Code, der auf falschen Überzeugungen über das grundlegende Verhalten der Technologie basiert. Wenn etwas schief geht, werden Sie mit einer unbequemen Wahrheit konfrontiert: dass Sie das zugrunde liegende Verhalten des Produkts oder die von den Autoren gewählten Kompromisse, wie Leistung versus Zuverlässigkeit oder Transaktionalität versus horizontale Skalierbarkeit, nicht wirklich verstanden haben .
Ohne ein tiefes Verständnis der Funktionsweise von Brokern machen Menschen scheinbar vernünftige Aussagen über ihre Nachrichtensysteme, wie zum Beispiel:
- Das System wird niemals Nachrichten verlieren
- Nachrichten werden nacheinander verarbeitet
- Durch das Hinzufügen von Verbrauchern wird das System schneller
- Nachrichten werden nur einmal zugestellt
Leider basieren einige dieser Aussagen auf Annahmen, die nur unter bestimmten Umständen zutreffen, während andere einfach falsch sind.
In diesem Buch erfahren Sie, wie Sie über Broker-basierte Messaging-Systeme denken und zwei beliebte Broker-Technologien vergleichen und gegenüberstellen: Apache ActiveMQ und Apache Kafka. Es werden die Anwendungsfälle und Entwicklungsanreize skizziert, die ihre Entwickler dazu veranlasst haben, sehr unterschiedliche Ansätze für denselben Bereich zu verfolgen – die Nachrichtenübermittlung zwischen Systemen mit einem zwischengeschalteten Broker. Wir werden diese Technologien von Grund auf betrachten und dabei die Auswirkungen verschiedener Designentscheidungen hervorheben. Sie erhalten ein tiefes Verständnis für beide Produkte, ein Verständnis dafür, wie sie verwendet werden sollten und was nicht, und ein Verständnis dafür, worauf Sie achten müssen, wenn Sie in Zukunft über andere Messaging-Technologien nachdenken.
Bevor wir beginnen, gehen wir die Grundlagen durch.
Was ist ein Nachrichtensystem und warum 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 Transports oder Protokolls wie HTTP, MQTT oder SMTP und die Aushandlung der Nachrichtenformate, die zwischen den Systemen ausgetauscht werden. Dabei kann es sich um einen strikten Prozess handeln, wie etwa das Definieren eines XML-Schemas mit Anforderungen an die Kosten für die Nachrichtennutzlast, oder um einen viel weniger formalen Prozess, wie etwa eine Vereinbarung zwischen zwei Entwicklern, dass ein Teil der HTTP-Anfrage die Client-ID enthalten wird.
Solange das Format der Nachrichten und die Reihenfolge, in der sie gesendet werden, zwischen den Systemen konsistent sind, können sie miteinander kommunizieren, ohne sich um die Implementierung des anderen Systems kümmern zu müssen. Die Interna dieser Systeme, wie etwa 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 seitens der Gegenseite fortgesetzt werden. Durch diese Schnittstelle werden die beiden Systeme effektiv entkoppelt (getrennt).
Bei Messaging-Systemen handelt es sich typischerweise um einen Vermittler zwischen zwei Systemen, die interagieren, um den Absender noch weiter vom Empfänger bzw. den Empfängern zu entkoppeln (zu trennen). In diesem Fall ermöglicht das Nachrichtensystem dem Absender, eine Nachricht zu senden, ohne zu wissen, wo sich der Empfänger befindet, ob er aktiv ist oder wie viele Instanzen es gibt.
Schauen wir uns ein paar Analogien für die Arten von Problemen an, die ein Nachrichtensystem löst, und führen wir einige Grundbegriffe ein.
Punkt zu Punkt
Alexandra geht zur Post, um Adam ein Paket zu schicken. Sie geht zum Fenster und überreicht der Mitarbeiterin das Paket. Der Mitarbeiter holt das Paket ab und gibt Alexandra eine Quittung. Adam muss nicht zu Hause sein, wenn das Paket verschickt wird. Alexandra ist zuversichtlich, dass das Paket irgendwann in der Zukunft bei Adam zugestellt wird und sie ihren Geschäften weiter nachgehen kann. Später erhält Adam irgendwann ein Paket.
Dies ist ein Beispiel für ein Messaging-Modell Punkt zu Punkt. Die Post fungiert hier als Paketverteilungsmechanismus und stellt sicher, dass jedes Paket einmal zugestellt wird. Bei der Nutzung eines Postamtes ist der Vorgang des Versendens eines Pakets von der Zustellung des Pakets getrennt.
In klassischen Messaging-Systemen wird das Punkt-zu-Punkt-Modell durch implementiert очереди. Die Warteschlange fungiert als FIFO-Puffer (First In, First Out), der von einem oder mehreren Verbrauchern abonniert werden kann. Jede Nachricht wird nur zugestellt an einen der abonnierten Verbraucher. Warteschlangen versuchen normalerweise, Nachrichten gerecht unter den Verbrauchern zu verteilen. Nur ein Verbraucher erhält diese Nachricht.
Für Warteschlangen wird der Begriff „langlebig“ verwendet. Zuverlässigkeit ist eine Diensteigenschaft, die sicherstellt, dass das Nachrichtensystem Nachrichten bei Abwesenheit aktiver Abonnenten so lange beibehält, bis ein Verbraucher die Warteschlange für die Nachrichtenzustellung abonniert.
Zuverlässigkeit wird oft verwechselt mit Beharrlichkeit und obwohl die beiden Begriffe synonym verwendet werden, erfüllen sie unterschiedliche Funktionen. Persistenz bestimmt, ob das Nachrichtensystem eine Nachricht zwischen dem Empfang und dem Senden an den Verbraucher in einen Speicher schreibt. An die Warteschlange gesendete Nachrichten können dauerhaft sein oder auch nicht.
Punkt-zu-Punkt-Nachrichten werden verwendet, wenn der Anwendungsfall eine einmalige Aktion für die Nachricht erfordert. Beispiele hierfür sind die Einzahlung von Geldern auf ein Konto oder die Ausführung eines Lieferauftrags. Wir werden später diskutieren, warum das Nachrichtensystem allein keine einmalige Zustellung bieten kann und warum Warteschlangen allenfalls eine Zustellungsgarantie bieten können zumindest einmal.
Herausgeber-Abonnent
Gabriella wählt die Konferenznummer. Während sie mit der Konferenz verbunden ist, hört sie zusammen mit den anderen Gesprächsteilnehmern alles, was der Sprecher sagt. Wenn sie abschaltet, verpasst sie, was gesagt wird. Wenn die Verbindung wiederhergestellt ist, hört sie weiterhin, was gesagt wird.
Dies ist ein Beispiel für ein Messaging-Modell Veröffentlichen-Abonnieren. Konferenzgespräche fungieren als Broadcast-Mechanismus. Der sprechenden Person ist es egal, wie viele Personen gerade telefonieren – das System stellt sicher, dass jeder, der gerade verbunden ist, hört, was gesagt wird.
In klassischen Messaging-Systemen wird das Publish-Subscribe-Messaging-Modell durch implementiert Themen. Das Thema bietet die gleiche Übertragungsmethode wie der Konferenzmechanismus. Wenn eine Nachricht an ein Thema gesendet wird, wird sie verteilt für alle abonnierten Benutzer.
Themen sind in der Regel unzuverlässig (nicht dauerhaft). So wie ein Zuhörer nicht hören kann, was in einer Telefonkonferenz gesagt wird, wenn der Zuhörer die Verbindung trennt, verpassen Themenabonnenten alle Nachrichten, die gesendet werden, während sie offline sind. Aus diesem Grund können wir sagen, dass Themen eine Liefergarantie bieten nicht mehr als einmal für jeden Verbraucher.
Publish-Subscribe-Messaging wird in der Regel verwendet, wenn die Nachrichten informativer Natur sind und der Verlust einer Nachricht nicht besonders schwerwiegend ist. Beispielsweise kann ein Thema einmal pro Sekunde Temperaturmesswerte einer Gruppe von Sensoren übertragen. Ein System, das sich für die aktuelle Temperatur interessiert und ein Thema abonniert, wird sich keine Sorgen machen, wenn ihm eine Nachricht entgeht – eine weitere wird in naher Zukunft eintreffen.
Hybridmodelle
Auf der Website des Geschäfts werden Bestellnachrichten in eine „Nachrichtenwarteschlange“ gestellt. Der Hauptkonsument dieser Nachrichten ist das Exekutivsystem. Darüber hinaus sollte das Prüfsystem über Kopien dieser Bestellnachrichten zur späteren Nachverfolgung verfügen. Beide Systeme können die Durchleitung von Nachrichten nicht zulassen, selbst wenn die Systeme selbst für einige Zeit nicht verfügbar sind. Die Website sollte keine Kenntnis von anderen Systemen haben.
Anwendungsfälle erfordern häufig eine Kombination aus Publish-Subscribe- und Punkt-zu-Punkt-Messaging-Modellen, beispielsweise wenn mehrere Systeme eine Kopie einer Nachricht benötigen und sowohl Zuverlässigkeit als auch Beständigkeit erforderlich sind, um Nachrichtenverluste zu verhindern.
In diesen Fällen ist ein Ziel (ein allgemeiner Begriff für Warteschlangen und Themen) erforderlich, das Nachrichten grundsätzlich als Thema verteilt, sodass jede Nachricht an ein separates System gesendet wird, das an diesen Nachrichten interessiert ist, wobei jedes System jedoch auch mehrere Verbraucher definieren kann, die eingehende Nachrichten empfangen Nachrichten, die eher einer Warteschlange ähneln. Der Lesetyp ist in diesem Fall einmal für jeden Stakeholder. Diese hybriden Ziele erfordern häufig Haltbarkeit, sodass die zu diesem Zeitpunkt gesendeten Nachrichten empfangen werden, wenn ein Verbraucher offline geht, nachdem der Verbraucher die Verbindung wiederhergestellt hat.
Hybridmodelle sind nicht neu und können in den meisten Messaging-Systemen verwendet werden, einschließlich ActiveMQ (über virtuelle oder zusammengesetzte Ziele, die Themen und Warteschlangen kombinieren) und Kafka (implizit als grundlegende Eigenschaft seines Zieldesigns).
Nachdem wir nun über einige grundlegende Begriffe und ein Verständnis dafür verfügen, wofür wir ein Nachrichtensystem verwenden können, gehen wir zu den Details über.
Übersetzung erledigt:
Der folgende übersetzte Teil:
To be continued ...
Source: habr.com