Compartilhar via

Comunicações resilientes

Dica

Esse conteúdo é um trecho do eBook, Architecting Cloud Native .NET Applications for Azure, disponível no .NET Docs ou como um PDF para download gratuito que pode ser lido offline.

Baixar PDF

Miniatura de capa do eBook

Ao longo deste livro, adotamos uma abordagem arquitetônica baseada em microsserviço. Embora essa arquitetura ofereç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 introduz congestionamento de rede, latência e falhas transitórias.

  • Descoberta de serviço. Como os microsserviços descobrem e se comunicam entre si ao executar em um cluster de computadores 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 entre várias instâncias de um microsserviço?

  • Segurança. Como as preocupações com a 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. 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á vinculado ao serviço - ele é criado com ele e compartilha seu ciclo de vida. A Figura 6-7 mostra esse cenário.

Malha de serviço com um carro lateral

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.

Plano de dados e controle de malha de serviço

Figura 6-8. Plano de dados e controle de malha de serviço

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. 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 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 ele retornar erros, uma malha removerá a instância do pool de balanceamento de carga e a reafirmará após a recuperação. Se uma solicitação atingir o tempo limite, uma malha poderá falhar e tentar novamente a solicitação. Uma 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, o Istio é o mais popular no momento desta 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 serviço a serviço em um cluster com autenticação e autorização forte baseadas em identidade.
  • Balanceamento automático de carga 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 de serviço.
  • Balanceamento de carga.
  • Término do 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 os Serviços de Kubernetes do Azure

A nuvem do Azure abraça o Istio e fornece suporte direto para ele nos Serviços de Kubernetes do Azure. Os links a seguir podem ajudá-lo a começar:

Referências

AnteriorPróximo