Estratégias para lidar com falhas parciais

Para lidar com falhas parciais, use uma das estratégias descritas aqui.

Use comunicação assíncrona (por exemplo, comunicação baseada em mensagem) em microsserviços internos. É altamente aconselhável não criar cadeias longas de chamadas HTTP síncronas nos microsserviços internos porque esse design incorreto acabará se tornando a principal causa de interrupções incorretas. Pelo contrário, exceto pelas comunicações front-end entre os aplicativos cliente e o primeiro nível de microsserviços ou gateways de API com granularidade fina, recomenda-se usar apenas a comunicação assíncrona (baseada em mensagem) após o ciclo inicial de solicitação e resposta, para os microsserviços internos. A consistência eventual e as arquiteturas controladas por eventos ajudarão a minimizar os efeitos de ondulação. Essas abordagens impõem um nível mais alto de autonomia de microsserviço e, portanto, impedem o problema observado aqui.

Usar novas tentativas com retirada exponencial. Essa técnica ajuda a evitar falhas curtas e intermitentes executando novas tentativas de chamada um determinado número de vezes, caso o serviço não esteja disponível apenas por um curto período de tempo. Isso pode ocorrer devido a problemas intermitentes na rede ou quando um microsserviço/contêiner é transferido para um nó diferente em um cluster. No entanto, se essas novas tentativas não foram criadas corretamente com disjuntores, os efeitos de ondulação poderão ser agravados e, em último caso, poderá até haver uma DoS (Negação de Serviço).

Solução alternativa para tempos limite de rede. Em geral, os clientes devem ser criados para não serem bloqueados indefinidamente e para sempre usar tempos limite ao aguardar uma resposta. Usar tempos limite garante que os recursos nunca fiquem bloqueados indefinidamente.

Use o padrão Circuit Breaker. Nessa abordagem, o processo cliente acompanha o número de solicitações falhadas. Se a taxa de erros exceder um limite configurado, um "disjuntor" será acionado para que tentativas adicionais falhem imediatamente. (Se um grande número de solicitações estiver falhando, isso sugere que o serviço está indisponível e que enviar solicitações é inútil.) Após um período de tempo limite, o cliente deverá tentar novamente e, se as novas solicitações forem bem-sucedidas, feche o disjuntor.

Forneça alternativas. Nessa abordagem, o processo do cliente executa a lógica de fallback quando uma solicitação falha, como o retorno de dados armazenados em cache ou um valor padrão. Essa é uma abordagem adequada para consultas e é mais complexa para atualizações ou comandos.

Limite o número de solicitações na fila. Os clientes também devem impor um limite superior ao número de solicitações pendentes que um microsserviço cliente pode enviar para um serviço específico. Se o limite tiver sido atingido, provavelmente será inútil fazer solicitações adicionais e essas tentativas deverão falhar imediatamente. Em termos de implementação, a política Isolamento do bulkhead da Polly pode ser usada para atender a esse requisito. Essa abordagem é essencialmente uma restrição de paralelização com SemaphoreSlim como a implementação. Ela também permite uma "fila" fora do bulkhead. Você pode perder proativamente o excesso de carga mesmo antes da execução (por exemplo, porque a capacidade é considerada completa). Isso torna sua resposta a determinados cenários de falha mais rápida do que seria a de um disjuntor, já que o disjuntor aguarda as falhas acontecerem. O objeto BulkheadPolicy na Polly expõe se o bulkhead e a fila estão cheios e oferece eventos em estouro, portanto, ele também pode ser usado para permitir a escala horizontal automatizada.

Recursos adicionais

• Padrões de resiliência
  https://learn.microsoft.com/azure/architecture/framework/resiliency/reliability-patterns

• Adicionando resiliência e otimizando o desempenho
  https://learn.microsoft.com/previous-versions/msp-n-p/jj591574(v=pandp.10)

• Antepara. Repositório GitHub. Implementação com a política Polly.
  https://github.com/App-vNext/Polly/wiki/Bulkhead

• Como desenvolver aplicativos resilientes do Azure
  https://learn.microsoft.com/azure/architecture/framework/resiliency/app-design

• Tratamento de falhas transitórias
  https://learn.microsoft.com/azure/architecture/best-practices/transient-faults