Panoramica del servizio Pub/Sub

Pub/Sub è un servizio publish/subscribe (Pub/Sub), un servizio di messaggistica in cui i mittenti dei messaggi vengono disaccoppiati dai destinatari dei messaggi. In un servizio Pub/Sub sono disponibili diversi concetti chiave, spiegati con l'aiuto della figura seguente.

Figura che mostra i diversi componenti di un servizio Pub/Sub e il modo in cui si connettono tra loro.
Figura 1 Due client publisher inviano due messaggi diversi a un argomento Pub/Sub comune.

Di seguito sono riportati i componenti di un servizio Pub/Sub:

  • Publisher (chiamato anche producer): crea i messaggi e li invia (li pubblica) al servizio di messaggistica su un argomento specificato.

  • Messaggio: i dati trasferiti attraverso il 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.

  • Sottoscrizione: un'entità denominata che rappresenta un interesse a ricevere messaggi su un determinato argomento.

  • Abbonato (detto anche consumer): riceve i messaggi di un abbonamento specificato.

La procedura seguente illustra il flusso di lavoro del servizio Pub/Sub:

  1. Due applicazioni del publisher, Publisher 1 e Publisher 2, inviano messaggi a un singolo argomento Pub/Sub. L'Editore 1 invia il messaggio A e l'Editore 2 invia il messaggio B.

  2. L'argomento è associato a due sottoscrizioni. Sono Abbonamento 1 e Abbonamento 2.

  3. L'argomento è collegato anche a uno schema.

  4. Ogni sottoscrizione riceve una copia dei messaggi A e B dall'argomento.

  5. L'Abbonamento 1 è collegato a due applicazioni dell'abbonato, Abbonato 1 e Abbonato 2. Le due applicazioni dell'abbonato ricevono un sottoinsieme dei messaggi dall'argomento. In questo esempio, il sottoscrittore 1 riceve il messaggio B, mentre il sottoscrittore 2 riceve il messaggio A dall'argomento.

  6. L'abbonamento 2 è collegato soltanto a una singola applicazione dell'abbonato denominata Abbonato 3. Pertanto, il Sottoscrittore 3 riceve tutti i messaggi dall'argomento.

Ciclo di vita di un messaggio in Pub/Sub

Supponi che un singolo client publisher sia collegato a un argomento. All'argomento è associato un singolo abbonamento. Un singolo abbonato è collegato all'abbonamento.

Figura che mostra il flusso di un messaggio all'interno di Pub/Sub.
Figura 2 Un messaggio passa dal client di un editore a un client abbonato attraverso Pub/Sub.

I passaggi seguenti descrivono il flusso di un messaggio in Pub/Sub:

  1. Un'applicazione del publisher invia un messaggio a un argomento Pub/Sub.

  2. Il messaggio viene scritto nello spazio di archiviazione.

  3. Oltre a scrivere il messaggio nello spazio di archiviazione, Pub/Sub lo recapita a tutte le sottoscrizioni allegate all'argomento.

    In questo esempio, si tratta di un abbonamento singolo.

  4. L'abbonamento invia il messaggio a un'applicazione dell'abbonato allegata.

  5. Il sottoscrittore invia a Pub/Sub una conferma di elaborazione del messaggio.

    Dopo che almeno un sottoscrittore per ogni sottoscrizione ha confermato il messaggio, Pub/Sub elimina il messaggio dall'archiviazione.

Stato di un messaggio in Pub/Sub

Mentre un messaggio è in sospeso per un sottoscrittore, Pub/Sub tenta di non recapitarlo a nessun altro sottoscrittore nella stessa sottoscrizione. Il sottoscrittore ha un periodo di tempo configurabile e limitato, noto come ackDeadline, per confermare il messaggio in sospeso. Una volta trascorsa la scadenza, il messaggio non è più considerato in sospeso e Pub/Sub tenta di recapitarlo.

In un servizio Pub/Sub possono esistere tre stati per un messaggio:

  • Messaggi confermati (con ACK). Dopo che un'applicazione sottoscrittore elabora un messaggio inviato da un argomento a una sottoscrizione, invia una conferma di conferma a Pub/Sub. Se tutte le sottoscrizioni di un argomento hanno confermato il messaggio, questo viene eliminato in modo asincrono dall'origine del messaggio di pubblicazione e dallo spazio di archiviazione.

  • Messaggi non confermati (non segnalati). Se Pub/Sub non riceve un riscontro entro la scadenza di conferma, un messaggio potrebbe essere recapitato più di una volta. Ad esempio, il sottoscrittore potrebbe inviare una conferma dopo la scadenza della scadenza o la conferma potrebbe andare persa a causa di problemi di rete temporanei. Un messaggio non confermato continua a essere recapitato fino alla scadenza del periodo di conservazione del messaggio dalla sua pubblicazione. A questo punto, il messaggio scade.

  • Messaggi con conferma negativa (nascosto). Se un messaggio viene eliminato da un sottoscrittore, Pub/Sub lo consegna immediatamente. Quando un sottoscrittore nasconde i messaggi non validi o non è in grado di elaborare i messaggi, contribuisce a garantire che questi messaggi non vengano persi e che alla fine vengano elaborati correttamente. Puoi utilizzare modifyAckDeadline con un valore pari a 0 per aggiungere un messaggio.

Scegli un pattern di pubblicazione e sottoscrizione Pub/Sub

Quando ci sono più client di editori e abbonati, devi anche scegliere il tipo di architettura di pubblicazione e sottoscrizione che vuoi configurare.

Figura che mostra diversi modelli di pubblicazione e sottoscrizione.
Figura 3 Le relazioni tra publisher e sottoscrittori possono essere many-to-one (fan-in), many-to-many (bilanciati del carico) e one-to-many (fan-out).

Alcuni dei pattern di sottoscrizione di pubblicazione Pub/Sub supportati includono quanto segue:

  • Fan-in (many-to-one). In questo esempio, più applicazioni di editori pubblicano messaggi in un singolo argomento. Questo singolo argomento è associato a un'unica sottoscrizione. La sottoscrizione è, a sua volta, collegata a un'applicazione di un singolo abbonato che riceve tutti i messaggi pubblicati dall'argomento.

  • Carico bilanciato (many-to-many). In questo esempio, una o più applicazioni dell'editore pubblicano messaggi in un singolo argomento. Questo singolo argomento è collegato a un singolo abbonamento che a sua volta è collegato a più applicazioni dell'abbonato. Ogni applicazione del sottoscrittore riceve un sottoinsieme dei messaggi pubblicati e nessuna delle applicazioni del sottoscrittore riceve lo stesso sottoinsieme di messaggi. In questo caso di bilanciamento del carico, utilizzi più sottoscritti per elaborare i messaggi su larga scala. Se è necessario supportare più messaggi, aggiungi altri sottoscrittori per ricevere i messaggi dallo stesso abbonamento.

  • Fan out (one-to-many). In questo esempio, una o più applicazioni dell'editore pubblicano messaggi in un singolo argomento. Questo singolo argomento è associato a più abbonamenti. Ogni abbonamento è connesso a una singola applicazione dell'abbonato. Ogni applicazione dell'abbonato riceve lo stesso insieme di messaggi pubblicati dall'argomento. Quando un argomento ha più sottoscrizioni, ogni messaggio deve essere inviato a un sottoscrittore che ne riceve messaggi per conto di ogni abbonamento. Se devi eseguire diverse operazioni sui dati sullo stesso insieme di messaggi, il fan-out è un'opzione valida. Puoi anche collegare più sottoscrittori a ogni sottoscrizione e ottenere un sottoinsieme di messaggi con bilanciamento del carico per ogni sottoscrittore.

Scegli un'opzione di configurazione Pub/Sub

Puoi configurare un ambiente Pub/Sub utilizzando una qualsiasi delle seguenti opzioni:

  • Console Google Cloud
  • Google Cloud CLI
  • Librerie client di Cloud (libreria client di alto livello)
  • API REST e RPC (libreria client di basso livello)

La scelta di un'opzione di configurazione Pub/Sub dipende dal 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 richieste velocità effettiva elevata e bassa latenza con overhead 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 generata automaticamente ed entra in gioco quando utilizzi direttamente le API di servizio.

Di seguito sono riportate alcune best practice per l'utilizzo delle librerie client:

  • Scegliere la lingua giusta della libreria client. Le prestazioni delle librerie client di Pub/Sub variano in base al linguaggio. Ad esempio, la libreria client Java è più efficace nello scale up verticalmente rispetto alla libreria client Python, ed è in grado di gestire una velocità effettiva superiore. Java, C++ e Go sono linguaggi più efficienti in termini di risorse di calcolo necessarie per gestire i carichi di pubblicazione o sottoscrizione.

  • Utilizza la versione più recente della libreria client. Le librerie client di 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 clienti degli editori. Durante la pubblicazione dei messaggi, è più efficiente riutilizzare lo stesso client editore invece di creare nuovi client editore per ogni richiesta di pubblicazione. Questo perché la prima richiesta di pubblicazione dopo la creazione di un nuovo client editore 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 principali per configurare Pub/Sub:

  1. Crea o scegli un progetto Google Cloud in cui configurare Pub/Sub.

  2. Abilita l'API Pub/Sub.

  3. Ottieni le autorizzazioni e i ruoli richiesti per eseguire Pub/Sub.

  4. Crea un argomento.

  5. Se la struttura dei messaggi è critica, definisci uno schema per i tuoi messaggi.

  6. Allega lo schema all'argomento.

  7. Configura un client editore in grado di pubblicare messaggi nell'argomento.

  8. Se necessario, configura opzioni di pubblicazione avanzate come il controllo dei flussi, la messaggistica batch e il controllo della contemporaneità.

  9. Scegli un tipo di sottoscrizione in base a come vuoi ricevere i messaggi.

  10. Crea una sottoscrizione per l'argomento scelto.

  11. Configura un client abbonato che può ricevere messaggi dalla sottoscrizione.

  12. Se necessario, configura le opzioni avanzate di consegna dei messaggi, come la consegna "exactly-once", la gestione dei lease, la consegna ordinata e il controllo del flusso.

  13. Inizia a pubblicare messaggi dal tuo client publisher nell'argomento.

  14. Contemporaneamente, configura il client abbonato per ricevere ed elaborare questi messaggi.

Linee guida per assegnare un nome a un argomento, una sottoscrizione, uno schema o uno snapshot

Il nome di una 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 rientrare nel formato seguente:

projects/project-identifier/collection/ID

  • project-identifier: deve essere l'ID o il numero del progetto, disponibile nella console Google Cloud. Ad esempio, my-cool-project è un ID progetto. 123456789123 è un numero di progetto.

  • collection: deve essere topics, subscriptions, schemas o snapshots.

  • ID: deve essere conforme alle seguenti linee guida:

    • Non iniziare con la stringa goog
    • Inizia con una lettera
    • Contenere tra 3 e 255 caratteri
    • Contenere solo i seguenti caratteri: lettere [A-Za-z], numeri [0-9], trattini -, trattini bassi _, punti ., tilde ~, più segni + e segni di percentuale %

    Puoi utilizzare i caratteri speciali dell'elenco precedente nei nomi delle risorse senza codifica URL. Tuttavia, devi assicurarti che tutti gli altri caratteri speciali vengano 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 si effettuano chiamate REST.

Passaggi successivi