Che cos'è il bus di servizio di Azure?

  • Articolo

Bus di servizio di Azure: broker di messaggi aziendale completamente gestito, con code di messaggi e argomenti di pubblicazione-sottoscrizione. Il bus di servizio viene usato per disaccoppiare le applicazioni dai servizi, offrendo i vantaggi seguenti:

  • Corretto funzionamento del bilanciamento del carico tra lavoratori concorrenti
  • Routing e trasferimento di dati in modo sicuro e controllo tra limiti di servizi e applicazioni
  • Coordinamento delle operazioni transazionali che richiedono un livello elevato di affidabilità

Panoramica

I dati vengono trasferiti tra applicazioni e servizi diversi usando i messaggi. Un messaggio è un contenitore decorato con metadati che contiene dati. I dati possono essere qualsiasi tipo di informazioni, tra cui dati strutturati codificati con formati comuni come i seguenti: JSON, XML, Apache Avro, testo normale.

Di seguito sono riportati alcuni scenari di messaggistica comuni:

  • Messaggistica. trasferimento di dati aziendali, ad esempio ordini di vendita o di acquisto, giornali di registrazione o movimenti di magazzino.

  • Separazione delle applicazioni. Miglioramento dell'affidabilità e della scalabilità di applicazioni e servizi. Il producer e il consumer non devono necessariamente essere online o immediatamente disponibili allo stesso tempo. Il carico viene livellato in modo tale che i picchi del traffico non sovraccarichino un servizio.

  • Bilanciamento del carico. Consente a più consumer in competizione di leggere da una coda contemporaneamente, ottenendo ognuno la proprietà esclusiva di specifici messaggi.

  • Argomenti e sottoscrizioni. Abilitano 1:n relazioni tra autori di pubblicazioni e sottoscrittori, consentendo ai sottoscrittori di selezionare specifici messaggi in un flusso di messaggi pubblicati.

  • Transazioni. Consentono di eseguire diverse operazioni, tutte nell'ambito della transazione atomica. Ad esempio, nell'ambito di una transazione è possibile eseguire le operazioni seguenti.

    1. Ottenere un messaggio da una coda.
    2. Pubblicare i risultati dell'elaborazione in una o più code diverse.
    3. Spostare il messaggio di input dalla coda originale.

    I risultati diventano visibili ai consumer downstream solo quando l'operazione riesce, ad esempio quando il messaggio di input viene gestito correttamente, consentendo la semantica dell'elaborazione di tipo "once-only". Questo modello di transazioni rappresenta una solida base per il modello di transazioni di compensazione nel contesto più ampio della soluzione.

  • Sessioni di messaggistica. Implementano un coordinamento su larga scala di flussi di lavoro e trasferimenti multiplex che richiedono un ordinamento rigoroso dei messaggi o il differimento degli stessi.

Se si ha familiarità con altri broker di messaggi, come Apache ActiveMQ, i concetti del bus di servizio sono simili a quelli già noti. Poiché un bus di servizio è un'offerta PaaS (platform-as-a-service), la principale differenza è che non bisogna preoccuparsi delle azioni seguenti. Azure le gestisce automaticamente.

  • Errori hardware
  • Applicazione continua di patch a sistemi operativi o prodotti
  • Inserimento di log e gestione dello spazio su disco
  • Gestione dei backup
  • Failover in un computer di riserva

Concetti

In questa sezione vengono illustrati i concetti di base di bus di servizio.

Code

I messaggi vengono inviati e ricevuti dalle code. Le code consentono di archiviare i messaggi fino a quando l'applicazione di destinazione è disponibile a riceverli ed elaborarli.

Diagramma che mostra una coda bus di servizio con un mittente e un destinatario che invia e riceve messaggi.

I messaggi nelle code vengono ordinati e vi viene aggiunto un timestamp all'arrivo. Dopo che il broker accetta il messaggio, il messaggio viene sempre mantenuto in modo permanente nell'archiviazione con ridondanza triplo, distribuito tra le zone di disponibilità se lo spazio dei nomi è abilitato per la zona. bus di servizio mantiene i messaggi in memoria o nell'archiviazione volatile fino a quando il client non li segnala come accettati.

I messaggi vengono recapitati in modalità pull, ovvero solo quando è richiesto. A differenza del modello di polling attivo di alcune altre code cloud, l'operazione pull può essere di lunga durata e viene completata solo quando un messaggio è disponibile.

Nota

Per un confronto delle code di bus di servizio con le code di Archiviazione, vedere Archiviazione code e code bus di servizio, confrontate e contrastate.

Argomenti

È anche possibile usare gli argomenti per inviare e ricevere i messaggi. Mentre una coda viene spesso usata per la comunicazione da punto a punto, gli argomenti sono utili negli scenari di pubblicazione-sottoscrizione.

Diagramma che mostra un argomento bus di servizio con un mittente e più ricevitori.

Gli argomenti possono avere più sottoscrizioni indipendenti, che si collegano all'argomento e altrimenti funzionano esattamente come code dal lato destinatario. Un sottoscrittore a un argomento può ricevere una copia di ogni messaggio inviato a tale argomento. Le sottoscrizioni sono entità denominate. Le sottoscrizioni sono durevoli per impostazione predefinita, ma possono essere configurate per scadere e quindi per essere automaticamente eliminate. Tramite l'API Java Message Service (JMS), bus di servizio Premium consente anche di creare sottoscrizioni volatili esistenti per la durata della connessione.

È possibile definire regole per una sottoscrizione. Una regola prevede un filtro per definire una condizione per cui il messaggio deve essere copiato nella sottoscrizione e un'azione facoltativa che può modificare i metadati del messaggio. Per altre informazioni, vedere Filtri e azioni per gli argomenti. Questa funzionalità è utile negli scenari seguenti:

  • Si vuole evitare che una sottoscrizione riceva tutti i messaggi inviati a un argomento.
  • Si vogliono contrassegnare i messaggi con metadati aggiuntivi quando attraversano una sottoscrizione.

Nota

Per altre informazioni su code e argomenti, vedere bus di servizio code, argomenti e sottoscrizioni.

Namespaces (Spazi dei nomi)

Uno spazio dei nomi è un contenitore per tutti i componenti di messaggistica (code e argomenti). Uno spazio dei nomi può avere una o più code e argomenti e spesso funge da contenitore di applicazioni.

Uno spazio dei nomi può essere paragonato a un "server" nella terminologia di altri broker, ma i concetti non sono direttamente equivalenti. Lo spazio dei nomi di un bus di servizio rappresenta una specifica quota di capacità di un cluster di grandi dimensioni costituito da decine di macchine virtuali tutte attive. Facoltativamente, si estende su tre zone di disponibilità di Azure. Si ottengono così tutti i vantaggi di disponibilità e affidabilità associati all'esecuzione del broker di messaggi su scala enorme. Inoltre, non bisogna preoccuparsi delle complessità sottostanti. bus di servizio è la messaggistica serverless.

Funzionalità avanzate

Il bus di servizio include anche funzionalità avanzate che consentono di risolvere problemi di messaggistica più complessi. Le sezioni seguenti descrivono queste funzionalità chiave:

Sessioni di messaggistica

Per realizzare una garanzia FIFO (First-In First-In, First-Out) nell'elaborazione dei messaggi in bus di servizio code o sottoscrizioni, usare le sessioni. Le sessioni possono essere usate anche per implementare modelli di richiesta-risposta. Il modello request-response consente all'applicazione mittente di inviare una richiesta e consente al destinatario di inviare correttamente una risposta all'applicazione mittente. Per altre informazioni, vedere Sessioni di messaggi.

Inoltro automatico

La funzionalità di inoltro automatico consente di concatenare una coda o una sottoscrizione a un'altra coda o argomento che fa parte dello stesso spazio dei nomi. Quando l'inoltro automatico è abilitato, il bus di servizio rimuove automaticamente i messaggi presenti nella prima coda o sottoscrizione (origine) e li inserisce nella seconda coda o argomento (destinazione). Per altre informazioni, vedere Concatenamento bus di servizio entità con inoltro automatico

Inserimento nella coda di messaggi non recapitabili

bus di servizio code e sottoscrizioni di argomenti forniscono una coda secondaria secondaria, denominata coda di messaggi non recapitabili (DLQ). La coda di messaggi non recapitabili contiene messaggi che non possono essere recapitati ad alcun destinatario o messaggi che non possono essere elaborati. È quindi possibile rimuovere messaggi dalla coda di messaggi non recapitabili ed esaminarli. Un'applicazione potrebbe, con l'aiuto di un operatore, correggere i problemi e inviare di nuovo il messaggio, registrare il fatto che si è verificato un errore ed eseguire un'azione correttiva. Per altre informazioni, vedere Panoramica delle code dei messaggi non recapitabili del bus di servizio.

Recapito pianificato

è possibile inviare messaggi a una coda oppure a un argomento per l'elaborazione posticipata. Ad esempio, per pianificare un processo per diventare disponibile per l'elaborazione da parte di un sistema in un determinato momento. Per altre informazioni, vedere Messaggi pianificati.

Differimento dei messaggi

Quando un client di coda o sottoscrizione riceve un messaggio che è disposto a elaborare, ma per cui l'elaborazione non è attualmente possibile a causa di circostanze particolari all'interno dell'applicazione, l'entità può rinviare il recupero del messaggio a un punto successivo. Il messaggio rimane nella coda o nella sottoscrizione, ma viene messo da parte. Per altre informazioni, vedere Differimento di messaggi.

Transazioni

Una transazione raggruppa due o più operazioni in un ambito di esecuzione. Il bus di servizio supporta le operazioni di raggruppamento in una singola entità di messaggistica (coda, argomento, sottoscrizione) nell'ambito di una transazione. Per altre informazioni, vedere Panoramica dell'elaborazione delle transazioni del bus di servizio.

Filtri e azioni

I sottoscrittori possono definire i messaggi che vogliono 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 ogni condizione di regola corrispondente, la sottoscrizione genera una copia del messaggio, che può essere annotata in modo diverso per ogni regola. Per altre informazioni, vedere Filtri e azioni per gli argomenti.

Eliminazione automatica in caso di inattività

L'eliminazione automatica in caso di inattività consente di specificare un intervallo di inattività dopo il quale la coda viene automaticamente eliminata. L'intervallo viene reimpostato quando è presente traffico nella coda. La durata minima è 5 minuti.

Rilevamento duplicati

Se si verifica un errore che fa sì che il client abbia dubbi sul risultato di un'operazione di invio, il rilevamento duplicato elimina il dubbio da queste situazioni consentendo al mittente di inviare nuovamente lo stesso messaggio e la coda o l'argomento rimuove eventuali copie duplicate. Per altre informazioni, vedere Rilevamento duplicati.

Sicurezza

bus di servizio supporta protocolli di sicurezza, ad esempioFirme di accesso condiviso (SAS), Controllo di accesso basate su ruoli (RBAC) e identità gestite per le risorse di Azure.

bus di servizio supporta standard Protocollo AMQP (Advanced Message Queuing Protocol) 1.0 e HTTP/REST.

Ripristino di emergenza geografico

Quando le aree o i data center di Azure riscontrano tempo di inattività, il ripristino di emergenza geografico fa in modo che l'elaborazione dei dati continui a funzionare in un'area o in un data center diverso.

Nota

Per altre informazioni su queste funzionalità, vedere Funzionalità avanzate di bus di servizio di Azure.

Conformità a standard e protocolli

Il protocollo di collegamento principale per il bus di servizio è Advanced Messaging Queueing Protocol (AMQP) 1.0, uno standard ISO/IEC aperto. Consente ai clienti di scrivere applicazioni che funzionano con il bus di servizio e i broker locali, ad esempio ActiveMQ o RabbitMQ. La guida del protocollo AMQP fornisce informazioni dettagliate nel caso si decida di creare tale astrazione.

Il bus di servizio Premium è pienamente conforme all'API Java Message Service (JMS) 2.0 di Java/Jakarta EE. E il bus di servizio Standard supporta il subset JMS 1.1 incentrato sulle code. JMS è un'astrazione comune per i broker di messaggi e si integra con molte applicazioni e diversi framework, tra cui il framework Spring ampiamente diffuso. Per passare al bus di servizio di Azure da altri broker, è sufficiente ricreare la topologia di code e argomenti, quindi cambiare le dipendenze del provider client e la configurazione. Per un esempio, vedere la guida alla migrazione di ActiveMQ.

Librerie client

Le librerie client del bus di servizio pienamente supportate sono disponibili tramite Azure SDK.

Il protocollo primario del bus di servizio di Azure è AMQP 1.0 e può essere usato da qualsiasi client di protocollo conforme a AMQP 1.0. Diversi client AMQP open source includono esempi che dimostrano esplicitamente l'interoperabilità con il bus di servizio. Vedere la guida al protocollo AMQP 1.0 per comprendere come usare direttamente le funzionalità di bus di servizio con i client AMQP 1.0.

Lingua Libreria
Java Apache Qpid Proton-J
C/C++ Azure uAMQP C, Apache Qpid Proton-C
Python Azure uAMQP per Python, Apache Qpid Proton Python
PHP Azure uAMQP per PHP
Ruby Apache Qpid Proton Ruby
Go Azure Go AMQP, Apache Qpid Proton Go
C#/F#/VB AMQP .NET Lite, Apache NMS AMQP
JavaScript/Node Rhea

Integrazione

Il bus di servizio si integra completamente con molti servizi di Microsoft e Azure, ad esempio:

Passaggi successivi

Per iniziare a usare la messaggistica del bus di servizio, vedere gli articoli seguenti: