Architekturübersicht von Pub/Sub

Pub/Sub ist ein asynchroner Messaging-Dienst, der sich durch hohe Zuverlässigkeit und Skalierbarkeit auszeichnet. Der Dienst basiert auf einer Google-Infrastrukturkernkomponente, die seit über zehn Jahren für viele Google-Produkte verwendet wird. Google-Produkte wie Google Ads, die Google-Suche und Gmail nutzen diese Infrastruktur zum Senden von über 500 Millionen Nachrichten pro Sekunde, also insgesamt über 1 TB/s an Daten. In diesem Artikel werden die wichtigsten Elemente beschrieben, durch die Pub/Sub diese Skalierung zuverlässig ermöglichen kann.

Bewertung der Leistung eines Messaging-Dienstes

Ein Messaging-Dienst wie Pub/Sub kann nach drei Aspekten seiner Leistung bewertet werden: Skalierbarkeit, Verfügbarkeit und Latenz. Diese drei Faktoren stehen oft im Widerspruch zueinander und erfordern dann Kompromisse bei einem Faktor, um die beiden anderen Faktoren zu verbessern.

Die Begriffe "Skalierbarkeit", "Verfügbarkeit" und "Latenz" können sich auf verschiedene Eigenschaften eines Systems beziehen. In den folgenden Abschnitten wird beschrieben, wie sie in Pub/Sub definiert sind.

Skalierbarkeit

Ein skalierbarer Dienst sollte in der Lage sein, höhere Lasten ohne erkennbare Verschlechterung der Latenz oder Verfügbarkeit zu bewältigen. "Last" kann sich auf verschiedene Dimensionen der Nutzung in Pub/Sub beziehen:

  • Zahl der Themen

  • Zahl der Publisher

  • Zahl der Abos

  • Zahl der Abonnenten

  • Zahl der Nachrichten

  • Größe der Nachrichten

  • Häufigkeit der veröffentlichten oder genutzten Nachrichten (Durchsatz)

  • Umfang des Rückstands eines Abos

Verfügbarkeit

In einem dezentralen System können die Arten und Schweregrade von Problemen sehr unterschiedlich sein. Die Verfügbarkeit eines Systems wird daran gemessen, wie gut es mit den verschiedenen Problemen umgeht und bei Fehlern reagiert, ohne dass die Endnutzer es bemerken. Fehler können in Verbindung mit Hardware (zum Beispiel nicht funktionsfähige Laufwerke oder Netzwerkverbindungsprobleme), Software und Auslastung auftreten. Fehler aufgrund der Last können auftreten, wenn eine plötzliche Zunahme des Datenverkehrs des Dienstes (oder von anderen Softwarekomponenten, die auf der gleichen Hardware oder in Softwareabhängigkeiten ausgeführt werden) Ressourcenknappheit zur Folge hat. Die Verfügbarkeit kann auch aufgrund menschlicher Fehler schlechter werden, wenn diese bei der Erstellung oder Bereitstellung von Software oder bei Konfigurationen passieren.

Latenz

Latenz ist ein zeitbasierter Messwert der Leistung eines Systems. Mit einem Dienst wird immer versucht, die Latenz möglichst zu minimieren. Für Pub/Sub sind die beiden wichtigsten Latenzmesswerte:

  1. Die Zeitspanne bis zur Bestätigung einer veröffentlichten Nachricht.

  2. Die Zeitspanne bis zum Senden einer veröffentlichten Nachricht an einen Abonnenten.

Grundlegende Pub/Sub-Architektur

In diesem Abschnitt wird die Struktur von Pub/Sub erläutert. Dabei werden die Skalierbarkeit, niedrige Latenz und hohe Verfügbarkeit des Dienstes beleuchtet. Das System ist horizontal skalierbar, das heißt, eine wachsende Zahl an Themen, Abos und Nachrichten kann durch Aufstockung der Zahl der aktiven Serverinstanzen verarbeitet werden.

Pub/Sub-Server werden weltweit in allen Google Cloud-Regionen ausgeführt. Damit bietet der Dienst einen schnellen, globalen Datenzugriff. Gleichzeitig können die Nutzer steuern, wo die Nachrichten gespeichert werden. Aufgrund des globalen Datenzugriffs mit Cloud Pub/Sub wissen die Publisher- und Abonnentenclients nicht, wo sich die Server befinden, zu denen sie eine Verbindung herstellen, oder auf welcher Route die Daten von den Diensten weitergeleitet werden.

Mit den Load Balancing-Mechanismen von Pub/Sub wird der Traffic des Publishers zum nächstgelegenen Google Cloud-Rechenzentrum mit zugelassener Datenspeicherung geleitet, wie im Abschnitt Beschränkung von Ressourcenstandorten in der Konsole „IAM und Verwaltung“ definiert. So können Publisher aus mehreren Regionen Nachrichten zu einem Thema veröffentlichen und profitieren dabei von niedriger Latenz. Jede einzelne Nachricht wird in genau einer Region gespeichert. Themen können jedoch Nachrichten umfassen, die in mehreren Regionen gespeichert sind. Fordert ein Abonnentenclient Nachrichten an, die zu einem solchen Thema veröffentlicht wurden, wird eine Verbindung zum nächstgelegenen Server hergestellt, der Daten aus allen zum Thema veröffentlichten Nachrichten aggregiert, um sie dem Client zuzustellen.

Pub/Sub setzt sich aus zwei Hauptbestandteilen zusammen: der Datenebene, auf der Nachrichten zwischen Publishern und Abonnenten verschoben werden, und der Steuerungsebene, die die Zuordnung von Publishern und Abonnenten zu Servern auf der Datenebene übernimmt. Die Server auf der Datenebene werden als Forwarder, die Server auf der Steuerungsebene als Router bezeichnet. Wenn Publisher und Abonnenten mit ihren zugewiesenen Forwardern verbunden sind, brauchen sie keine Informationen von den Routern (wenn diese Forwarder zugänglich bleiben). Daher ist es möglich, ein Upgrade der Steuerungsebene von Pub/Sub ohne Auswirkungen auf die Clients durchzuführen, die bereits verbunden sind und Nachrichten senden oder empfangen.

Steuerungsebene

Über die Steuerungsebene von Pub/Sub werden Clients so auf Forwarder verteilt, dass Skalierbarkeit, Verfügbarkeit und geringe Latenz für alle Clients gewährleistet sind. Jeder Forwarder kann Clients für beliebige Themen oder Abos einsetzen. Wenn ein Client eine Verbindung zu Pub/Sub herstellt, bestimmt der Router die Rechenzentren, zu denen die Verbindung hergestellt werden soll. Zu diesem Zweck verwendet er die kürzeste Netzwerkdistanz, eine Messung der Latenz der Verbindung zwischen zwei Punkten. Innerhalb eines Rechenzentrums versucht der Router, die Gesamtlast auf die verfügbaren Forwarder zu verteilen. Der Router muss zwei verschiedene Ziele in Einklang bringen, wenn diese Zuweisung durchgeführt wird: (a) Einheitlichkeit der Last (d. h. idealerweise ist jeder Forwarder gleich ausgelastet) und (b) die Stabilität der Zuweisungen (d. h. idealerweise werden durch eine Änderung der Last oder der verfügbaren Forwarder möglichst wenige der vorhandenen Zuweisungen angepasst). Der Router verwendet eine Variante der konsistenten Hash-Technologie, die von Google Research entwickelt wurde, um Konsistenz und Einheitlichkeit optimal abstimmen zu können. Der Router stellt für den Client eine geordnete Liste von Forwardern bereit, mit denen er sich verbinden kann. Diese geordnete Liste kann sich entsprechend der Verfügbarkeit des Forwarders und der Art der Last vom Client ändern.

Ein Client stellt anhand dieser Liste von Forwardern die Verbindung mit einem oder mehreren von ihnen her. Der Client bevorzugt dabei die Verbindung mit denjenigen Forwardern, die am häufigsten vom Router empfohlen werden, aber er bezieht auch aufgetretene Fehler mit ein. Zum Beispiel könnte er entscheiden, Forwarder in einem anderen Rechenzentrum einzusetzen, wenn mehrere Versuche mit den nächstgelegenen fehlgeschlagen sind. Um Pub/Sub-Clients von diesen Implementierungsdetails zu entziehen, gibt es einen Dienstproxy zwischen den Clients und Forwardern, der diese Verbindungsoptimierung im Namen der Clients durchführt.

Datenebene: Die verschiedenen Phasen einer Nachricht

Die Datenebene empfängt Nachrichten von Publishern und sendet sie an Clients. Wenn Sie die Datenebene von Pub/Sub besser verstehen möchten, sehen Sie sich die verschiedenen Phasen einer Nachricht an, vom Empfang durch den Dienst bis zu dem Zeitpunkt, zu dem sie den Dienst verlässt. Dazu verfolgen wir die Phasen bei der Verarbeitung einer Nachricht. Wie in diesem Abschnitt beschrieben, gehen wir davon aus, dass mit dem Thema, zu dem die Nachricht veröffentlicht wird, mindestens ein Abo verbunden ist. Allgemein durchläuft eine Nachricht die folgenden Phasen:

  1. Ein Publisher sendet eine Nachricht.

  2. Die Nachricht wird gespeichert.

  3. Pub/Sub bestätigt dem Publisher, dass die Nachricht empfangen wurde, und garantiert ihre Zustellung an alle zugehörigen Abos.

  4. Die Zustellung an die Abonnenten erfolgt, während die Nachricht in den Speicher geschrieben wird.

  5. Die Abonnenten senden Pub/Sub eine Bestätigung über die Verarbeitung der Nachricht.

  6. Nachdem mindestens ein Abonnent für jedes Abo die Nachricht bestätigt hat, wird sie von Pub/Sub aus dem Speicher gelöscht.

Zuerst sendet ein Publisher eine Nachricht zu einem Thema an Pub/Sub. Sie wird durch den Proxylayer verschlüsselt und an einen Forwarder gesendet, mit dem der Publisher verbunden ist. Um die sichere Zustellung der Nachricht zu gewährleisten, wird sie sofort gespeichert. Der Forwarder schreibt die Nachricht zunächst in N Cluster (wobei N eine ungerade Zahl ist) und die Nachricht gilt als dauerhaft, wenn sie mindestens in ⌈N/2⌉ geschrieben wurde. Nachdem eine Nachricht gespeichert wurde, bestätigt der Publishing-Forwarder dem Publisher den Erhalt der Nachricht. Daraufhin garantiert Pub/Sub, dass die Nachricht an alle verbundenen Abonnements gesendet wird.

In jedem Cluster wird die Nachricht auf M unabhängige Datenträger geschrieben (wobei M eine ungerade Zahl ist) und die Daten müssen sich auf ⌈M/2⌉ Datenträgern befinden, bevor sie in diesem Cluster als dauerhaft gelten. Insgesamt wird jede veröffentlichte Nachricht auf mindestens ⌈M/2⌉ unabhängige Datenträger in ⌈N/2⌉ Clustern geschrieben, bis sie als persistent gilt und schließlich auf N*M Laufwerken repliziert wird.

Der Publishing-Forwarder hat eine Liste aller Abonnenten, die mit einem Thema verbunden sind. Er hat die Aufgabe, die veröffentlichten Nachrichten und die Metadaten zu speichern, mit denen die Nachrichten beschrieben werden, die von jedem Abo bestätigt werden. Die Reihe der von einem Publishing-Forwarder zu einem bestimmten Thema erhaltenen und gespeicherten Nachrichten wird zusammen mit dieser Erfassung bestätigter Nachrichten als Publish-Nachrichtenquelle bezeichnet. Entsprechend den Durchsatzanforderungen für das Thema kann ein einzelner Publisher seine Nachrichten an mehrere Publishing-Forwarder senden und Nachrichten in mehreren Publish-Nachrichtenquellen speichern. Verschiedene Publisher für ein Thema können auch Nachrichten an unterschiedliche Publishing-Forwarder senden. Jede Nachricht wird nur an einen einzelnen Publishing-Forwarder gesendet. Pub/Sub stimmt die Anzahl der Publishing-Forwarder, die Nachrichten für ein bestimmtes Thema erhalten, dynamisch mit dem sich ändernden Durchsatz ab.

Abonnenten erhalten Nachrichten, indem sie sich mit abonnierenden Forwardern verbinden, also mit Forwardern, durch die Nachrichten von Publishern an Abonnenten weitergeleitet werden. "Verbinden" bedeutet im Fall eines Pull-Abonnenten "Stellen einer Pull-Anfrage". "Verbinden" bedeutet im Fall eines Push-Abonnenten, dass der Push-Endpunkt bei Pub/Sub registriert ist. Wenn ein Abo erstellt wird, ist garantiert, dass jede danach veröffentlichte Nachricht an dieses Abo gesendet wird. Dies wird als Sync-Point-Garantie bezeichnet.

Jeder Abo-Forwarder muss Nachrichten von Publishing-Forwardern anfordern, die veröffentlichte Nachrichtenquellen für das Thema haben. Wie Publisher können sich Abonnenten mit mehreren abonnierenden Forwardern verbinden, um Nachrichten zu erhalten. Auf diese Weise muss nicht jeder abonnierende Forwarder Nachrichten von jeder Publishing-Nachrichtenquelle für ein Thema kennen oder empfangen, eine wichtige Eigenschaft für die horizontale Skalierung von Pub/Sub. Je nach Durchsatz von Nachrichten, die an Abonnenten zugestellt werden, passt Pub/Sub die Anzahl der Abo-Forwarder dynamisch an, über die Abonnenten Nachrichten zu einem bestimmten Thema erhalten, wenn sich der Durchsatz ändert.

Ein Abo-Forwarder stellt Anfragen bei einem oder mehreren Publishing-Forwardern, die Publish-Nachrichtenquellen für ein Thema enthalten, um die erforderlichen Nachrichten anzufordern. Der Publishing-Forwarder sendet die unbestätigten Nachrichten an den Abo-Forwarder, der die Nachrichten dann an einen Abonnenten weiterleitet.

Wenn ein Abonnent eine Nachricht verarbeitet, sendet er eine Bestätigung zurück an den Abo-Forwarder. Der Abonnent-Forwarder leitet diese Bestätigung an den Publishing-Forwarder weiter, der die Bestätigung in der Publish-Nachrichtenquelle speichert. Wenn alle Abos eines Themas eine Nachricht bestätigt haben, wird die Nachricht asynchron aus der Publish-Nachrichtenquelle und aus dem Speicher gelöscht.

Unterschiedliche Nachrichten für ein Thema und ein Abo können über viele Publisher, Abonnenten, Publisher-Forwarder und Abo-Forwarder gesendet werden. Publisher können gleichzeitig mehrere Forwarder veröffentlichen und Abonnenten können eine Verbindung zu mehreren abonnierenden Forwardern herstellen, um Nachrichten zu empfangen. Daher kann der Nachrichtenfluss über Verbindungen zwischen Publishern, Abonnenten und Forwardern komplex sein. Das folgende Diagramm zeigt, wie Nachrichten für ein einzelnes Thema und ein einzelnes Abo weitergeleitet werden können, wobei unterschiedliche Farben angeben, wie Nachrichten von Publishern zu Abonnenten verlaufen können:

Nachrichten von mehreren Publishern werden durch Veröffentlichungen und Abo-Forwarder an Abonnenten weitergeleitet.

Pub/Sub am Laufen halten

Es sind ein hohes Maß an Transparenz und Steuerung des Systems erforderlich, damit ein verteiltes System wie Pub/Sub unterbrechungsfrei ausgeführt und allen Kunden eine zuverlässige Verwendung ermöglicht wird. Für die Aufrechterhaltung des Dienstes sind unsere Site Reliability Engineers (SREs) zuständig. Für Pub/Sub sind diese Entwickler weltweit an mehreren Standorten tätig, um eine Abdeckung rund um die Uhr zu gewährleisten.

Umgebungen

Der erste Teil der Verwaltung eines Systems wie Pub/Sub ist die Fähigkeit, Software zu testen, bevor sie von Kunden verwendet wird. Dazu gibt es drei Pub/Sub-Umgebungen: Test, Staging und Produktion. In "Test" und "Staging" findet kein Kundendatenverkehr statt; hier finden nur unsere ständig laufenden Tests und Überwachungen statt, die uns helfen, Problemen mit Releases auf die Spur zu kommen. Diese Umgebungen enthalten neue Releases der Software vor der Produktion. Der Unterschied zwischen "Test" und "Staging" besteht darin, dass "Staging" eine genaue Kopie des derzeit (oder demnächst) vorhandenen Inhalts der Produktionsumgebung ist, einschließlich Softwareversion und Befehlszeilen-Flags. Für "Test" können Merkmale aktiviert sein, an denen Entwickler derzeit noch arbeiten und die für einen späteren Zeitpunkt zur Veröffentlichung geplant sind.

Einführung

Das Verfahren zum Einführen und Testen von Pub/Sub wurde entwickelt, um mögliche Auswirkungen zu minimieren. Das sind typischerweise die Schritte für die Einführung einer neuen Pub/Sub-Version:

  1. Dafür sorgen, dass alle Unit- und Integrationstests bestanden werden.

  2. Eine neue Version aller Server erstellen.

  3. Die neuen Server für die Test- und Staging-Umgebungen bereitstellen.

  4. Die Server mehrere Tage lang in der Test- und Staging-Umgebung betreiben.

  5. Wenn keine Probleme bekannt sind, die Server für Canary freigeben, einen Teilbereich der Produktionsumgebung mit geringerem Kundendatenverkehr.

  6. Wenn in Canary keine Probleme erkannt werden, im Lauf mehrere Tage die Server für einen größeren Produktionsbereich einführen, bis sie überall freigegeben sind.

Pub/Sub ist für minimale Störungsanfälligkeit ausgelegt, z. B. ist die Einführung neuer Versionen von Servern durch die Trennung der Steuerungs- und Datenebene für Kunden unterbrechungsfrei und sollte keine Auswirkung auf die sichtbare Leistung haben.

Monitoring

Für eine unterbrechungsfreie Ausführung von Pub/Sub wird gesorgt, indem Probleme erkannt und minimiert werden, bevor sie für den Endnutzer sichtbar sind. Hierfür muss das System gründlich überwacht werden. Das Site Reliability Engineering-Team (SRE) verwaltet eine Reihe von Service Level Indicators (SLIs). Hierbei handelt es sich um präzise definierte Messwerte, mit denen das Verhalten des Systems beschrieben wird. Zu den Messwerten gehören beispielsweise die „Zeit, die zum Erstellen einer CreateSubscription-Anfrage erforderlich ist“ oder die „Rate der von Publish-Anfragen generierten Fehler“. Diese Messwerte werden auf unterschiedliche Weise erfasst. Einige von ihnen sind ausschließlich intern für unsere Forwarder und Router gedacht. Zum Beispiel wird mit ihnen gemessen, wie lange das Speichern von Nachrichten dauert.

Alle diese Maßnahmen helfen dabei, interne Service Level Objectives (SLOs) zu definieren, also spezifische Ziele für die SLIs. Beispiel: „Eine CreateSubscription-Anfrage sollte maximal fünf Sekunden dauern.“ SREs werden bei SLO-Verstößen benachrichtigt und müssen Benachrichtigungen innerhalb von fünf Minuten bearbeiten.

In einem Service Level Agreement (SLA) werden die SLOs aufgeführt, die unsere Leistungsgarantien gegenüber unseren Endnutzern sowie die Konsequenzen definieren, wenn wir diese nicht erfüllen. Sie können das SLA für Pub/Sub hier nachlesen.

Wir pflegen eine Reihe von Clients, die regelmäßig veröffentlichen und abonnieren. Diese werden als Sondierungsfragen bezeichnet. Prober gibt es für die Datenebene und die Steuerungsebene. Mit jedem unserer Probierer werden spezielle Aktionen genau wie von Kunden durchgeführt und es wird gemessen, wie lange die Vorgänge dauern. Wir haben beispielsweise einen Prober, mit dem ein neues Abo erstellt, eine Nachricht veröffentlicht und geprüft wird, wie lange es dauert, das Abo zu erstellen und die Nachricht zu empfangen. Wenn die Prober feststellen, dass ein oder mehrere der gemessenen Messwerte nicht so sind wie erwartet, werden SREs benachrichtigt.

Die Messwerte für unsere Server und Prober sind auf mehreren internen Dashboards zusammengefasst, wo die SREs zuerst nachsehen, wenn sie potenzielle Probleme untersuchen. Diese Seiten bieten schnellen Zugriff auf Statistiken und Diagramme des gesamten Dienstes. Sie können auch nach Thema, Rechenzentrum oder Einzelaufgabe aufgeteilt werden.

Die Messwerte, die für Nutzer des Dienstes am interessantesten sind, werden über Google Cloud Monitoring angegeben.

Einstellungen

Sie haben mehrere Möglichkeiten, um die Leistung von Pub/Sub zu beeinflussen. Einige dieser Steuermöglichkeiten sind als Hilfen bei Ausfällen von Rechenzentren oder Geräten konzipiert. Wir können Routing-Beschränkungen für ein Thema oder alle Themen festlegen. Dies sind Regeln, durch die Gruppen von Clients festgelegt werden, die Verbindungen mit verschiedenen Forwardern herstellen können (oder nicht können). Wir nutzen Beschränkungen, um Datenverkehr von einzelnen Forwarder-Aufgaben oder ganzen Rechenzentren abzuziehen, die nicht wie erwartet funktionieren.

Eine weitere einstellbare Funktion ist die Ablaufsteuerung. Mithilfe dieser Funktion können wir den Durchsatz maximieren und gleichzeitig Überlastungen im Dienst vermeiden. Ablaufsteuerung ist eine Form der Regelung des Datenverkehrs, durch die plötzliche Spitzenlasten im Lauf der Zeit ausgeglichen werden können, um mehr Stabilität des Dienstes zu erreichen. Ablaufsteuerung wirkt sich systemweit oder pro Abonnent aus und soll die Zahl der Nachrichten oder Bytes beschränken, die übertragen werden oder noch offen sind. In diesem Fall bedeutet "offen", dass an den Kunden gesendet, aber noch nicht bestätigt wurde. Sowohl die Ablaufsteuerung als auch die Routing-Beschränkungen ermöglichen die Optimierung der Leistung von Pub/Sub, ohne dass sich Kunden um diese Details kümmern müssen.

Fazit

Die Vorteile bei der Skalierbarkeit, Verfügbarkeit und Latenz eines Dienstes wie Pub/Sub definieren das Wertversprechen für Kunden, die zu verwalteten Clouddiensten wechseln möchten. Ein asynchroner Messaging-Dienst muss von Anfang an auf diese Eigenschaften hin entwickelt werden. Mit mehr als einem Jahrzehnt Erfahrung bei der zuverlässigen und schnellen Zustellung vieler Nachrichten hat das Pub/Sub-Team einen Dienst entwickelt und verwaltet, der den Anforderungen der wichtigsten Produkte von Google gerecht wird. Jetzt ist dieser Dienst für alle externen Kunden verfügbar, die ihre Nachrichten weltweit senden möchten, ohne sich darum kümmern zu müssen, ob ihr Messaging-System das Doppelte, Zehnfache oder Hundertfache ihrer aktuellen Auslastung bewältigen kann.

Glossar

Begriff Beschreibung
Cluster Eine logische Gruppierung von Geräten, die normalerweise zu einem gemeinsamen Ausfallbereich gehören (z. B. gemeinsam verwendetes lokales Netzwerk und gemeinsame Stromversorgung).
Steuerungsebene Der Bereich von Pub/Sub, in dem die Zuweisung von Publishern und Abonnenten zu Servern auf der Datenebene abgewickelt wird.
Datenebene Der Bereich von Pub/Sub, in dem Nachrichten zwischen Publishern und Abonnenten gesendet werden.
Forwarder Ein Server in der Datenebene.
Globaler Datenzugriff Pub/Sub-Publisher sowie Abonnenten-Clients wissen nicht, wo sich die Daten befinden. Routing und Speicherung werden vom Dienst selbst durchgeführt und entsprechen der Richtlinie zur Standortbeschränkung.
Horizontal skalierbar Die Fähigkeit des Dienstes, nahtlos eine größere Auslastung zu bewältigen, indem die Zahl der Instanzen von Komponenten des Dienstes erhöht wird.
message Die Daten, die durch Pub/Sub geleitet werden.
Netzwerkdistanz Eine Maßzahl der Latenz der Verbindung zwischen zwei Punkten.
Prober Eine Aufgabe, die als Client fungiert und vorhersehbar eine oder mehrere Aktionen auf den Pub/Sub-Servern ausführt.
Publisher-Nachrichtenquelle Eine Reihe von Nachrichten, die von einem Publishing-Forwarder empfangen und gespeichert werden, und die Reihe der IDs von Nachrichten, die durch alle angehängten Abonnenten bestätigt wurden.
Dienst zum Veröffentlichen/Abonnieren (Pub/Sub Service) Ein Messaging-Dienst, bei dem die Absender von Nachrichten von den Empfängern entkoppelt werden
Publisher Ein Client von Pub/Sub, der Nachrichten erstellt und zu einem bestimmten Thema sendet (veröffentlicht).
Router Ein Server auf der Steuerungsebene.
Routing-Beschränkungen Eine Liste von Regeln, durch die angegeben wird, welche Forwarder als mögliche Endpunkte für Verbindungen durch Router an Clients gesendet werden sollen.
Service Level Agreement (SLA) Eine Liste der SLOs, mit denen die Leistungsgarantien eines Systems an Kunden definiert und die Folgen bei Nichterfüllung angegeben werden.
Service Level Indicator (SLI) Ein wohldefinierter Messwert, mit dem das Verhalten des Systems beschrieben wird.
Service Level Objective (SLO) Eine spezielle Zielvorgabe für einen SLI.
Abonnent Ein Client von Pub/Sub, der Nachrichten zu einem bestimmten Abo erhält.
Abo Eine benannte Entität, die für ein Interesse am Erhalt aller Nachrichten zu einem bestimmten Thema steht.
Sync-Point-Garantie Der Zeitpunkt, zu dem ein Abo erstellt wird und alle nachfolgend veröffentlichten Nachrichten an die Abonnenten gesendet werden.
Thema Eine benannte Entität, die für einen Feed von Nachrichten steht.