Implementare un criterio di ripetizione dei tentativi con .NET

Qualsiasi applicazione eseguita nel cloud o comunica con servizi e risorse remoti deve essere in grado di gestire gli errori temporanei. È comune che queste applicazioni verifichino errori a causa di una perdita momentanea della connettività di rete, di un timeout della richiesta quando un servizio o una risorsa è occupato o altri fattori. Gli sviluppatori devono creare applicazioni per gestire in modo trasparente gli errori temporanei per migliorare la stabilità e la resilienza.

Questo articolo illustra come usare la libreria client Archiviazione di Azure per .NET per configurare un criterio di ripetizione dei tentativi per un'applicazione che si connette a Archiviazione BLOB di Azure. I criteri di ripetizione dei tentativi definiscono il modo in cui l'applicazione gestisce le richieste non riuscite e devono essere sempre ottimizzate per soddisfare i requisiti aziendali dell'applicazione e la natura dell'errore.

Configurare le opzioni di ripetizione dei tentativi

I criteri di ripetizione dei tentativi per l'archiviazione BLOB vengono configurati a livello di codice, offrendo il controllo sulla modalità di applicazione delle opzioni di ripetizione ai vari scenari e richieste di servizio. Ad esempio, un'app Web che invia richieste in base all'interazione dell'utente potrebbe implementare un criterio con meno tentativi e ritardi più brevi per aumentare la velocità di risposta e notificare all'utente quando si verifica un errore. In alternativa, un'app o un componente che esegue richieste batch in background potrebbe aumentare il numero di tentativi e usare una strategia di backoff esponenziale per consentire il completamento corretto del tempo di richiesta.

Nella tabella seguente sono elencate le proprietà della classe RetryOptions , insieme al tipo, a una breve descrizione e al valore predefinito se non si apportano modifiche. Dovresti essere proattivo nell'ottimizzazione dei valori di queste proprietà per soddisfare le esigenze della tua app.

In questo esempio di codice per l'archiviazione BLOB vengono configurate le opzioni di ripetizione dei tentativi nella Retry proprietà della classe BlobClientOptions . Viene quindi creato un oggetto client per il servizio BLOB usando le opzioni di ripetizione dei tentativi.

// Provide the client configuration options for connecting to Azure Blob Storage
BlobClientOptions blobOptions = new BlobClientOptions()
{
    Retry = {
        Delay = TimeSpan.FromSeconds(2),
        MaxRetries = 5,
        Mode = RetryMode.Exponential,
        MaxDelay = TimeSpan.FromSeconds(10),
        NetworkTimeout = TimeSpan.FromSeconds(100)
    },
};

BlobServiceClient blobServiceClient = new BlobServiceClient(
    accountUri,
    new DefaultAzureCredential(),
    blobOptions);

In questo esempio ogni richiesta di servizio generata dall'oggetto BlobServiceClient usa le opzioni di ripetizione dei tentativi, come definito nell'oggetto BlobClientOptions . È possibile configurare diverse strategie di ripetizione dei tentativi per i client del servizio in base alle esigenze dell'app.

Usare la ridondanza geografica per migliorare la resilienza delle app

Se l'app richiede disponibilità elevata e maggiore resilienza in caso di errori, è possibile sfruttare Archiviazione di Azure opzioni di ridondanza geografica come parte dei criteri di ripetizione dei tentativi. Gli account di archiviazione configurati per la replica con ridondanza geografica vengono replicati in modo sincrono nell'area primaria e replicati in modo asincrono in un'area secondaria a centinaia di chilometri di distanza.

Archiviazione di Azure offre due opzioni per la replica con ridondanza geografica: Archiviazione con ridondanza geografica e archiviazione con ridondanza geografica della zona. Oltre ad abilitare la ridondanza geografica per l'account di archiviazione, è anche necessario configurare l'accesso in lettura ai dati nell'area secondaria. Per informazioni su come modificare le opzioni di replica per l'account di archiviazione, vedere Modificare la modalità di replica di un account di archiviazione.

In questo esempio viene impostata la proprietà GeoRedundantSecondaryUri in BlobClientOptions. Se questa proprietà è impostata, l'URI secondario viene usato per GET le richieste o HEAD durante i tentativi. Se lo stato della risposta dall'URI secondario è 404, i tentativi successivi per la richiesta non usano di nuovo l'URI secondario, perché questo codice di stato indica che la risorsa potrebbe non essere stata ancora propagata. In caso contrario, i tentativi successivi si alternano tra l'URI primario e quello secondario.

Uri secondaryAccountUri = new Uri($"https://{accountName}-secondary.blob.core.windows.net/");

// Provide the client configuration options for connecting to Azure Blob Storage
BlobClientOptions blobOptionsGRS = new BlobClientOptions()
{
    Retry = {
        Delay = TimeSpan.FromSeconds(2),
        MaxRetries = 5,
        Mode = RetryMode.Exponential,
        MaxDelay = TimeSpan.FromSeconds(10),
        NetworkTimeout = TimeSpan.FromSeconds(100)
    },

    // Set the secondary storage URI
    GeoRedundantSecondaryUri = secondaryAccountUri
};

BlobServiceClient blobServiceClient = new BlobServiceClient(
    accountUri,
    new DefaultAzureCredential(),
    blobOptionsGRS);

Le app che usano la ridondanza geografica devono tenere presenti alcune considerazioni di progettazione specifiche. Per altre informazioni, vedere Usare la ridondanza geografica per progettare applicazioni a disponibilità elevata.

Passaggi successivi

• Questo articolo fa parte della Guida per sviluppatori di Archiviazione BLOB per .NET. Vedere l’elenco completo degli articoli della guida per sviluppatori in Creare la propria app.
• Per indicazioni sull'architettura e procedure consigliate generali per i criteri di ripetizione dei tentativi, vedere gestione degli errori temporanei.
• Per indicazioni sull'implementazione di un modello di ripetizione dei tentativi per gli errori temporanei, vedere Modello di ripetizione dei tentativi.