Comunicação resiliente
Dica
Esse conteúdo é um trecho do livro eletrônico, para Projetar os Aplicativos .NET nativos de nuvem para o Azure, disponível no .NET Docs ou como um PDF para download gratuito que pode ser lido offline.
Ao longo deste livro, adotamos uma abordagem arquitetônica baseada em microsserviço. Embora essa arquitetura forneça benefícios importantes, ela apresenta muitos desafios:
Comunicação de rede fora do processo. Cada microsserviço se comunica por meio de um protocolo de rede que insere congestionamento de rede, latência e falhas transitórias.
Descoberta de serviço. Como os microsserviços descobrem e se comunicam entre si ao serem executados em um cluster de computadores com seus próprios endereços IP e portas?
Resiliência. Como gerenciar falhas de curta duração e manter o sistema estável?
Balanceamento de carga. Como o tráfego de entrada é distribuído em várias instâncias do microsserviço?
Segurança. Como as preocupações de segurança, como criptografia no nível do transporte e gerenciamento de certificados, são impostas?
Monitoramento distribuído. - Como correlacionar e capturar a rastreabilidade e o monitoramento de uma única solicitação em vários microsserviços de consumo?
Você pode resolver essas preocupações com diferentes bibliotecas e estruturas, mas a implementação pode ser cara, complexa e demorada. Você também acaba com preocupações de infraestrutura acopladas à lógica de negócios.
Malha de serviço
Uma abordagem melhor é uma tecnologia em evolução intitulada Malha de Serviço. Uma malha de serviço é uma camada de infraestrutura configurável com recursos internos para lidar com a comunicação de serviço e os outros desafios mencionados acima. Ela separa essas preocupações ao movê-las para um proxy de serviço. O proxy é implantado em um processo separado (chamado de sidecar) para fornecer isolamento do código comercial. No entanto, o sidecar está vinculado ao serviço, ele é criado com ele e compartilha seu ciclo de vida. A Figura 6-7 mostra esse cenário.
Figura 6-7. Malha de serviço com um carro lateral
Na figura anterior, observe como o proxy intercepta e gerencia a comunicação entre os microsserviços e o cluster.
Uma malha de serviço é dividida logicamente em dois componentes diferentes: um plano de dados e um plano de controle. A figura 6-8 mostra esses componentes e suas responsabilidades.
Figura 6-8. Plano de dados e controle de malha de serviço
Depois de configurada, a malha de serviço é altamente funcional. Ela pode recuperar um pool correspondente de instâncias de um ponto de extremidade de descoberta de serviço. Em seguida, a malha pode enviar uma solicitação para uma instância específica, registrando a latência e o tipo de resposta do resultado. Uma malha pode escolher a instância com maior probabilidade de retornar uma resposta rápida com base em vários fatores, incluindo a latência observada para solicitações recentes.
Se uma instância não responder ou falhar, a malha tentará novamente a solicitação em outra instância. Se ela retornar erros, a malha removerá a instância do pool de balanceamento de carga e a repetirá após a recuperação. Se uma solicitação atingir o tempo limite, a malha poderá falhar e tentar novamente a solicitação. A malha captura e emite métricas e rastreamento distribuído para um sistema de métricas centralizado.
Istio e Envoy
Embora existam algumas opções de malha de serviço atualmente, a Istio é o mais popular no momento dessa gravação. A Istio é uma joint venture da IBM, Google e Lyft. É uma oferta de software livre que pode ser integrada a um aplicativo distribuído novo ou existente. A tecnologia fornece uma solução consistente e completa para proteger, conectar e monitorar microsserviços. Seus recursos incluem:
- Proteger a comunicação de serviço a serviço em um cluster com autenticação e autorização forte baseada em identidade.
- Balanceamento de carga automático para tráfego HTTP, gRPC, WebSocket e TCP.
- Controle refinado do comportamento de tráfego com regras de roteamento, repetições, failovers e injeção de falhas avançadas.
- Uma camada de política plugável e uma API de configuração que dá suporte a controles de acesso, limites de taxa e cotas.
- Métricas, logs e rastreamentos automáticos para todo o tráfego em um cluster, incluindo entrada e saída do cluster.
Um componente-chave para uma implementação Istio é um serviço proxy intitulado proxy Envoy. Ele é executado junto com cada serviço e fornece uma base independente de plataforma para os seguintes recursos:
- Descoberta dinâmica do serviço.
- Balanceamento de carga.
- Encerramento de TLS.
- Proxies HTTP e gRPC.
- Resiliência do disjuntor.
- Verificações de integridade.
- Atualizações sem interrupção com implantações canárias.
Conforme discutido anteriormente, o Envoy é implantado como um sidecar para cada microsserviço no cluster.
Integração com o Serviço de Kubernetes do Azure
A nuvem do Azure adota a Istio e fornece suporte direto para ela nos Serviços de Kubernetes do Azure. Os seguintes links podem ajudá-lo a começar:
