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 determinato argomento.

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

La seguente procedura 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. Questi sono Abbonamento 1 e Abbonamento 2.

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

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

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

  6. Abbonamento 2 è collegato solo a una singola applicazione per abbonati chiamata Abbonato 3. Pertanto, Subscriber 3 riceve tutti i messaggi dall'argomento.

Durata di un messaggio

Supponi che un singolo client editore sia connesso a un argomento. L'argomento ha una sola sottoscrizione collegata. Un solo abbonato è collegato all'abbonamento.

Figura che mostra il flusso di un messaggio all'interno di Pub/Sub.
Figura 2 Un messaggio scorre 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 nell'archiviazione, Pub/Sub lo recapita a tutte le sottoscrizioni associate all'argomento.

    In questo esempio, si tratta di un singolo abbonamento.

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

  5. Il sottoscrittore invia un riconoscimento a Pub/Sub per comunicare 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 consegnato a un sottoscrittore, Pub/Sub non tenta di consegnarlo 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 sospeso. Dopo 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 riconoscimento a Pub/Sub. Se tutte le sottoscrizioni di un argomento hanno riconosciuto il messaggio, quest'ultimo 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 entro la scadenza, un messaggio potrebbe essere recapitato più di una volta. Ad esempio, l'abbonato potrebbe inviare una conferma dopo la scadenza del termine 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 dei messaggi dalla pubblicazione. A questo punto, il messaggio scade.

  • Messaggi con riconoscimento negativo (NACK). Il mancato riconoscimento di un messaggio da parte di un sottoscrittore fa sì che Pub/Sub lo invii nuovamente immediatamente in base alle impostazioni di nuovi tentativi predefinite, che possono essere modificate. Quando un abbonato invia un NACK per i messaggi non validi o quando non riesce a elaborare i messaggi, l'abbonato contribuisce a garantire che questi messaggi non vengano persi e che vengano elaborati correttamente. Puoi utilizzare modifyAckDeadline con un valore pari a 0 per inviare un NACK a un messaggio.

Scegliere un pattern di pubblicazione e sottoscrizione Pub/Sub

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

Figura che mostra diversi pattern di pubblicazione e iscrizione.
Figura 3: le relazioni tra publisher e abbonati possono essere molti-a-uno (fan-in), molti-a-molti (bilanciamento del carico) e uno-a-molti (fan-out).

Alcuni dei pattern di pubblicazione/sottoscrizione Pub/Sub supportati includono i seguenti:

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

  • Bilanciamento del carico (molti a molti). 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 è connessa a più applicazioni del sottoscrittore. Ciascuna delle applicazioni di sottoscrizione riceve un sottoinsieme dei messaggi pubblicati e non ci sono due applicazioni di sottoscrizione 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 abbonati per ricevere messaggi dallo stesso abbonamento.

  • Fan out (uno-a-molti). In questo esempio, una o più applicazioni publisher pubblicano messaggi in un singolo argomento. Questo singolo argomento è collegato a più abbonamenti. Ogni abbonamento è collegato a una singola applicazione per abbonati. Ciascuna delle applicazioni del 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 diverse sui dati sullo stesso insieme di messaggi, la distribuzione è una buona opzione. Puoi anche allegare più sottoscrittori a ogni sottoscrizione e ottenere un sottoinsieme di messaggi con bilanciamento del carico per ogni sottoscrittore.

Scegliere un'opzione di configurazione di Pub/Sub

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

  • ConsoleGoogle 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 di 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 richiesti throughput elevato e bassa latenza con 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 generata automaticamente e viene utilizzata quando usi direttamente le API di servizio.

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

  • Scegli la lingua della libreria client corretta. Il rendimento delle librerie client Pub/Sub varia 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 iscrizione.

  • Utilizza l'ultima versione della libreria client. Le librerie client Pub/Sub vengono costantemente aggiornate con nuove funzionalità e correzioni di bug. Assicurati di utilizzare l'ultima versione della libreria client per il tuo linguaggio.

  • Riutilizzare i clienti 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 editore esplicito, riutilizza l'oggetto su cui chiami il metodo publish. 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 progetto Google Cloud 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 tuoi messaggi.

  6. Allega lo schema all'argomento.

  7. Configura un client publisher che possa pubblicare messaggi nell'argomento.

  8. Se necessario, configura le opzioni di pubblicazione avanzate, ad esempio il controllo del flusso, la messaggistica batch econtrollo della contemporaneitàa.

  9. Scegli un tipo di abbonamento in base a come vuoi ricevere i 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 avanzate di pubblicazione dei messaggi, ad esempio la pubblicazione esattamente una volta, la gestione dei lease, la pubblicazione ordinata e il controllo del flusso.

  13. Inizia a pubblicare messaggi dal client publisher all'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 di 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 corrispondere al seguente formato:

projects/project-identifier/collection/ID

  • project-identifier: deve essere l'ID progetto o il numero di progetto, disponibile nella console Google Cloud . 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 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 ., 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