Tratar falhas parciais

Em sistemas distribuídos, como aplicativos baseados em microsserviços, há um risco sempre presente de falha parcial. Por exemplo, um único microsserviço/contêiner pode falhar ou pode não estar disponível para responder por um curto período de tempo, ou uma única VM ou servidor pode falhar. Como clientes e serviços são processos separados, um serviço pode não ser capaz de responder em tempo hápl de uma solicitação de um cliente. O serviço pode estar sobrecarregado e respondendo muito lentamente às solicitações ou pode simplesmente não estar acessível por um curto período devido a problemas de rede.

Por exemplo, considere a página de detalhes do Pedido no aplicativo de exemplo eShopOnContainers. Se o microsserviço responsável pelo processamento de pedidos não responder quando o usuário tentar enviar um pedido, uma implementação incorreta do processo do cliente (o aplicativo Web MVC) — por exemplo, se o código do cliente usasse RPCs síncronos sem um tempo limite — bloquearia threads, esperando indefinidamente por uma resposta. Além de criar uma experiência de usuário ruim, cada espera sem resposta consome ou bloqueia um thread e os threads são extremamente valiosos em aplicativos altamente escalonáveis. Se houver muitos threads bloqueados, o runtime do aplicativo poderá eventualmente ficar sem threads. Nesse caso, o aplicativo pode ficar globalmente sem resposta em vez de apenas não responder parcialmente, conforme mostrado na Figura 8-1.

Figura 8-1. Falhas parciais devido a dependências que afetam a disponibilidade do thread de serviço

Em um aplicativo grande baseado em microsserviços, qualquer falha parcial pode ser amplificada, especialmente se a maior parte da interação interna de microsserviços for baseada em chamadas HTTP síncronas (que é considerada um antipadrão). Pense em um sistema que recebe milhões de chamadas de entrada por dia. Se o sistema tiver um design incorreto baseado em cadeias longas de chamadas HTTP síncronas, essas chamadas de entrada poderão resultar em muitos milhões de chamadas de saída (vamos supor uma taxa de 1:4) para dezenas de microsserviços internos como dependências síncronas. Essa situação é mostrada na Figura 8-2, especialmente na dependência nº 3, que inicia uma cadeia, chamando a dependência nº 4, que chama o nº 5.

Figura 8-2. O impacto de ter um design incorreto com cadeias longas de solicitações HTTP

A falha intermitente é garantida em um sistema distribuído e baseado em nuvem, mesmo que cada dependência em si tenha excelente disponibilidade. É um fato que você precisa considerar.

Se você não criar nem implementar técnicas para garantir a tolerância a falhas, até mesmo pequenos tempos de inatividade poderão ser amplificados. Por exemplo, 50 dependências, cada uma com 99,99% de disponibilidade, poderia resultar em várias horas de tempo de inatividade por mês devido a esse efeito de ondulação. Quando uma dependência de microsserviço falha ao lidar com um alto volume de solicitações, essa falha pode saturar rapidamente todos os threads de solicitação disponíveis em cada serviço e travar todo o aplicativo.

Figura 8-3. Falha parcial amplificada por microsserviços com cadeias longas de chamadas HTTP síncronas

Para minimizar esse problema, na seção Integração de microsserviços assíncrona impõe a autonomia do microsserviço, este guia incentiva você a usar a comunicação assíncrona entre os microsserviços internos.

Além disso, é essencial que você projete seus microsserviços e aplicativos cliente para lidar com falhas parciais, ou seja, para criar microsserviços resilientes e aplicativos cliente.