Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Pub-/Submuster
Wenn eine Plattform wächst, kann es für verschiedene Microservices schwierig sein, zu interagieren, ohne gegenseitige Abhängigkeit zu erzeugen. Das Publish/Abonnieren (Pub/Sub) -Muster bietet asynchrone Kommunikation zwischen mehrerenAWSDienste wie Amazon SQS, Lambda oder Amazon Simple Storage Service (Amazon S3), ohne Interdependenz zu schaffen. In diesem Muster veröffentlichen Microservices Ereignisse als Nachrichten in einem Kanal, den Abonnenten anhören können. Beispielsweise kann eine Fabrik ein Pub/Untermuster verwenden, um Geräten die Veröffentlichung von Problemen oder Fehlern in einem Kanal zu ermöglichen. Ein Abonnent kann dann diese Geräteprobleme anzeigen und protokollieren.
Sie sollten dieses Muster in Betracht ziehen, wenn:
-
Sie haben eine ereignisgesteuerte Architektur.
-
Sie können lose gekoppelte Architektur aktivieren.
-
Sie müssen nicht alle betrieblichen Teile einer Transaktion abschließen, bevor Sie auf das aufrufende System zurückkehren (bestimmte Vorgänge können asynchron sein).
-
Sie müssen auf Volumes skalieren, die über die Fähigkeit eines herkömmlichen Rechenzentrums hinausgehen. Diese Skalierbarkeit ist hauptsächlich auf parallele Operationen, Nachrichten-Caching, baumbasiertes Routing und andere Funktionen zurückzuführen, die in das Pub/Sub-Modell integriert sind.
Die Verwendung dieses Musters hat mehrere Nachteile. Beispielsweise kann das Pub/Sub-Muster normalerweise die Zustellung von Nachrichten an alle Abonnententypen nicht garantieren, obwohl bestimmte Dienste wie Amazon Simple Notification Service (Amazon SNS) bereitstellen könnengenau einmaligLieferung an einige Teilmengen des Abonnenten. Ein weiterer Nachteil ist, dass ein Herausgeber davon ausgehen könnte, dass ein Abonnent einen Kanal hört, wenn dies tatsächlich nicht der Fall ist.
Anwendungsfall
In diesem Anwendungsfall wird ein SNS-Thema verwendet, um Ereignisse auf mehreren abhängigen Microservices in einem Versicherungssystem zu veröffentlichen. Nachdem ein Kunde seine monatliche Zahlung geleistet hat, müssen die Informationen in Subsystemen wie „Kunde“ oder „Verkauf“ aktualisiert werden, und eine E-Mail muss mit der Zahlungsbestätigung an den Kunden gesendet werden. Dieses Muster kann entweder mit Amazon SNS oder Amazon EventBridge implementiert werden.
EventBridge filtert Ereignisse zwischen mehreren Abonnenten. Die EventBridge-Implementierung bietet die folgenden zwei Optionen:
-
Senden Sie drei Events mit verschiedenen Ereignistypen. Das entfernte Ziel nimmt sie basierend auf der Ereignisregel auf.
-
Senden Sie eine Nachricht mit drei Ereignisregeln, die denselben Ereignistyp hören. Unnötige Daten werden herausgefiltert, bevor bestimmte Ziele aufgerufen werden.
Amazon SNS SNS-Implementierung
Die folgende Abbildung zeigt, wie Amazon SNS zur Implementierung des Pub/Sub-Musters verwendet wird. Nachdem ein Benutzer eine Zahlung geleistet hat, wird von der Lambda-Funktion „Zahlungen“ eine SNS-Nachricht an das SNS-Thema „Zahlungen“ gesendet. Dieses SNS-Thema hat drei Abonnenten, die eine Kopie der Nachricht erhalten und verarbeiten.
Amazon EventBridge EventBridge-Implementierung
In der folgenden Abbildung wird EventBridge verwendet, um eine Version des Pub/Sub-Musters zu erstellen, in dem Abonnenten mithilfe von Ereignisregeln definiert werden. Nachdem ein Benutzer eine Zahlung geleistet hat, sendet die Lambda-Funktion „Zahlungen“ eine Nachricht an EventBridge, indem er den Standardereignisbus verwendet, der auf einem benutzerdefinierten Schema basiert, das drei verschiedene Regeln enthält, die auf verschiedene Ziele verweisen. Jeder Microservice verarbeitet die Nachrichten und führt die erforderlichen Aktionen aus.
