Modelli di messaggistica asincrona e disponibilità elevata

La messaggistica asincrona può essere implementata in molti modi diversi. Con code, argomenti e sottoscrizioni, il bus di servizio di Azure supporta la messaggistica asincrona tramite un meccanismo di archiviazione e inoltro. In un'operazione normale (sincrona) i messaggi vengono inviati a code e argomenti e ricevuti da code e sottoscrizioni. Le applicazioni create dipendono dalla disponibilità continua di queste entità. Quando l'integrità dell'entità cambia a causa di diverse circostanze, è necessario fornire un'entità a capacità limitata che possa soddisfare la maggior parte delle esigenze.

In genere, le applicazioni usano modelli di messaggistica asincrona per consentire diversi scenari di comunicazione. È possibile creare applicazioni in cui i client possono inviare messaggi ai servizi anche quando questi non sono in esecuzione. Per le applicazioni che riscontrano picchi di comunicazioni, una coda può aiutare a livellare il carico fornendo una posizione per memorizzare nel buffer le comunicazioni. Infine è possibile ottenere un semplice ma efficace servizio di bilanciamento del carico per distribuire i messaggi tra più computer.

Per mantenere la disponibilità di una qualsiasi di queste entità, è necessario considerare i diversi casi in cui le entità possono risultare non disponibili per un sistema di messaggistica permanente. In generale, si noterà che l'entità non è più disponibile per le applicazioni scritte nei modi seguenti:

• Impossibilità di inviare messaggi.
• Impossibilità di ricevere messaggi.
• Impossibilità di gestire le entità, ad esempio eseguire operazioni di creazione, recupero, aggiornamento o eliminazione.
• Impossibilità di contattare il servizio.

Per ognuno di questi problemi, esistono diverse modalità di errore che consentono a un'applicazione di continuare a funzionare a un certo livello di capacità limitata. Ad esempio, un sistema che può inviare messaggi, ma non riceverli, e continuare comunque a ricevere ordini dai clienti senza però poterli elaborare. Questo argomento illustra i problemi che possono verificarsi e le tecniche per attenuarne gli effetti. Nel bus di servizio sono state introdotte numerose misure di prevenzione che richiedono un consenso esplicito, le cui regole d'uso sono illustrate in questo argomento.

Affidabilità nel bus di servizio

Sono disponibili diverse modalità di gestione dei problemi relativi a entità e messaggi, oltre a linee guida per l'utilizzo appropriato di queste misure di prevenzione. Per comprendere le linee guida, è necessario comprendere prima di tutto i motivi per cui nel bus di servizio si possono verificare errori. Considerata la progettazione dei sistemi Azure, tutti questi problemi sono in genere di breve durata. Ad alto livello, le diverse cause della mancata disponibilità si manifestano nei modi seguenti:

• Limitazione da un sistema esterno dal quale dipende il bus di servizio. La limitazione è generata da interazioni con le risorse di archiviazione e calcolo.
• Problema dovuto a un sistema dal quale dipende il bus di servizio. Ad esempio, problemi che possono verificarsi in una determinata risorsa di archiviazione.
• Errore del bus di servizio in un singolo sottosistema. In questo caso, è possibile che un nodo di calcolo si trovi in uno stato incoerente e debba essere riavviato, causando il bilanciamento del carico in altri nodi di tutte le entità servite. Questa situazione può causare a sua volta un breve periodo di elaborazione lenta dei messaggi.
• Errore del bus di servizio all'interno di un data center di Azure. Questo è un "errore irreversibile" durante il quale il sistema risulta irraggiungibile per diversi minuti o per alcune ore.

Nel bus di servizio sono disponibili diverse misure di prevenzione per questi problemi. Le sezioni seguenti illustrano ogni problema e le relative misure di prevenzione.

Limitazione

Nel bus di servizio la limitazione consente la gestione congiunta della frequenza dei messaggi. Ogni singolo nodo del bus di servizio ospita molte entità, ognuna delle quali invia richieste al sistema in termini di CPU, memoria, archiviazione e altri facet. Quando uno di questi facet individua un utilizzo superiore alla soglia predefinita, il bus di servizio può negare una richiesta specifica. Il chiamante riceve un'eccezione server occupata e riprova dopo 10 secondi.

Come misura di prevenzione, il codice deve leggere l'errore e bloccare ogni nuovo tentativo del messaggio per almeno 10 secondi. Poiché l'errore può verificarsi in più parti dell'applicazione del cliente, è previsto che ogni parte esegui in modo indipendente la logica di ripetizione dei tentativi. Il codice può ridurre la probabilità di essere limitato abilitando il partizionamento in uno spazio dei nomi, una coda o un argomento.

Per altre informazioni sul modo in cui il codice dell'applicazione deve gestire i problemi di limitazione, vedere la documentazione sul modello di limitazione.

Problema per una dipendenza di Azure

Anche per altri componenti di Azure possono occasionalmente verificarsi problemi di servizio. Quando, ad esempio, si aggiorna un sistema usato dal bus di servizio, è possibile che il sistema funzioni temporaneamente con capacità limitate. Per risolvere questo tipo di problemi, il bus di servizio analizza e implementa regolarmente le misure di prevenzione. È tuttavia possibile che si verifichino effetti collaterali di misure di prevenzione. Ad esempio, per gestire problemi temporanei con l'archiviazione, il bus di servizio implementa un sistema che consente il funzionamento uniforme delle operazioni di invio dei messaggi. Considerata la natura della misura di prevenzione, un messaggio inviato può impiegare fino a 15 minuti prima di essere visualizzato nella sottoscrizione o nella coda interessata ed essere pronto per un'operazione di ricezione. In genere, la maggior parte delle entità non è interessata da questo problema. Dato tuttavia il numero di entità presenti nel bus di servizio all'interno di Azure, questa misura di prevenzione può essere utile a volte per un limitato sottoinsieme di clienti del bus di servizio.

Errore del bus di servizio in un singolo sottosistema

In qualsiasi applicazione possono verificarsi casi in cui un componente interno del bus di servizio diventa incoerente. Quando il bus di servizio rileva questo problema, raccoglie dati dall'applicazione a fini diagnostici. Una volta raccolti i dati, l'applicazione viene riavviata nel tentativo di ripristinarne un stato coerente. Questo processo avviene abbastanza velocemente e causa la mancata disponibilità di un'entità per alcuni minuti, anche se in genere i tempi di inattività sono molto più brevi.

In questi casi, l'applicazione client genera un'eccezione di timeout o un'eccezione di messaggistica. Il bus di servizio include una misura di prevenzione per questo problema basata sulla logica di ripetizione automatica dei tentativi del client. Al termine del periodo di ripetizione, se il messaggio non è stato recapitato, è possibile provare a usare altre funzionalità citate nell'articolo sulla gestione delle interruzioni e delle emergenze.

Passaggi successivi

Dopo avere appreso le nozioni di base della messaggistica asincrona nel bus di servizio, vedere le altre informazioni sulla gestione delle interruzioni e delle emergenze.