Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Modello Pub/sub
Quando una piattaforma cresce, può essere difficile per diversi microservizi interagire senza creare interdipendenza. Il pattern pubblicazione/sottoscrizione (pub/sub) fornisce una comunicazione asincrona tra moltepliciAWSservizi, ad esempio Amazon SQS, Lambda o Amazon Simple Storage Service (Amazon S3), senza creare interdipendenza. In questo schema, i microservizi pubblicano eventi come messaggi in un canale che gli abbonati possono ascoltare. Ad esempio, una fabbrica può utilizzare un pattern pub/sub per consentire alle apparecchiature di pubblicare problemi o guasti su un canale, un abbonato può quindi visualizzare e registrare questi problemi relativi all'apparecchiatura.
Dovresti considerare l'utilizzo di questo modello se:
-
Hai un'architettura basata sugli eventi.
-
È possibile abilitare l'architettura abbinata liberamente.
-
Non è necessario completare tutte le parti operative di una transazione prima della risposta al sistema chiamante (alcune operazioni possono essere asincrone).
-
È necessario scalare i volumi che vanno oltre la capacità di un data center tradizionale. Questo livello di scalabilità è dovuto principalmente a operazioni parallele, memorizzazione nella cache dei messaggi, routing basato su albero e altre funzionalità integrate nel modello pub/sub.
Ci sono diversi svantaggi nell'utilizzo di questo modello. Ad esempio, il pattern pub/sub in genere non può garantire la consegna di messaggi a tutti i tipi di abbonati, sebbene alcuni servizi come Amazon Simple Notification Service (Amazon SNS) possano fornireesattamente una voltaconsegna ad alcuni sottoscrittori. Un altro svantaggio è che un editore potrebbe presumere che un abbonato stia ascoltando un canale quando, di fatto, non lo sono.
Caso d'uso
In questo caso d'uso, un argomento SNS viene utilizzato per pubblicare eventi su diversi microservizi dipendenti in un sistema assicurativo. Dopo che un cliente ha effettuato il pagamento mensile, le informazioni devono essere aggiornate in sottosistemi come «Cliente» o «Vendite» e un'e-mail deve essere inviata al cliente con la conferma del pagamento. Questo modello può essere implementato utilizzando Amazon SNS o Amazon EventBridge.
EventBridge filtra gli eventi tra più abbonati. L'implementazione EventBridge offre le due seguenti due opzioni:
-
Invia tre eventi con diversi tipi di eventi. Il target distante li raccoglie in base alla regola dell'evento.
-
Invia un messaggio con tre regole evento in ascolto dello stesso tipo di evento. I dati non necessari vengono filtrati prima che vengano richiamati obiettivi specifici.
Implementazione Amazon SNS
La seguente illustrazione mostra come Amazon SNS viene utilizzato per implementare il pattern pub/sub. Dopo che un utente ha effettuato un pagamento, viene inviato un messaggio SNS tramite la funzione Lambda «Pagamenti» all'argomento SNS «Pagamenti». Questo argomento SNS contiene tre abbonati che ricevono una copia del messaggio e lo elaborano.
Implementazione Amazon EventBridge
Nella figura seguente, EventBridge viene utilizzato per creare una versione del pattern pub/sub in cui gli abbonati sono definiti utilizzando le regole degli eventi. Dopo che un utente ha effettuato un pagamento, la funzione Lambda «Pagamenti» invia un messaggio a EventBridge utilizzando il bus eventi predefinito basato su uno schema personalizzato con tre regole diverse che puntano a target diversi. Ogni microservizio elabora i messaggi ed esegue le azioni richieste.
