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

Qualquer aplicativo que seja executado na nuvem ou se comunique com serviços e recursos remotos deve ser capaz de lidar com falhas transitórias. É comum que esses aplicativos apresentem 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 cliente do Armazenamento do 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 lida com 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 para armazenamento de Blob são configuradas programaticamente, oferecendo controle sobre como as opções de repetição são aplicadas a várias solicitações de serviço e cenários. 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 ocorre 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 recuo exponencial para permitir que a solicitação seja concluída com êxito.

A tabela a seguir lista as propriedades da classe RetryOptions , juntamente com o tipo, uma breve descrição e o valor padrão se você não fizer alterações. Você deve ser proativo no ajuste dos valores dessas propriedades para atender às necessidades do seu aplicativo.

Neste exemplo de código para Blob Storage, configuramos as opções de repetição na Retry propriedade da classe BlobClientOptions . Em seguida, criamos um objeto de cliente para o serviço de 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 a partir do BlobServiceClient objeto usa as opções de repetição conforme definido no BlobClientOptions objeto. Você pode configurar várias estratégias de repetição para clientes de serviço com base nas necessidades do seu aplicativo.

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

Se seu aplicativo exigir alta disponibilidade e maior resiliência contra 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 de forma assíncrona para uma região secundária a centenas de quilômetros de distância.

O Armazenamento do Azure oferece duas opções para replicação com redundância geográfica: armazenamento com redundância geográfica (GRS) e armazenamento com redundância de zona geográfica (GZRS). 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, consulte Alterar a forma como uma conta de armazenamento é replicada.

Neste exemplo, definimos a propriedade GeoRedundantSecondaryUri em BlobClientOptions. Se essa propriedade for definida, o URI secundário será usado para GET ou HEAD solicitações durante as tentativas. Se o status da resposta do URI secundário for um 404, as tentativas subsequentes da solicitação não usarão o URI secundário novamente, pois esse código de status indica que o recurso pode não ter se propagado lá ainda. 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 redundância geográfica precisam ter em mente algumas considerações específicas de design. Para saber mais, consulte Usar redundância geográfica para projetar aplicativos altamente disponíveis.

Próximos passos

• Este artigo faz parte do guia do desenvolvedor do Armazenamento de Blobs para .NET. Consulte a lista completa de artigos do guia do desenvolvedor em Crie seu aplicativo.
• Para obter orientação de arquitetura e práticas recomendadas gerais para políticas de repetição, consulte Tratamento de falhas transitórias.
• Para obter orientação sobre como implementar um padrão de repetição para falhas transitórias, consulte Padrão de nova tentativa.