Pub/Sub è un servizio pub/sub (pubblica/abbonati), un servizio di messaggistica in cui i mittenti dei messaggi vengono disaccoppiati dai destinatari. Un servizio Pub/Sub include diversi concetti chiave, illustrati con l'aiuto della figura seguente.
Di seguito sono riportati i componenti di un servizio Pub/Sub:
Publisher (chiamato anche producer): crea messaggi e li invia (pubblica) al servizio di messaggistica in base a un argomento specificato.
Messaggio: i dati che si spostano all'interno del servizio.
Argomento: un'entità denominata che rappresenta un feed di messaggi.
Schema: un'entità denominata che regola il formato dei dati di un messaggio Pub/Sub.
Abbonamento: un'entità denominata che rappresenta l'interesse a ricevere messaggi su un determinato argomento.
Abbonato (chiamato anche consumatore): riceve i messaggi su una sottoscrizione specificata.
La procedura riportata di seguito illustra il flusso di lavoro del servizio Pub/Sub:
Due applicazioni publisher, Publisher 1 e Publisher 2, inviano messaggi a un singolo argomento Pub/Sub. Il publisher 1 invia il messaggio A e il publisher 2 invia il messaggio B.
L'argomento stesso è collegato a due abbonamenti. Si tratta di Abbonamento 1 e Abbonamento 2.
L'argomento è inoltre associato a uno schema.
Ogni sottoscrizione riceve una copia dei messaggi A e B dall'argomento.
L'abbonamento 1 è collegato a due applicazioni di abbonati, Abbonato 1 e Abbonato 2. Le due applicazioni sottoscrittore ricevono un sottoinsieme di messaggi dall'argomento. In questo esempio, l'abbonato 1 riceve il messaggio B, mentre l'abbonato 2 riceve il messaggio A dall'argomento.
L'abbonamento 2 è collegato a una sola applicazione Abbonato chiamata Abbonato 3. Di conseguenza, Abbonato 3 riceve tutti i messaggi dall'argomento.
Ciclo di vita di un messaggio
Supponiamo che un singolo client editore sia collegato a un argomento. All'argomento è associata una singola sottoscrizione. Un singolo abbonato è collegato all'abbonamento.
I passaggi riportati di seguito descrivono il flusso di un messaggio in Pub/Sub:
Un'applicazione publisher invia un messaggio a un argomento Pub/Sub.
Il messaggio viene scritto nello spazio di archiviazione.
Oltre a scrivere il messaggio nello spazio di archiviazione, Pub/Sub lo consegna a tutte le sottoscrizioni collegate dell'argomento.
In questo esempio, si tratta di una singola sottoscrizione.
La sottoscrizione invia il messaggio a un'applicazione del sottoscrittore collegata.
Il sottoscrittore invia a Pub/Sub un ACK per indicare che ha elaborato il messaggio.
Dopo che almeno un sottoscrittore per ogni sottoscrizione ha confermato il messaggio, Pub/Sub lo elimina dall'archiviazione.
Stato di un messaggio in Pub/Sub
Mentre un messaggio è in attesa per un sottoscrittore, Pub/Sub non tenta di consegnarlo a nessun altro sottoscrittore della stessa sottoscrizione. Il sottoscrittore ha un periodo di tempo limitato e configurabile, noto come ackDeadline, per confermare il messaggio in sospeso. Una volta trascorsa la scadenza, il messaggio non viene più considerato in sospeso ed è di nuovo disponibile per la consegna.
Un messaggio in un servizio Pub/Sub può avere tre stati:
Messaggi confermati (ACK). Dopo che un'applicazione del sottoscrittore elabora un messaggio inviato da un argomento a una sottoscrizione, invia un messaggio di conferma a Pub/Sub. Se tutte le iscrizioni a un argomento hanno confermato il messaggio, questo viene eliminato in modo asincrono dall'origine messaggio di pubblicazione e dall'archiviazione.
Messaggi non confermati (unacked). Se Pub/Sub non riceve un conferma entro la scadenza, un messaggio potrebbe essere recapitato più volte. Ad esempio, l'abbonato potrebbe inviare un messaggio di conferma dopo la scadenza o il messaggio potrebbe andare perso a causa di problemi temporanei della rete. Un messaggio non confermato continua a essere recapitato fino alla scadenza del tempo di conservazione dei messaggi dalla data di pubblicazione. A questo punto, il messaggio scade.
Messaggi con ack negativo (nacked). Se un sottoscrittore esegue il nack di un messaggio, Pub/Sub lo riconsegna immediatamente. Quando un sottoscrittore ignora i messaggi non validi o non riesce a elaborarli, contribuisce a garantire che questi messaggi non vadano persi e che vengano eventualmente elaborati correttamente. Puoi utilizzare modifyAckDeadline con un valore pari a 0 per ignorare un messaggio.
Scegliere un pattern di pubblicazione e sottoscrizione Pub/Sub
Quando sono presenti più client Pub/Sub publisher e subscriber, devi anche scegliere il tipo di architettura di pubblicazione e sottoscrizione che vuoi configurare.
Alcuni dei pattern di pubblicazione e sottoscrizione Pub/Sub supportati includono quanto segue:
Fan in (many-to-one). In questo esempio, più applicazioni di publisher pubblicano messaggi in un unico argomento. Questo singolo argomento è collegato a una singola sottoscrizione. La sottoscrizione è a sua volta collegata a un'unica applicazione del sottoscrittore che riceve tutti i messaggi pubblicati dall'argomento.
Con bilanciamento del carico (many-to-many). In questo esempio, una o più applicazioni di publisher pubblicano messaggi in un singolo argomento. Questo singolo argomento è collegato a una singola sottoscrizione che, a sua volta, è collegata a più applicazioni del sottoscrittore. Ciascuna delle applicazioni di abbonamento riceve un sottoinsieme di messaggi pubblicati e nessuna delle applicazioni di abbonamento riceve lo stesso sottoinsieme di messaggi. In questo caso di bilanciamento del carico, utilizzi più sottoscrittori per elaborare i messaggi su larga scala. Se è necessario supportare più messaggi, puoi aggiungere altri abbonati che riceveranno i messaggi dallo stesso abbonamento.
Espansione (da uno a molti). In questo esempio, una o più applicazioni publisher pubblicano messaggi in un singolo argomento. Questo singolo argomento è collegato a più iscrizioni. Ogni abbonamento è collegato a una singola applicazione di abbonamento. Ciascuna delle applicazioni degli abbonati riceve lo stesso insieme di messaggi pubblicati dall'argomento. Quando un argomento ha più iscrizioni, ogni messaggio deve essere inviato a un sottoscrittore che riceve i messaggi per conto di ogni sottoscrizione. Se devi eseguire operazioni di dati diverse sullo stesso insieme di messaggi, la distribuzione a ventaglio è una buona opzione. Puoi anche associare più sottoscrittori a ogni sottoscrizione e ottenere un sottoinsieme di messaggi bilanciato in base al carico per ogni sottoscrittore.
Scegliere un'opzione di configurazione Pub/Sub
Puoi configurare un ambiente Pub/Sub utilizzando una delle seguenti opzioni:
- Console Google Cloud
- Google Cloud CLI
- Librerie client di Cloud (libreria client di alto livello)
- API REST ed RPC (libreria client di basso livello)
La scelta di un'opzione di configurazione di Pub/Sub dipende dal tuo caso d'uso.
Se non hai mai utilizzato la console Google Cloud e vuoi testare Pub/Sub, utilizza la console o gcloud CLI.
La libreria client di alto livello è consigliata per i casi in cui sono necessari throughput elevato e latenza ridotta con un sovraccarico operativo e costi di elaborazione minimi. Per impostazione predefinita, la libreria client di alto livello utilizza l'API StreamingPull. Le librerie client di alto livello contengono funzioni e classi predefinite che gestiscono le chiamate API sottostanti per l'autenticazione, l'ottimizzazione della velocità effettiva e della latenza, la formattazione dei messaggi e altre funzionalità.
La libreria client di basso livello è una libreria gRPC autogenerata e viene utilizzata quando utilizzi direttamente le API di servizio.
Per utilizzare le librerie client di alto livello, consulta Librerie client Pub/Sub.
Per utilizzare direttamente le librerie client di basso livello generate automaticamente, consulta la panoramica delle API Pub/Sub.
Di seguito sono riportate alcune best practice per l'utilizzo delle librerie client:
Scegli la lingua della libreria client corretta. Le prestazioni delle librerie client Pub/Sub variano in base al linguaggio. Ad esempio, la libreria client Java è più efficace nell'eseguire l'upgrade verticale rispetto alla libreria client Python e può gestire una maggiore velocità in uscita. Java, C++ e Go sono linguaggi più efficienti in termini di risorse di calcolo necessarie per gestire i caricamenti di pubblicazione o abbonamento.
Utilizza la versione più recente della libreria client. Le librerie client Pub/Sub vengono costantemente aggiornate con nuove funzionalità e correzioni di bug. Assicurati di utilizzare la versione più recente della libreria client per la tua lingua.
Riutilizza i client del publisher. Quando pubblichi i messaggi, è più efficiente riutilizzare lo stesso client publisher anziché creare nuovi client publisher per ogni richiesta di pubblicazione. Questo perché la prima richiesta di pubblicazione dopo la creazione di un nuovo client publisher richiede un po' di tempo per stabilire una connessione autorizzata. In alcuni linguaggi, come Node, che non hanno un client editore esplicito, riutilizza l'oggetto su cui chiami il metodo di pubblicazione. Ad esempio, in Node, salva e riutilizza l'oggetto argomento.
Come configurare Pub/Sub
Ecco i passaggi di primo livello per configurare Pub/Sub:
Crea o scegli un progetto Google Cloud in cui puoi configurare Pub/Sub.
Abilita l'API Pub/Sub.
Ottieni i ruoli e le autorizzazioni richiesti per eseguire Pub/Sub.
Crea un argomento.
Se la struttura del messaggio è fondamentale, definisci uno schema per i messaggi.
Collega lo schema all'argomento.
Configura un client publisher che possa pubblicare messaggi nell'argomento.
Se necessario, configura le opzioni di pubblicazione avanzate come il controllo del flusso, i messaggi batch e controllo della contemporaneità.
Scegli un tipo di sottoscrizione in base alla modalità di ricezione dei messaggi.
Crea una sottoscrizione per l'argomento scelto.
Configura un client sottoscrittore che possa ricevere messaggi dalla sottoscrizione.
Se necessario, configura opzioni avanzate di recapito dei messaggi, come la consegna esattamente una volta, la gestione dei lease, la consegna ordinata e il controllo del flusso.
Inizia a pubblicare messaggi dal tuo client publisher nell'argomento.
Contemporaneamente, configura il client sottoscrittore in modo che riceva ed elabori questi messaggi.
Linee guida per assegnare un nome a un argomento, una sottoscrizione, uno schema o uno snapshot
Un nome risorsa Pub/Sub identifica in modo univoco una risorsa Pub/Sub, ad esempio un argomento, una sottoscrizione, uno schema o uno snapshot. Il nome della risorsa deve avere il seguente formato:
projects/project-identifier/collection/ID
project-identifier: deve essere l'ID progetto o il numero progetto, disponibile nella console Google Cloud. Ad esempio,my-cool-projectè un ID progetto.123456789123è un numero di progetto.collection: deve essere uno tratopics,subscriptions,schemasosnapshots.ID: deve essere conforme alle seguenti linee guida:- Non deve iniziare con la stringa
goog - Inizia con una lettera
- Contenere da 3 a 255 caratteri
- Contenere solo i seguenti caratteri: lettere
[A-Za-z], numeri[0-9], trattini-, trattini bassi_, punti., tildi~, segni più+e segni di percentuale%
Puoi utilizzare i caratteri speciali nell'elenco precedente nei nomi delle risorse senza codifica URL. Tuttavia, devi assicurarti che tutti gli altri caratteri speciali siano codificati o decodificati correttamente quando li utilizzi negli URL. Ad esempio,
mi-tópicoè un ID non valido. Tuttavia,mi-t%C3%B3picoè valido. Questo formato è importante quando esegui chiamate REST.- Non deve iniziare con la stringa
Passaggi successivi
Per iniziare a configurare Pub/Sub utilizzando gcloud CLI, consulta Guida rapida: pubblica e ricevi messaggi in Pub/Sub utilizzando gcloud CLI.
Per iniziare a configurare Pub/Sub utilizzando la console Google Cloud, consulta Guida rapida: pubblicare e ricevere messaggi in Pub/Sub utilizzando la console Google Cloud.
Per iniziare a configurare Pub/Sub utilizzando le librerie client, consulta Guida rapida: pubblica e ricevi messaggi in Pub/Sub utilizzando la libreria client.