Implementare un criterio di ripetizione dei tentativi con Go

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 il modulo client di Archiviazione di Azure per Go per configurare un criterio di ripetizione dei tentativi per un'applicazione che si connette ad 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 elencati i campi disponibili per la configurazione in un'istanza di 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.

Proprietà Type Descrizione Default value
MaxRetries int32 Facoltativo. Specifica il numero massimo di tentativi di ripetizione di un'operazione non riuscita prima di generare un errore. Un valore minore di zero indica un tentativo e nessun tentativo. 3
TryTimeout time.Duration Facoltativo. Indica il tempo massimo consentito per un singolo tentativo di una richiesta HTTP. Specificare un valore maggiore di zero da abilitare. Nota: l'impostazione di questo campo su un valore ridotto potrebbe causare timeout prematuri delle richieste HTTP. Disabilitato per impostazione predefinita.
RetryDelay time.Duration Facoltativo. Specifica la quantità iniziale di ritardo da utilizzare prima di riprovare a eseguire un'operazione. Il valore viene usato solo se la risposta HTTP non contiene un'intestazione Retry-After. Il ritardo aumenta in modo esponenziale con ogni tentativo fino al massimo specificato da MaxRetryDelay. Un valore minore di zero indica un ritardo tra i tentativi. 4 secondi
MaxRetryDelay time.Duration Facoltativo. Specifica il ritardo massimo consentito prima di ripetere un'operazione. In genere, il valore è maggiore o uguale al valore specificato in RetryDelay. Un valore minore di zero indica che non esiste alcun valore massimo. 60 secondi
StatusCodes []int Facoltativo. Specifica i codici di stato HTTP che indicano che l'operazione deve essere ritentata. Se si specificano valori, i valori predefiniti vengono sostituiti. Se si specifica una sezione vuota, vengono disabilitati i tentativi per i codici di stato HTTP. 408 - http. StatusRequestTimeout
429 - http. StatusTooManyRequests
500 - http. StatusInternalServerError
502 - http. StatusBadGateway
503 - http. StatusServiceUnavailable
504 - http. StatusGatewayTimeout
ShouldRetry func(*http.Response, error) bool Facoltativo. valuta se il criterio di ripetizione dei tentativi deve ripetere la richiesta. Se specificato, la funzione esegue l'override del confronto con l'elenco dei codici di stato HTTP e il controllo degli errori all'interno dei criteri di ripetizione dei tentativi. Gli errori di Context e NonRetriable rimangono valutati prima di chiamare ShouldRetry. I parametri *http.Response e error si escludono a vicenda, ovvero se uno è nil, l'altro non è nil. Un valore restituito true indica che il criterio di ripetizione dei tentativi deve riprovare.

Per usare l'esempio di codice in questo articolo, aggiungere i percorsi seguenti import al codice:

import (
	"context"
	"time"

	"github.com/Azure/azure-sdk-for-go/sdk/azcore"
	"github.com/Azure/azure-sdk-for-go/sdk/azcore/policy"
	"github.com/Azure/azure-sdk-for-go/sdk/azidentity"
	"github.com/Azure/azure-sdk-for-go/sdk/storage/azblob"
)

Nell'esempio di codice seguente vengono configurate le opzioni di ripetizione dei tentativi in un'istanza di RetryOptions, includerla in un'istanza clientOptions e creare un nuovo oggetto client:

options := azblob.ClientOptions{
	ClientOptions: azcore.ClientOptions{
		Retry: policy.RetryOptions{
			MaxRetries:    10,
			TryTimeout:    time.Minute * 15,
			RetryDelay:    time.Second * 1,
			MaxRetryDelay: time.Second * 60,
			StatusCodes:   []int{408, 429, 500, 502, 503, 504},
		},
	},
}

credential, err := azidentity.NewDefaultAzureCredential(nil)
handleError(err)

client, err := azblob.NewClient(accountURL, credential, &options)
handleError(err)

In questo esempio ogni richiesta di servizio generata da client usa le opzioni di ripetizione dei tentativi, come definito nello struct RetryOptions. Questo criterio si applica alle richieste client. È possibile configurare diverse strategie di ripetizione dei tentativi per i client del servizio in base alle esigenze dell'app.

Contenuto correlato

  • Last updated on