Consigli per la gestione degli errori temporanei

Questa guida descrive i consigli per la gestione degli errori temporanei nelle applicazioni cloud. Tutte le applicazioni che comunicano con servizi e risorse remoti devono essere sensibili agli errori temporanei. Ciò è particolarmente vero per le applicazioni eseguite nel cloud, dove, a causa della natura dell'ambiente e della connettività Internet, è probabile che questo tipo di errore venga riscontrato più spesso. Gli errori temporanei includono la perdita momentanea di connettività di rete a componenti e servizi, la temporanea indisponibilità di un servizio e i timeout che si verificano quando un servizio è occupato. Questi errori spesso si correggono automaticamente, quindi, se l'azione viene ripetuta dopo un adeguato ritardo, è probabile che abbia successo.

Questo articolo fornisce indicazioni generali per la gestione degli errori temporanei. Per informazioni sull'implementazione di nuovi tentativi nel codice dell'applicazione per gestire gli errori temporanei, vedere il modello di ripetizione dei tentativi e quando si usano i servizi di Azure, vedere le linee guida per i tentativi per i servizi di Azure.

Errori temporanei

Gli errori temporanei possono verificarsi in qualsiasi ambiente, su qualsiasi piattaforma o sistema operativo e in qualsiasi tipo di applicazione. Per le soluzioni eseguite nell'infrastruttura locale locale, le prestazioni e la disponibilità dell'applicazione e dei relativi componenti vengono in genere mantenute tramite ridondanza hardware costosa e spesso sottoutilata e i componenti e le risorse si trovano vicini tra loro. Questo approccio rende meno probabile l'errore, ma possono verificarsi errori temporanei, in quanto possono verificarsi interruzioni causate da eventi imprevisti come l'alimentatore esterno o i problemi di rete o scenari di emergenza.

L'hosting cloud, inclusi i sistemi cloud privati, può offrire una maggiore disponibilità complessiva usando risorse condivise, ridondanza, failover automatico e allocazione dinamica delle risorse in molti nodi di calcolo di base. Tuttavia, a causa della natura degli ambienti cloud, è più probabile che si verifichino errori temporanei. Esistono diversi motivi per questo:

• Molte risorse in un ambiente cloud vengono condivise e l'accesso a queste risorse è soggetto a limitazioni per proteggere le risorse. Alcuni servizi rifiutano le connessioni quando il carico aumenta a un livello specifico o quando viene raggiunta una velocità effettiva massima, per consentire l'elaborazione delle richieste esistenti e mantenere le prestazioni del servizio per tutti gli utenti. La limitazione consente di mantenere la qualità del servizio per gli utenti vicini e altri clienti che usano la risorsa condivisa.

• Gli ambienti cloud usano un numero elevato di unità hardware di base. Offrono prestazioni distribuendo dinamicamente il carico tra più unità di calcolo e componenti dell'infrastruttura. Offrono affidabilità riciclando o sostituendo automaticamente le unità non riuscite. A causa di questa natura dinamica, possono verificarsi occasionalmente errori temporanei e guasti di connessione.

• Sono spesso presenti più componenti hardware, tra cui l'infrastruttura di rete, ad esempio router e servizi di bilanciamento del carico, tra l'applicazione e le risorse e i servizi usati. Questa infrastruttura aggiuntiva può talvolta introdurre altri errori di connessione e latenza di connessione temporanei.

• Le condizioni di rete tra il client e il server potrebbero essere variabili, soprattutto quando la comunicazione attraversa Internet. Anche nelle posizioni locali, i carichi di traffico pesanti possono rallentare la comunicazione e causare errori di connessione intermittenti.

Gli errori temporanei possono avere un effetto significativo sulla disponibilità percepita di un'applicazione, anche se è stata testata approfonditamente in tutte le circostanze prevedibili. Per garantire che le applicazioni ospitate nel cloud funzionino in modo affidabile, è necessario assicurarsi che possano rispondere alle sfide seguenti:

• L'applicazione deve essere in grado di rilevare gli errori quando si verificano e determinare se è probabile che siano transitori, di lunga durata o guasti terminali. È probabile che risorse diverse restituiscano risposte diverse quando si verifica un errore e queste risposte possono anche variare a seconda del contesto dell'operazione. Ad esempio, la risposta per un errore quando l'applicazione legge dall'archiviazione potrebbe differire dalla risposta per un errore durante la scrittura nell'archiviazione. Molte risorse e servizi hanno contratti relativi a errori temporanei ben documentati. Tuttavia, quando tali informazioni non sono disponibili, può essere difficile individuare la natura dell'errore e se è probabile che sia temporaneo.

• L'applicazione deve essere in grado di ritentare l'operazione se determina che è probabile che l'errore sia temporaneo. Deve inoltre tenere traccia del numero di tentativi di esecuzione dell'operazione.

• L'applicazione deve utilizzare una strategia appropriata per i nuovi tentativi. La strategia specifica il numero di tentativi dell'applicazione, il ritardo tra ogni tentativo e le azioni da intraprendere dopo un tentativo fallito. Il numero appropriato di tentativi e il ritardo tra ciascuno di essi sono spesso difficili da determinare. La strategia varia a seconda del tipo di risorsa e delle attuali condizioni operative della risorsa e dell'applicazione.

Le seguenti linee guida possono aiutarti a progettare meccanismi di gestione degli errori temporanei adatti alle tue applicazioni.

Implementazione di nuovi tentativi

Determina se è presente un meccanismo di ripetizione integrato

• Molti servizi forniscono un SDK o una libreria client che contiene un meccanismo di gestione degli errori temporanei. I criteri di ripetizione dei tentativi utilizzati sono in genere adattati alla natura e ai requisiti del servizio di destinazione. In alternativa, le interfacce REST per i servizi potrebbero restituire informazioni che possono aiutare a determinare se un nuovo tentativo è appropriato e quanto tempo attendere prima del successivo tentativo.

• È consigliabile utilizzare il meccanismo di ripetizione dei tentativi integrato quando disponibile, a meno che non si disponga di requisiti specifici e ben compresi che rendano più appropriato un comportamento di ripetizione diverso.

Determina se l'operazione è adatta per riprovare

• Esegui le operazioni per un nuovo tentativo solo quando gli errori sono temporanei (in genere indicati dalla natura dell'errore) e quando esiste almeno una certa probabilità che l'operazione abbia esito positivo quando viene ripetuta. Non è possibile ripetere le operazioni che tentano un'operazione non valida, ad esempio un aggiornamento del database a un elemento che non esiste o una richiesta a un servizio o a una risorsa che ha subito un errore irreversibile.

• In generale, implementare nuovi tentativi solo quando è possibile determinare l'effetto completo di questa operazione e quando le condizioni sono ben comprensibili e possono essere convalidate. In caso contrario, lasciare che il codice chiamante implementi i ritentativi. Ricorda che gli errori restituiti da risorse e servizi al di fuori del tuo controllo potrebbero evolversi nel tempo e potrebbe essere necessario rivedere la logica di rilevamento degli errori temporanei.

• Quando si creano servizi o componenti, è consigliabile implementare codici di errore e messaggi che consentono ai client di determinare se devono ripetere le operazioni non riuscite. In particolare, indicare se il client deve ritentare l'operazione (ad esempio restituendo un valore isTransient ) e suggerire un ritardo appropriato prima del successivo tentativo di ripetizione. Se crei un servizio Web, valuta la possibilità di restituire errori personalizzati definiti nei contratti di servizio. Anche se i client generici potrebbero non essere in grado di leggere questi errori, sono utili per la creazione di client personalizzati.

Determina un conteggio e un intervallo di tentativi appropriati

• Ottimizza il conteggio dei tentativi e l'intervallo in base al tipo di caso d'uso. Se non riprovi abbastanza volte, l'applicazione non potrà completare l'operazione e probabilmente fallirà. Se si ritenta un numero eccessivo di tentativi o con un intervallo troppo breve tra tentativi, l'applicazione potrebbe contenere risorse come thread, connessioni e memoria per lunghi periodi, che influiscono negativamente sull'integrità dell'applicazione.

• Adatta i valori per l'intervallo di tempo e il numero di tentativi al tipo di operazione. Ad esempio, se l'operazione fa parte di un'interazione con l'utente, l'intervallo dovrebbe essere breve e dovrebbero essere effettuati solo pochi tentativi. Usando questo approccio, è possibile evitare di rendere gli utenti in attesa di una risposta, che contiene connessioni aperte e può ridurre la disponibilità per altri utenti. Se l'operazione fa parte di un flusso di lavoro a esecuzione prolungata o critica, in cui l'annullamento e il riavvio del processo richiede molto tempo, è opportuno attendere più tempo tra i tentativi e riprovare più volte.

• Tieni presente che determinare gli intervalli appropriati tra i tentativi è la parte più difficile della progettazione di una strategia di successo. Le strategie tipiche utilizzano i seguenti tipi di intervallo tra i tentativi:

  • Back-off esponenziale. L'applicazione attende qualche istante prima del primo tentativo e poi aumenta esponenzialmente il tempo tra ogni tentativo successivo. Ad esempio, potrebbe ritentare l'operazione dopo 3 secondi, 12 secondi, 30 secondi e così via. Per migliorare ulteriormente questa strategia, è possibile aggiungere jitter al back-off esponenziale. Jitter introduce un ritardo casuale per ogni tentativo di ripetizione, che consente di impedire a più client di riprovare contemporaneamente e causare un picco di carico

  • Intervalli incrementali. L'applicazione attende un breve periodo di tempo prima del primo tentativo e quindi aumenta in modo incrementale il tempo tra ogni tentativo successivo. Ad esempio, potrebbe ritentare l'operazione dopo 3 secondi, 7 secondi, 13 secondi e così via.

  • Intervalli regolari. L'applicazione attende lo stesso periodo di tempo tra ogni tentativo. Ad esempio, potrebbe ritentare l'operazione ogni 3 secondi.

  • Nuovo tentativo immediato. A volte un errore temporaneo è breve, probabilmente causato da un evento come un conflitto di pacchetti di rete o un picco in un componente hardware. In questo caso, ritentare immediatamente l'operazione è appropriato perché potrebbe avere esito positivo se l'errore viene cancellato nel tempo necessario all'applicazione per assemblare e inviare la richiesta successiva. Tuttavia, non dovrebbe mai esserci più di un tentativo di nuovo tentativo immediato. È consigliabile passare a strategie alternative, ad esempio azioni di back-off esponenziale o di fallback, se il tentativo immediato non riesce.

  • Randomizzazione. Una delle strategie di ripetizione dei tentativi elencate in precedenza può includere una casualizzazione per impedire che più istanze del client inviino tentativi successivi contemporaneamente. Ad esempio, un'istanza potrebbe ritentare l'operazione dopo 3 secondi, 11 secondi, 28 secondi e così via, mentre un'altra istanza potrebbe ritentare l'operazione dopo 4 secondi, 12 secondi, 26 secondi e così via. La randomizzazione è una tecnica utile che può essere combinata con altre strategie.

• Come linea guida generale, usare un backoff esponenziale con strategia di jitter per le operazioni in background e usare strategie di retry immediato o a intervallo regolare per le operazioni interattive. In entrambi i casi, è consigliabile scegliere il ritardo e il numero di tentativi in modo che la latenza massima per tutti i tentativi rientri nei requisiti di latenza end-to-end richiesti.

• Prendere in considerazione la combinazione di tutti i fattori che contribuiscono al timeout massimo complessivo per un'operazione ritentata. Questi fattori includono il tempo necessario per una connessione non riuscita per produrre una risposta (in genere impostata da un valore di timeout nel client), il ritardo tra i tentativi di ripetizione e il numero massimo di tentativi. La somma di tutti questi tempi può comportare tempi operativi complessivi lunghi, soprattutto quando si utilizza una strategia di ritardo esponenziale in cui l'intervallo tra i tentativi aumenta rapidamente dopo ogni errore. Se un processo deve soddisfare uno specifico contratto di servizio, il tempo operativo complessivo, inclusi tutti i timeout e i ritardi, deve rientrare nei limiti definiti nel contratto di servizio.

• Non implementare strategie di ripetizione eccessivamente aggressive. Si tratta di strategie che hanno intervalli troppo brevi o tentativi troppo frequenti. Possono avere un effetto negativo sulla risorsa o sul servizio di destinazione. Queste strategie potrebbero impedire il ripristino della risorsa o del servizio dallo stato di sovraccarico e continuerà a bloccare o rifiutare le richieste. Questo scenario si traduce in un circolo vizioso, in cui sempre più richieste vengono inviate alla risorsa o al servizio. Di conseguenza, la sua capacità di recupero è ulteriormente ridotta.

• Tenere conto del timeout delle operazioni quando si sceglie intervalli di ripetizione dei tentativi per evitare di avviare immediatamente un tentativo successivo( ad esempio, se il periodo di timeout è simile all'intervallo di ripetizione dei tentativi). Valutare anche se è necessario mantenere il periodo totale possibile (il timeout più gli intervalli di ripetizione dei tentativi) al di sotto di un tempo totale specifico. Se un'operazione presenta un timeout insolitamente breve o lungo, il timeout potrebbe influire sulla durata dell'attesa e sulla frequenza con cui ripetere l'operazione.

• Usare il tipo dell'eccezione e i dati contenuti o i codici di errore e i messaggi restituiti dal servizio per ottimizzare il numero di tentativi e l'intervallo tra di essi. Ad esempio, alcune eccezioni o codici errore (come il codice HTTP 503, Servizio non disponibile, con un'intestazione Retry-After nella risposta) potrebbero indicare quanto tempo potrebbe durare l'errore o che il servizio non è riuscito e non risponderà ad alcun successivo tentativo.

• Prendere in considerazione l'uso di un approccio alla coda di messaggi non recapitati per garantire che tutte le informazioni della chiamata in ingresso non vadano perse dopo che tutti i tentativi sono stati esauriti.

Evita anti-criteri

• Nella maggior parte dei casi, evita le implementazioni che includono livelli duplicati di codice di ripetizione. Evitare progettazioni che includono meccanismi di ripetizione dei tentativi a catena o che implementano nuovi tentativi in ogni fase di un'operazione che implica una gerarchia di richieste, a meno che non si disponga di requisiti specifici che richiedono tale operazione. In queste circostanze eccezionali, utilizza criteri che impediscano un numero eccessivo di tentativi e periodi di ritardo e assicurati di comprenderne le conseguenze. Ad esempio, supponiamo che un componente effettui una richiesta a un altro, che quindi accede al servizio di destinazione. Se implementi i tentativi con un conteggio di tre su entrambe le chiamate, ci sono nove tentativi in totale sul servizio. Molti servizi e risorse implementano un meccanismo di tentativi integrato. È consigliabile indagare su come disabilitare o modificare questi meccanismi se hai bisogno di implementare nuovi tentativi a un livello superiore.

• Non implementare mai un meccanismo di tentativi infiniti. Ciò potrebbe impedire il ripristino della risorsa o del servizio da situazioni di sovraccarico e causare limitazioni e connessioni rifiutate per un periodo di tempo più lungo. Usare un numero finito di tentativi o implementare un modello come Circuit Breaker per consentire al servizio di recuperare.

• Non eseguire mai un tentativo immediato più di una volta.

• Evitare di usare un intervallo regolare per i tentativi di ripetizione quando si accede a servizi e risorse in Azure, soprattutto quando si ha un numero elevato di tentativi. L'approccio migliore in questo scenario è una strategia di back-off esponenziale con funzionalità di interruzione del circuito.

• Impedire a più istanze dello stesso client o a più istanze di client diversi di inviare nuovi tentativi contemporaneamente. Se questo scenario è probabile che si verifichi, introdurre la casualizzazione negli intervalli di ripetizione dei tentativi.

Testare le strategie e l'implementazione dei tentativi di ripetizione

• Testa completamente la tua strategia di ripetizione nel più ampio insieme di circostanze possibile, soprattutto quando sia l'applicazione che le risorse o i servizi di destinazione utilizzati sono sottoposti a un carico estremo. Per verificare il comportamento durante il test, puoi:

  • Includere errori temporanei nella ingegneria del caos e nelle pratiche di iniezione dei guasti introducendoli intenzionalmente negli ambienti non di produzione e produzione. Ad esempio, invia richieste non valide o aggiungi codice che rilevi richieste di test e risponda con diversi tipi di errori.

  • Crea un modello della risorsa o del servizio che restituisca una serie di errori che il servizio reale potrebbe restituire. Copri tutti i tipi di errori che la tua strategia di ripetizione è progettata per rilevare.

  • Per i servizi personalizzati creati e distribuiti, forza il verificarsi di errori temporanei disabilitando o sovraccaricando temporaneamente il servizio. (Non tentare di sovraccaricare risorse condivise o servizi condivisi in Azure).

  • Usare librerie o soluzioni che intercettano e modificano il traffico di rete per replicare scenari sfavorevoli dai test automatizzati. Ad esempio, i test possono aggiungere tempi di round trip aggiuntivi, eliminare pacchetti, modificare le intestazioni o persino modificare il corpo della richiesta stessa. In questo modo è possibile eseguire test deterministici di un subset delle condizioni di errore, per errori temporanei e altri tipi di errori.

  • Quando testi la resilienza di un'applicazione Web client agli errori temporanei, utilizza gli strumenti di sviluppo del browser o la capacità del tuo framework di test per inserire in modo fittizio o bloccare richieste di rete.

  • Eseguire test simultanei e fattori di carico elevati per garantire che il meccanismo e la strategia di ripetizione dei tentativi funzionino correttamente in queste condizioni. Questi test aiutano inoltre a garantire che il nuovo tentativo non abbia un effetto negativo sul funzionamento del client o causi contaminazione incrociata tra le richieste.

Gestire le configurazioni dei criteri di ripetizione

• Un criterio di ripetizione è una combinazione di tutti gli elementi della tua strategia di ripetizione. Definisce il meccanismo di rilevamento che determina se è probabile che un errore sia temporaneo, il tipo di intervallo da usare (ad esempio, back-off esponenziale regolare e casualizzazione), i valori effettivi dell'intervallo e il numero di tentativi.

• Implementare i ritentativi in molti punti, anche nell'applicazione più semplice e a ogni livello delle applicazioni più complesse. Invece di hard-codificare gli elementi di ogni politica in più posizioni, è consigliabile usare un'unica posizione centrale per archiviare tutte le politiche. Ad esempio, archiviare valori come l'intervallo e il numero di tentativi nei file di configurazione dell'applicazione, leggerli in fase di esecuzione e compilare i criteri di ripetizione dei tentativi a livello di codice. In questo modo è più semplice gestire le impostazioni e modificare e ottimizzare i valori per rispondere ai requisiti e agli scenari mutevoli. Tuttavia, progettare il sistema per archiviare i valori anziché rileggere un file di configurazione ogni volta e usare valori predefiniti appropriati se i valori non possono essere ottenuti dalla configurazione.

• Archiviare i valori usati per compilare i criteri di ripetizione dei tentativi in fase di esecuzione nel sistema di configurazione dell'applicazione in modo da poterli modificare senza dover riavviare l'applicazione.

• Sfruttare le strategie di ripetizione integrate o predefinite disponibili nelle API client usate, ma solo quando sono appropriate per il tuo scenario. Queste strategie sono in genere generiche. In alcuni scenari potrebbero essere tutto ciò di cui hai bisogno, ma in altri scenari non offrono la gamma completa di opzioni per soddisfare le tue esigenze specifiche. Per determinare i valori più appropriati, è necessario eseguire dei test per comprendere in che modo le impostazioni influiscono sull'applicazione.

Registra e monitora gli errori temporanei e non temporanei

• Nell'ambito della strategia di ripetizione dei tentativi, includi la gestione delle eccezioni e altri strumenti che registrano i tentativi. Sono previsti errori temporanei occasionali e nuovi tentativi che non indicano un problema. Un numero regolare e crescente di tentativi, tuttavia, è spesso un indicatore di un problema che potrebbe causare un errore o ridurre le prestazioni e la disponibilità dell'applicazione.

• Registra gli errori temporanei come voci di avviso anziché come voci di errore in modo che i sistemi di monitoraggio non li rilevino come errori dell'applicazione che potrebbero attivare falsi avvisi.

• Valuta la possibilità di archiviare un valore nelle voci di log che indichi se i nuovi tentativi sono causati dalla limitazione del servizio o da altri tipi di errori, come errori di connessione, in modo da poterli differenziare durante l'analisi dei dati. Un aumento del numero di errori di limitazione è spesso un indicatore di un difetto di progettazione nell'applicazione o la necessità di passare a un servizio Premium che offre hardware dedicato.

• Valutare e registrare i tempi complessivi trascorsi per le operazioni che includono un meccanismo di ripetizione dei tentativi. Questa metrica è un buon indicatore dell'effetto complessivo degli errori temporanei nei tempi di risposta dell'utente, nella latenza dei processi e nell'efficienza dei casi d'uso delle applicazioni. Registrare anche il numero di tentativi che si verificano in modo da poter comprendere i fattori che contribuiscono al tempo di risposta.

• Prendi in considerazione l'implementazione di un sistema di telemetria e monitoraggio in grado di generare avvisi quando aumenta il numero e il tasso di errori, il numero medio di tentativi o il tempo complessivo trascorso prima che le operazioni abbiano successo.

Gestire le operazioni con errori continui

• Considera come gestire le operazioni che continuano a fallire ad ogni tentativo. Situazioni come questa sono inevitabili.

  • Anche se una strategia di ripetizione dei tentativi definisce il numero massimo di tentativi di ripetizione di un'operazione, non impedisce all'applicazione di ripetere l'operazione con lo stesso numero di tentativi. Ad esempio, se un servizio di elaborazione degli ordini fallisce con un errore irreversibile che lo mette fuori uso in modo permanente, la strategia di ripetizione dei tentativi potrebbe rilevare un timeout di connessione e considerarlo un errore transitorio. Il codice ritenta l'operazione un numero specificato di volte e quindi rinuncia. Tuttavia, quando un altro cliente effettua un ordine, l'operazione viene tentata di nuovo, anche se avrà esito negativo ogni volta.

  • Per evitare tentativi continui nelle operazioni che falliscono ripetutamente, è consigliabile implementare il Circuit Breaker pattern . Quando si usa questo modello, se il numero di errori all'interno di un intervallo di tempo specificato supera una soglia, le richieste tornano immediatamente al chiamante come errori e non viene eseguito alcun tentativo di accesso alla risorsa o al servizio non riuscito.

  • L'applicazione può testare periodicamente il servizio, in modo intermittente e con lunghi intervalli tra le richieste, per rilevare quando diventa disponibile. Un intervallo appropriato dipende da fattori quali la criticità dell'operazione e la natura del servizio. Potrebbe durare da pochi minuti a diverse ore. Quando il test ha esito positivo, l'applicazione può riprendere le normali operazioni e passare le richieste al servizio appena ripristinato.

  • Nel frattempo, potrebbe essere possibile eseguire il fallback a un'altra istanza del servizio (forse in un data center o un'applicazione diversa), usare un servizio simile che offre funzionalità compatibili (forse più semplici) o eseguire alcune operazioni alternative in base alla speranza che il servizio sarà presto disponibile. Ad esempio potrebbe essere opportuno archiviare le richieste del servizio in coda o archivio dati e riprovarle in seguito. In alternativa, potrebbe essere possibile reindirizzare l'utente a un'istanza alternativa dell'applicazione, ridurre le prestazioni dell'applicazione, ma offrire comunque funzionalità accettabili o semplicemente restituire un messaggio all'utente per indicare che l'applicazione non è attualmente disponibile.

Ottimizzare l'implementazione dei tentativi

• Quando decidi i valori per il numero di tentativi e gli intervalli tra i tentativi per un criterio, valuta se l'operazione sul servizio o sulla risorsa fa parte di un'operazione a lunga esecuzione o a più passaggi. Potrebbe essere difficile o costoso compensare tutti gli altri passaggi operativi che hanno già avuto esito positivo quando si verifica un errore. In questo caso, un intervallo molto lungo e un numero elevato di tentativi potrebbe essere accettabile purché tale strategia non blocchi altre operazioni mantenendo o bloccando risorse scarse.

• Valuta se riprovare la stessa operazione potrebbe causare incoerenze nei dati. Se alcune parti di un processo a più fasi vengono ripetute e le operazioni non sono idempotenti, potrebbero verificarsi incoerenze. Ad esempio, se un'operazione che incrementa un valore viene ripetuta, produce un risultato non valido. La ripetizione di un'operazione che invia un messaggio a una coda potrebbe causare un'incoerenza nel consumatore di messaggi se il consumatore non riesce a rilevare messaggi duplicati. Per evitare questi scenari, progettare ogni passaggio come operazione idempotente. Per altre informazioni, vedere Modelli di Idempotency.

• Considera l'ambito delle operazioni ritentate. Ad esempio, potrebbe essere più semplice implementare il codice di ripetizione a un livello che comprenda diverse operazioni e riprovarle tutte se una fallisce. Tuttavia, ciò potrebbe causare problemi di idempotenza o operazioni di rollback non necessarie.

• Se si sceglie un ambito di ripetizione dei tentativi che include diverse operazioni, tenere conto della latenza totale di tutte quando si determinano gli intervalli di ripetizione dei tentativi, quando si monitorano i tempi trascorsi dell'operazione e prima di generare avvisi per gli errori.

• Valutare il modo in cui la strategia di ripetizione dei tentativi potrebbe influire sui vicini e sugli altri tenant in un'applicazione condivisa e quando si usano risorse e servizi condivisi. I criteri di ripetizione aggressivi possono causare un numero crescente di errori temporanei per questi altri utenti e per le applicazioni che condividono le risorse e i servizi. Analogamente, l'applicazione potrebbe essere interessata dai criteri di ripetizione dei tentativi implementati da altri utenti delle risorse e dei servizi. Per le applicazioni critiche per l'azienda, è possibile usare servizi Premium che non sono condivisi. In questo modo è possibile controllare maggiormente il carico e la conseguente limitazione di queste risorse e servizi, che possono contribuire a giustificare il costo aggiuntivo.

Facilitazione di Azure

La maggior parte dei servizi di Azure e degli SDK client offre un meccanismo di ripetizione dei tentativi. Tuttavia, questi meccanismi differiscono perché ogni servizio ha caratteristiche e requisiti diversi e ogni meccanismo di ripetizione dei tentativi viene ottimizzato per il servizio specifico. Questa sezione riepiloga le funzionalità del meccanismo di ripetizione dei tentativi per alcuni servizi di Azure di uso comune.

Example

Per un esempio che usa molti dei modelli descritti in questo articolo, vedere Modello di app Web affidabile per .NET . È disponibile anche un'implementazione di riferimento in GitHub.

Collegamenti correlati

• Modello Circuit Breaker
• modello di tentativo ripetuto
• Modello di limitazione
• Modello di Transazione Compensativa
• Un post di blog sui modelli di idempotenza
• Resilienza delle connessioni
• Inserire servizi fittizi
• Modello di coda dei messaggi morti

Elenco di controllo per l'affidabilità

Fare riferimento al set completo di raccomandazioni.