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 longas cadeias de chamadas HTTP síncronas nos microsserviços internos, porque esse design incorreto acabará se tornando a principal causa de interrupções ruins. Pelo contrário, exceto para as comunicações front-end entre os aplicativos cliente e o primeiro nível de microsserviços ou gateways de API refinados, recomenda-se usar apenas comunicação assíncrona (baseada em mensagem) uma vez passado o ciclo inicial de solicitação/resposta, em todos os microsserviços internos. Eventual consistência e arquiteturas orientadas a eventos ajudarão a minimizar os efeitos em cascata. Essas abordagens impõem um nível mais alto de autonomia de microsserviços e, portanto, evitam o problema mencionado aqui.

Use repetições com recuo exponencial. Esta técnica ajuda a evitar falhas curtas e intermitentes, realizando repetições de chamadas um certo 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 de rede intermitentes ou quando um microsserviço/contêiner é movido para um nó diferente em um cluster. No entanto, se essas novas tentativas não forem projetadas corretamente com disjuntores, isso pode agravar os efeitos em cascata, causando até mesmo uma negação de serviço (DoS).

Contorne os time-outs de rede. Em geral, os clientes devem ser concebidos para não bloquear indefinidamente e sempre usar limites de tempo ao esperar por uma resposta. O uso de timeouts garante que os recursos nunca fiquem presos indefinidamente.

Use o padrão Circuit Breaker. Nessa abordagem, o processo do cliente rastreia o número de solicitações com falha. Se a taxa de erro exceder um limite configurado, um "disjuntor" aciona para que novas tentativas falhem imediatamente. (Se um grande número de solicitações estiver falhando, isso sugere que o serviço não está disponível e que o envio de solicitações é inútil.) Após um período de tempo limite, o cliente deve tentar novamente e, se as novas solicitações forem bem-sucedidas, fechar o disjuntor.

Fornecer 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. Esta é uma abordagem adequada para consultas e é mais complexa para atualizações ou comandos.

Limite o número de solicitações enfileiradas. 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 determinado serviço. Se o limite tiver sido atingido, provavelmente não faz sentido fazer solicitações adicionais, e essas tentativas devem falhar imediatamente. Em termos de implementação, a política Polly Bulkhead Isolation pode ser usada para cumprir este requisito. Esta abordagem é essencialmente um acelerador de paralelização, com SemaphoreSlim como a implementação. Também permite uma "fila" fora da divisória. Você pode eliminar proativamente o excesso de carga antes mesmo da execução (por exemplo, porque a capacidade é considerada cheia). Isto faz com que a sua resposta a certos cenários de falha seja mais rápida do que seria um disjuntor, uma vez que o disjuntor aguarda pelas falhas. O objeto BulkheadPolicy em Polly expõe quão cheias estão a antepara e a fila, e oferece eventos de estouro, pelo que também pode ser utilizado para impulsionar o dimensionamento horizontal automatizado.

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 utilizando a política Polly.
  https://github.com/App-vNext/Polly/wiki/Bulkhead

• Conceber aplicações resilientes para o 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