Compartilhar via

Resiliência e alta disponibilidade em microsserviços

Dica

Esse conteúdo é um trecho do eBook, arquitetura de microsserviços do .NET para aplicativos .NET em contêineres, disponível em do .NET Docs ou como um PDF para download gratuito que pode ser lido offline.

Baixar PDF

miniatura da capa do eBook sobre arquitetura de microsserviços do .NET para aplicativos .NET em contêineres.

Lidar com falhas inesperadas é um dos problemas mais difíceis de se resolver, especialmente em um sistema distribuído. Grande parte do código que os desenvolvedores gravam envolve o tratamento de exceções, e também é onde mais tempo é gasto em testes. O problema está mais envolvido do que escrever código para lidar com falhas. O que acontece quando o computador em que o microsserviço está em execução falha? Você não só precisa detectar essa falha de microsserviço (um problema difícil por conta própria), mas também precisa de algo para reiniciar seu microsserviço.

Um microsserviço precisa ser resiliente a falhas e ser capaz de reiniciar com frequência em outro computador para disponibilidade. Essa resiliência também se resume ao estado que foi salvo em nome do microsserviço, do qual o microsserviço pode recuperar esse estado e se o microsserviço pode ser reiniciado com êxito. Em outras palavras, é necessário haver resiliência na funcionalidade de computação (o processo pode ser reiniciado a qualquer momento), bem como resiliência no estado ou nos dados (sem perda de dados e os dados permanecem consistentes).

Os problemas de resiliência são agravados durante outros cenários, como quando ocorrem falhas durante uma atualização de aplicativo. O microsserviço, trabalhando com o sistema de implantação, precisa determinar se ele pode continuar a avançar para a versão mais recente ou, em vez disso, reverter para uma versão anterior para manter um estado consistente. Perguntas como se computadores suficientes estão disponíveis para continuar avançando e como recuperar versões anteriores do microsserviço precisam ser consideradas. Essa abordagem requer que o microsserviço emita informações de saúde para que o aplicativo e o orquestrador possam tomar essas decisões.

Além disso, a resiliência está relacionada à forma como os sistemas baseados em nuvem devem se comportar. Conforme mencionado, um sistema baseado em nuvem deve lidar com falhas e tentar se recuperar automaticamente delas. Por exemplo, em caso de falhas de rede ou contêiner, os aplicativos cliente ou os serviços cliente devem ter uma estratégia para tentar novamente enviar mensagens ou repetir solicitações, pois em muitos casos as falhas na nuvem são parciais. A seção Implementando Aplicativos Resilientes neste guia aborda como lidar com falhas parciais. Ele descreve técnicas como retentativas com recuo exponencial ou o padrão Circuit Breaker no .NET usando bibliotecas como Polly, que oferece uma grande variedade de estratégias para lidar com essas situações.

Gerenciamento e diagnóstico de saúde em microsserviços

Pode parecer óbvio, e muitas vezes é negligenciado, mas um microsserviço deve relatar sua integridade e diagnóstico. Caso contrário, há pouco entendimento de uma perspectiva operacional. Correlacionar eventos de diagnóstico em um conjunto de serviços independentes e lidar com distorções de relógio de computador para entender a ordem do evento é desafiador. Da mesma forma que você interage com um microsserviço sobre protocolos e formatos de dados acordados, há a necessidade de padronização em como registrar eventos de integridade e diagnóstico que acabam em um repositório de eventos para consulta e exibição. Em uma abordagem de microsserviços, é fundamental que diferentes equipes concordem com um único formato de log. Precisa haver uma abordagem consistente para exibir eventos de diagnóstico no aplicativo.

Exames de saúde

Integridade é diferente de diagnóstico. Integridade significa que o microsserviço reporta seu estado atual para tomar as devidas ações. Um bom exemplo é trabalhar com mecanismos de atualização e implantação para manter a disponibilidade. Embora um serviço possa não estar íntegro no momento devido a uma falha de processo ou reinicialização do computador, o serviço ainda pode estar operacional. A última coisa que você precisa é piorar isso executando uma atualização. A melhor abordagem é fazer uma investigação primeiro ou dar tempo para o microsserviço se recuperar. Os eventos de integridade de um microsserviço permitem tomar decisões bem informadas e ajudam realmente a criar serviços que recuperam a si próprios.

Na seção Implementando verificações de integridade nos serviços do ASP.NET Core deste guia, explicamos como usar a nova biblioteca ASP.NET HealthChecks em seus microsserviços, permitindo que eles informem seu estado a um serviço de monitoramento, para que ações apropriadas possam ser tomadas.

Você também tem a opção de usar uma excelente biblioteca de software livre chamada AspNetCore.Diagnostics.HealthChecks, disponível no GitHub e como um pacote NuGet. Essa biblioteca também faz verificações de saúde, com uma abordagem única, e lida com dois tipos de verificações:

  • Liveness: verifica se o microsserviço está ativo, ou seja, se ele é capaz de aceitar solicitações e responder.
  • Preparação: verifica se as dependências do microsserviço (banco de dados, serviços de fila etc.) estão prontas para que o microsserviço possa fazer o que deveria fazer.

Usando fluxos de eventos de diagnóstico e logs

Os logs fornecem informações sobre como um aplicativo ou serviço está em execução, incluindo exceções, avisos e mensagens informativas simples. Normalmente, cada log está em um formato de texto com uma linha por evento, embora exceções geralmente mostrem o rastreamento de pilha em várias linhas.

Em aplicativos monolíticos baseados em servidor, você pode gravar logs em um arquivo em disco (um logfile) e analisá-lo com qualquer ferramenta. Como a execução do aplicativo é limitada a um servidor fixo ou VM, geralmente não é muito complexo analisar o fluxo de eventos. No entanto, em um aplicativo distribuído em que vários serviços são executados em muitos nós em um cluster de orquestrador, ser capaz de correlacionar eventos distribuídos é um desafio.

Um aplicativo baseado em microsserviço não deve tentar armazenar o fluxo de saída de eventos ou logfiles sozinho e nem mesmo tentar gerenciar o roteamento dos eventos para um local central. Ele deve ser transparente, o que significa que cada processo deve apenas gravar seu fluxo de eventos em uma saída padrão que, abaixo, será coletada pela infraestrutura do ambiente de execução em que está em execução. Um exemplo desses roteadores de fluxo de eventos é Microsoft.Diagnostic.EventFlow, que coleta fluxos de eventos de várias fontes e os publica em sistemas de saída. Isso pode incluir uma saída padrão simples para um ambiente de desenvolvimento ou sistemas de nuvem como o Azure Monitor e o Diagnóstico do Azure. Também há boas plataformas e ferramentas de análise de log de terceiros que podem pesquisar, alertar, relatar e monitorar logs, mesmo em tempo real, como Splunk ou Middleware.

Orquestradores que gerenciam informações de saúde e diagnóstico

Ao criar um aplicativo baseado em microsserviço, você precisa lidar com a complexidade. É claro que um único microsserviço é simples de lidar, mas dezenas ou centenas de tipos e milhares de instâncias de microsserviços é um problema complexo. Não se trata apenas de criar sua arquitetura de microsserviços, você também precisa de alta disponibilidade, capacidade de endereçamento, resiliência, integridade e diagnóstico se você pretende ter um sistema estável e coeso.

Diagrama de clusters que fornecem uma plataforma de suporte para microsserviços.

Figura 4-22. Uma Plataforma de Microsserviço é fundamental para o gerenciamento de integridade de um aplicativo

Os problemas complexos mostrados na Figura 4-22 são difíceis de resolver sozinho. As equipes de desenvolvimento devem se concentrar na solução de problemas de negócios e na criação de aplicativos personalizados com abordagens baseadas em microsserviço. Eles não devem se concentrar na resolução de problemas complexos de infraestrutura; se o fizessem, o custo de qualquer aplicativo baseado em microsserviço seria enorme. Portanto, há plataformas orientadas a microsserviços, conhecidas como orquestradores ou clusters de microsserviço, que tentam resolver os problemas difíceis de criar e executar um serviço e usar recursos de infraestrutura com eficiência. Essa abordagem reduz as complexidades da criação de aplicativos que usam uma abordagem de microsserviços.

Orquestradores diferentes podem parecer semelhantes, mas as verificações de diagnóstico e integridade oferecidas por cada um deles variam em termos de recursos e estágio de maturidade, dependendo às vezes da plataforma do sistema operacional, conforme explicado na próxima seção.

Recursos adicionais

AnteriorPróximo