Condividi tramite

Code, argomenti e sottoscrizioni del bus di servizio

  • Articolo

Il bus di servizio di Azure supporta l'accodamento dei messaggi affidabile e la messaggistica di pubblicazione/sottoscrizione durevole. Le entità di messaggistica che costituiscono le funzionalità di messaggistica di base nel bus di servizio sono code, argomenti e sottoscrizioni.

Importante

Se non si ha una versione del bus di servizio di Azure, leggere Che cos'è il bus di servizio di Azure? prima di proseguire con questo articolo.

Code

Le code consentono un recapito dei messaggi di tipo FIFO (First In, First Out) a uno o più consumer concorrenti. Ovvero, i destinatari in genere ricevono ed elaborano i messaggi nell'ordine in cui sono stati aggiunti alla coda. Inoltre, un solo consumer di messaggi riceve ed elabora ogni messaggio.

Immagine che mostra il funzionamento delle code del servizio.

Il vantaggio principale derivante dall'uso delle code è quello di ottenere un disaccoppiamento temporale dei componenti applicativi, ovvero In altre parole, non è necessario che i producer e i consumer inviino e ricevano i messaggi contemporaneamente perché i messaggi restano archiviati nella coda. Il producer inoltre non deve attendere la risposta del consumer per continuare a elaborare e inviare messaggi.

Un vantaggio correlato è quello del livellamento del carico, che permette ai producer e ai consumer di inviare e ricevere i messaggi a velocità diverse. In molte applicazioni, il carico del sistema varia nel tempo. Tuttavia, il tempo di elaborazione necessario per ogni unità di lavoro normalmente è costante. L'intermediazione di producer e consumer di messaggi con una coda significa che l'applicazione consumer deve essere solo in grado di gestire il carico medio anziché i picchi di carico. La profondità della coda aumenta e si contrae al variare del carico in ingresso. Questa funzionalità permette un risparmio diretto in termini economici rispetto alle risorse infrastrutturali richieste per gestire il carico dell'applicazione. Con l'aumentare del carico, è possibile aggiungere più processi di lavoro da leggere dalla coda. Ogni messaggio viene elaborato solo da uno dei processi di lavoro. Inoltre, il bilanciamento del carico di tipo pull permette un uso ottimale dei computer di lavoro anche quando questi effettuano il pull dei messaggi alla velocità massima. Questo modello viene spesso definito modello del consumer concorrente.

L'uso di code per l'intermediazione tra producer e consumer di messaggi fornisce un accoppiamento intrinseco libero tra i componenti. Poiché producer e consumer sono indipendenti gli uni dagli altri, è possibile aggiornare un consumer senza causare alcun effetto sul producer.

Creare code

È possibile creare code usando una delle opzioni seguenti:

Quindi, inviare e ricevere messaggi usando i client scritti nei linguaggi di programmazione, inclusi quelli seguenti:

Modalità di ricezione

È possibile specificare due modalità diverse in cui i consumer possono ricevere messaggi dal bus di servizio.

  • Ricevere ed eliminare. In questa modalità, quando il bus di servizio riceve la richiesta dal consumer, contrassegna il messaggio come utilizzato e lo restituisce all'applicazione consumer. Questa modalità è il modello più semplice ed è adatta per scenari in cui l'applicazione può tollerare la mancata elaborazione di un messaggio in caso di errore. Per comprendere meglio questo scenario, si consideri uno scenario in cui il consumer invia la richiesta di ricezione e viene arrestato in modo anomalo prima dell'elaborazione. Appena il bus di servizio contrassegna il messaggio come utilizzato, l'applicazione inizia a utilizzare i messaggi al riavvio. Non verrà visualizzato il messaggio utilizzato prima dell'arresto anomalo. Questo processo viene spesso definito di tipo at-most once.
  • Visualizzazione blocco. In questa modalità il processo di ricezione diventa un'operazione in due fasi, che rende possibile il supporto di applicazioni che non sono in grado di tollerare messaggi mancanti.

    1. Trova il messaggio successivo da consumare, lo blocca per impedire ad altri consumer di riceverlo e lo restituisce all'applicazione.

    2. Al termine dell'elaborazione del messaggio, l'applicazione richiede al bus di servizio di completare la seconda fase del processo di ricezione. Quindi, il servizio contrassegna il messaggio come utilizzato.

      Se l'applicazione non è in grado di elaborare il messaggio per qualche motivo, può richiedere al bus di servizio di abbandonare il messaggio. Il bus di servizio sblocca il messaggio e lo rende disponibile per essere nuovamente ricevuto dallo stesso consumer o da un altro consumer concorrente. In secondo luogo, è presente un timeout associato al blocco. Se l'applicazione non riesce a elaborare il messaggio prima della scadenza del timeout del blocco, il bus di servizio sblocca automaticamente il messaggio rendendolo nuovamente disponibile per la ricezione.

      Se l'applicazione si arresta in modo anomalo dopo aver elaborato il messaggio ma prima di richiedere al servizio del bus di servizio di completarlo, il bus di servizio ripristina il messaggio nell'applicazione quando viene riavviato. Questo processo viene spesso definito di tipo at-least once. In altre parole, ogni messaggio viene elaborato almeno una volta. Tuttavia, in determinate situazioni lo stesso messaggio potrebbe essere recapitato di nuovo. Se lo scenario non è in grado di tollerare l'elaborazione duplicata, includere una logica aggiuntiva nell'applicazione per rilevare i duplicati. Per altre informazioni, vedere Rilevamento duplicati, noto come elaborazione di tipo exactly once.

      Nota

      Per altre informazioni su queste due modalità, vedere Finalizzazione delle operazioni di ricezione.

Argomenti e sottoscrizioni

Una coda consente l'elaborazione di un messaggio da parte di un singolo consumer. A differenza delle code, gli argomenti e le sottoscrizioni consentono di eseguire una comunicazione uno-a-molti, secondo un modello di pubblicazione e sottoscrizione. È utile per il ridimensionamento a un numero elevato di destinatari. Ogni messaggio pubblicato viene reso disponibile per ogni sottoscrizione registrata con l'argomento. Il server di pubblicazione invia un messaggio a un argomento e uno o più sottoscrittori ricevono una copia del messaggio.

Immagine che mostra un argomento del bus di servizio con tre sottoscrizioni.

I server di pubblicazione inviano messaggi a un argomento nello stesso modo in cui inviano messaggi a una coda. Tuttavia, i consumer non ricevono messaggi direttamente dall'argomento. I consumer ricevono invece i messaggi dalle sottoscrizioni dell'argomento. Una sottoscrizione dell'argomento è simile a una coda virtuale che riceve copie dei messaggi inviati all'argomento. I consumer ricevono messaggi da una sottoscrizione in modo identico al modo in cui ricevono messaggi da una coda. La funzionalità di invio dei messaggi di una coda esegue il mapping direttamente a un argomento e la funzionalità di ricezione dei messaggi esegue il mapping a una sottoscrizione. Questa funzione implica anche che le sottoscrizioni supportano gli stessi modelli descritti prima in questa sezione in merito alle code: consumer concorrente, disaccoppiamento temporale, livellamento del carico e bilanciamento del carico.

Le sottoscrizioni possono definire i messaggi che desiderano ricevere da un argomento. Per specificare tali messaggi, viene usata una o più regole di sottoscrizione denominate. Ogni regola è costituita da una condizione di filtro che seleziona determinati messaggi e, facoltativamente, contiene un'azione che annota il messaggio selezionato. Per impostazione predefinita, una sottoscrizione a un argomento riceve tutti i messaggi inviati all'argomento. La sottoscrizione ha una regola predefinita iniziale con un filtro vero che consente di selezionare tutti i messaggi nella sottoscrizione. La regola predefinita non ha alcuna azione associata. È possibile definire filtri con regole e azioni in una sottoscrizione in modo che la sottoscrizione riceva solo un subset di messaggi inviati all'argomento.

Per altre informazioni sui filtri, i filtri e le azioni.

Creare argomenti e sottoscrizioni

La procedura per la creazione di un argomento è simile a quella per la creazione di una coda, descritta nella sezione precedente. È possibile creare argomenti e sottoscrizioni usando una delle opzioni seguenti:

Inviare quindi messaggi a un argomento e ricevere messaggi dalle sottoscrizioni usando i client scritti nei linguaggi di programmazione, inclusi quelli seguenti:

Regole e azioni

In molti scenari, i messaggi con caratteristiche specifiche devono essere elaborati in modi specifici. Per abilitare questa elaborazione, è possibile configurare le sottoscrizioni in modo che trovino i messaggi che presentano le proprietà desiderate e apportare quindi alcune modifiche a tali proprietà. Mentre nelle sottoscrizioni del bus di servizio tutti i messaggi vengono inviati all'argomento, è possibile copiare solo un subset di tali messaggi nella coda virtuale delle sottoscrizioni. Questo filtraggio viene eseguito usando i filtri della sottoscrizione. Queste modifiche sono chiamate azioni di filtro. Quando viene creata una sottoscrizione, è possibile specificare un'espressione filtro che opera sulle proprietà del messaggio. Le proprietà possono essere sia proprietà di sistema (ad esempio, Label) che proprietà personalizzate dell'applicazione (ad esempio StoreName). In questo caso, l'espressione filtro SQL è facoltativa. Senza un'espressione di filtro SQL, qualsiasi azione di filtro definita in una sottoscrizione viene eseguita in tutti i messaggi di tale sottoscrizione.

Per un esempio funzionante completo, vedere l'esempio TopicFilters su GitHub. Per altre informazioni sui filtri, vedere Filtri e azioni degli argomenti.

Entità di JMS (Java Message Service) 2.0

Le entità seguenti sono accessibili tramite l'API JMS (Java Message Service) 2.0.

  • Code temporanee
  • Argomenti temporanei
  • Sottoscrizioni durevoli condivise
  • Sottoscrizioni durevoli non condivise
  • Sottoscrizioni non durevoli condivise
  • Sottoscrizioni non durevoli non condivise

Altre informazioni sulle entità JMS 2.0 e su come usarle.

Entità Express

Le entità rapide sono state create per scenari di velocità effettiva elevata e latenza ridotta. Quando si usano le entità rapide, un messaggio inviato a una coda o a un argomento non viene archiviato immediatamente nell'archivio di messaggistica. Il messaggio viene invece inizialmente memorizzato nella cache. I messaggi che rimangono nell'entità vengono scritti nell'archivio messaggi dopo un ritardo, a questo punto sono protetti da perdite dovute a un'interruzione del servizio.

Nelle entità regolari, qualsiasi operazione di runtime (ad esempio Send, Complete, Abandon, Deadletter) viene prima salvata in modo permanente nell'archivio e solo dopo questa operazione viene riconosciuta al client come riuscita. Nelle entità express, un'operazione di runtime viene riconosciuta prima al client come riuscita e solo in un secondo momento viene salvata in modo persistente nell'archivio. Di conseguenza, in caso di riavvio del computer o quando si verifica un problema hardware, alcune operazioni di runtime riconosciute potrebbero non essere persistenti. Ciò significa che il client ottiene una latenza inferiore e una maggiore velocità effettiva con entità express, a scapito della potenziale perdita di dati e/o della riconsegna dei messaggi.

Inoltre, nel corso del tempo sono state eseguite molte ottimizzazioni all'interno del bus di servizio, il che significa che i vantaggi della velocità effettiva e della latenza delle entità express sono attualmente minimi. Inoltre, il livello Premium del bus di servizio non supporta leentità Express. Per questo motivo, non è attualmente consigliabile usare questa funzionalità.

Passaggi successivi

Provare gli esempi nel linguaggio preferito:

Per esempi che usano versioni precedenti delle librerie client .NET e Java, usare i collegamenti seguenti:

Il 30 settembre 2026 verranno ritirate le librerie dell'SDK del bus di servizio di Azure WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus e com.microsoft.azure.servicebus, che non sono conformi alle linee guida di Azure SDK. Verrà terminato anche il supporto del protocollo SBMP, quindi non sarà più possibile usare questo protocollo dopo il 30 settembre 2026. Eseguire la migrazione alle librerie più recenti di Azure SDK, che offrono aggiornamenti critici della sicurezza e funzionalità migliorate, prima di tale data.

Anche se le librerie precedenti possono ancora essere usate oltre il 30 settembre 2026, non riceveranno più il supporto e gli aggiornamenti ufficiali da Microsoft. Per altre informazioni, vedere l'annuncio del ritiro del supporto.