Partilhar via

Resiliência e alta disponibilidade em microsserviços

  • 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.

Lidar com falhas inesperadas é um dos problemas mais difíceis de resolver, especialmente em um sistema distribuído. Grande parte do código que os desenvolvedores escrevem envolve o tratamento de exceções, e é também aqui que o maior tempo é gasto em testes. O problema está mais envolvido do que escrever código para lidar com falhas. O que acontece quando a máquina onde o microsserviço está sendo executado falha? Você não só precisa detetar essa falha de microsserviço (um problema difícil por si só), 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 outra máquina para disponibilidade. Essa resiliência também se resume ao estado que foi salvo em nome do microsserviço, de onde o microsserviço pode recuperar esse estado e se o microsserviço pode reiniciar com êxito. Em outras palavras, precisa haver resiliência na capacidade de computação (o processo pode reiniciar 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 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. Questões como se há máquinas suficientes 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 integridade para que o aplicativo geral 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. Como mencionado, um sistema baseado em nuvem deve aceitar falhas e deve tentar se recuperar automaticamente delas. Por exemplo, em caso de falhas de rede ou contêiner, os aplicativos ou serviços do cliente devem ter uma estratégia para tentar enviar mensagens novamente ou repetir solicitações, já que 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 novas tentativas com backoff exponencial ou o padrão Circuit Breaker no .NET usando bibliotecas como Polly, que oferece uma grande variedade de políticas para lidar com esse assunto.

Gestão e diagnóstico de saúde em microsserviços

Pode parecer óbvio, e muitas vezes é negligenciado, mas um microsserviço deve relatar sua saúde e diagnósticos. Caso contrário, há pouca perceção do ponto de vista das operações. Correlacionar eventos de diagnóstico em um conjunto de serviços independentes e lidar com distorções de relógio da máquina para entender a ordem do evento é um desafio. Da mesma forma que você interage com um microsserviço sobre protocolos e formatos de dados acordados, há uma necessidade de padronização em como registrar eventos de integridade e diagnóstico que, em última análise, acabam em um armazenamento de eventos para consulta e visualização. Em uma abordagem de microsserviços, é fundamental que diferentes equipes concordem em um único formato de registro. Precisa haver uma abordagem consistente para exibir eventos de diagnóstico no aplicativo.

Controlos sanitários

A saúde é diferente do diagnóstico. Saúde é sobre o microsserviço relatar seu estado atual para tomar as ações apropriadas. Um bom exemplo é trabalhar com mecanismos de atualização e implantação para manter a disponibilidade. Embora um serviço possa estar atualmente não íntegro devido a uma falha de processo ou reinicialização da máquina, 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 que o microsserviço se recupere. Os eventos de saúde de um microsserviço ajudam-nos a tomar decisões informadas e, de facto, ajudam a criar serviços de autorrecuperação.

Na seção Implementando verificações de integridade em ASP.NET serviços principais deste guia, explicamos como usar uma nova biblioteca ASP.NET HealthChecks em seus microsserviços para que eles possam relatar seu estado a um serviço de monitoramento para tomar as ações apropriadas.

Você também tem a opção de usar uma excelente biblioteca de código aberto chamada AspNetCore.Diagnostics.HealthChecks, disponível no GitHub e como um pacote NuGet. Esta biblioteca também faz verificações de integridade, com um toque, ela lida com dois tipos de verificações:

  • Liveness: Verifica se o microsserviço está ativo, ou seja, se é capaz de aceitar solicitações e responder.
  • Prontidã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á sendo executado, incluindo exceções, avisos e mensagens informativas simples. Normalmente, cada log está em um formato de texto com uma linha por evento, embora as exceções também geralmente mostrem o rastreamento de pilha em várias linhas.

Em aplicativos monolíticos baseados em servidor, você pode gravar logs em um arquivo no disco (um arquivo de log) e, em seguida, 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 onde vários serviços são executados em vários nós em um cluster orchestrator, 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 arquivos de log por si só, 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 onde está sendo executado. Um exemplo desses roteadores de fluxo de eventos é o Microsoft.Diagnostic.EventFlow, que coleta fluxos de eventos de várias fontes e os publica em sistemas de saída. Eles podem incluir saída padrão simples para um ambiente de desenvolvimento ou sistemas de nuvem como o Azure Monitor e o Azure Diagnostics. Há também boas plataformas e ferramentas de análise de logs de terceiros que podem pesquisar, alertar, relatar e monitorar logs, mesmo em tempo real, como o Splunk.

Orquestradores gerenciando informações de integridade e diagnóstico

Ao criar um aplicativo baseado em microsserviços, 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ço — você também precisa de alta disponibilidade, endereçabilidade, resiliência, integridade e diagnósticos se pretende ter um sistema estável e coeso.

Diagram of clusters supplying a support platform for microservices.

Figura 4-22. Uma plataforma de microsserviços é fundamental para o gerenciamento de integridade de um aplicativo

Os problemas complexos mostrados na Figura 4-22 são difíceis de resolver sozinhos. 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ços. Não devem concentrar-se na resolução de problemas complexos de infraestruturas; Se o fizessem, o custo de qualquer aplicativo baseado em microsserviços seria enorme. Portanto, existem plataformas orientadas a microsserviços, referidas como orquestradores ou clusters de microsserviços, que tentam resolver os problemas difíceis de construir e executar um serviço e usar recursos de infraestrutura de forma eficiente. Essa abordagem reduz as complexidades da criação de aplicativos que usam uma abordagem de microsserviços.

Orquestradores diferentes podem parecer semelhantes, mas os diagnósticos e verificações de integridade oferecidos por cada um deles diferem em recursos e estado de maturidade, às vezes dependendo da plataforma do sistema operacional, conforme explicado na próxima seção.

Recursos adicionais

AnteriorSeguinte