A arquitetura de microsserviços (também conhecida como MSA) está atingindo um ponto onde lidar adequadamente com a complexidade do sistema tornou-se vital para obter os benefícios que a própria arquitetura traz ao mercado. Implementar microsserviços não exige mais muito esforço, dada a vasta gama de frameworks disponíveis (como Spring Boot, DropWizard, NodeJs, MSF4J, etc). A implantação dos microsserviços também é uma questão bem resolvida graças a ferramentas de deploy conteinerizadas como Docker, Kubernetes, Cloud Foundry, OpenShift, 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 baseada em microsserviços é a comunicação entre eles. Parece que estamos de volta ao início do SOA, onde tínhamos a arquitetura de implantação tipo “espaguete”, na qual a comunicação entre serviços usava o modelo ponto-a-ponto. Entretanto, as empresas percorreram um longo caminho desde então, por meio de ESB, API Gateways, Edge proxies, etc. E, agora, não é mais possível voltar ao mesmo momento da história. Esse requisito de comunicação entre microsserviços não foi uma consideração a posteriori. O método proposto desde o início da “onda” dos microsserviços foi o de usar:
- Terminais inteligentes (Smart Endpoints) e
- Canais de comunicação simples (Dump pipes)
Partindo desse princípio, os desenvolvedores usaram message brokers como o canal de comunicação simples enquanto tornaram o microsserviço em si um terminal inteligente. Embora o conceito tenha funcionado bem para as implementações iniciais de microsserviços, com o avanço das implementações e o aumento de sua escala e complexidade, esse fundamento 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 a implementação pragmática de microsserviços. A service mesh pode ser considerada a evolução de conceitos como ESB, API Gateway, Edge proxy do mundo SOA monolítico, adaptando-os para o mundo dos microsserviços.
Fonte: https://medium.com/@mattklein123/service-mesh-data-plane-vs-control-plane-2774e720f7fc
A service mesh utiliza o design pattern Sidecar: Cada instância de microsserviço tem seu próprio proxy, e é ele quem cuida da comunicação com outros serviços. O serviço A não precisa estar ciente da rede ou das interconexões com outros serviços. Ele só precisa conhecer seu Sidecar proxy, e realizará toda a comunicação através dele.
De forma mais ampla, a service mesh pode ser considerada uma infraestrutura de software dedicada responsável por realizar 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 em tempo adequado. Em termos de funcionalidade, isso é similar à função do ESB da arquitetura SOA, quando interliga sistemas heterogêneos proporcionando um mecanismo adequado para comunicação por mensagens. A diferença aqui é que não há nenhum componente centralizado, mas sim uma rede distribuída de sidecar proxies.
No nível de funcionalidade, a service mesh é análoga à pilha da redeTCP/IP. 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, switches e cabos. Ela tem a capacidade de absorver falhas e garantir que as mensagens sejam entregues corretamente. De forma similar, a service mesh entrega solicitações de um microsserviço para outro através da rede de service mesh que é executada sobre uma rede não confiável de microsserviços.
Embora existam semelhanças entre o TCP/IP e a service mesh, essa última exige muito mais funcionalidades em uma implantação corporativa real. A seguir, é apresentada uma lista das funcionalidades que são esperadas de uma boa implementação de service mesh:
- Descoberta de serviços (mesmo frente a flutuações de consistência e de disponibilidade desses serviços);
- Balanceamento de carga (que deve levar em consideração a latência na comunicação entre os serviços);
- Implementação do pattern Circuit Breaker, de mecanismos de repetição de tentativas em caso de falhas (retries) e temporização de chamadas (timeout);
- Roteamento
- Autenticação e Autorização (Segurança)
- Observabilidade
Embora possam haver mais características do as apresentadas acima, essas são as funcionalidades mínimas oferecidas por um bom framework. Essas funcionalidades são executadas no sidecar proxy, que se conecta diretamente com o microsserviço. Esse sidecar proxy pode estar dentro do mesmo contêiner do microsserviço ou em um contêiner separado.
À medida que mais e mais recursos foram sendo inseridos na 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 linhas gerais, podemos dizer que 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 em tempo adequado. Então, funcionalidades como:
- Descoberta de serviço
- Health checking (verificação de integridade)
- Roteamento
- Balanceamento de carga
- Segurança
- Monitoramento
são parte das funcionalidades do plano de dados.
Plano de controle
Embora as funcionalidades mencionadas acima sejam fornecidas dentro do plano de dados no sidecar proxy, a configuração dessas funcionalidades é feita efetivamente dentro do plano de controle. O plano de controle pega todos os sidecar proxies sem estado (stateless) 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 eles. 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 ilustra as funcionalidades 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 de tudo que discutimos acima, temos que:
- O plano de dados cuida de todas as solicitações que estão passando pelo sistema e executa funcionalidades como descoberta, roteamento, balanceamento de carga, segurança e observabilidade;
- O plano de controle fornece as políticas e as configurações para todos os planos de dados e os transforma em uma rede distribuída.
Abaixo 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 tanto ao plano de dados quanto ao plano de controle.
Referências:
Autor: Chanaka Fernando
