Configuring Polly Retries for Service-to-Service Communication with Aspire Service Defaults

O Desafio das Falhas Transitórias e o Padrão Retry

Em uma arquitetura de microsserviços, as chamadas de rede são inerentemente menos confiáveis do que as chamadas de método em processo. Um serviço pode estar temporariamente indisponível por inúmeras razões. O padrão de repetição (Retry Pattern) é uma estratégia fundamental para lidar com isso: em vez de falhar imediatamente, o serviço cliente tenta reenviar a mesma solicitação algumas vezes, na esperança de que a falha seja transitória e a próxima tentativa seja bem-sucedida.

Para implementar esse e outros padrões de resiliência em .NET, a biblioteca de referência é a Polly.

Polly e as Novas APIs de Resiliência do .NET 8

Polly é uma biblioteca de resiliência e tratamento de falhas transitórias para .NET. Com o .NET 8, a equipe do .NET colaborou com a comunidade Polly para criar uma nova API modernizada e de alto desempenho, integrada diretamente ao HttpClientFactory. Essa nova API está no pacote NuGet Microsoft.Extensions.Http.Resilience.

O vídeo a seguir, da conferência .NET Conf 2023, apresenta essa nova abordagem e a filosofia por trás dela.

Configurando uma Política de Retry Personalizada

Para entender profundamente como o mecanismo de repetição funciona, vamos primeiro ver como configurar uma política personalizada usando as novas APIs. Isso nos dá controle total sobre o comportamento da repetição.

As principais configurações para uma política de repetição robusta são:

1. Número de Tentativas (MaxRetryAttempts): Quantas vezes reenviar a solicitação após a falha inicial.
2. Estratégia de Backoff (BackoffType): O tempo de espera entre as tentativas. Uma espera constante não é ideal. A melhor prática é usar um backoff exponencial, onde o tempo de espera aumenta a cada nova tentativa (ex: 2s, 4s, 8s). Isso dá ao serviço sobrecarregado tempo para se recuperar.
3. Jitter: Adicionar uma pequena variação aleatória ao tempo de backoff. Isso é crucial para evitar o problema do "rebanho trovejante" (thundering herd), onde vários clientes, após uma falha, tentam se reconectar exatamente ao mesmo tempo, sobrecarregando novamente o serviço.

O vídeo a seguir demonstra de forma prática e detalhada como configurar uma política de repetição com essas opções.

O código para adicionar um manipulador de resiliência personalizado a um HttpClient se parece com isto:

// Exemplo de configuração em um programa .NET
builder.Services.AddHttpClient<MyApiClient>()
    .AddResilienceHandler("MyCustomPipeline", builder =>
    {
        builder.AddRetry(new HttpRetryStrategyOptions
        {
            MaxRetryAttempts = 3,
            BackoffType = DelayBackoffType.Exponential,
            UseJitter = true,
            Delay = TimeSpan.FromSeconds(2) // Atraso base para o backoff
        });
    });

A Forma Aspire: AddStandardResilienceHandler e ServiceDefaults

Configurar políticas personalizadas é poderoso, mas requer conhecimento das melhores práticas. Felizmente, o .NET Aspire simplifica isso drasticamente. O projeto ServiceDefaults que o Aspire cria para você já inclui uma chamada que adiciona uma política de resiliência padrão e recomendada a todos os HttpClients registrados.

Isso é feito através do método de extensão AddStandardResilienceHandler().

Vamos consultar a documentação oficial para entender o que essa política padrão inclui.

Como você viu na documentação, o AddStandardResilienceHandler configura um pipeline com cinco estratégias, incluindo uma política de repetição com padrões sólidos:

Isso significa que, por padrão, qualquer HttpClient em um projeto Aspire já tentará reenviar uma solicitação falhada 3 vezes, com um backoff exponencial aleatório começando em 2 segundos. Isso é feito automaticamente para você, seguindo as melhores práticas da indústria, e é uma das grandes vantagens do Aspire para construir aplicações nativas da nuvem.

O vídeo de Milan Jovanović também ilustra esse ponto de forma excelente.

Conclusão

Nesta lição, você aprendeu como tornar suas aplicações distribuídas mais robustas implementando o padrão de repetição. Vimos que, embora seja possível configurar políticas de repetição altamente personalizadas, o .NET Aspire promove as melhores práticas ao fornecer uma política de resiliência padrão e sensata pronta para uso.

Principais Pontos:

• Falhas transitórias são comuns em sistemas distribuídos, e o padrão de repetição (Retry) é uma defesa de primeira linha contra elas.
• A biblioteca Polly, através do novo pacote Microsoft.Extensions.Http.Resilience, é a maneira moderna de implementar resiliência no .NET.
• Uma política de repetição eficaz usa backoff exponencial e jitter para evitar sobrecarregar os serviços dependentes.
• O .NET Aspire simplifica enormemente a resiliência ao aplicar o AddStandardResilienceHandler por padrão a todos os HttpClients através do projeto ServiceDefaults, garantindo que sua aplicação seja resiliente desde o início.

Próxima Lição:
Repetir indefinidamente uma chamada para um serviço que está completamente fora do ar não é apenas inútil, mas também prejudicial, pois consome recursos do serviço cliente. Para evitar isso, precisamos de um mecanismo que possa "abrir o circuito" e parar de enviar solicitações por um tempo. Na próxima lição, vamos explorar o padrão Circuit Breaker, a próxima camada em nossa estratégia de resiliência.