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/Sub-Muster
Wenn eine Plattform wächst, kann es für verschiedene Microservices schwierig sein, miteinander zu interagieren, ohne dass eine gegenseitige Abhängigkeit entsteht. Das Musterpublish/subscribe (pub/sub) ermöglicht asynchrone Kommunikation zwischen mehreren AWS Diensten wie Amazon SQS, Lambda oder Amazon Simple Storage Service (Amazon S3), ohne dass eine gegenseitige Abhängigkeit entsteht. In diesem Muster veröffentlichen Microservices Ereignisse als Nachrichten in einem Kanal, die Abonnenten abhören können. Beispielsweise kann eine Fabrik ein Pub/Sub-Muster verwenden, damit Geräte Probleme oder Ausfälle auf einem Kanal veröffentlichen können. Ein Abonnent kann diese Geräteprobleme dann anzeigen und protokollieren.
Sie sollten in Betracht ziehen, dieses Muster zu verwenden, wenn:
-
Sie haben eine ereignisgesteuerte Architektur.
-
Sie können eine lose gekoppelte Architektur aktivieren.
-
Sie müssen nicht alle operativen Teile einer Transaktion abschließen, bevor die Antwort an das aufrufende System zurückgesendet wird (bestimmte Operationen können asynchron sein).
-
Sie müssen auf Volumen skalieren, die die Möglichkeiten eines herkömmlichen Rechenzentrums übersteigen. Dieses Maß an Skalierbarkeit ist hauptsächlich auf parallel Operationen, Nachrichtenzwischenspeicherung, 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 in der Regel nicht garantieren, dass Nachrichten an alle Abonnententypen zugestellt werden, obwohl bestimmte Dienste wie Amazon Simple Notification Service (Amazon SNS) einigen Abonnenten-Untergruppen eine exakte Einmalzustellung ermöglichen können. Ein weiterer Nachteil besteht darin, dass ein Publisher davon ausgehen könnte, dass ein Abonnent einen Kanal anhört, obwohl dies in Wirklichkeit nicht der Fall ist.
Anwendungsfall
In diesem Anwendungsfall wird ein SNS-Thema verwendet, um Ereignisse in mehreren voneinander 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 „Vertrieb“ aktualisiert werden, und es muss eine E-Mail mit der Zahlungsbestätigung an den Kunden gesendet werden. Dieses Muster kann entweder mithilfe von Amazon SNS oder Amazon EventBridge implementiert werden.
EventBridge filtert Ereignisse zwischen mehreren Abonnenten. Die EventBridge Implementierung bietet die folgenden zwei Optionen:
-
Senden Sie drei Ereignisse mit unterschiedlichen Ereignistypen. Das entfernte Ziel nimmt sie auf der Grundlage der Ereignisregel auf.
-
Senden Sie eine Nachricht mit drei Ereignisregeln, die denselben Ereignistyp berücksichtigen. Unnötige Daten werden herausgefiltert, bevor bestimmte Ziele aufgerufen werden.
Implementierung von Amazon SNS
Die folgende Abbildung zeigt, wie Amazon SNS zur Implementierung des Pub/Sub-Musters verwendet wird. Nachdem ein Benutzer eine Zahlung getätigt 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 diese verarbeiten.
EventBridge Amazon-Implementierung
In der folgenden Abbildung EventBridge wird verwendet, um eine Version des Pub/Sub-Musters zu erstellen, in dem Abonnenten mithilfe von Ereignisregeln definiert werden. Nachdem ein Benutzer eine Zahlung getätigt hat, sendet die Lambda-Funktion „Zahlungen“ eine Nachricht an, EventBridge indem sie den Standard-Event-Bus verwendet, der auf einem benutzerdefinierten Schema basiert, das drei verschiedene Regeln hat, die auf unterschiedliche Ziele verweisen. Jeder Microservice verarbeitet die Nachrichten und führt die erforderlichen Aktionen aus.
