In diesem Dokument werden die Unterschiede zwischen lokalen, warteschlangenorientierten Architekturen und den ereignisbasierten, ereignisgesteuerten Architekturen beschrieben, die in Pub/Sub implementiert sind. Wenn Sie lokale Muster direkt auf cloudbasierte Technologien anwenden, entgeht Ihnen möglicherweise der einzigartige Wert, der die Cloud eigentlich einzigartig macht.
Dieses Dokument richtet sich an Systemarchitekten, die Designs von lokalen Architekturen zu cloudbasierten Designs migrieren. In diesem Dokument wird davon ausgegangen, dass Sie ein grundlegendes Verständnis von Nachrichtensystemen haben.
Das folgende Diagramm gibt einen Überblick über ein Nachrichtenwarteschlangenmodell und ein Pub/Sub-Modell.
Im vorherigen Diagramm wird ein Nachrichtenwarteschlangenmodell mit einem Pub/Sub-Ereignisstreammodell verglichen. Bei einem Nachrichtenwarteschlangenmodell überträgt der Publisher Nachrichten in eine Warteschlange, wobei jeder Abonnent eine bestimmte Warteschlange überwachen kann. Im Ereignisstreammodell, das Pub/Sub nutzt, überträgt der Publisher Nachrichten an ein Thema, das mehrere Abonnenten überwachen können. Die Unterschiede zwischen diesen Modellen werden in den folgenden Abschnitten erläutert.
Ereignisstreams und warteschlangenbasierte Nachrichten vergleichen
Wenn Sie mit lokalen Systemen arbeiten, sind Sie bereits mit Enterprise Service Buses (ESBs) und Nachrichtenwarteschlangen vertraut. Ereignisstreams sind ein neues Muster und es gibt wichtige Unterschiede bei konkreten Vorteilen für moderne Echtzeitsysteme.
In diesem Dokument werden die wichtigsten Unterschiede im Transportmechanismus und in den Nutzlastdaten in einer ereignisbasierten Architektur erläutert.
Nachrichtentransport
Die Systeme, die Daten in diesen Modellen verschieben, werden als Nachrichtenbroker bezeichnet und es gibt eine Vielzahl von Frameworks. Eines der ersten Konzepte ist die zugrunde liegende Mechanik, die Nachrichten vom Publisher an den Empfänger sendet. Bei lokalen Nachrichten-Frameworks gibt das Ursprungssystem eine explizite und entkoppelte Remote-Nachricht mit einer Nachrichtenwarteschlange für den Transport an ein nachgelagertes Verarbeitungssystem aus.
Das folgende Diagramm zeigt ein Nachrichtenwarteschlangenmodell:
Im obigen Diagramm fließen die Nachrichten von einem vorgelagerten Publisher-Prozess in einen nachgelagerten Abonnentenprozess über eine Nachrichtenwarteschlange ein.
System A (der Publisher) sendet eine Nachricht an eine Warteschlange auf dem Nachrichten-Broker, der für System B (Abonnenten) zuständig ist. Der Abonnent der Warteschlange kann zwar aus mehreren Clients bestehen, alle diese Clients sind jedoch doppelte Instanzen von System B, die für Skalierung und Verfügbarkeit bereitgestellt werden. Wenn zusätzliche nachgelagerte Prozesse (z. B. System C) dieselben Nachrichten vom Ersteller (System A) benötigen, ist eine neue Warteschlange erforderlich. Sie müssen den Produzenten aktualisieren, damit die Nachrichten in der neuen Warteschlange veröffentlicht werden. Dieses Modell wird häufig als Message Passing bezeichnet.
Die Nachrichtentransportebene für diese Warteschlangen kann die Nachrichtenreihenfolge unter Umständen garantieren. Häufig wird von Nachrichtenwarteschlangen erwartet, dass sie ein Modell mit garantierter Reihenfolge bereitstellen, bei dem die Daten in einem strengen FIFO-Zugriffsmodell (First-in-First-out) angeordnet sind, ähnlich wie bei einer Aufgabenwarteschlange. Dieses Muster lässt sich zuerst leicht implementieren, führt letztendlich jedoch zu Herausforderungen in Verbindung mit der Skalierung- und dem Betrieb. Zur Implementierung von Nachrichten in einer bestimmten Reihenfolge benötigt das System einen zentralen Prozess, damit die Daten geordnet werden können. Dieser Prozess beschränkt die Skalierungsfunktionen und reduziert die Dienstverfügbarkeit, da es sich um einen Single Point of Failure handelt.
Die Nachrichtenbroker in diesen Architekturen implementieren normalerweise eine zusätzliche Logik, z. B. um zu verfolgen, welcher Abonnent welche Nachrichten empfangen hat und um die Auslastung der Abonnenten zu überwachen. Die Abonnenten sind in der Regel nur reaktiv und haben nicht das Wissen über das Gesamtsystem. Sie führen einfach eine Funktion nach Erhalt der Nachricht aus. Diese Art von Architekturen werden als Smart Pipes (Nachrichtenwarteschlangensystem) und Dumb Endpoints (Abonnent) bezeichnet.
Pub/Sub-Transport
Ähnlich wie nachrichtenorientierte Systeme werden auch bei Ereignis-Streaming-Systemen Nachrichten von einem Quellsystem an entkoppelte Zielsysteme übertragen. Anstatt jedoch jede Nachricht an eine prozessorientierte Warteschlange zu senden, werden ereignisbasierte Systeme dazu verwendet, Nachrichten in einem gemeinsam genutzten Thema zu veröffentlichen. Dann rufen ein oder mehrere Empfänger dieses Thema auf, um relevante Nachrichten zu erhalten.
Das folgende Diagramm zeigt, wie verschiedene Nachrichten von einem vorgelagerten Publisher an ein einzelnes Thema ausgegeben und dann an den entsprechenden nachgelagerten Abonnenten weitergeleitet werden:
Der Begriff pub/sub geht auf das Muster „Publish and Subscribe“ (Veröffentlichen und Abonnieren) zurück. Dieses Muster ist auch die Grundlage für das Google Cloud-Produkt Pub/Sub. In diesem Dokument bezieht sich pubsub auf das Muster und Pub/Sub auf das Produkt.
Im Pub/Sub-Modell benötigt das Nachrichtensystem keine Informationen über die Abonnenten. Er erfasst nicht, welche Nachrichten empfangen wurden, und verwaltet auch nicht die Last des laufenden Prozesses. Stattdessen erfassen die Abonnenten, welche Nachrichten empfangen wurden, und müssen sich selbst um das Lastniveau und die Skalierung kümmern.
Ein großer Vorteil besteht darin, dass Sie bei der Nutzung neuer Daten für das Pub/Sub-Modell das Ursprungssystem nicht aktualisieren müssen, um in neuen Warteschlangen oder doppelten Daten zu veröffentlichen. Stattdessen können Sie einen neuen Nutzer ohne Auswirkungen auf das vorhandene System einem neuen Abo zuordnen.
Die Aufrufe von Ereignisstreamingsystemen sind fast immer asynchron, sie senden Ereignisse und warten nicht auf Antworten. Das asynchrone Ereignis bietet eine größere Skalierungsmöglichkeit für den Ersteller und den Nutzer. Dieses asynchrone Muster kann jedoch zur Herausforderung werden, wenn Sie eine FIFO-Garantie für die Nachrichtenreihenfolge erwarten.
Nachrichtenwarteschlangendanten
Die zwischen Nachrichtenwarteschlangensystemen und Pub/Sub-basierten Systemen übertragenen Daten werden jeweils als Nachricht bezeichnet. Das Modell, in dem diese Daten dargestellt werden, unterscheidet sich jedoch. In Nachrichtenwarteschlangensystemen stehen die Nachrichten für einen Befehl, mit dem der Status der Downstream-Daten geändert werden soll. Bei der Betrachtung der Daten für lokale Nachrichtenwarteschlangensysteme kann der Publisher explizit angeben, was der Nutzer tun soll. Eine Inventarnachricht könnte beispielsweise Folgendes enthalten:
<m:SetInventoryLevel>
<inventoryValue>3001</inventoryValue>
</m: SetInventoryLevel>
In diesem Beispiel teilt der Ersteller dem Nutzer mit, dass er die Inventarebene auf 3.001 festlegen muss. Dieser Ansatz kann eine Herausforderung darstellen, da der Ersteller die Geschäftslogik jedes Nutzers verstehen und separate Nachrichtenstrukturen für verschiedene Anwendungsfälle erstellen muss. Dieses Nachrichtenwarteschlangensystem war in den großen monolithischen Anwendungen, die von den meisten Unternehmen implementiert wurden, eine gängige Praxis. Wenn Sie jedoch schneller wachsen, höher skalieren und innovativer arbeiten möchten, können diese zentralisierten Systeme zu einem Engpass führen, da eine Änderung riskant und langsam ist.
Auch bei diesem Verhalten gibt es operative Herausforderungen. Wenn fehlerhafte Daten, doppelte Datensätze oder andere Probleme auftreten und behoben werden müssen, stellt dieses Nachrichtenmodell eine große Herausforderung dar. Wenn Sie beispielsweise ein Rollback der im vorherigen Beispiel verwendeten Nachricht ausführen müssen, wissen Sie nicht, wie der korrigierte Wert eingestellt werden soll, da es keinen Verweis auf den vorherigen Status gibt. Sie wissen nicht, ob der Inventarwert vor dem Senden dieser Nachricht bei 3.000 oder 4.000 lag.
Pubsub-Daten
Ereignisse sind eine weitere Möglichkeit, Nachrichtendaten zu senden. Das Besondere ist, dass sich ereignisgesteuerte Systeme auf das Ereignis beziehen, das stattgefunden hat, und nicht auf das sich daraus ergebende Ergebnis. Statt Daten zu senden, die angeben, welche Aktion ein Nutzer ausführen soll, konzentrieren sich die Daten auf die Details des erzeugten Ereignisses. Ereignisgesteuerte Systeme können auf einer Vielzahl von Plattformen implementiert werden. Sie sind jedoch häufig auf Pub/Sub-Systemen zu finden.
Ein Inventarereignis könnte beispielsweise so aussehen:
{ "inventory":-1 }
Die vorherigen Ereignisdaten weisen darauf hin, dass ein Ereignis aufgetreten ist, das das Inventar um 1 verringert hat. Die Nachrichten beziehen sich auf ein Ereignis in der Vergangenheit und keinen Status, der in Zukunft geändert werden sollte. Publisher können Nachrichten auf asynchrone Weise senden. Dadurch werden ereignisgesteuerte Systeme einfacher skaliert als bei Nachrichtenwarteschlangenmodellen. Im Pub/Sub-Modell können Sie die Geschäftslogik entkoppeln, damit der Produzent nur die ausgeführten Aktionen und die nachgelagerten Prozesse verstehen muss. Die Abonnenten dieser Daten können auswählen, wie sie mit den empfangenen Daten umgehen möchten. Da diese Nachrichten keine überflüssigen Befehle sind, wird die Reihenfolge der Nachrichten weniger wichtig.
Mit diesem Muster ist es einfacher, Änderungen rückgängig zu machen. In diesem Beispiel sind keine zusätzlichen Informationen erforderlich, da Sie den Inventarwert negieren können, um ihn in die entgegengesetzte Richtung zu verschieben. Nachrichten, die zu spät oder in der falschen Reihenfolge eingehen, sind kein Problem mehr.
Modellvergleich
In diesem Szenario gibt es vier Artikel desselben Produkts in Ihrem Inventar. Ein Kunde gibt einen Artikel zurück und der nächste Kunde kauft drei Artikel vom selben Produkt. In diesem Szenario wird davon ausgegangen, dass die Nachricht für das zurückgegebene Produkt verspätet war.
In der folgenden Tabelle wird die Inventarstufe des Nachrichtenwarteschlangenmodells verglichen, in der die Inventaranzahl in der richtigen Reihenfolge empfangen wird. Dabei wird mit demselben Modell die Inventaranzahl in der falschen Reihenfolge zurückgegeben:
| Nachrichtenwarteschlange (richtige Reihenfolge) | Nachrichtenwarteschlange (falsche Reihenfolge) |
|---|---|
Anfängliches Inventar: 4 |
Anfängliches Inventar: 4 |
Nachricht 1: setInventory(5) |
Nachricht 2: setInventory(2) |
Nachricht 2: setInventory(2) |
Nachricht 1: setInventory(5) |
Inventarebene: 2 |
Inventarebene: 5 |
Im Nachrichtenwarteschlangenmodell ist die Reihenfolge, in der die Nachrichten empfangen werden, wichtig, da die Nachricht den vorab berechneten Wert enthält. Wenn die Nachrichten in diesem Beispiel in der richtigen Reihenfolge ankommen, besteht die Inventarebene 2. Wenn die Nachrichten jedoch nicht in der richtigen Reihenfolge ankommen, besteht die Inventarebene 5, was nicht korrekt ist.
In der folgenden Tabelle wird die Inventarebene des pubsub-basierten Systems verglichen, das die Inventaranzahl in der richtigen Reihenfolge erhält, und zwar im gleichen System, in dem die Inventaranzahl nicht in der richtigen Reihenfolge ausgegeben wird:
| Pubsub (richtige Reihenfolge) | Pubsub (falsche Reihenfolge) |
|---|---|
| Anfängliches Inventar: 4 | Anfängliches Inventar: 4 |
Nachricht 2: "inventory":-3 |
Nachricht 1: "inventory":+1 |
Nachricht 1: "inventory":+1 |
Nachricht 2: "inventory":-3 |
Inventarebene: 2 |
Inventarebene: 2 |
Im Pub/Sub-System spielt die Reihenfolge der Nachrichten keine Rolle, da sie von Diensten unterstützt wird, die Ereignisse erstellen. Die Inventarebene ist ungeachtet der Reihenfolge der Nachrichten korrekt.
Das folgende Diagramm zeigt, wie die Warteschlange im Nachrichtenwarteschlangenmodell Befehle ausführt, die dem Abonnenten mitteilen, wie sich der Status im pubsub-Modell ändern sollte. Die Abonnenten reagieren auf Ereignisdaten, die angeben, was im Ersteller vorgefallen ist:
Ereignisgesteuerte Architekturen implementieren
Bei der Implementierung ereignisgesteuerter Architekturen gibt es verschiedene Konzepte. In den folgenden Abschnitten werden einige dieser Themen vorgestellt.
Übermittlungsgarantien
Ein Konzept, das in einer Systemdiskussion eingesetzt wird, ist die Zuverlässigkeit der Nachrichtenzustellungsgarantien. Unterschiedliche Anbieter und Systeme bieten möglicherweise unterschiedliche Zuverlässigkeitsgrade. Deshalb ist es wichtig, die Unterschiede zu verstehen.
Der erste Garantietyp stellt eine einfache Frage: Wenn eine Nachricht gesendet wurde, wird die Übermittlung garantiert? Dies wird als mindestens einmalige Übermittlung bezeichnet. Es wird garantiert, dass die Nachricht mindestens einmal zugestellt wird. Sie kann aber mehrmals gesendet werden.
Eine anderer Garantietyp ist die höchstens einmalige Übermittlung. Bei der höchstens einmaligen Übermittlung wird die Nachricht höchstens einmal zugestellt. Es gibt jedoch keine Garantie dafür, dass die Nachricht tatsächlich gesendet wird.
Die letzte Variante der Auslieferungsgarantien ist eine genau einmalige Übermittlung. Bei diesem Modell sendet das System nur eine Kopie der Nachricht, die garantiert zugestellt wird.
Reihenfolge und Duplikate
Lokale Architekturen folgen häufig einem FIFO-Modell. Zu diesem Zweck verwaltet ein zentrales Verarbeitungssystem die Abfolge von Nachrichten, damit die Reihenfolge korrekt ist. Geordnete Nachrichten sind schwierig, da alle fehlerhaften Nachrichten noch einmal in der richtigen Reihenfolge gesendet werden müssen. Jedes zentralisierte System kann in Sachen Verfügbarkeit und Skalierbarkeit eine Herausforderung darstellen. Das Skalieren eines zentralen Systems, das die Reihenfolge verwaltet, ist in der Regel nur möglich, wenn einer vorhandenen Maschine weitere Ressourcen hinzugefügt werden. Da nur ein einziges System die Reihenfolge verwaltet, wirkt sich die Zuverlässigkeit auf das gesamte System und nicht nur auf diese Maschine aus.
Hoch skalierbare und verfügbare Messaging-Dienste nutzen häufig mehrere Verarbeitungssysteme, damit Nachrichten mindestens einmal zugestellt werden. Bei vielen Systemen kann die Nachrichtenreihenfolge nicht garantiert werden.
Ereignisbasierte Architekturen verlassen sich nicht auf die Nachrichtenreihenfolge und können doppelte Nachrichten tolerieren. Wenn eine Reihenfolge erforderlich ist, können Subsysteme Aggregations- und Windowing-Techniken implementieren. Bei diesem Ansatz werden Skalierbarkeit und Verfügbarkeit jedoch im Rahmen dieser Komponente berücksichtigt.
Filter- und Fanout-Methoden
Da ein Ereignis-Stream Daten enthalten kann, die von jedem Abonnenten benötigt werden, müsse die Daten, die ein bestimmter Abonnenten erhält, oft beschränkt werden. Es gibt zwei Muster für die Verwaltung dieser Anforderung: Ereignisfilter und Ereignis-Fanouts.
Das folgende Diagramm zeigt ein ereignisgesteuertes System mit Ereignisfiltern, die Nachrichten für Abonnenten filtern:
Im vorherigen Diagramm verwenden Ereignisfilter Filtermechanismen, die die Ereignisse beschränken, die den Abonnenten erreichen. In diesem Modell enthält ein einzelnes Thema alle Varianten einer Nachricht. Damit ein Abonnent nicht jede Nachricht lesen und dahingehend prüfen muss, ob sie geeignet ist, wertet die Filterlogik im Nachrichtensystem die Nachricht aus und stellt sie anderen Abonnenten nicht zu.
Das folgende Diagramm zeigt eine Variante des Ereignisfiltermusters, das als Ereignis-Fanout bezeichnet wird und mehrere Themen verwendet:
Im obigen Diagramm enthält das Hauptthema alle Varianten einer Nachricht, aber ein Ereignis-Fanout-Mechanismus veröffentlicht die Nachrichten zu Themen noch einmal, die sich auf diese Untergruppe von Abonnenten beziehen.
Nicht verarbeitete Nachrichtenwarteschlangen
Selbst bei den besten Systemen können Fehler auftreten. Nicht verarbeitete Nachrichtenwarteschlangen sind eine Methode zur Behebung solcher Fehler. Bei den meisten ereignisgesteuerten Architekturen sendet das Nachrichtensystem eine Nachricht an den Abonnenten, bis diese vom Abonnenten angenommen wird.
Wenn es ein Problem mit einer Nachricht gibt, z. B. ungültige Zeichen im Nachrichtentext, kann der Abonnent die Nachricht möglicherweise nicht annehmen. Das System kann das Szenario nicht verarbeiten und den Vorgang unter Umständen sogar beenden.
Systeme versuchen normalerweise, nicht bestätigte oder fehlerhafte Nachrichten noch einmal zuzustellen. Wenn eine ungültige Nachricht nach einer zuvor festgelegten Zeit nicht angenommen wird, kommt es zu einer Zeitüberschreitung und sie wird aus dem Thema entfernt. Aus operativen Sicht ist es hilfreich, die Nachrichten zu prüfen, anstatt sie zu entfernen. Hier kommen nicht verarbeitete Nachrichtenwarteschlangen ins Spiel. Statt die Nachricht aus dem Thema zu entfernen, wird sie in ein anderes Thema verschoben, in dem sie verarbeitet oder dahingehend geprüft werden kann, warum es zu einem Fehler kam.
Streamverlauf und Wiederholungen
Ereignisstreams sind stetige Datenflüsse. Der Zugriff auf diese Verlaufsdaten ist nützlich. Möglicherweise möchten Sie wissen, wie ein System einen bestimmten Status erreicht hat. Eventuell haben Sie sicherheitsrelevante Fragen, für die eine Prüfung der Daten erforderlich ist. Für den langfristigen Betrieb eines ereignisgesteuerten Systems muss ein Verlaufslog der Ereignisse erstellt werden können.
Bei Verlaufsereignisdaten wird oft ein Wiederholungssystem genutzt. Wiederholungen werden zu Testzwecken verwendet. Durch das Wiederholen von Ereignisdaten aus der Produktion in anderen Umgebungen wie Phase oder Test können Sie neue Funktionen mit echten Datasets validieren. Sie können auch Verlaufsdaten wiederholen, um sie aus einem fehlerhaften Zustand wiederherzustellen. Wenn ein System ausfällt oder verloren geht, können Teams den Ereignisverlauf von einem bekannten Punkt aus wiederholen. Der Dienst kann dann den Zustand wiederherstellen, den er verloren hat.
Das Erfassen dieser Ereignisse in logbasierten Warteschlangen oder Logging-Streams ist auch dann nützlich, wenn Abonnenten zu verschiedenen Zeiten Zugriff auf eine Ereignissequenz benötigen. Logging-Streams sind in Systemen mit Offline-Funktionalität sichtbar. Mithilfe Ihres Streamverlaufs können Sie die neuesten neuen Einträge verarbeiten, indem Sie den Stream ab dem last-read-Zeiger lesen.
Datenansichten: Echtzeit und echtzeitnah
Da alle Daten die Systeme durchlaufen, müssen Sie sie auch nutzen können. Es gibt viele Möglichkeiten, um diese Ereignisstreams zu nutzen und auf sie zuzugreifen. Üblicherweise wird jedoch der Gesamtstatus von Daten zu einem bestimmten Zeitpunkt ermittelt. Dazu kommen oftmals rechnerisch ausgerichtete Fragen wie „wie viele“ oder „aktuelles Level“ zum Einsatz, die von anderen Systemen oder von Nutzern verwendet werden können. Es gibt mehrere Implementierungen, die diese Fragen beantworten können:
- Ein Echtzeitsystem kann dauerhaft ausgeführt werden und den aktuellen Status verfolgen. Da das System jedoch nur eine speicherinterne Berechnung hat, setzt die Ausfallzeit die Berechnung auf null.
- Das System kann Werte aus der Verlaufstabelle für jede Anfrage berechnen. Dies kann jedoch zu Problemen führen, da der Versuch, für jede Anfrage Werte zu berechnen, während die Daten größer werden, möglicherweise scheitert.
- Das System kann Snapshots der Berechnungen in bestimmten Intervallen erstellen, wobei die Verwendung von Snapshots nicht die Echtzeitdaten widerspiegelt.
Nützlich ist z. B. die Implementierung einer Lambda-Architektur mit Echtzeitfunktionen und echtzeitnahen Funktionen. Beispielsweise kann die Produktseite einer E-Commerce-Website echtzeitnahe Ansichten von Inventardaten enthalten. Wenn Kunden Bestellungen aufgeben, wird ein Echtzeitdienst verwendet, um aktuelle Statusaktualisierungen der Inventardaten zu erhalten. Zur Implementierung dieses Musters reagiert der Dienst auf echtzeitnahe Anfragen von einer Snapshot-Tabelle mit berechneten Werten für ein bestimmtes Intervall. Bei einer Echtzeitanfrage werden sowohl die Snapshot-Tabelle als auch die Werte in der Verlaufstabelle seit dem letzten Snapshot verwendet, um den exakten aktuellen Status abzurufen. Diese materialisierten Ansichten der Ereignisstreams liefern umsetzbare Daten, um echte Geschäftsprozesse zu fördern.
Nächste Schritte
- Informationen zu Pub/Sub oder Cloud Tasks für die Nachrichtenweitergabe und asynchrone Integration
- Kurzanleitung zu Pub/Sub
- Informationen zur Architektur von Pub/Sub
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center