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à.
# Schema di pubblicazione-sottoscrizione
## Intento
Il modello di pubblicazione-sottoscrizione, noto anche come modello pub-sub, è un modello di messaggistica che separa il mittente del messaggio (*editore*) dai destinatari interessati (*sottoscrittori*). Questo modello implementa comunicazioni asincrone pubblicando messaggi o eventi tramite un intermediario noto come *broker di messaggi* o *router* (infrastruttura di messaggi). Il modello di pubblicazione-sottoscrizione aumenta la scalabilità e la reattività dei mittenti, scaricando la responsabilità del recapito dei messaggi sull'infrastruttura dei messaggi in modo che il mittente possa concentrarsi sull'elaborazione principale dei messaggi.
## Motivazione
Nelle architetture distribuite, i componenti del sistema spesso devono fornire informazioni ad altri componenti man mano che si verificano eventi all'interno del sistema. Lo schema di pubblicazione-sottoscrizione separa le preoccupazioni in modo che le applicazioni possano concentrarsi sulle proprie funzionalità principali mentre l'infrastruttura dei messaggi gestisce le responsabilità di comunicazione come il routing dei messaggi e la consegna affidabile. Il modello di pubblicazione-sottoscrizione consente la messaggistica asincrona per separare editore e sottoscrittori. Gli editori possono anche inviare messaggi all'insaputa dei sottoscrittori.
## Applicabilità
Utilizza il modello di pubblicazione-sottoscrizione quando:
+ È necessaria un'elaborazione parallela se un singolo messaggio ha flussi di lavoro diversi.
+ Non sono richieste la trasmissione di messaggi a più sottoscrittori e le risposte in tempo reale da parte dei destinatari.
+ Il sistema o l'applicazione possono tollerare l'eventuale coerenza dei dati o dello stato.
+ L'applicazione o il componente deve comunicare con altre applicazioni o servizi che potrebbero utilizzare linguaggi, protocolli o piattaforme diversi.
## Problemi e considerazioni
+ **Disponibilità dei sottoscrittori:** l'editore non sa se i sottoscrittori stanno ascoltando e, in effetti, potrebbero non ascoltare. I messaggi pubblicati sono di natura temporanea e possono essere eliminati se i sottoscrittori non sono disponibili.
+ **Garanzia di consegna dei messaggi:** in genere, il modello di pubblicazione-sottoscrizione non può garantire la consegna dei messaggi a tutti i tipi di sottoscrittori, sebbene alcuni servizi come Amazon Simple Notification Service (Amazon SNS) possano garantire la consegna [una sola volta](https://docs.aws.amazon.com/sns/latest/dg/fifo-message-dedup.html) ad alcuni sottoinsiemi di sottoscrittori.
+ **Time to live (TTL):** i messaggi hanno una durata e scadono se non vengono elaborati entro il periodo di tempo. Valuta la possibilità di aggiungere i messaggi pubblicati a una coda in modo che possano persistere e garantisci l'elaborazione oltre il periodo TTL.
+ **Pertinenza del messaggio:** i producer possono impostare un intervallo di tempo per la pertinenza come parte dei dati del messaggio e il messaggio può essere eliminato dopo tale data. Valuta la possibilità di invitare i consumer a esaminare queste informazioni prima di decidere come elaborare il messaggio.
+ **Coerenza finale:** c'è un ritardo tra il momento in cui il messaggio viene pubblicato e il momento in cui viene utilizzato dall'abbonato. Ciò potrebbe far sì che i datastore dei sottoscrittori diventino alla fine coerenti quando è richiesta una forte coerenza. L'eventuale coerenza potrebbe essere un problema anche quando producer e consumer richiedono un'interazione quasi in tempo reale.
+ **Comunicazione unidirezionale:** il modello di pubblicazione-sottoscrizione è considerato unidirezionale. Le applicazioni che richiedono la messaggistica bidirezionale con un canale di sottoscrizione di ritorno dovrebbero prendere in considerazione l'utilizzo di uno schema di richiesta-risposta se è richiesta una risposta sincrona.
+ **Ordine dei messaggi:** l'ordine dei messaggi non è garantito. Se i consumatori richiedono messaggi ordinati, ti consigliamo di utilizzare gli [argomenti FIFO di Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/fifo-topic-message-ordering.html) per garantire l'ordine.
+ **Duplicazione dei messaggi:** in base all'infrastruttura di messaggistica, è possibile recapitare messaggi duplicati ai consumer. I consumer devono essere progettati per essere idempotenti nel gestire l'elaborazione di messaggi duplicati. In alternativa, utilizza gli [argomenti FIFO di Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/fifo-topic-message-ordering.html) per garantire la consegna esattamente una volta.
+ **Filtro dei messaggi:** i consumer sono spesso interessati solo a un sottoinsieme dei messaggi pubblicati da un producer. Fornisci meccanismi per consentire agli abbonati di filtrare o limitare i messaggi che ricevono fornendo argomenti o filtri di contenuto.
+ **Riproduzione dei messaggi:** le funzionalità di riproduzione dei messaggi potrebbero dipendere dall'infrastruttura di messaggistica. È inoltre possibile fornire implementazioni personalizzate a seconda del caso d'uso.
+ **Code DLQ:** in un sistema postale, un ufficio DL è una struttura per l'elaborazione della posta non recapitabile. Nella [messaggistica pub/sub](https://aws.amazon.com/pub-sub-messaging/), una coda DLQ è una coda per i messaggi che non possono essere recapitati a un endpoint sottoscritto.
## Implementazione
### Architettura di alto livello
In un modello di pubblicazione/sottoscrizione, il sottosistema di messaggistica asincrono noto come broker di messaggi o router tiene traccia delle sottoscrizioni. Quando un producer pubblica un evento, l'infrastruttura di messaggistica invia un messaggio a ciascun consumer. Dopo che un messaggio è stato inviato agli abbonati, viene rimosso dall'infrastruttura dei messaggi in modo che non possa essere riprodotto e i nuovi abbonati non possano visualizzare l'evento. I broker di messaggi o i router separano il produttore di eventi dai consumer di messaggi in base a:
+ Fornire al producer un canale di input per pubblicare eventi raggruppati in messaggi, utilizzando un formato di messaggio definito.
+ Creazione di un singolo canale di output per sottoscrizione. Una *sottoscrizione* è la connessione del consumer, tramite la quale ascolta i messaggi relativi agli eventi associati a un canale di input specifico.
+ Copia dei messaggi dal canale di input al canale di output per tutti i consumer quando l'evento viene pubblicato.
![\[copia dei messaggi dal canale di ingresso a quello di uscita.\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/cloud-design-patterns/images/publish-subscribe-1.png)
### Implementazione tramite servizi AWS
**Amazon SNS**
Amazon SNS è un servizio editore-abbonato completamente gestito che fornisce messaggi application-to-application (A2A) per disaccoppiare le applicazioni distribuite. Fornisce inoltre messaggi application-to-person (A2P) per l'invio di SMS, e-mail e altre notifiche push.
Amazon SNS offre due tipi di argomenti: standard e FIFO (first in, first out).
+ Gli argomenti standard supportano un numero illimitato di messaggi al secondo e forniscono il massimo livello di ordinamento e deduplicazione.
![\[Argomenti standard in Amazon SNS.\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/cloud-design-patterns/images/publish-subscribe-2.png)
+ Gli argomenti FIFO forniscono un ordinamento e una deduplicazione rigorosi e supportano fino a 300 messaggi al secondo o 10 MB al secondo per argomento FIFO (a seconda di quale evento si verifica per primo).
![\[Argomenti FIFO in Amazon SNS\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/cloud-design-patterns/images/publish-subscribe-3.png)
L'illustrazione seguente mostra come utilizzare Amazon SNS per implementare il modello di pubblicazione-sottoscrizione. Dopo che un utente ha effettuato un pagamento, la funzione Lambda `Payments` invia un messaggio SNS all'argomento SNS `Payments`. Questo argomento SNS ha tre sottoscrittori. Ogni sottoscrittore riceve una copia del messaggio e la elabora.
![\[Come usare Amazon EventBridge per implementare il modello di pubblicazione-sottoscrizione.\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/cloud-design-patterns/images/publish-subscribe-4.png)
**Amazon EventBridge**
Puoi usare Amazon EventBridge quando hai bisogno di un instradamento più complesso dei messaggi da più produttori attraverso protocolli diversi verso i consumatori abbonati o abbonamenti diretti e fan-out. EventBridge supporta anche il routing, il filtraggio, il sequenziamento e la suddivisione o l'aggregazione basati sui contenuti. Nella figura seguente, EventBridge viene utilizzato per creare una versione del modello publish-subscribe in cui i sottoscrittori vengono definiti utilizzando le regole degli eventi. Dopo che un utente ha effettuato un pagamento, la funzione `Payments` Lambda invia un messaggio a EventBridge utilizzando il bus eventi predefinito basato su uno schema personalizzato con tre regole che puntano a destinazioni diverse. Ogni microservizio elabora i messaggi ed esegue le azioni richieste.
![\[Come usare Amazon per EventBridge implementare il modello di pubblicazione e sottoscrizione.\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/cloud-design-patterns/images/publish-subscribe-5.png)
### Workshop
+ [Creazione di architetture basate sugli eventi in AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/63320e83-6abc-493d-83d8-f822584fb3cb/en-US/)
+ [Invio di notifiche di eventi fanout utilizzando Amazon Simple Queue Service (Amazon SQS) e Amazon Simple Notification Service (Amazon SNS)](https://aws.amazon.com/getting-started/hands-on/send-fanout-event-notifications/)
## Riferimenti del blog
+ [Scelta tra servizi di messaggistica per applicazioni serverless](https://aws.amazon.com/blogs/compute/choosing-between-messaging-services-for-serverless-applications/)
+ [Progettazione di applicazioni serverless DLQs durevoli con Amazon SNS, Amazon SQS, AWS Lambda](https://aws.amazon.com/blogs/compute/designing-durable-serverless-apps-with-dlqs-for-amazon-sns-amazon-sqs-aws-lambda/)
+ [Semplifica la pub/sub messaggistica con il filtraggio dei messaggi di Amazon SNS](https://aws.amazon.com/blogs/compute/simplify-pubsub-messaging-with-amazon-sns-message-filtering/)
## Contenuti correlati
+ [Funzionalità della messaggistica pub/sub](https://aws.amazon.com/what-is/pub-sub-messaging/)