Comunicações resilientes
Gorjeta
Este conteúdo é um excerto do eBook, Architecting Cloud Native .NET Applications for Azure, disponível no .NET Docs ou como um PDF transferível gratuito que pode ser lido offline.
Ao longo deste livro, adotamos uma abordagem arquitetônica baseada em microsserviços. Embora essa arquitetura proporcione 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 introduz congestionamento de rede, latência e falhas transitórias.
Descoberta de serviços. Como os microsserviços descobrem e se comunicam entre si quando executados em um cluster de máquinas com seus próprios endereços IP e portas?
Resiliência. Como você gerencia falhas de curta duração e mantém o sistema estável?
Balanceamento de carga. Como o tráfego de entrada é distribuído em várias instâncias de um microsserviço?
Segurança. Como são aplicadas as preocupações de segurança, como a criptografia no nível de transporte e o gerenciamento de certificados?
Monitoramento distribuído. - Como você correlaciona e captura 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 Service Mesh. 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. Ele dissocia essas preocupações, movendo-as 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á ligado ao serviço - é criado com ele e partilha o 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 interceta e gerencia a comunicação entre os microsserviços e o cluster.
Uma malha de serviço é logicamente dividida 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. Controle de malha de serviço e plano de dados
Uma vez configurada, uma malha de serviço é altamente funcional. Ele pode recuperar um pool correspondente de instâncias de um ponto de extremidade de descoberta de serviço. A malha pode então 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 muitos fatores, incluindo sua 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 retornar erros, uma malha removerá a instância do pool de balanceamento de carga e a reafirmará depois que ela for corrigida. Se um pedido expirar, uma malha pode falhar e, em seguida, repetir o pedido. Uma malha captura e emite métricas e rastreia distribuído para um sistema de métricas centralizado.
Istio e Enviado
Embora existam atualmente algumas opções de malha de serviço, o Istio é o mais popular no momento em que este artigo foi escrito. A Istio é uma joint venture da IBM, Google e Lyft. É uma oferta de código aberto que pode ser integrada em um aplicativo distribuído novo ou existente. A tecnologia fornece uma solução consistente e completa para proteger, conectar e monitorar microsserviços. As suas características incluem:
- Proteja a comunicação serviço-a-serviço em um cluster com autenticação e autorização fortes baseadas em identidade.
- Balanceamento automático de carga para tráfego HTTP, gRPC, WebSocket e TCP.
- Controle refinado do comportamento do tráfego com regras de roteamento avançadas, tentativas, failovers e injeção de falhas.
- Uma camada de política conectável e uma API de configuração que suportam controles de acesso, limites de taxa e cotas.
- Métricas, logs e rastreamentos automáticos para todo o tráfego dentro de um cluster, incluindo entrada e saída de cluster.
Um componente-chave para uma implementação do Istio é um serviço de proxy intitulado proxy Envoy. Ele é executado ao lado de cada serviço e fornece uma base independente de plataforma para os seguintes recursos:
- Descoberta dinâmica de serviços.
- Balanceamento de carga.
- Rescisão TLS.
- Proxies HTTP e gRPC.
- Resiliência do disjuntor.
- Controlos de saúde.
- Atualizações contínuas com implantações canárias .
Como discutido anteriormente, o Envoy é implantado como um sidecar para cada microsserviço no cluster.
Integração com os Serviços Kubernetes do Azure
A nuvem do Azure adota o Istio e fornece suporte direto para ele nos Serviços Kubernetes do Azure. Os links a seguir podem ajudá-lo a começar:
