Publish-Subscribe-Muster

Absicht Motivation Anwendbarkeit Fehler und Überlegungen Implementierung Blog-Referenzen Verwandter Inhalt

Das Publish-Subscribe-Muster, das auch als Pub-Sub-Muster bekannt ist, ist ein Nachrichtenmuster, das einen Nachrichtensender (Publisher) von interessierten Empfängern (Subscriber) entkoppelt. Dieses Muster implementiert eine asynchrone Kommunikation durch die Veröffentlichung von Nachrichten oder Ereignissen über einen Vermittler, den so genannten Message Broker oder Router (Nachrichteninfrastruktur). Das Publish-Subscribe-Muster erhöht die Skalierbarkeit und Reaktionsfähigkeit für Absender, indem es die Verantwortung für die Nachrichtenzustellung an die Nachrichteninfrastruktur abgibt, so dass sich der Absender auf die eigentliche Nachrichtenverarbeitung konzentrieren kann.

In verteilten Architekturen müssen Systemkomponenten oft Informationen an andere Komponenten weitergeben, wenn Ereignisse innerhalb des Systems stattfinden. Das Publish-Subscribe-Muster trennt Belange, so dass sich Anwendungen auf ihre Kernfunktionen konzentrieren können, während die Nachrichteninfrastruktur Kommunikationsaufgaben wie das Routing von Nachrichten und die zuverlässige Zustellung übernimmt. Das Publish-Subscribe-Muster ermöglicht asynchrone Nachrichtenübermittlung, um Publisher und Subscriber zu entkoppeln. Publisher können Nachrichten auch ohne das Wissen der Subscriber versenden.

Verwenden Sie das Publish-Subscribe-Muster, wenn:

Parallele Verarbeitung erforderlich ist, wenn eine einzelne Nachricht Teil von unterschiedlichen Workflows ist.
Das Senden von Nachrichten an mehrere Subscriber und Antworten von Empfängern in Echtzeit nicht erforderlich sind.
Das System oder die Anwendung kann Ereigniskonsistenz für Daten oder Zustände tolerieren.
Die Anwendung oder Komponente muss mit anderen Anwendungen oder Services kommunizieren, die möglicherweise andere Sprachen, Protokolle oder Plattformen verwenden.

Subscriber-Verfügbarkeit: Der Publisher weiß nicht, ob die Subscriber Listener sind, und vielleicht sind sie das auch nicht. Veröffentlichte Nachrichten sind flüchtiger Natur und können verworfen werden, wenn die Subscriber nicht verfügbar sind.
Garantie für die Nachrichtenzustellung: In der Regel kann das Publish-Subscribe-Muster nicht die Zustellung von Nachrichten an alle Subscriber-Typen garantieren. Bestimmte Services wie Amazon Simple Notiﬁcation Service (Amazon SNS) können jedoch eine exactly-once Zustellung an bestimmte Subscriber-Gruppen gewährleisten.
Time to Live (TTL): Nachrichten haben eine Lebensdauer und laufen ab, wenn sie nicht innerhalb dieses Zeitraums verarbeitet werden. Erwägen Sie, die veröffentlichten Nachrichten einer Warteschlange hinzuzufügen, damit sie dauerhaft gespeichert werden können, und garantiert wird, dass sie auch nach Ablauf der TTL-Periode verarbeitet werden.
Nachrichtenrelevanz: Produzenten können als Teil der Nachrichtendaten eine Zeitspanne für die Relevanz festlegen, und die Nachricht kann nach diesem Datum verworfen werden. Erwägen Sie, die Verbraucher so zu gestalten, dass sie diese Informationen prüfen, bevor Sie entscheiden, wie die Nachricht verarbeitet werden soll.
Ereigniskonsistenz: Es gibt eine Verzögerung zwischen dem Zeitpunkt, an dem die Nachricht veröffentlicht wird, und dem Zeitpunkt, an dem sie vom Subscriber abgerufen wird. Dies kann dazu führen, dass die Subscriber-Datenspeicher mit der Zeit konsistent werden, wenn eine hohe Konsistenz erforderlich ist. Ereigniskonsistenz kann auch dann ein Problem sein, wenn Produzenten und Verbraucher nahezu in Echtzeit interagieren müssen.
Unidirektionale Kommunikation: Das Publish-Subscribe-Muster wird als unidirektional betrachtet. Anwendungen, die einen bidirektionalen Nachrichtenaustausch mit einem Rückkanal für Abonnements benötigen, sollten ein Anfrage-Antwort-Muster verwenden, wenn eine synchrone Antwort erforderlich ist.
Nachrichtenreihenfolge: Die Reihenfolge der Nachrichten ist nicht sichergestellt. Wenn Verbraucher sortierte Nachrichten benötigen, empfehlen wir Ihnen, Amazon-SNS-FIFO-Themen zu verwenden, um die Reihenfolge zu garantieren.
Vervielfältigung von Nachrichten: Je nach Nachrichteninfrastruktur können doppelte Nachrichten an Verbraucher zugestellt werden. Die Verbraucher müssen so konzipiert sein, dass sie für die Verarbeitung doppelter Nachrichten idempotent sind. Verwenden Sie alternativ Amazon-SNS-FIFO-Themen, um sicherzustellen, dass die Zustellung exakt einmal erfolgt.
Nachrichtenfilterung: Verbraucher sind oft nur an einer Teilmenge der von einem Produzenten veröffentlichten Nachrichten interessiert. Stellen Sie Mechanismen bereit, mit denen Subscriber die Nachrichten, die sie erhalten, filtern oder eingrenzen können, indem Sie Themen oder Inhaltsfilter angeben.
Nachrichtenwiedergabe: Die Funktionen zur Nachrichtenwiedergabe hängen möglicherweise von der Nachrichteninfrastruktur ab. Je nach Anwendungsfall können Sie auch benutzerdefinierte Implementierungen bereitstellen.
Warteschlangen für unzustellbare Nachrichten: In einem Postsystem ist ein Büro für unzustellbare Briefe eine Einrichtung zur Bearbeitung unzustellbarer Post. Im pub/sub-Messaging ist eine Warteschlange für unzustellbare Nachrichten eine Warteschlange für Nachrichten, die nicht an einen abonnierten Endpunkt gesendet werden können.

In einem Publish-Subscribe-Muster verfolgt das asynchrone Nachrichten-Subsystem, auch Message Broker oder Router genannt, die Abonnements. Wenn ein Produzent ein Ereignis veröffentlicht, sendet die Nachrichten-Infrastruktur eine Nachricht an jeden Verbraucher. Nachdem eine Nachricht an Subscriber gesendet wurde, wird sie aus der Nachrichteninfrastruktur entfernt, sodass sie nicht erneut abgespielt werden kann und neue Subscriber das Ereignis nicht sehen. Message Broker oder Router entkoppeln den Ereignisproduzenten von den Nachrichtenverbrauchern, indem sie:

Einen Eingangskanal für den Produzenten bereitstellen, um Ereignisse, die in Nachrichten verpackt sind, unter Verwendung eines definierten Nachrichtenformats zu veröffentlichen.
Erstellung eines individuellen Ausgabekanals pro Abonnement. Ein Abonnement ist die Verbindung des Verbrauchers, über die er auf Ereignisnachrichten wartet, die einem bestimmten Eingangskanal zugeordnet sind.
Kopieren von Nachrichten aus dem Eingabekanal in den Ausgabekanal für alle Verbraucher, wenn das Ereignis veröffentlicht wird.

Amazon SNS

Amazon SNS ist ein vollständig verwalteter Publisher-Subscriber-Service, der Application-to-Application-Messaging (A2A) bietet, um verteilte Anwendungen zu entkoppeln. Es bietet auch Application-to-Person (A2P)-Messaging für das Senden von SMS, E-Mail und anderen Push-Benachrichtigungen.

Amazon SNS bietet zwei Arten von Themen: Standard und First-in, First-Out-(FIFO).

Standardthemen unterstützen eine unbegrenzte Anzahl von Nachrichten pro Sekunde und bieten bestmögliche Sortierung und Deduplizierung.
FIFO-Themen bieten eine strikte Reihenfolge und Deduplizierung und unterstützen bis zu 300 Nachrichten pro Sekunde oder 10 MB pro Sekunde pro FIFO-Thema (je nachdem, was zuerst eintritt).

Die folgende Abbildung zeigt, wie Sie Amazon SNS verwenden können, um das Publish-Subscribe-Muster zu implementieren. Nachdem ein Benutzer eine Zahlung getätigt hat, wird von der Payments-Lambda-Funktion eine SNS-Nachricht an das Payments-SNS-Thema gesendet. Dieses SNS-Thema hat drei Subscriber. Jeder Subscriber erhält eine Kopie der Nachricht und verarbeitet sie.

Amazon EventBridge

Sie können Amazon EventBridge verwenden, wenn Sie eine komplexere Weiterleitung von Nachrichten von mehreren Produzenten über verschiedene Protokolle an abonnierte Verbraucher oder für Direkte- und Fanout-Abonnements benötigen. EventBridge unterstützt auch inhaltsbasiertes Routing, Filterung, Sequenzierung und Aufteilung oder Aggregation. In der folgenden Abbildung wird EventBridge verwendet, um eine Version des Publish-Subscribe-Musters zu erstellen, in dem Subscriber mithilfe von Ereignisregeln definiert werden. Nachdem ein Benutzer eine Zahlung getätigt hat, sendet die Payments-Lambda-Funktion eine Nachricht an EventBridge, indem sie den Standard-Event-Bus auf der Grundlage eines benutzerdefinierten Schemas verwendet, das drei Regeln enthält, die auf verschiedene Ziele verweisen. Jeder Microservice verarbeitet die Nachrichten und führt die erforderlichen Aktionen aus.