Code, argomenti e sottoscrizioni del bus di servizio

bus di servizio di Azure supporta l'accodamento dei messaggi affidabile e la messaggistica di pubblicazione/sottoscrizione durevoli. Le entità di messaggistica che costituiscono il nucleo delle funzionalità di messaggistica in bus di servizio sono code, argomenti e sottoscrizioni.

Importante

Se non si ha bus di servizio di Azure, leggere Che cos'è bus di servizio di Azure? prima di passare a 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.

Image showing how Service Queues work.

Il vantaggio principale derivante dall'uso delle code è quello di ottenere un disaccoppiamento temporale dei componenti applicativi, ovvero In altre parole, i producer (mittenti) e i consumer (ricevitori) non devono inviare e ricevere messaggi contemporaneamente, perché i messaggi vengono archiviati in modo permanente nella coda. Inoltre, il producer non deve attendere che una risposta del consumer continui 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à consente di risparmiare direttamente sulla quantità di infrastruttura necessaria per il servizio del 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, questo bilanciamento del carico basato sul pull consente l'uso ottimale dei computer di lavoro anche se i computer di lavoro con potenza di elaborazione dei messaggi pull a 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é i produttori e i consumer non sono a conoscenza l'uno dell'altro, un consumer può essere aggiornato senza avere alcun effetto sul producer.

Creare code

È possibile creare code usando una delle opzioni seguenti:

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 da 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 chiamato al massimo una volta l'elaborazione.
  • Visualizzare il 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 chiamato almeno una volta l'elaborazione. 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 può tollerare l'elaborazione duplicata, aggiungere logica aggiuntiva nell'applicazione per rilevare i duplicati. Per altre informazioni, vedere Rilevamento duplicati, noto come esattamente una volta l'elaborazione.

      Nota

      Per altre informazioni su queste due modalità, vedere Settling receive operations.For more information about these two modes, see Settling receive operations.

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 offrono una forma di comunicazione uno-a-molti in 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.

Image showing a Service Bus topic with three subscriptions.

Per limitare i messaggi da ricevere, le sottoscrizioni possono usare altri filtri. 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 di messaggi di una coda viene mappata direttamente a un argomento e la relativa funzionalità di ricezione dei messaggi viene mappata a una sottoscrizione. Tra le altre cose, questa funzionalità significa che le sottoscrizioni supportano gli stessi modelli descritti in precedenza in questa sezione relative alle code: consumer concorrenti, disaccoppiamento temporale, livellamento del carico e bilanciamento del carico.

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 bus di servizio sottoscrizioni visualizzano tutti i messaggi inviati all'argomento, è possibile copiare solo un subset di tali messaggi nella coda della sottoscrizione virtuale. 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 su tutti i messaggi per 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 permanenti non condivise
  • Sottoscrizioni non durevoli condivise
  • Sottoscrizioni non durevoli non condivise

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

Passaggi successivi

Provare gli esempi nella lingua preferita:

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

Il 30 settembre 2026 verranno ritirati le librerie bus di servizio di Azure SDK WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus e com.microsoft.azure.servicebus, che non sono conformi alle linee guida di Azure SDK. Il supporto del protocollo SBMP verrà terminato, 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 di ritiro del supporto.