Service Mesh e a Comunicação dos Microsserviços

A arquitetura de Microsserviços (também conhecida como MSA) está chegando em um ponto no qual manusear a complexidade do sistema tornou-se vital para colher os benefícios da própria arquitetura posta à mesa. Implementar microsserviços não é grande coisa dada a vasta gama de frameworks disponíveis (como Spring Boot, DropWizard, NodeJs, MSF4J, etc). A implantação dos microsserviços também é amplamente abrangida com ferramentas de implantação conteinerizadas, como docker, kubernetes, Cloud Foundary, Open Shift, etc.

Esse texto é uma tradução autorizada do artigo escrito por Chanaka Fernando. Para acessar a versão original em inglês, clique aqui.

O verdadeiro desafio da implementação tipo microsserviços é a comunicação entre microsserviços. Agora, voltamos à era em que tínhamos a arquitetura de implantação de espaguete, na qual a comunicação de serviço para serviço acontece de modo ponto a ponto. As empresas percorreram um longo caminho desde aquela posição, por meio de ESB, API Gateways, Edge proxies, etc. Agora não é mais possível voltar ao mesmo momento na história. Esse requisito de comunicação entre microsserviços não foi uma consideração a posteriori. O método proposto no início da onda dos microsserviços foi o de usar

  • Terminais inteligentes (Smart Endpoints) e
  • Fluxos simples (Dump pipes)

Desenvolvedores usaram message brokers como o canal de comunicação (fluxo simples) enquanto tornaram o microsserviço em si um terminal inteligente. Embora esse conceito funcionou bem para as implementações iniciais de microsserviços, com os avanços das implementações, a escala e a complexidade, esse conceito não foi mais suficiente para lidar com a comunicação entre microsserviços.

É aí que o conceito de service mesh entrou em cena com um conjunto de recursos que são necessários para implementações pragmáticas de microsserviços. Service mesh podem ser consideradas a evolução de conceitos como ESB, API Gateway, Edge proxy do mundo SOA monolítico para o mundo dos microsserviços.

Fonte: https://medium.com/@mattklein123/service-mesh-data-plane-vs-control-plane-2774e720f7fc

 

A service mesh segue o padrão de design de sidecar, em que cada instância de serviço tem seu próprio sidecar proxy, o qual lida com a comunicação para outros serviços. O Serviço A não precisa estar ciente da rede ou das interconexões com outros serviços. Ele só vai precisar saber sobre a existência do sidecar proxy e fazer a comunicação por meio dele.

Em um alto nível, a service mesh pode ser considerada uma infraestrutura de software dedicada a lidar com a comunicação entre microsserviços. A principal responsabilidade da service mesh é entregar os pedidos do serviço X ao serviço Y de maneira confiável, segura e oportuna. Em termos de funcionalidade, isso é similar à função do ESB, com a qual ele interliga sistemas heterogêneos para comunicação de mensagens. A diferença aqui é que não há nenhum componente centralizado, mas sim uma rede distribuída de sidecar proxies.

A service mesh é análoga à pilha de redes TCP/IP em um nível funcional. No TCP/IP, os bytes (pacotes de rede) são entregues de um computador para outro através da camada física subjacente que consiste em roteadores, interruptores e cabos. Ele tem a capacidade de absorver falhas e garantir que as mensagens sejam entregues corretamente. Similarmente, a service mesh entrega solicitações de um microsserviço para outro microsserviço sobre a rede de service mesh que é executada sobre uma rede de microsserviços não confiável.

Embora existam semelhanças entre o TCP/IP e a service mesh, a última exige muito mais funcionalidade dentro de uma implantação corporativa real. Dada a seguir, há uma lista de funcionalidades que são esperadas de uma boa implementação de service mesh.

  • Descoberta de serviço de consistência eventual
  • Balanceamento de carga com reconhecimento de latência
  • Circuit breaking (interrupção) / Retries (tentativas) / Timeout (deadlines)
  • Roteamento
  • Autenticação e Autorização (Segurança)
  • Observabilidade

Podem haver mais recursos do que os da lista acima. Mas podemos considerar qualquer framework como bom, caso ofereça a lista mencionada acima. As funcionalidades acima mencionadas são executadas no sidecar proxy, onde se conecta diretamente com o microsserviço. Esse sidecar proxy pode viver dentro do mesmo contêiner ou em um contêiner separado.

Com o advento de mais e mais recursos dentro da arquitetura de service mesh, ficou evidente que deveria haver um mecanismo para configurar esses recursos por meio de um painel de controle centralizado ou comum. É aí que entram os conceitos de “Plano de dados” e “Plano de controle”.

Plano de dados

Em um alto nível, a responsabilidade do “plano de dados” é garantir que as solicitações sejam entregues do microsserviço X ao microsserviço Y de maneira confiável, segura e oportuna. Então as funcionalidades como

  • Descoberta de serviço
  • Health checking (verificação de saúde ou integridade)
  • Roteamento
  • Balanceamento de carga
  • Segurança
  • Monitoramento

são todas partes da funcionalidade do plano de dados.

Plano de controle

Embora as funcionalidades mencionadas acima sejam fornecidas dentro do plano de dados no sidecar proxy, a verdadeira configuração dessas funcionalidades é feita dentro do plano de controle. O plano de controle pega todos os sidecar proxies sem estado e os transforma em um sistema distribuído. Se correlacionarmos a analogia TCP/IP aqui, o plano de controle é semelhante a configurar os switches e roteadores, de forma que o TCP/IP funcione corretamente sobre esses switches e roteadores. Na Service mesh, o plano de controle é responsável por configurar a rede de sidecar proxies. As funcionalidades do plano de controle incluem configurar

  • Rotas
  • Balanceamento de carga
  • Circuit Breaker / Retry / Timeout
  • Implantações
  • Descoberta de Serviço

A figura a seguir explica bem a funcionalidade do plano de dados e do plano de serviço.

fonte: https://developer.ibm.com/code/2017/07/21/service-mesh-architecture-and-istio/

Como um resumo das coisas que discutimos acima,

  • O plano de dados toca todas as solicitações que estão passando pelo sistema e executa as funcionalidades como descoberta, roteamento, balanceamento de carga, segurança e observabilidade
  • O plano de controle fornece as políticas e configurações para todos os planos de dados e os transforma em uma rede distribuída

Aqui estão alguns dos projetos que implementaram esses conceitos.

Planos de dados – Linkered, Nginx, Envoy, HAProxy

Planos de controle – Istio, Nelson

Embora estejam categorizados em 2 seções, alguns frameworks têm funcionalidades relacionadas ao plano de dados e ao plano de controle.

 

Referências:

https://medium.com/@mattklein123/service-mesh-data-plane-vs-control-plane-2774e720f7fc

https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/

https://developer.ibm.com/code/2017/07/21/service-mesh-architecture-and-istio/

 

Autor: Chanaka Fernando

fique atualizado

Assine nossa newsletter e acompanhe as nossas novidades.

© 2019 Opus Software. Todos os direitos reservados. All rights reserved.