Partilhar via

Estratégias para lidar com falhas parciais

  • Artigo

Gorjeta

Este conteúdo é um trecho do eBook, .NET Microservices Architecture for Containerized .NET Applications, disponível no .NET Docs ou como um PDF para download gratuito que pode ser lido offline.

Descarregar PDF

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

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 backoff 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 tempos limite da rede. Em geral, os clientes devem ser projetados para não bloquear indefinidamente e sempre usar tempos limite ao esperar por uma resposta. O uso de tempos limite garante que os recursos nunca fiquem presos indefinidamente.

Use o padrão Disjuntor. 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 fallbacks. 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 a implementação. Também permite uma "fila" fora da antepara. 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 o quão cheio a antepara e a fila estão e oferece eventos em estouro, portanto, também pode ser usado para impulsionar o dimensionamento horizontal automatizado.

Recursos adicionais

AnteriorSeguinte