Analogie e differenze tra le code di archiviazione e le code del bus di servizio
Questo articolo analizza le differenze e le analogie tra i due tipi di code offerte da Microsoft Azure: code di archiviazione e code bus di servizio. Usando queste informazioni, è possibile prendere una decisione più informata sulla soluzione più adatta alle proprie esigenze.
Introduzione
Azure supporta due tipi di meccanismi di code: code di archiviazione e code del bus di servizio.
Le code di archiviazione fanno parte dell'infrastruttura di Archiviazione di Azure. Consentono di archiviare un numero elevato di messaggi. È possibile accedere ai messaggi ovunque ci si trovi con chiamate autenticate tramite HTTP o HTTPS. Un messaggio in coda avere dimensioni fino a 64 KB. Una coda può contenere milioni di messaggi, fino al limite di capacità totale dell'account di archiviazione. Le code vengono in genere usate per creare un backlog di lavoro da elaborare in modo asincrono. Per altre informazioni, vedere Che cosa sono Archiviazione di Azure code.
bus di servizio code fanno parte di un'infrastruttura di messaggistica di Azure più ampia che supporta accodamento, pubblicazione/sottoscrizione e modelli di integrazione più avanzati. Sono progettati per integrare applicazioni o componenti dell'applicazione che possono estendersi su più protocolli di comunicazione, contratti dati, domini di attendibilità o ambienti di rete. Per altre informazioni su bus di servizio code/argomenti/sottoscrizioni, vedere le code, gli argomenti e le sottoscrizioni bus di servizio.
Considerazioni sulla selezione della tecnologia
Le code di archiviazione e le code del bus di servizio hanno un set di funzionalità leggermente diverso. È possibile scegliere una o entrambe le opzioni, a seconda delle esigenze della soluzione specifica.
Quando si stabilisce la tecnologia di accodamento che soddisfa lo scopo di una determinata soluzione, è consigliabile che gli architetti e gli sviluppatori di soluzioni tengano in considerazione le indicazioni riportate di seguito.
Valutare l'uso delle code di archiviazione
Gli architetti e gli sviluppatori di soluzioni dovrebbero considerare l'uso delle code di Azure quando:
- L'applicazione deve archiviare più di 80 gigabyte di messaggi in una coda.
- L'applicazione deve tenere traccia dello stato dell'elaborazione di un messaggio nella coda. È utile se il ruolo di lavoro che elabora un messaggio si arresta in modo anomalo. Un altro ruolo di lavoro può quindi usare tali informazioni per continuare dal punto in cui è stato interrotto il ruolo di lavoro precedente.
- Sono necessari i log lato server di tutte le transazioni eseguite sulle code.
Valutare la possibilità di usare le code del bus di servizio
Gli architetti e gli sviluppatori di soluzioni dovrebbero considerare l'uso delle code del bus di servizio quando:
- La soluzione deve ricevere messaggi senza dover eseguire il polling della coda. Con bus di servizio, è possibile ottenere questo risultato usando un'operazione di ricezione con polling prolungato tramite protocolli basati su TCP supportati dal bus di servizio.
- La soluzione richiede che la coda specifichi un recapito ordinato First In First Out (FIFO) garantito.
- La soluzione deve supportare il rilevamento automatico dei duplicati.
- L'applicazione dovrà elaborare i messaggi come flussi paralleli a esecuzione prolungata (i messaggi sono associati a un flusso mediante la proprietà session ID). In questo modello ogni nodo dell'applicazione che utilizza il servizio entra in competizione con gli altri nodi per l'acquisizione dei flussi anziché dei messaggi. Quando un flusso viene assegnato a un nodo basato sul servizio, tale nodo può esaminare lo stato del flusso dell'applicazione mediante transazioni.
- La soluzione richiede il comportamento transazionale e l'atomicità quando si inviano o ricevono più messaggi da una coda.
- L'applicazione gestisce messaggi che possono superare i 64 KB, ma probabilmente non raggiungerà il limite di 256 KB o 1 MB, a seconda del livello di servizio scelto (anche se le code bus di servizio possono gestire i messaggi fino a 100 MB).
- È necessario fornire un modello di accesso basato sui ruoli alle code e autorizzazioni/diritti diversi per mittenti e destinatari. Per altre informazioni, vedere gli articoli seguenti:
- Le dimensioni della coda non supereranno gli 80 GB.
- Si vuole usare il protocollo di messaggistica basato sugli standard AMQP 1.0. Per altre informazioni su AMQP, vedere Panoramica di AMQP per il bus di servizio.
- Si prevede una migrazione finale dalla comunicazione point-to-point basata su coda a un modello di messaggistica publish-subscribe. Questo modello consente l'integrazione di ricevitori aggiuntivi (sottoscrittori). Ogni ricevitore riceve copie indipendenti di alcuni o tutti i messaggi inviati alla coda.
- La soluzione di messaggistica deve supportare le garanzie di recapito "At-Most-Once" e "At-Least-Once" senza la necessità di creare i componenti aggiuntivi dell'infrastruttura.
- La soluzione deve pubblicare e utilizzare batch di messaggi.
Confrontare le code di archiviazione e le code di bus di servizio
Le tabelle nelle sezioni seguenti forniscono un raggruppamento logico delle funzionalità della coda. Consentono di confrontare, a colpo d'occhio, le funzionalità disponibili sia nelle code Archiviazione di Azure che nelle code bus di servizio.
Funzionalità fondamentali
Questa sezione confronta alcune delle funzionalità di accodamento fondamentali fornite dalle code di archiviazione e dalle code del bus di servizio.
| Criteri di confronto | Code di archiviazione | Code del bus di servizio |
|---|---|---|
| Garanzia di ordinamento | No Per altre informazioni, vedere la prima nota nella sezione Informazioni aggiuntive. |
Sì - First-In-First-Out (FIFO) (usando sessioni di messaggi) |
| Garanzia di recapito | At-Least-Once | At-Least-Once (tramite la modalità di ricezione PeekLock. È l'impostazione predefinita) At-Most-Once (tramite la modalità di ricezione ReceiveAndDelete) Altre informazioni sulle varie modalità di ricezione |
| Supporto per l'operazione atomica | No | Sì |
| Comportamento di ricezione | Non bloccanti (viene completata immediatamente se non vengono trovati altri messaggi) |
Blocco con o senza timeout (offre disponibilità di polling prolungato o la "Tecnica Comet") Non bloccanti (solo con l'API gestita .NET) |
| API di tipo push | No | Sì Gli SDK .NET, Java, JavaScript e Go offrono API in stile push. |
| Modalità di ricezione | Visualizzazione e lease | Visualizzazione e blocco Ricezione ed eliminazione |
| Modalità di accesso esclusivo | Basato sul lease | Basato sul blocco |
| Durata lease/blocco | 30 secondi (impostazione predefinita) 7 giorni (massimo) (è possibile rinnovare o rilasciare un lease di messaggi usando l'API UpdateMessage ). |
30 secondi (impostazione predefinita) È possibile rinnovare il blocco dei messaggi per la stessa durata del blocco ogni volta manualmente o usare la funzionalità di rinnovo automatico del blocco in cui il client gestisce automaticamente il rinnovo del blocco. |
| Precisione lease/blocco | Livello di messaggio Ogni messaggio può avere un valore di timeout diverso, che è quindi possibile aggiornare in base alle esigenze durante l'elaborazione del messaggio usando l'API UpdateMessage . |
Livello di coda Ogni coda ha una precisione di blocco applicata a tutti i messaggi, ma il blocco può essere rinnovato come descritto nella riga precedente. |
| Ricezione in batch | Sì (specifica esplicitamente il numero di messaggi durante il recupero dei messaggi, fino a un massimo di 32 messaggi). |
Sì (abilitando in modo implicito una proprietà di prelettura o in modo esplicito tramite transazioni) |
| Invio in batch | No | Sì (usando transazioni o batch sul lato client) |
Informazioni aggiuntive
- I messaggi nelle code di archiviazione sono in genere first-in-first-out, ma a volte possono non essere in ordine. Ad esempio, quando la durata del timeout di visibilità di un messaggio scade perché un'applicazione client si arresta in modo anomalo durante l'elaborazione di un messaggio. Quando il timeout di visibilità scade, il messaggio risulta nuovamente visibile nella coda in modo che un altro utente possa rimuoverlo. A questo punto, il messaggio appena visibile potrebbe essere inserito nella coda per essere nuovamente dequeuato.
- Il modello FIFO garantito nelle code del bus di servizio richiede l'uso di sessioni di messaggistica. Se l'applicazione si arresta in modo anomalo durante l'elaborazione di un messaggio ricevuto nella modalità Peek &Lock , la volta successiva che un ricevitore di coda accetta una sessione di messaggistica, inizierà con il messaggio non riuscito dopo la scadenza della durata del blocco della sessione.
- Le code di archiviazione sono progettate per supportare scenari di accodamento standard, ad esempio quelli seguenti:
- Disaccoppiamento dei componenti dell'applicazione per aumentare la scalabilità e la tolleranza per gli errori
- Livellamento del carico
- Creazione di flussi di lavoro di processo.
- Le incoerenze relative alla gestione dei messaggi nel contesto di bus di servizio sessioni possono essere evitate usando lo stato della sessione per archiviare lo stato dell'applicazione in relazione allo stato di avanzamento della gestione della sequenza di messaggi della sessione e usando le transazioni relative alla risoluzione dei messaggi ricevuti e aggiornando lo stato della sessione. Questo tipo di funzionalità di coerenza viene talvolta etichettato esattamente una volta nell'elaborazione nei prodotti di altri fornitori. Eventuali errori di transazione causeranno ovviamente la rielizione dei messaggi e questo è il motivo per cui il termine non è esattamente adeguato.
- Le code di archiviazione offrono un modello di programmazione uniforme e coerente tra code, tabelle e BLOB, sia per i team di sviluppo che per i team operativi.
- Le code del bus di servizio offrono supporto per le transazioni locali nel contesto di una singola coda.
- La modalità Ricezione ed eliminazione supportata dal bus di servizio offre la possibilità di ridurre il numero di operazioni di messaggistica (e relativo costo) in cambio di una garanzia di recapito più bassa.
- Le code di archiviazione offrono lease con possibilità di estensione per i messaggi. Questa funzionalità consente ai processi di lavoro di mantenere brevi lease sui messaggi. Pertanto, se un ruolo di lavoro si arresta in modo anomalo, il messaggio può essere elaborato di nuovo rapidamente da un altro ruolo di lavoro. Inoltre, un ruolo di lavoro può estendere il lease in un messaggio se deve elaborarlo più a lungo del tempo di lease corrente.
- Le code di archiviazione offrono un timeout di visibilità che può essere impostato al momento dell'inserimento o della rimozione dalla coda di un messaggio. È anche possibile aggiornare un messaggio con valori di lease diversi in fase di esecuzione e aggiornare valori diversi tra i messaggi nella stessa coda. bus di servizio timeout di blocco sono definiti nei metadati della coda. Tuttavia, è possibile rinnovare manualmente il blocco dei messaggi per la durata del blocco predefinito o usare la funzionalità di rinnovo automatico del blocco in cui il client gestisce automaticamente il rinnovo del blocco.
- Il timeout massimo per un'operazione di ricezione del blocco nelle code del bus di servizio è di 24 giorni. I timeout basati su REST, tuttavia, hanno un valore massimo di 55 secondi.
- Il batch sul lato client fornito dal bus di servizio consente a un client di coda di inviare in batch più messaggi in una singola operazione di invio. L'invio in batch è disponibile solo per le operazioni di invio asincrone.
- Funzionalità come il limite massimo di 200 TB di code di archiviazione (più quando si virtualizzano gli account) e code illimitate lo rendono una piattaforma ideale per i provider SaaS.
- Le code di archiviazione forniscono un meccanismo di controllo di accesso delegato flessibile ed efficiente.
Funzionalità avanzate
Questa sezione confronta le funzionalità avanzate fornite dalle code di archiviazione e dalle code del bus di servizio.
| Criteri di confronto | Code di archiviazione | Code del bus di servizio |
|---|---|---|
| Recapito pianificato | Sì | Sì |
| Mancato recapito automatico dei messaggi | No | Sì |
| Valore TTL di accodamento aumentato | Sì (tramite aggiornamento sul posto del timeout di visibilità) |
Sì (specificato tramite una funzione API dedicata) |
| Supporto messaggi non elaborabili | Sì | Sì |
| Aggiornamento sul posto | Sì | Sì |
| Log delle transazioni sul lato server | Sì | No |
| Metriche di archiviazione | Sì Metriche dei minuti fornisce metriche in tempo reale per disponibilità, TPS, conteggi delle chiamate API, conteggi degli errori e altro ancora. Sono tutti in tempo reale, aggregati al minuto e segnalati entro pochi minuti da ciò che è successo nell'ambiente di produzione. Per altre informazioni, vedere About Storage Analytics Metrics (Informazioni sulle metriche di analisi dell'archiviazione). |
Sì Per informazioni sulle metriche supportate da bus di servizio di Azure, vedere Metriche dei messaggi. |
| Gestione dello stato | No | Sì (Active, Disabled, SendDisabled, ReceiveDisabled. Per informazioni dettagliate su questi stati, vedere Stato coda |
| Inoltro automatico dei messaggi | No | Sì |
| Funzione di eliminazione della coda | Sì | Sì |
| Gruppi di messaggi | No | Sì (usando sessioni di messaggistica) |
| Stato dell'applicazione per gruppo di messaggi | No | Sì |
| Rilevamento duplicati | No | Sì (configurabile sul lato del mittente) |
| Esplorazione di gruppi di messaggi | No | Sì |
| Recupero delle sessioni di messaggistica per ID | No | Sì |
Informazioni aggiuntive
- Entrambe le tecnologie di accodamento consentono di pianificare il recapito di un messaggio in un momento successivo.
- L'inserimento automatico delle code consente a migliaia di code di completare automaticamente i messaggi in una singola coda, da cui l'applicazione ricevente utilizza il messaggio. Questo meccanismo consente di ottenere un valore elevato di sicurezza, di controllare il flusso e di isolare le aree di archiviazione tra i server di pubblicazione dei messaggi.
- Le code di archiviazione offrono supporto per l'aggiornamento del contenuto del messaggio. Questa funzionalità consente di rendere permanenti le informazioni sullo stato e gli aggiornamenti sull'avanzamento incrementale all'interno del messaggio, in modo che sia possibile elaborare quest'ultimo dall'ultimo checkpoint noto anziché dall'inizio. Con bus di servizio code, è possibile abilitare lo stesso scenario usando sessioni di messaggi. Per altre informazioni, vedere Stato sessione messaggi.
- bus di servizio code supportano l'inserimento di messaggi non recapitabili. Può essere utile per isolare i messaggi che soddisfano i criteri seguenti:
- I messaggi non possono essere elaborati correttamente dall'applicazione ricevente
- I messaggi non possono raggiungere la destinazione a causa di una proprietà TTL (Time-to-Live) scaduta. Tramite il valore TTL viene specificata la durata del messaggio nella coda. Con il bus di servizio, il messaggio verrà spostato in una coda speciale denominata $DeadLetterQueue allo scadere del periodo TTL.
- Per trovare messaggi "non elaborabili" nelle code di archiviazione, durante la rimozione di un messaggio dalla coda l'applicazione esamina la proprietà DequeueCount del messaggio. Se il valore della proprietà DequeueCount supera la soglia specificata, l'applicazione sposta il messaggio in una coda di "messaggio non recapitabile" definita dall'applicazione.
- Le code di archiviazione consentono di ottenere un log dettagliato di tutte le transazioni eseguite sulla coda e delle metriche aggregate. Queste opzioni sono entrambe utili per il debug e per comprendere in che modo l'applicazione usa le code di archiviazione. Sono utili anche per ottimizzare le prestazioni dell'applicazione e ridurre i costi dell'uso delle code.
- Le sessioni di messaggio supportate da bus di servizio consentono l'associazione di messaggi appartenenti a un gruppo logico a un ricevitore. Crea un'affinità simile alla sessione tra i messaggi e i rispettivi ricevitori. È possibile abilitare questa funzionalità avanzata in bus di servizio impostando la proprietà ID sessione in un messaggio. I destinatari possono quindi restare in ascolto su un ID di sessione specifico e ricevere messaggi in cui viene condiviso l'identificatore di sessione specificato.
- La funzionalità di rilevamento della duplicazione delle code bus di servizio rimuove automaticamente i messaggi duplicati inviati a una coda o a un argomento, in base al valore della proprietà ID messaggio.
Capacità e quote
Questa sezione confronta le code di archiviazione e le code bus di servizio dal punto di vista della capacità e delle quote che potrebbero essere applicate.
| Criteri di confronto | Code di archiviazione | Code del bus di servizio |
|---|---|---|
| Dimensioni massime della coda | 500 TB (limitate alla capacità di un singolo account di archiviazione) |
Da 1 GB a 80 GB (SKU Premium o SKU Standard con partizionamento) |
| Dimensioni massime del messaggio | 64 kB (48 KB quando si usa la codifica Base 64) Azure supporta messaggi di grandi dimensioni combinando code e BLOB. È quindi possibile accodare fino a 200 GB per un unico elemento. |
256 KB, 1 MB o 100 MB (inclusi l'intestazione e il corpo, dimensioni massime dell'intestazione: 64 KB). Dipende dal livello di servizio. |
| Durata TTL massima del messaggio | Infinito (api-version 2017-07-27 o versione successiva) | TimeSpan.MaxValue |
| Numero massimo di code | Illimitato | 10.000 (SKU Standard) 1000/unità di messaggistica (SKU Premium) (per spazio dei nomi del servizio) |
| Numero massimo di client concorrenti | Illimitato | 5,000 |
Informazioni aggiuntive
- Bus di servizio impone l'applicazione dei limiti di dimensione della coda. La dimensione massima della coda viene specificata durante la creazione di una coda. Può essere compreso tra 1 GB e 80 GB. Se le dimensioni della coda raggiungono questo limite, i messaggi in arrivo aggiuntivi verranno rifiutati e il chiamante riceverà un'eccezione. Per altre informazioni sulle quote nel bus di servizio, vedere Quote del bus di servizio.
- Nel livello di messaggistica Standard è possibile creare bus di servizio code e argomenti in 1 (impostazione predefinita), 2, 3, 4 o 5 GB. Quando si abilita il partizionamento nel livello Standard, bus di servizio crea 16 copie (16 partizioni) dell'entità, ognuna delle stesse dimensioni specificate. Di conseguenza, se si crea una coda di dimensioni pari a 5 GB, con 16 partizioni la dimensione massima della coda diventa (5 * 16) = 80 GB. È possibile visualizzare le dimensioni massime della coda o dell'argomento partizionato nella portale di Azure.
- Con le code di archiviazione, se il contenuto del messaggio non è sicuro da XML, deve essere codificato in Base64 . Se per il messaggio non è stata usata la codifica Base64, il payload dell'utente può essere fino a 48 KB, anziché 64.
- Con le code del bus di servizio, ogni messaggio archiviato in una coda è costituito da due parti: un'intestazione e un corpo. Le dimensioni totali del messaggio non possono superare le dimensioni massime del messaggio supportate dal livello di servizio.
- Se le comunicazioni tra client e code del bus di servizio vengono stabilite tramite il protocollo TCP, il numero massimo di connessioni simultanee a una singola coda del bus di servizio è limitato a 100. Questo numero è condiviso tra mittenti e destinatari. Se questa quota viene raggiunta, le richieste di connessioni aggiuntive verranno rifiutate e verrà ricevuta un'eccezione dal codice chiamante. Questo limite non viene imposto ai client che si connettono alle code usando l'API basata su REST.
- Per ridimensionare oltre 10.000 code con bus di servizio SKU Standard o 1000 code/unità di messaggistica con SKU Premium bus di servizio, è anche possibile creare spazi dei nomi aggiuntivi usando il portale di Azure.
Gestione e operazioni
Questa sezione confronta le funzionalità di gestione fornite dalle code di archiviazione e dalle code del bus di servizio.
| Criteri di confronto | Code di archiviazione | Code del bus di servizio |
|---|---|---|
| Protocollo di gestione | REST su HTTP/HTTPS | REST su HTTPS |
| Protocollo runtime | REST su HTTP/HTTPS | REST su HTTPS Standard AMQP 1.0 (TCP con TLS) |
| API .NET | Sì (API client di archiviazione .NET) |
Sì (API del bus di servizio .NET) |
| C++ nativo | Sì | Sì |
| API Java | Sì | Sì |
| API PHP | Sì | Sì |
| API Node.js | Sì | Sì |
| Supporto metadati arbitrario | Sì | No |
| Regole di denominazione delle code | Può contenere fino a 63 caratteri (le lettere del nome di una coda devono essere minuscole). |
Lunghezza fino a 260 caratteri (i percorsi e i nomi di code non fanno distinzione tra maiuscole e minuscole). |
| Funzione di recupero della lunghezza della coda | Sì (valore indicativo se i messaggi scadono dopo il TTL senza essere eliminati). |
Sì (Valore esatto e temporizzato). |
| Funzione di visualizzazione | Sì | Sì |
Informazioni aggiuntive
- Le code di archiviazione forniscono supporto per gli attributi arbitrari applicabili alla descrizione della coda, sotto forma di coppie nome-valore.
- Entrambe le tecnologie di coda consentono di visualizzare un messaggio senza doverlo bloccare. Questa funzionalità può essere utile quando si implementa uno strumento di esplorazione delle code.
- Le API di messaggistica negoziata .NET bus di servizio usano connessioni TCP full duplex per migliorare le prestazioni rispetto a REST su HTTP e supportano il protocollo standard AMQP 1.0.
- I nomi delle code di archiviazione possono avere una lunghezza compresa tra 3 e 63 caratteri e contenere lettere minuscole, numeri e trattini. Per altre informazioni, vedere Naming Queues and Metadata (Denominazione di code e metadati).
- I nomi delle code del bus di servizio possono avere una lunghezza massima di 260 caratteri e presentano regole di denominazione meno restrittive. I nomi delle code del bus di servizio possono contenere lettere, numeri, punti, trattini e caratteri di sottolineatura.
Autenticazione e autorizzazione
Questa sezione illustra le funzionalità di autenticazione e autorizzazione supportate dalle code di archiviazione e dalle code del bus di servizio.
| Criteri di confronto | Code di archiviazione | Code del bus di servizio |
|---|---|---|
| Autenticazione | Chiave simmetrica e controllo degli accessi in base al ruolo | Chiave simmetrica e controllo degli accessi in base al ruolo |
| Federazione del provider di identità | Sì | Sì |
Informazioni aggiuntive
- Ogni richiesta a entrambe le tecnologie di accodamento deve essere autenticata. Le code pubbliche con accesso anonimo non sono supportate.
- Usando l'autenticazione con firma di accesso condiviso è possibile creare una regola di autorizzazione di accesso condiviso in una coda in grado di concedere agli utenti un accesso in sola scrittura, di sola lettura o di accesso completo. Per altre informazioni, vedere Archiviazione di Azure - Autenticazione sas e bus di servizio di Azure - Autenticazione sas.
- Entrambe le code supportano l'autorizzazione dell'accesso tramite Microsoft Entra ID. L'autorizzazione di utenti o applicazioni tramite il token OAuth 2.0 restituito da Microsoft Entra ID offre una maggiore sicurezza e facilità d'uso rispetto alle firme di accesso condiviso (SAS). Con Microsoft Entra ID non è necessario archiviare i token nel codice e rischiare potenziali vulnerabilità di sicurezza. Per altre informazioni, vedere Archiviazione di Azure - Autenticazione di Microsoft Entra e bus di servizio di Azure - Autenticazione di Microsoft Entra.
Conclusione
Acquisendo una conoscenza più approfondita delle due tecnologie, è possibile prendere una decisione più informata sulla tecnologia di accodamento da usare e quando. La decisione su quando usare le code di archiviazione o le code di bus di servizio dipende chiaramente da molti fattori. Questi fattori dipendono in modo elevato dalle singole esigenze dell'applicazione e dalla relativa architettura.
È possibile scegliere code di archiviazione per motivi come quelli seguenti:
- Se l'applicazione usa già le funzionalità principali di Microsoft Azure
- Se è necessaria la comunicazione e la messaggistica di base tra i servizi
- Sono necessarie code con dimensioni superiori a 80 GB
bus di servizio code offrono molte funzionalità avanzate, ad esempio quelle seguenti. Potrebbero quindi essere una scelta preferita se si sta creando un'applicazione ibrida o se l'applicazione richiede in caso contrario queste funzionalità.
- Sessioni
- Transazioni
- Rilevamento duplicati
- Messaggi non recapitabili automatici
- Funzionalità di pubblicazione e sottoscrizione durevoli
Passaggi successivi
Gli articoli seguenti offrono ulteriori indicazioni e informazioni sull'uso delle code di archiviazione e delle code del bus di servizio.