Chaos Engineering com .NET 5 + Polly + Simmy: um exemplo prático
O tratamento de falhas em aplicações .NET com Polly já é um tema recorrente neste blog, com publicações trazendo diferentes possibilidades de uso desta biblioteca. São notórios dentro da comunidade .NET os benefícios da adoção de Polly nos mais variados tipos de projetos, descomplicando a aplicação de inúmeros patterns voltados à resiliência de sistemas e evitando construções de código muito extensas (dispensando até mesmo inúmeros try-catch encadeados).
A seguir estão os 2 artigos mais recentes que produzi sobre esse tema:
Tratamento de Falhas com .NET + Polly: implementando o padrão Circuit Breaker
Tratamento de Falhas com .NET + Polly: implementando o uso de Wait and Retry
Também abordei anteriormente o uso da biblioteca Simmy, um projeto mantido pelo time do Polly e voltado a Chaos Engineering (Engenharia de Caos). Este tipo de prática permite simular um ou mais problemas que aconteceriam com um software em produção, superando eventuais limitações técnicas e sem que isto implique em modificar o código de uma dependência desta aplicação apenas para simular uma falha. O artigo em questão demonstrava a utilização de Simmy com ASP.NET Core:
ASP.NET Core + Chaos Engineering: simulação de falhas com Polly + Simmy
Neste novo post dou continuidade à implementação de Chaos Engineering em .NET, desta vez com um exemplo agora de implementação do padrão Fallback com Polly e em conjunto com uma Policy de simulação de falhas gerada com a biblioteca Simmy. O projeto demonstrado aqui já foi disponibilizado no GitHub:
https://github.com/renatogroffe/DotNet5-Worker-Polly-Fallback-Simmy_ConsumoAPIContagem
O padrão Fallback envolve a geração de um valor alternativo ou o processamento de uma ação substituta diante da ocorrência de um erro. Fiz inclusive uma demonstração recente do uso deste pattern com Polly, durante uma live no Canal .NET:
Foram adicionados no projeto de exemplo os packages Polly e Polly.Contrib.Simmy:
A aplicação descrita neste post nada mais é do que um Worker Service criado com .NET 5, o qual consumirá uma API de contagem de acessos.
A classe FallbackContagem será responsável pela geração de uma Policy de Fallback:
- No parâmetro fallbackAction está o código com o retorno a ser produzido caso ocorra uma falha (uma instância de ResultadoContador);
- Já no parâmetro onFallbackAsync constará uma ação a ser executada quando do início do processamento da Policy de Fallback.
A classe MonkeyPolicy (disponibilizada pelo Simmy) permitirá a criação de uma Policy destinada à simulação de falhas:
- Uma exceção do tipo Exception será informada como parâmetro ao método InjectExceptionAsync, indicando o objeto correspondente às falhas produzidas para fins de testes;
- Tais erros serão gerados aleatoriamente, seguindo uma taxa para falhas de 30%.
A interação entre as Policy de Fallback e a MonkeyPolicy para simulação de falhas será configurada na classe Program:
- Foram utilizadas as classes FallbackContagem e MonkeyPolicyContagem;
- Uma nova Policy foi obtida a partir do método WrapAsync, combinando a Policy de Fallback e a MonkeyPolicy. O objeto correspondente será injetado como um Singleton.
E chegamos à classe Worker:
- Um objeto do tipo AsyncPolicyWrap será injetado no construtor dessa estrutura;
- Essa instância será utiliza para chamadas à API de contagem (linhas 38 a 42) de forma protegida. Erros poderão acontecer de forma aleatória (via MonkeyPolicy), com o tratamento dos mesmos empregando a Fallback Policy.
Na próxima imagem temos a execução deste Worker consumindo a API de contagem de acessos, com um exemplo de falha simulada destacado em vermelho:
