Esporta (0) Stampa
Espandi tutto

Analogie e differenze tra le code di Azure e le code di Service Bus

Aggiornamento: giugno 2014

Autori: Valery Mizonov, Seth Manheim e Abhishek Lal

Collaboratori: Brad Calder, Jai Haridas, Jason Hogg, Jeff Irwin, Jaganathan Thangavelu, Kartik Paramasivam, Todd Holmquist-Sutherland e Ruppert Koch

In questo articolo vengono analizzate le differenze e le analogie presenti tra i due tipi di code offerte attualmente da Azure: code di e code di Service Bus di Microsoft Azure. Grazie a queste informazioni, è possibile confrontare e contrapporre le rispettive tecnologie ed essere quindi in grado di fare una scelta più oculata circa la soluzione che soddisfa meglio le proprie esigenze.

supporta due tipi di meccanismi di code: code di e code di Service Bus.

Le code di , che fanno parte dell'infrastruttura di Archiviazione di Microsoft Azure, offrono un'interfaccia per operazioni di ricezione/inserimento/visualizzazione basata su REST in grado di fornire funzionalità di messaggistica affidabili e persistenti in e tra i servizi.

Le code di Service Bus fanno parte di un'infrastruttura di messaggistica di Azure più ampia che supporta l'accodamento, oltre a modelli di pubblicazione, sottoscrizione, comunicazione remota del servizio Web e integrazione. Per altre informazioni su code di Service Bus, argomenti e inoltri, vedere Panoramica dei modelli di messaggistica supportati da Service Bus.

Anche se entrambe le tecnologie di accodamento sono disponibili contemporaneamente, le code di sono state introdotte prima, come meccanismo dedicato di archiviazione delle code creato in Archiviazione di Microsoft . Le code di Service Bus vengono create nell'infrastruttura di messaggistica negoziata più ampia progettata per integrare applicazioni e componenti delle applicazioni in grado di estendere più protocolli di comunicazione, contratti dati, domini trusted e/o ambienti di rete.

In questo articolo vengono confrontate le due tecnologie di accodamento offerte da , illustrando le differenze di comportamento e implementazione delle funzionalità fornite da ognuna. Nell'articolo sono inoltre disponibili informazioni aggiuntive per la scelta delle funzionalità che possono soddisfare meglio le proprie esigenze di sviluppo di applicazioni.

Sia le code di sia quelle di Service Bus sono implementazioni del servizio di accodamento messaggi attualmente disponibile in . Ciascuna tecnologia presenta un set di funzionalità leggermente diverso, pertanto è possibile scegliere l'una o l'altra, o entrambe, a seconda delle esigenze della particolare soluzione in uso o di un problema aziendale o tecnico da risolvere.

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. Per ulteriori dettagli, vedere la sezione seguente.

Per gli architetti o gli sviluppatori di soluzioni, è consigliabile considerare l'utilizzo delle code di nelle situazioni seguenti:

  • Tramite l'applicazione devono essere archiviati in una coda oltre 80 GB di messaggi la cui durata è inferiore a 7 giorni.

  • Tramite l'applicazione si desidera tenere traccia dello stato dell'elaborazione di un messaggio all'interno della coda. Ciò si rivela utile se si verifica un arresto anomalo del processo di lavoro tramite cui si elabora il messaggio. Queste informazioni possono quindi essere utilizzate in un processo di lavoro successivo per continuare dal punto in cui è stato interrotto il processo di lavoro precedente.

  • A tale scopo, sono inoltre necessari i log sul lato server di tutte le transazioni eseguite nelle code.

Per gli architetti o gli sviluppatori di soluzioni, è consigliabile considerare l'utilizzo delle code di Service Bus nelle situazioni seguenti:

  • Tramite la soluzione deve essere possibile ricevere messaggi senza dover eseguire il polling della coda. Con Service Bus, è possibile ottenere questo risultato mediante l'operazione di ricezione con polling prolungato che utilizza i protocolli basati su TCP supportati da Service Bus.

  • Tramite la soluzione deve essere garantito il recapito ordinato FIFO (First In First Out) da parte della coda.

  • Si desidera una configurazione simmetrica in e su Windows Server (cloud privato). Per altre informazioni, vedere Service Bus for Windows Server (Service Bus 1.1).

  • Tramite la soluzione deve essere possibile eseguire il rilevamento duplicato automatico.

  • Si desidera che l'applicazione elabori i messaggi come flussi paralleli a esecuzione prolungata (i messaggi sono associati a un flusso mediante la proprietà SessionId). In questo modello ciascun 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.

  • Per la soluzione sono necessari atomicità e comportamento transazionale in caso di invio o ricezione di più messaggi da una coda.

  • La caratteristica relativa alla durata (TTL) del carico di lavoro specifico dell'applicazione può superare il periodo di 7 giorni.

  • Tramite l'applicazione vengono gestiti messaggi che possono superare i 64 KB ma che probabilmente non si avvicineranno al limite dei 256 KB.

  • È necessario fornire un modello di accesso basato sui ruoli alle code e autorizzazioni/diritti diversi per mittenti e destinatari.

  • Le dimensioni della coda non aumenteranno più di 80 GB.

  • Si desidera utilizzare il broker di messaggistica basato su standard AMQP 1.0. Per altre informazioni su AMQP, vedere Panoramica di AMQP per Service Bus.

  • È possibile prevedere un'eventuale migrazione dalla comunicazione punto a punto basata sulla coda a un modello di scambio dei messaggi mediante il quale viene garantita un'integrazione continua di destinatari aggiuntivi (sottoscrittori), mediante ognuno dei quali vengono ricevute copie separate di alcuni o di tutti i messaggi inviati alla coda. Quest'ultima viene definita funzionalità di pubblicazione/sottoscrizione a livello nativo fornita da Service Bus.

  • La soluzione di messaggistica deve garantire il recapito "At-Most-Once" senza che sia necessario sviluppare i componenti aggiuntivi dell'infrastruttura.

  • Si desidera essere in grado di pubblicare e utilizzare batch di messaggi.

  • È necessaria l'integrazione completa con lo stack di comunicazione Windows Communication Foundation (WCF) in .

Nelle tabelle delle sezioni riportate di seguito viene fornito un raggruppamento logico delle funzionalità relative alle code e viene offerta la possibilità di un confronto immediato delle funzionalità disponibili sia nelle code di sia in quelle di Service Bus.

In questa sezione vengono confrontate alcune delle funzionalità di accodamento fondamentali fornite dalle code di e da quelle di Service Bus di Microsoft Azure.

 

Criteri di confronto Code di Code di Service Bus

Garanzia di ordinamento

No

Sì, FIFO (First In First Out)

(tramite l'utilizzo di sessioni di messaggistica)

Garanzia di recapito

At-Least-Once

At-Least-Once

At-Most-Once

Supporto per le transazioni

No

(tramite l'utilizzo di transazioni locali)

Comportamento di ricezione

Senza blocco

(completamento immediato in caso di assenza di nuovi messaggi)

Blocco con/senza timeout

(disponibilità di polling prolungato o "tecnica Comet")

Senza blocco

(solo tramite l'utilizzo dell'API gestita .NET)

API di tipo push

No

API gestita .NET di sessioni OnMessage e OnMessage.

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 (durata massima) (È possibile rinnovare o rilasciare un lease di un messaggio utilizzando l'API UpdateMessage.

60 secondi (impostazione predefinita)

È possibile rinnovare il blocco su un messaggio utilizzando l'API RenewLock.

Granularità di lease/blocco

A livello di messaggio

(Ciascun messaggio può avere un valore di timeout diverso. Durante l'elaborazione del messaggio, è possibile aggiornare tale valore nel modo necessario utilizzando l'API UpdateMessage).

A livello di coda

(ogni coda dispone di una granularità di blocco applicata a tutti i relativi messaggi, tuttavia è possibile rinnovare il blocco utilizzando l'API RenewLock).

Ricezione in batch

(specifica esplicita del numero di messaggi durante il recupero di questi ultimi, fino a un massimo di 32 messaggi)

(abilitazione implicita di una proprietà di prelettura o esplicita tramite l'utilizzo di transazioni)

Invio in batch

No

(tramite l'utilizzo di transazioni o invio in batch sul lato client)

  • Se all'utilizzo di blob e tabelle di Archiviazione di Microsoft Azure si affianca quello delle code, viene garantita una disponibilità pari al 99,9%. Se si utilizzando blob e tabelle con code di Service Bus, la disponibilità risulta ridotta.

  • Il modello FIFO garantito delle code di Service Bus richiede l'utilizzo di sessioni di messaggistica. In caso di arresto anomalo dell'applicazione durante l'elaborazione di un messaggio ricevuto nella modalità Peek & Lock, alla prossima accettazione di una sessione di messaggistica da parte di un destinatario di code, l'avvio verrà eseguito con il messaggio non recapitato dopo la scadenza della relativa durata (TTL).

  • Le code di sono progettate per supportare scenari di accodamento standard, ad esempio componenti dell'applicazione per il disaccoppiamento per aumentare la scalabilità e la tolleranza di errore, il livellamento del carico e i flussi di lavoro per la definizione dei processi.

  • Le code di Service Bus supportano la garanzia di recapito At-Least-Once. Inoltre, la semantica At-Most-Once può essere supportata tramite lo stato della sessione per archiviare lo stato dell'applicazione e tramite le transazioni per ricevere i messaggi in modo atomico e aggiornare lo stato della sessione. Questa tecnica viene utilizzata dal servizio Flusso di lavoro di per garantire il recapito con semantica At-Most-Once.

  • Le code di offrono un modello di programmazione uniforme e coerente tra code, tabelle e BLOB, utilizzabile sia dagli sviluppatori sia dai team addetti alle operazioni.

  • Le code di Service Bus offrono supporto per le transazioni locali nel contesto di una singola coda.

  • La modalità Ricezione ed eliminazione supportata da Service Bus 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 forniscono lease con possibilità di estensione per i messaggi. In questo modo i processi di lavoro possono gestire lease brevi nei messaggi. Pertanto, se un processo di lavoro viene arrestato in modo anomalo, il messaggio può essere elaborato di nuovo rapidamente da un altro processo di lavoro. Inoltre, tramite un processo di lavoro è possibile estendere il lease in un messaggio se l'elaborazione di quest'ultimo richiede più tempo del lease corrente.

  • Le code di offrono un timeout di visibilità che può essere impostato durante l'inserimento o la rimozione dalla coda di un messaggio. È inoltre possibile aggiornare un messaggio con valori di lease diversi in fase di esecuzione, nonché aggiornare valori diversi nei messaggi presenti nella stessa coda. I timeout dei blocchi di Service Bus vengono definiti nei metadati della coda. È tuttavia possibile rinnovare il blocco chiamando il metodo RenewLock.

  • Il timeout massimo per un'operazione di ricezione del blocco nelle code di Service Bus è di 24 giorni. I timeout basati su REST, tuttavia, hanno un valore massimo di 55 secondi.

  • La funzionalità di invio in batch sul lato client fornita da Service Bus consente a un client code di inviare in batch più messaggi con una singola operazione. L'invio in batch è disponibile solo per le operazioni di invio asincrone.

  • Caratteristiche quali la capacità massima di 200 TB (capacità ancora superiore se gli account vengono virtualizzati) e la disponibilità in numero illimitato rendono le code di una piattaforma ideale per i provider SaaS.

  • Le code di forniscono un meccanismo di controllo di accesso delegato flessibile ed efficiente.

In questa sezione vengono confrontate le funzionalità avanzate fornite dalle code di e da quelle di Service Bus.

 

Criteri di confronto Code di Code di Service Bus

Recapito pianificato

Mancato recapito automatico dei messaggi

No

Valore TTL aumentato

(tramite aggiornamento sul posto di timeout di visibilità)

(fornito tramite una funzione API dedicata)

Supporto messaggi non elaborabili

Aggiornamento sul posto

Log delle transazioni sul lato server

No

Metriche di archiviazione

Metriche al minuto: fornisce metriche in tempo reale relative a disponibilità, TPS, numero di chiamate API, numero di errori e molto altro (aggregate per minuto e segnalate entro pochi minuti rispetto agli eventi in fase di produzione). Per altre informazioni, vedere Informazioni sulle metriche di Analisi archiviazione.

(query in blocco chiamando GetQueues)

Gestione dello stato

No

Microsoft.ServiceBus.Messaging.EntityStatus.Active, Microsoft.ServiceBus.Messaging.EntityStatus.Disabled, Microsoft.ServiceBus.Messaging.EntityStatus.SendDisabled, Microsoft.ServiceBus.Messaging.EntityStatus.ReceiveDisabled

Inoltro automatico dei messaggi

No

Funzione di eliminazione della coda

No

Gruppi di messaggi

No

(tramite l'utilizzo di sessioni di messaggistica)

Stato dell'applicazione per gruppo di messaggi

No

Rilevamento duplicato

No

(configurabile sul lato del mittente)

Integrazione di WCF

No

(disponibilità di associazioni WCF predefinite)

Integrazione WF

Personalizzato

(compilazione di un'attività WF personalizzata necessaria)

Nativo

(disponibilità di attività WF predefinite)

Esplorazione di gruppi di messaggi

No

Recupero delle sessioni di messaggistica per ID

No

  • Entrambe le tecnologie di accodamento consentono di pianificare il recapito di un messaggio in un momento successivo.

  • La funzionalità di inoltro automatico consente a migliaia di code di inoltrare automaticamente i propri messaggi a una singola coda dalla quale l'applicazione ricevente preleva 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 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 le code di Service Bus è possibile abilitare lo stesso scenario mediante sessioni di messaggistica. Le sessioni consentono di salvare e recuperare lo stato di elaborazione dell'applicazione utilizzando SetState e GetState.

  • Il mancato recapito dei messaggi, funzionalità supportata solo dalle code di Service Bus, può essere utile per isolare i messaggi che non possono essere elaborati correttamente dall'applicazione ricevente o quando i messaggi non possono essere recapitati a causa di una proprietà di durata (TTL) scaduta. Tramite il valore TTL viene specificata la durata del messaggio nella coda. Con Service Bus, il messaggio verrà spostato in una coda speciale chiamata $ DeadLetterQueue allo scadere del periodo TTL.

  • Per trovare messaggi "non elaborabili" nelle code di , durante la rimozione di un messaggio dalla coda, tramite l'applicazione viene esaminata la proprietà DequeueCount del messaggio. Se il valore della proprietà DequeueCount supera il valore di soglia specificato, il messaggio viene spostato dall'applicazione in una coda di "messaggio non recapitabile" definita dall'applicazione.

  • Le code di consentono di ottenere un log dettagliato di tutte le transazioni eseguite nella coda, nonché le metriche di aggregazione. Queste opzioni sono entrambe utili per eseguire il debug e comprendere la modalità di utilizzo delle code di da parte dell'applicazione. Inoltre, sono utili per l'ottimizzazione delle prestazioni dell'applicazione e per la riduzione dei costi di utilizzo delle code.

  • Il concetto di “sessione di messaggistica” supportato da Service Bus consente di associare a uno specifico destinatario i messaggi appartenenti a un determinato gruppo logico. Il destinatario crea a sua volta un'affinità di tipo sessione tra i messaggi e i relativi destinatari. È possibile abilitare questa funzionalità avanzata in Service Bus impostando la proprietà SessionID 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 di duplicazione supportata dalle code di Service Bus rimuove automaticamente i messaggi duplicati inviati a una coda o a un argomento, in base al valore della proprietà MessageID.

In questa sezione vengono confrontate le code di e quelle di Service Bus relativamente alla capacità e alle quote.

 

Criteri di confronto Code di Code di Service Bus

Dimensioni massime della coda

200 TB

(limitate alla capacità di un singolo account di archiviazione)

Da 1 GB a 80 GB

(valori definiti al momento della creazione della coda e dell'abilitazione del partizionamento)

Dimensioni massime del messaggio

64 KB

(48 KB in caso di codifica Base64)

Grazie alla combinazione di code e BLOB, Azure supporta messaggi di grandi dimensioni consentendo di accodare fino a 200 GB per un singolo elemento.

256 KB

(dimensioni massime dell'intestazione, inclusi sia l'intestazione sia il corpo: 64 KB)

Durata TTL massima del messaggio

7 giorni

Illimitato

Numero massimo di code

Illimitato

10,000

(per spazio dei nomi del servizio, può essere aumentato)

Numero massimo di client concorrenti

Illimitato

Illimitato

(limite di 100 connessioni simultanee applicato solo alla comunicazione basata su protocollo TCP)

  • Con le code di , se il contenuto del messaggio non è XML-safe, deve avere la codifica Base64. Se per il messaggio non è stata utilizzata la codifica Base64, il payload dell'utente può essere fino a 48 KB, anziché 64.

  • Con le code di Service Bus, ogni messaggio archiviato in una coda è costituito da due parti: un'intestazione e un corpo. Le dimensioni totali del messaggio non possono superare 256 KB.

  • Se le comunicazioni tra client e code di Service Bus vengono stabilite tramite il protocollo TCP, il numero massimo di connessioni simultanee a una singola coda di Service Bus è limitato a 100. Questo numero è condiviso tra mittenti e destinatari. Se questa quota viene raggiunta, le richieste successive per connessioni aggiuntive saranno rifiutate e dal codice chiamante verrà ricevuta un'eccezione. Questo limite non viene imposto ai client tramite cui viene effettuata la connessione alle code mediante l'API basata su REST.

  • Service Bus impone l'applicazione dei limiti di dimensione. Le dimensioni massime della coda vengono specificate al momento della creazione della coda stessa e possono avere un valore compreso tra 1 e 80 GB. Se viene raggiunto il valore delle dimensioni della coda impostato al momento della creazione, i successivi messaggi in arrivo verranno rifiutati e il codice chiamante riceverà un'eccezione. Per altre informazioni su quote in Service Bus, vedere Quote di Windows Azure Service Bus.

  • Se sono necessarie più di 10.000 code in un singolo Service Bus del spazio dei nomi servizio, è possibile contattare il team di supporto di e richiedere un aumento. Per ridimensionare più di 10.000 code con Service Bus, è inoltre possibile creare spazi dei nomi aggiuntivi del servizio tramite il portale di gestione di .

In questa sezione vengono confrontate le funzionalità di gestione fornite dalle code di e da quelle di Service Bus.

 

Criteri di confronto Code di Code di Service Bus

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 gestita .NET

(API del client di archiviazione gestita .NET)

(API di messaggistica negoziata gestita .NET)

C++ nativo

No

API Java

API PHP

API Node.js

Supporto metadati arbitrario

No

Regole di denominazione delle code

Lunghezza massima pari a 63 caratteri

(le lettere del nome di una coda devono essere minuscole)

Lunghezza massima pari a 260 caratteri

(per i nomi di code non viene fatta distinzione tra maiuscole e minuscole)

Funzione di recupero della lunghezza della coda

(valore indicativo se i messaggi scadono oltre il TTL senza essere eliminati)

(esatto, valore temporizzato)

Funzione di visualizzazione

  • Le code di 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 gestite .NET di messaggistica negoziata di Service Bus utilizzano le connessioni TCP full-duplex per ottenere migliori livelli di prestazioni rispetto a REST su HTTP e supportano il protocollo standard AMQP 1.0.

  • I nomi delle code di possono avere una lunghezza compresa tra 3 e 63 caratteri e contenere lettere minuscole, numeri e trattini. Per altre informazioni, vedere Denominazione di code e metadati.

  • I nomi delle code di Service Bus possono avere una lunghezza massima di 260 caratteri e presentano regole di denominazione meno restrittive. I nomi delle code di Service Bus possono contenere lettere, numeri, punti (.), trattini (-) e caratteri di sottolineatura (_).

In questa sezione vengono confrontate le code di e quelle di Service Bus relativamente alle prestazioni.

 

Criteri di confronto Code di Code di Service Bus

Velocità effettiva massima

Fino a 2.000 messaggi al secondo

(in base al benchmark con messaggi di 1 KB)

Fino a 2.000 messaggi al secondo

(in base al benchmark con messaggi di 1 KB)

Latenza media

10 ms

(con l'algoritmo di Nagle di TCP disabilitato)

20-25 ms

Comportamento di limitazione

Rifiuto con codice HTTP 503

(le richieste limitate non vengono considerate fatturabili)

Rifiuto con eccezione/HTTP 503

(le richieste limitate non vengono considerate fatturabili)

  • Una singola coda di può elaborare fino a 2000 transazioni al secondo. Una transazione è un'operazione Put, Get o Delete. L'invio di un singolo messaggio a una coda (Put) viene contato come una transazione, ma la ricezione di un messaggio è spesso un processo a due passaggi che comporta il recupero (Get), seguito da una richiesta di rimozione del messaggio dalla coda (Delete). Di conseguenza, un'operazione di rimozione dalla coda completata comporta in genere due transazioni. L'impatto di questo inconveniente può essere ridotto mediante il recupero in batch di più messaggi. È infatti possibile eseguire un'operazione di recupero (Get) per un numero massimo di 32 messaggi, seguita da un'operazione di eliminazione (Delete) per ciascuno di essi. Per ottenere una migliore velocità effettiva è possibile creare più code (un account di archiviazione può avere un numero illimitato di code).

  • Quando l'applicazione raggiunge la velocità effettiva massima per una coda di , il servizio di accodamento restituisce in genere un errore HTTP 503 in cui si indica che il server è occupato. In questo caso, tramite l'applicazione deve essere attivata la logica di ripetizione tentativi con ritardo esponenziale backoff.

  • Quando si gestiscono messaggi di piccole dimensioni (minori di 10 KB) da un servizio ospitato ubicato nello stesso percorso (area) dell'account di archiviazione, la latenza media delle code di è 10 millisecondi.

  • Le code di e di Service Bus applicano entrambe il comportamento di limitazione rifiutando richieste a una coda limitata. Tuttavia, le richieste limitate non vengono considerate come fatturabili da entrambi i tipi di code.

  • I benchmark relativi alle code di Service Bus hanno dimostrato che una singola coda può raggiungere una velocità effettiva massima di 2000 messaggi al secondo, per messaggi di dimensioni pari a circa 1 KB. Per ottenere una velocità effettiva più elevata, utilizzare più code. Per ulteriori informazioni sull'ottimizzazione delle prestazioni con Service Bus, vedere Procedure consigliate per il miglioramento delle prestazioni tramite la messaggistica negoziata di Service Bus.

  • Quando l'applicazione raggiunge la la velocità effettiva massima per una coda di Service Bus, al client della coda verrà restituito un messaggio ServerBusyException (se si utilizza l'API gestita .NET di messaggistica negoziata) o HTTP 503 (se si utilizza l'API basata su REST) in cui si indica che la coda è limitata.

In questa sezione vengono illustrate le funzionalità di autenticazione e autorizzazione supportate dalle code di e da quelle di Service Bus.

 

Criteri di confronto Code di Code di Service Bus

Autenticazione

Chiave simmetrica

Chiave simmetrica

Modello di controllo di accesso

Accesso delegato tramite token SAS.

RBAC tramite ACS

Federazione del provider di identità

No

  • Ogni richiesta a entrambe le tecnologie di accodamento deve essere autenticata. Le code pubbliche con accesso anonimo non sono supportate. L'utilizzo di SAS consente di ovviare a questo inconveniente mediante la pubblicazione di un SAS di sola scrittura, di sola lettura o anche di accesso completo.

  • Lo schema di autenticazione fornito dalle code di prevede l'utilizzo di una chiave simmetrica, ovvero un codice HMAC (Hash Message Authentication Code) calcolato dall'algoritmo SHA-256 e codificato come stringa Base64. Per altre informazioni su sul relativo protocollo. Vedere Autenticazione dell'accesso all'account di archiviazione di Azure. Le code di Service Bus supportano un modello simile mediante l'utilizzo di chiavi simmetriche. Per altre informazioni, vedere Autenticazione della firma di accesso condiviso con Service Bus.

  • Il Microsoft Azure Active Directory Access Control (anche noto come Servizio di controllo di accesso o ACS) supportato da Service Bus offre tre ruoli distinti: ruolo di amministratore, ruolo di mittente e ruolo di destinatario, quest'ultimo attualmente non supportato per le code di .

  • Poiché Service Bus offre l'integrazione di ACS, è possibile eseguire la federazione con Active Directory (tramite l'utilizzo di AFDS) e provider di identità Web comuni quali Live ID, Google, Facebook e Yahoo.

In questa sezione vengono confrontate le code di e quelle di Service Bus relativamente ai costi.

 

Criteri di confronto Code di Code di Service Bus

Costo della transazione della coda

$0.0005

(per 10.000 transazioni)

$0.01

(per 10.000 messaggi)

Operazioni fatturabili

All

Solo invio/ricezione

(nessun addebito per altre operazioni)

Transazioni inattive

Fatturabile

(l'esecuzione di query su una coda vuota viene contata come transazione fatturabile)

Fatturabile

(una ricezione in una coda vuota è considerata un messaggio fatturabile)

Costo di archiviazione

$0.07

(per GB/mese)

$0.00

Costi di trasferimento dei dati in uscita

$0.12 - $0.19

(a seconda dell'area geografica)

$0.12 - $0.19

(a seconda dell'area geografica)

  • I trasferimenti dei dati vengono addebitati in base alla quantità totale di dati che vengono trasferiti dai data center di tramite Internet in un determinato periodo di fatturazione.

  • I trasferimenti dei dati tra servizi di ubicati all'interno della stessa area non sono soggetti ad addebito.

  • Al momento della stesura di questo documento, tutti i trasferimenti dei dati in ingresso non sono soggetti ad addebito.

  • Quando si effettuano operazioni di messaggistica su code di Service Bus, il costo delle transazioni ACS è trascurabile. Service Bus acquisisce un token ACS per una singola istanza dell'oggetto factory di messaggistica. Il token viene quindi riutilizzato fino alla scadenza, dopo circa 20 minuti. Pertanto, il volume di operazioni di messaggistica in Service Bus non è direttamente proporzionale alla quantità di transazioni ACS necessarie per supportare queste operazioni.

  • In base al supporto per polling prolungato, l'utilizzo di code di Service Bus può essere economicamente conveniente in situazioni in cui è richiesto il recapito a bassa latenza.

noteNota
Tutti i costi sono soggetti a modifica. Nella tabella sopra indicata sono riportati i prezzi correnti al momento della stesura di questo articolo e non sono incluse eventuali offerte promozionali che possono essere attualmente disponibili. Per informazioni aggiornate sui prezzi, vedere la pagina relativa alla panoramica dei prezzi.

La scelta di utilizzare le code di o quelle di Service Bus si basa chiaramente su diversi fattori che possono dipendere soprattutto dalla singole esigenze dell'applicazione in uso e dalla relativa architettura. Se l'applicazione utilizza già le funzionalità principali di , è possibile scegliere le code di , specialmente se sono richieste la comunicazione e la messaggistica di base tra servizi o se sono necessarie code che possono avere dimensioni maggiori di 80 GB.

Poiché offrono numerose funzionalità avanzate quali sessioni, transazioni rilevamento duplicato, mancato recapito automatico dei messaggi e funzionalità di pubblicazione e sottoscrizione permanente, le code di Service Bus possono rappresentare la soluzione migliore quando si sviluppa un'applicazione ibrida o se l'applicazione in uso richiede comunque tali funzionalità.

Nella parte iniziale di questo articolo è stato presentato un riepilogo di indicazioni normative. Successivamente, sono state elencate e confrontate le funzionalità di ogni tecnologia di accodamento offerta attualmente da . Elencando le diverse funzionalità in gruppi che ne descrivono l'utilizzo e le caratteristiche, l'articolo presenta un'analisi side-by-side mediante tabelle di facile consultazione che consentono di comprendere le analogie e le differenze tra le code di e quelle di Service Bus. Acquisendo una comprensione più profonda delle due tecnologie, si sarà in grado di prendere una decisione più oculata circa la tecnologia di coda da utilizzare e il momento in cui adottarla.

Vedere anche

Microsoft sta conducendo un sondaggio in linea per comprendere l'opinione degli utenti in merito al sito Web di MSDN. Se si sceglie di partecipare, quando si lascia il sito Web di MSDN verrà visualizzato il sondaggio in linea.

Si desidera partecipare?
Mostra:
© 2014 Microsoft