Implementar uma política de repetição com o .NET

Qualquer aplicativo executado na nuvem ou que se comunique com serviços e recursos remotos deve ser capaz de lidar com falhas transitórias. É comum que esses aplicativos sofram falhas devido a uma perda momentânea de conectividade de rede, um tempo limite de solicitação quando um serviço ou recurso está ocupado ou outros fatores. Os desenvolvedores devem criar aplicativos para lidar com falhas transitórias de forma transparente para melhorar a estabilidade e a resiliência.

Neste artigo, você aprenderá a usar a biblioteca de clientes do Armazenamento do Microsoft Azure para .NET para configurar uma política de repetição para um aplicativo que se conecta ao Armazenamento de Blobs do Azure. As políticas de repetição definem como o aplicativo trata solicitações com falha e devem sempre ser ajustadas para corresponder aos requisitos de negócios do aplicativo e à natureza da falha.

Configurar opções de repetição

As políticas de repetição do Armazenamento de Blobs são configuradas programaticamente, oferecendo controle sobre como as opções de repetição são aplicadas a várias solicitações e cenários de serviço. Por exemplo, um aplicativo Web que emite solicitações com base na interação do usuário pode implementar uma política com menos tentativas e atrasos mais curtos para aumentar a capacidade de resposta e notificar o usuário quando ocorrer um erro. Como alternativa, um aplicativo ou componente executando solicitações em lote em segundo plano pode aumentar o número de novas tentativas e usar uma estratégia de retirada exponencial para permitir que o tempo da solicitação seja concluído com êxito.

A tabela a seguir lista as propriedades da classe RetryOptions, acompanhado do tipo, de uma breve descrição e do valor padrão caso você não faça alterações. Você deve ser proativo ao ajustar os valores dessas propriedades de acordo com as necessidades do seu aplicativo.

Neste exemplo de código do Armazenamento de Blobs, configuramos as opções de repetição da propriedade Retry da classe BlobClientOptions. Em seguida, criamos um objeto cliente para o serviço blob usando as opções de repetição.

// 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);

Neste exemplo, cada solicitação de serviço emitida do objeto BlobServiceClient usa as opções de repetição definidas no objeto BlobClientOptions. Você pode configurar várias estratégias de repetição para clientes de serviço com base nas necessidades do seu aplicativo.

Usar redundância geográfica para melhorar a resiliência do aplicativo

Se o aplicativo exigir alta disponibilidade e maior resiliência em relação a falhas, você poderá aproveitar as opções de redundância geográfica do Armazenamento do Azure como parte de sua política de repetição. As contas de armazenamento configuradas para replicação com redundância geográfica são replicadas de forma síncrona na região primária e replicadas assincronamente em uma região secundária que está a centenas de quilômetros de distância.

O Armazenamento do Azure oferece duas opções para replicação com redundância geográfica: GRS (armazenamento com redundância geográfica) e GZRS (armazenamento com redundância de zona geográfica). Além de habilitar a redundância geográfica para sua conta de armazenamento, você também precisa configurar o acesso de leitura aos dados na região secundária. Para saber como alterar as opções de replicação para sua conta de armazenamento, confira Alterar como uma conta de armazenamento é replicada.

Neste exemplo, definimos a propriedade GeoRedundantSecondaryUri em BlobClientOptions. Caso essa propriedade esteja definida, o URI secundário será usado para GET ou HEAD solicitações durante novas tentativas. Caso o status da resposta do URI secundário seja 404, as novas tentativas subsequentes para a solicitação não usarão o URI secundário novamente, pois esse código de status indica que o recurso talvez ainda não tenha sido propagado. Caso contrário, as tentativas subsequentes alternam entre o URI primário e secundário.

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);

Os aplicativos que usam a redundância geográfica precisam ter em mente algumas considerações de design específicas. Para saber mais, confira Uso da redundância geográfica para criar aplicativos altamente disponíveis

Conteúdo relacionado

• Para obter diretrizes arquitetônicas e práticas recomendadas gerais para políticas de repetição, confira Tratamento de falhas transitórias.
• Para obter diretrizes sobre como implementar um padrão de repetição para falhas transitórias, confira o padrão de Repetição.