Consigli per la gestione degli errori temporanei

  • Articolo

Si applica a questa raccomandazione per l'affidabilità di Azure Well-Architected Framework:

RE:07 Rafforzare la resilienza e la recuperabilità del carico di lavoro implementando misure di auto-conservazione e riparazione automatica. Creare funzionalità nella soluzione usando modelli di affidabilità basati sull'infrastruttura e modelli di progettazione basati su software per gestire gli errori dei componenti e gli errori temporanei. Creare funzionalità nel sistema per rilevare gli errori dei componenti della soluzione e avviare automaticamente un'azione correttiva mentre il carico di lavoro continua a funzionare con funzionalità complete o ridotte.

Guide correlate:Conservazioneautomaticadei processi | in background

Questa guida descrive le raccomandazioni 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ò vale soprattutto per le applicazioni eseguite nel cloud, in cui, a causa della natura dell'ambiente e della connettività tramite Internet, questo tipo di errore è probabile che si verifichi più spesso. Gli errori temporanei includono la perdita momentanea della connettività di rete a componenti e servizi, l'indisponibilità temporanea di un servizio e i timeout che si verificano quando un servizio è occupato. Questi errori sono spesso auto-corretti, quindi, se l'azione viene ripetuta dopo un ritardo appropriato, è probabile che abbia esito positivo.

Questo articolo fornisce indicazioni generali per la gestione degli errori temporanei. Per informazioni sulla gestione degli 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.

Strategie di progettazione chiave

Gli errori temporanei possono verificarsi in qualsiasi ambiente, su qualsiasi piattaforma o sistema operativo e in ogni 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 sottoutilizzate e i componenti e le risorse si trovano vicini tra loro. Questo approccio rende meno probabile l'errore, ma possono verificarsi errori temporanei, perché possono verificarsi interruzioni causate da eventi imprevisti come l'alimentatore esterno o i problemi di rete o da scenari di emergenza.

L'hosting nel cloud, anche in sistemi cloud privati, può offrire una maggiore disponibilità complessiva attraverso risorse condivise, ridondanza, failover automatico e allocazione dinamica delle risorse su molti nodi di calcolo specifici. Tuttavia, a causa della natura degli ambienti cloud, è più probabile che si verifichino errori temporanei. per vari motivi:

  • Molte risorse in un ambiente cloud sono condivise e l'accesso a queste risorse è soggetto a limitazioni per proteggere le risorse. Alcuni servizi rifiutano le connessioni quando il carico raggiunge 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 adiacenti e altri tenant 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 di connessione e errori di connessione temporanei.

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

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

Problematiche

Gli errori temporanei possono avere un effetto significativo sulla disponibilità percepita di un'applicazione, anche se è stato testato accuratamente 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 gli errori sono probabilmente temporanei, durano a lungo o sono errori del terminale. È probabile che risorse diverse restituiscano risposte diverse quando si verifica un errore e queste risposte possono variare anche 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 nella risorsa di archiviazione. Molte risorse e servizi hanno contratti di errore 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 ripetere l'operazione se determina che è probabile che l'errore sia temporaneo. Deve anche tenere traccia del numero di tentativi di ripetizione dell'operazione.

  • L'applicazione deve usare una strategia appropriata per i tentativi. La strategia specifica il numero di tentativi dell'applicazione, il ritardo tra ogni tentativo e le azioni da eseguire dopo un tentativo non riuscito. Il numero appropriato di tentativi e il ritardo tra ognuno di essi sono spesso difficili da determinare. La strategia varia a seconda del tipo di risorsa e delle condizioni operative correnti della risorsa e dell'applicazione.

Linee guida generali

Le linee guida seguenti consentono di progettare meccanismi di gestione degli errori temporanei adatti per le applicazioni.

Determinare se è presente un meccanismo di ripetizione dei tentativi predefinito

  • Molti servizi forniscono una libreria client o SDK che include un meccanismo di gestione degli errori temporanei. I criteri di ripetizione usati si basano in genere sulla natura e sui requisiti del servizio di destinazione. In alternativa, le interfacce REST per i servizi potrebbero restituire informazioni che consentono di determinare se un nuovo tentativo è appropriato e quanto tempo attendere prima del tentativo successivo.

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

Determinare se l'operazione è adatta per la ripetizione dei tentativi

  • Eseguire operazioni di ripetizione dei tentativi solo quando gli errori sono temporanei (in genere indicati dalla natura dell'errore) e quando è probabile che l'operazione abbia esito positivo quando viene ritentata. Non è necessario 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, consentire al codice chiamante di implementare nuovi tentativi. Tenere presente che gli errori restituiti da risorse e servizi esterni al controllo possono evolversi nel tempo e potrebbe essere necessario rivedere la logica di rilevamento degli errori temporanei.

  • Quando si creano servizi o componenti, è consigliabile implementare i codici di errore e i 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 si compila un servizio Web, è consigliabile restituire errori personalizzati definiti all'interno dei 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.

Determinare un numero di tentativi e un intervallo appropriati

  • Ottimizzare il numero di tentativi e l'intervallo per il tipo di caso d'uso. Se i tentativi non sono sufficienti, l'applicazione non può completare l'operazione e probabilmente avrà esito negativo. 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 periodi lunghi, che influiscono negativamente sull'integrità dell'applicazione.

  • Adattare 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 dell'utente, l'intervallo deve essere breve e devono essere tentati solo alcuni tentativi. Usando questo approccio, è possibile evitare di fare in modo che gli utenti attendino una risposta, che contiene connessioni aperte e possano 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ù a lungo tra i tentativi e ripetere i tentativi più volte.

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

    • Backoff esponenziale. L'applicazione attende un breve periodo di tempo prima del primo tentativo e quindi aumenta in modo esponenziale il tempo tra ogni tentativo successivo. Ad esempio, potrebbe ripetere l'operazione dopo 3 secondi, 12 secondi, 30 secondi e così via.

    • 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 ripetere l'operazione dopo 3 secondi, 7 secondi, 13 secondi e così via.

    • Intervalli regolari. L'applicazione attende lo stesso intervallo di tempo prima di ripetere ogni nuovo tentativo. Ad esempio, potrebbe ripetere l'operazione ogni 3 secondi.

    • 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, ripetere 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 ci dovrebbero mai essere più tentativi immediati. È consigliabile passare a strategie alternative, ad esempio azioni di back-off esponenziale o di fallback, se il nuovo tentativo immediato ha esito negativo.

    • Sequenza casuale. 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 ripetere l'operazione dopo 3 secondi, 11 secondi, 28 secondi e così via, mentre un'altra istanza potrebbe ripetere l'operazione dopo 4 secondi, 12 secondi, 26 secondi e così via. La casualizzazione è una tecnica utile che può essere combinata con altre strategie.

  • Come linea guida generale, usare una strategia di back-off esponenziale per le operazioni in background e usare strategie di ripetizione immediata o regolare degli intervalli per le operazioni interattive. In entrambi i casi è necessario scegliere l'intervallo di tempo e il numero di tentativi in modo che la latenza massima per tutti i tentativi non superi i requisiti di latenza end-to-end previsti.

  • 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 generare 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. Il totale di tutti questi tempi può comportare tempi complessivi lunghi, soprattutto quando si usa una strategia di ritardo esponenziale in cui l'intervallo tra tentativi cresce rapidamente dopo ogni errore. Se un processo deve soddisfare un contratto di servizio specifico, il tempo complessivo dell'operazione, inclusi tutti i timeout e i ritardi, deve essere entro i limiti definiti nel contratto di servizio.

  • Non implementare strategie di ripetizione eccessivamente aggressive. Queste sono 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 overload e continueranno a bloccare o rifiutare le richieste. Questo scenario comporta un circolo vizioso, dove più e più richieste vengono inviate alla risorsa o al servizio. Di conseguenza, la sua capacità di recuperare è ulteriormente ridotta.

  • Tenere conto del timeout delle operazioni quando si scelgono 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) al di sotto di un tempo totale specifico. Se un'operazione ha un timeout insolitamente breve o lungo, il timeout potrebbe influire sulla durata dell'attesa e sulla frequenza di ripetizione dell'operazione.

  • Usare il tipo dell'eccezione e tutti i dati che contiene 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 di errore,ad esempio il codice HTTP 503, Service Unavailable, con un'intestazione Retry-After nella risposta, potrebbero indicare quanto tempo potrebbe durare l'errore o che il servizio non è riuscito e non risponderà a alcun tentativo successivo.

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

Evitare anti-modelli

  • Nella maggior parte dei casi, evitare implementazioni che includono livelli duplicati di codice di ripetizione dei tentativi. Evitare progettazioni che includono meccanismi di ripetizione dei tentativi a catena o che implementano i tentativi in ogni fase di un'operazione che implica una gerarchia di richieste, a meno che non siano presenti requisiti specifici che richiedono questa operazione. In questi casi eccezionali usare criteri che impediscono un numero eccessivo di tentativi e periodi di attesa e accertarsi di comprendere le conseguenze di questo tipo di progettazione. Ad esempio, si supponga che un componente faccia una richiesta a un'altra, che quindi accede al servizio di destinazione. Se si implementa un nuovo tentativo con un conteggio di tre chiamate in entrambe le chiamate, sono presenti nove tentativi in totale rispetto al servizio. Molti servizi e risorse implementano un meccanismo di ripetizione dei tentativi predefinito. È consigliabile analizzare come disabilitare o modificare questi meccanismi se è necessario implementare i tentativi a un livello superiore.

  • Non implementare mai un meccanismo a ciclo infinito. In questo modo è probabile che la risorsa o il servizio vengano ripristinate da situazioni di overload e per causare la limitazione e la rifiuto delle connessioni per continuare per un periodo di tempo più lungo. Usare un numero limitato di tentativi o implementare un modello come Circuit Breaker per consentire al servizio di ripristinare.

  • Evitare di eseguire più volte una ripetizione di tentativo immediata.

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

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

Testare la strategia di ripetizione dei tentativi e l'implementazione

  • Testare completamente la strategia di ripetizione dei tentativi nel modo più ampio possibile, soprattutto quando sia l'applicazione che le risorse di destinazione o i servizi usati sono in carico estremo. Per controllare il comportamento durante il test, è possibile:

    • Inserire nel servizio errori temporanei e non temporanei. Ad esempio, inviare richieste non valide o aggiungere il codice che rileva le richieste di test e risponde con diversi tipi di errori.

    • Creare un mockup della risorsa o del servizio che restituisce un intervallo di errori restituiti dal servizio reale. Coprire tutti i tipi di errori progettati per rilevare la strategia di ripetizione dei tentativi.

    • Per i servizi personalizzati creati e distribuiti, forzare l'esecuzione di errori temporanei disabilitando temporaneamente o sovraccaricando il servizio. Non tentare di eseguire l'overload di risorse condivise o servizi condivisi in Azure.

    • Usare librerie o soluzioni che intercettano e modificano il traffico di rete per replicare scenari non favorevoli dai test automatizzati. Ad esempio, i test possono aggiungere tempi di andata e ritorno aggiuntivi, eliminare pacchetti, modificare le intestazioni o anche 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 si testa la resilienza di un'applicazione Web client a errori temporanei, usare gli strumenti di sviluppo del browser o la capacità del framework di test di simulare o bloccare le richieste di rete.

    • Eseguire test simultanei e fattori di carico elevati per garantire che il meccanismo di ripetizione dei tentativi e la strategia funzionino correttamente in queste condizioni. Questi test consentono anche di assicurarsi che il tentativo non abbia un effetto negativo sull'operazione del client o causare la contaminazione incrociata tra le richieste.

Gestire le configurazioni dei criteri di ripetizione dei tentativi

  • Un criterio di ripetizione dei tentativi è una combinazione di tutti gli elementi della strategia di ripetizione dei tentativi. 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 ed casualizzazione), i valori di intervallo effettivi e il numero di volte da ripetere.

  • Implementare tentativi in molte posizioni, anche nell'applicazione più semplice e in ogni livello di applicazioni più complesse. Anziché scrivere hardcode gli elementi di ogni criterio in più posizioni, considerare l'uso di un punto centrale per archiviare tutti i criteri. Ad esempio, archiviare valori come l'intervallo e il conteggio dei tentativi nei file di configurazione dell'applicazione, leggerli in fase di esecuzione e compilare a livello di codice i criteri di ripetizione dei tentativi. In questo modo è più semplice gestire le impostazioni e modificare e ottimizzare i valori per rispondere ai requisiti e agli scenari modificati. Tuttavia, progettare il sistema per archiviare i valori anziché rireading di un file di configurazione ogni volta e usare le impostazioni predefinite appropriate 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 che sia possibile modificarli senza dover riavviare l'applicazione.

  • Sfruttare le strategie predefinite di ripetizione dei tentativi predefinite disponibili nelle API client usate, ma solo quando sono appropriate per lo scenario. Queste strategie sono in genere generiche. In alcuni scenari, potrebbero essere tutti necessari, ma in altri scenari non offrono la gamma completa di opzioni per soddisfare i requisiti specifici. Per determinare i valori più appropriati, è necessario eseguire test per comprendere come le impostazioni influiscono sull'applicazione.

Log e tenere traccia degli errori temporanei e nontransienti

  • Come parte della strategia di ripetizione dei tentativi, includere la gestione delle eccezioni e altre strumentazioni che registrano tentativi di ripetizione dei tentativi. Un errore temporaneo occasionale e i tentativi sono previsti e non indicano un problema. I tentativi regolari e crescenti, tuttavia, sono spesso un indicatore di un problema che potrebbe causare un errore o che degrada le prestazioni e la disponibilità dell'applicazione.

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

  • È consigliabile archiviare un valore nelle voci di log che indica se i tentativi sono causati dalla limitazione nel servizio o da altri tipi di errori, ad esempio gli errori di connessione, in modo che sia possibile differenziarli durante l'analisi dei dati. Un aumento del numero di errori di limitazione è spesso indicativo di un problema di progettazione nell'applicazione o della necessità di passare a un servizio premium in grado di offrire hardware dedicato.

  • Valutare la misurazione e la registrazione dei 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 sui tempi di risposta dell'utente, sulla latenza del processo e sull'efficienza dei casi d'uso dell'applicazione. Registrare anche il numero di tentativi che si verificano in modo da poter comprendere i fattori che contribuiscono al tempo di risposta.

  • Prendere in considerazione l'implementazione di un sistema di telemetria e monitoraggio che può generare avvisi quando il numero e la frequenza di errori, il numero medio di tentativi o i tempi complessivi trascorsi prima dell'aumento delle operazioni.

Gestire le operazioni che hanno esito negativo continuamente

  • Si consideri come gestire le operazioni che continuano a non riuscire a ogni tentativo. Le situazioni come questa sono inevitabili.

    • Anche se una strategia di ripetizione dei tentativi definisce il numero massimo di tentativi che un'operazione deve essere riprovata, non impedisce all'applicazione di ripetere l'operazione con lo stesso numero di tentativi. Ad esempio, se un servizio di elaborazione degli ordini ha esito negativo con un errore irreversibile che lo inserisce in modo permanente, la strategia di ripetizione dei tentativi potrebbe rilevare un timeout di connessione e considerarlo un errore temporaneo. Il codice esegue il tentativo dell'operazione un numero specificato di volte e quindi rinuncia. Tuttavia, quando un altro cliente inserisce un ordine, l'operazione viene riprovata, anche se avrà esito negativo ogni volta.

    • Per evitare tentativi continui per le operazioni che non riescono continuamente, è consigliabile implementare il modello di interruttore. 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 esiste alcun tentativo di accedere alla risorsa o al servizio non riuscito.

    • L'applicazione può testare periodicamente il servizio, in modo intermittente e con intervalli di tempo lunghi tra le richieste, per rilevare quando diventa disponibile. Un intervallo appropriato dipende da fattori come la criticità dell'operazione e la natura del servizio. Potrebbe essere qualcosa tra pochi minuti e diverse ore. Al termine del test, l'applicazione può riprendere le normali operazioni e passare le richieste al servizio appena ripristinato.

    • Nel frattempo, potrebbe essere possibile tornare 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 necessario archiviare le richieste per il servizio in una coda o in un archivio dati e riprovarli in un secondo momento. In alternativa, potrebbe essere possibile reindirizzare l'utente a un'istanza alternativa dell'applicazione, ridurre le prestazioni dell'applicazione, ma comunque offrire funzionalità accettabili o semplicemente restituire un messaggio all'utente per indicare che l'applicazione non è attualmente disponibile.

Altre considerazioni

  • Quando si decide sui valori per il numero di tentativi e gli intervalli di ripetizione dei tentativi per un criterio, valutare se l'operazione nel servizio o nella risorsa fa parte di un'operazione a esecuzione prolungata o multistep. Potrebbe essere difficile o costoso compensare tutti gli altri passaggi operativi che hanno già avuto esito positivo quando uno ha esito negativo. In questo caso, un intervallo molto lungo e un numero elevato di tentativi potrebbe essere accettabile fino a quando tale strategia non blocca altre operazioni mantenendo o bloccando risorse scarse.

  • Valutare se ripetere l'operazione potrebbe causare incoerenze nei dati. Se alcune parti di un processo multistep vengono ripetute e le operazioni non sono idempotenti, potrebbero verificarsi incoerenze. Ad esempio, se un'operazione che incrementa un valore viene ripetuta, genera un risultato non valido. La ripetizione di un'operazione che invia un messaggio a una coda potrebbe causare una incoerenza nel consumer del messaggio se il consumer non riesce a rilevare i messaggi duplicati. Per evitare questi scenari, progettare ogni passaggio come operazione idempotente. Per altre informazioni, vedere Modelli di Idempotency.

  • Prendere in considerazione l'ambito delle operazioni che vengono ritrite. Ad esempio, potrebbe essere più semplice implementare il codice di ripetizione dei tentativi a un livello che include diverse operazioni e riprovare tutte se si verifica un errore. Tuttavia, questa operazione 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 tutti quando si determinano intervalli di tentativi, quando si monitorano i tempi trascorsi dell'operazione e prima di generare avvisi per gli errori.

  • Si consideri come la strategia di ripetizione dei tentativi potrebbe influire sui vicini e altri tenant in un'applicazione condivisa e quando si usano risorse e servizi condivisi. L'adozione di criteri aggressivi di ripetizione dei tentativi possono causare un numero crescente di errori temporanei si verifichi per gli 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 business-critical, è possibile usare i servizi Premium non condivisi. In questo modo si garantisce un maggiore controllo sul carico e sulla limitazione di queste risorse e servizi, che possono aiutare a giustificare il costo aggiuntivo.

Nota

Per ulteriori indicazioni sui compromessi e sui rischi, vedere Problemi e considerazioni nel modello di ripetizione dei tentativi.

Facilitazione di Azure

La maggior parte dei servizi e degli SDK client di Azure 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 comunemente usati.

Servizio Funzionalità per la ripetizione di tentativi Configurazione dei criteri Ambito Funzionalità di telemetria
Microsoft Entra ID Nativo nella libreria di autenticazione Microsoft (MSAL) Incorporato nella libreria MSAL Interno Nessuno
Azure Cosmos DB Nativo nel servizio Non configurabile Globale TraceSource
Archiviazione di Azure Data Lake Nativo nel client Non configurabile Singole operazioni Nessuno
Hub eventi di Azure Nativo nel client Programmatica Client Nessuno
Hub IoT di Azure Nativo nell'SDK client Programmatica Client Nessuno
Cache di Azure per Redis Nativo nel client Programmatica Client TextWriter
Ricerca cognitiva di Azure Nativo nel client Programmatica Client ETW o personalizzato
Bus di servizio di Azure Nativo nel client Programmatica NamespaceManager, MessagingFactory e client ETW
Azure Service Fabric Nativo nel client Programmatica Client Nessuno
database Azure SQL con ADO.NET Polly Dichiarativa e a livello di codice Singole istruzioni o blocchi di codice Personalizzato
Database SQL con Entity Framework Nativo nel client Programmatica Globale per AppDomain Nessuno
Database SQL con Entity Framework Core Nativo nel client Programmatica Globale per AppDomain Nessuno
Archiviazione di Azure Nativo nel client Programmatica Client e singole operazioni TraceSource

Nota

Per la maggior parte dei meccanismi predefiniti di ripetizione dei tentativi di Azure, non è attualmente possibile applicare criteri di ripetizione diversi per diversi tipi di errori o eccezioni. È necessario configurare un criterio che fornisca prestazioni e disponibilità medie ottimali. Un modo per ottimizzare i criteri consiste nell'analizzare i file di log per determinare il tipo di errori temporanei che si verificano.

Esempio

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

Elenco di controllo affidabilità

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo affidabilità