Panoramica del servizio Pub/Sub

Pub/Sub è un servizio di pubblicazione/sottoscrizione (Pub/Sub), un servizio di messaggistica in cui i mittenti dei messaggi vengono disaccoppiati dai destinatari dei messaggi. Esistono diversi concetti chiave in un servizio Pub/Sub, che vengono 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 messaggi e li invia (pubblica) al servizio di messaggistica su un argomento specificato.

  • Messaggio: i dati che si spostano 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 l'interesse a ricevere messaggi su un argomento specifico.

  • Sottoscrittore (chiamato anche consumer): riceve messaggi su una sottoscrizione specificata.

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

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

  2. L'argomento stesso è collegato a due sottoscrizioni. Si tratta di Sottoscrizione 1 e Sottoscrizione 2.

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

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

  5. Sottoscrizione 1 è collegata a due applicazioni sottoscrittore, Sottoscrittore 1 e Sottoscrittore 2. Le due applicazioni sottoscrittore ricevono un sottoinsieme dei messaggi dall'argomento. In questo esempio, Sottoscrittore 1 riceve il messaggio B mentre Sottoscrittore 2 riceve il messaggio A dall'argomento.

  6. Sottoscrizione 2 è collegata solo a una singola applicazione sottoscrittore chiamata Sottoscrittore 3. Pertanto, Sottoscrittore 3 riceve tutti i messaggi dall'argomento.

Durata di un messaggio

Supponiamo che un singolo client publisher sia connesso a un argomento. L'argomento ha una sola sottoscrizione collegata. Un singolo sottoscrittore è connesso alla sottoscrizione.

Figura che mostra il flusso di un messaggio all'interno di Pub/Sub.
Figura 2 Un messaggio passa da un client publisher a un client sottoscrittore tramite Pub/Sub.

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

  1. Un'applicazione 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 collegate dell'argomento.

    In questo esempio, si tratta di una singola sottoscrizione.

  4. La sottoscrizione invia il messaggio a un'applicazione sottoscrittore collegata.

  5. Il sottoscrittore invia a Pub/Sub una conferma di ricezione che indica di aver elaborato il messaggio.

    Dopo che almeno un sottoscrittore per ogni sottoscrizione ha confermato il messaggio, Pub/Sub lo elimina dallo spazio di archiviazione.

Stato di un messaggio in Pub/Sub

Mentre un messaggio è in attesa di essere ricevuto da un sottoscrittore, Pub/Sub non tenta di recapitarlo a nessun altro sottoscrittore della stessa sottoscrizione. Il sottoscrittore ha un periodo di tempo configurabile e limitato, noto come ackDeadline, per confermare il messaggio in attesa. Una volta superata la scadenza, il messaggio non viene più considerato in attesa ed è di nuovo disponibile per la consegna.

Un messaggio in un servizio Pub/Sub può avere tre stati:

  • Messaggi confermati (acked). Dopo che un'applicazione sottoscrittore elabora un messaggio inviato da un argomento a una sottoscrizione, invia una conferma di ricezione 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 (unacked). Se Pub/Sub non riceve una conferma di ricezione entro la scadenza, un messaggio potrebbe essere recapitato più di una volta. Ad esempio, il sottoscrittore potrebbe inviare una conferma di ricezione dopo la scadenza o la conferma di ricezione 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 dei messaggi dalla data di pubblicazione. A questo punto, il messaggio scade.

  • Messaggi con conferma di ricezione negativa (nacked). Se un sottoscrittore invia una conferma di ricezione negativa per un messaggio, Pub/Sub lo recapita immediatamente in base alle impostazioni di nuovi tentativi predefinite, che possono essere modificate. Quando un sottoscrittore invia una conferma di ricezione negativa per i messaggi non validi o quando non riesce a elaborarli, il sottoscrittore contribuisce a garantire che questi messaggi non vadano persi e che vengano elaborati correttamente. Puoi utilizzare modifyAckDeadline con un valore di 0 per inviare una conferma di ricezione negativa per un messaggio.

Scegliere un pattern di pubblicazione e sottoscrizione Pub/Sub

Quando sono presenti più client publisher e sottoscrittore Pub/Sub, devi anche scegliere il tipo di architettura di pubblicazione e sottoscrizione che vuoi configurare.

Figura che mostra diversi pattern di pubblicazione e iscrizione.
Figura 3 Le relazioni publisher-sottoscrittore possono essere many-to-one (fan-in), many-to-many (con bilanciamento del carico) e one-to-many (fan-out).

Di seguito sono riportati alcuni dei pattern di pubblicazione-sottoscrizione Pub/Sub supportati:

  • Fan-in (many-to-one). In questo esempio, più applicazioni publisher pubblicano messaggi in un singolo argomento. Questo singolo argomento è collegato a una singola sottoscrizione. La sottoscrizione, a sua volta, è collegata a una singola applicazione sottoscrittore che riceve tutti i messaggi pubblicati nell'argomento.

  • Con bilanciamento del carico (many-to-many). In questo esempio, una o più applicazioni publisher pubblicano messaggi in un singolo argomento. Questo singolo argomento è collegato a una singola sottoscrizione che, a sua volta, è collegata a più applicazioni sottoscrittore. Ogni applicazione sottoscrittore riceve un sottoinsieme dei messaggi pubblicati e non esistono due applicazioni sottoscrittore che ricevono 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, aggiungi altri sottoscrittori per ricevere messaggi dalla stessa sottoscrizione.

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

Scegliere un'opzione di configurazione Pub/Sub

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

  • Google Cloud Console
  • 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 tuo caso d'uso.

Se non hai familiarità con la Google Cloud console e vuoi testare Pub/Sub, utilizza la console o il gcloud CLI.

La libreria client di alto livello è consigliata nei casi in cui sono richiesti un throughput elevato e una latenza ridotta con un sovraccarico operativo e un costo 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 del throughput e della latenza, la formattazione dei messaggi e altre funzionalità.

La libreria client di basso livello è una libreria gRPC generata automaticamente e viene utilizzata quando utilizzi direttamente le API di servizio.

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

  • Scegliere il linguaggio della libreria client corretto. Le prestazioni delle librerie client Pub/Sub variano in base alla lingua. Ad esempio, la libreria client Java è più efficace per lo scale up verticale rispetto alla libreria client Python e può gestire un throughput maggiore. Java, C++ e Go sono linguaggi più efficienti in termini di risorse di calcolo necessarie per gestire i carichi di pubblicazione o sottoscrizione.

  • Utilizzare 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.

  • Riutilizzare i client publisher. Quando pubblichi messaggi, è più efficiente riutilizzare lo stesso client publisher anziché crearne di nuovi 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 publisher 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:

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

  2. Abilita l'API Pub/Sub.

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

  4. Crea un argomento.

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

  6. Collega lo schema all'argomento.

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

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

  9. Scegli un tipo di sottoscrizione in base alla modalità di ricezione dei messaggi.

  10. Crea una sottoscrizione per l'argomento scelto.

  11. Configura un client sottoscrittore in grado di ricevere messaggi dalla sottoscrizione.

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

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

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

Linee guida per denominare 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 rispettare il seguente formato:

projects/project-identifier/collection/ID

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

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

  • ID: deve rispettare le seguenti linee guida:

    • Non iniziare con la stringa goog
    • Iniziare 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 effettui chiamate REST.

Passaggi successivi