A arquitetura de microsserviços tem evoluído muito nos últimos dois anos e alguns novos conceitos e padrões estão surgindo. O conceito de Service mesh está ficando bastante popular. Neste post, a ideia é abordar os principais conceitos relacionados à Service mesh e como ela é usada em implementações de microsserviços do mundo real.
Por que Service Mesh?
Tal como acontece com muitas tecnologias emergentes, houve muito entusiasmo em torno da arquitetura de microsserviços. A maioria das pessoas imagina que os microsserviços são a resposta para todos os problemas que elas tiveram com arquiteturas anteriores, como SOA/ESB. No entanto, quando observamos as implementações de microsserviços do mundo real, podemos ver que a maioria das funcionalidades que um barramento centralizado (ESB) suporta, agora está implementada no nível de microsserviços. Então, estamos resolvendo mais ou menos o mesmo conjunto de problemas fundamentais, mas estamos resolvendo-os em diferentes dimensões com os microsserviços.
Figura 1: Da integração centralizada/ESB para os microsserviços
Por exemplo, vamos considerar um cenário em que você precisa chamar vários serviços downstream (que retornam dados para o cliente) de maneira confiável e expor a funcionalidade como um outro serviço (composto). Como mostrado na figura 1, com a arquitetura ESB, você pode facilmente aproveitar os recursos embutidos do ESB, para construir serviços virtuais/compostos e funcionalidades como circuit breakers, timeouts e descoberta de serviços, etc., os quais são úteis durante a comunicação entre serviços.
Quando você implementa o mesmo cenário usando microsserviços, não tem mais uma camada de integração/ESB centralizada, mas um conjunto de microsserviços (compostos e atômicos). Portanto, você precisa implementar todas essas funcionalidades no nível dos microsserviços.
Figura 2: Componentes do microsserviço e comunicação de serviço a serviço
Assim, um dado microsserviço que se comunica com outros serviços (figura 2), compreende:
- Lógica do negócio (bussiness logic) que implementa as funcionalidades de negócios, cálculos e lógica de composição/integração de serviços;
- Funções de rede que cuidam dos mecanismos de comunicação entre serviços (chamada de serviço básico através de um determinado protocolo, utilização dos patterns de resiliência e estabilidade, descoberta de serviços, etc.). Essas funções de rede são construídas sobre a pilha de rede subjacente no nível do sistema operacional.
Agora, pense no esforço envolvido na implementação desse microsserviço. Implementar as funcionalidades relacionadas à comunicação serviço-a-serviço a partir do princípio (“do zero”) é um pesadelo. Ao invés de se concentrar na lógica do negócio, você terá que gastar muito tempo na criação de funcionalidades de comunicação serviço-a-serviço. E isso é ainda pior se você usar várias tecnologias para construir os microsserviços (como, por exemplo, várias linguagens de programação como mostrado na figura 1), porque você precisa duplicar os mesmos esforços em diferentes linguagens (por exemplo, circuit breaker deve ser implementado em Java, Node/JavaScript, Python etc.).
O desafio mais complexo na concretização da arquitetura de microsserviço não é a construção dos serviços em si, mas a comunicação entre os serviços.
Uma vez que a maioria dos requisitos de comunicação entre serviços é bastante genérica em todas as implementações de microsserviços, podemos pensar em transferir todas essas tarefas para uma camada diferente, para que possamos manter o código do serviço independente. É aí que entra a ‘service mesh’.
O que é uma Service Mesh?
Em suma, uma service mesh é uma infraestrutura de comunicação entre serviços.
Com uma service mesh:
- Um determinado microsserviço não se comunicará diretamente com os outros microsserviços;
- Em vez disso, todas as comunicações serviço-a-serviço acontecerão através de um componente de software chamado service mesh (ou sidecar proxy);
- A service mesh fornece suporte integrado para algumas funções de rede, como resiliência, descoberta de serviços, etc;
- Portanto, os desenvolvedores de serviços podem se concentrar mais na lógica do negócio, enquanto a maior parte do trabalho relacionado à comunicação de rede é transferida para a service mesh;
- Por exemplo, você não precisa mais se preocupar com circuit breaking quando seu microsserviço chama outro serviço. Isso já vem como parte da service mesh;
- A service mesh é independente da linguagem: como a comunicação de microsserviço para o service mesh proxy está sempre sobre os protocolos padrão, como HTTP1.x/2.x, gRPC etc., você pode escrever seu microsserviço a partir de qualquer tecnologia e eles ainda irão funcionar com a service mesh.
Figura 3: Comunicação serviço a serviço da Service Mesh
Vamos tentar entender melhor as interações e responsabilidades do serviço mostradas na figura 3.
Lógica do Negócio
A implementação do serviço deve conter a implementação das funcionalidades do negócio. Isso inclui a lógica relacionada às suas funções de negócios, cálculos, integração com outros serviços/sistemas (incluindo sistemas legados, proprietários e SaaS) ou composições de serviço, lógica de roteamento complexa, lógica de mapeamento entre diferentes tipos de mensagens, etc.
Funções Primitivas de Rede
Embora tenhamos transferido a maioria das funções de rede para a service mesh, o serviço deve conter as interações de rede de alto nível básicas para conectar-se à service mesh/sidecar proxy. Portanto, a implementação deverá usar uma biblioteca de rede (ao contrário do mundo do ESB, onde você só precisa usar uma abstração muito simples) para iniciar chamadas de rede (apenas para a service mesh). Na maioria dos casos, o framework de desenvolvimento dos microsserviços incorpora as bibliotecas de rede necessárias para serem usadas para essas funções.
Funções de Aplicações de Rede
Existem funcionalidades da aplicação que são fortemente acopladas à rede, como circuit breaking, timeouts, descoberta de serviços, etc. Estas, são explicitamente separadas do código do serviço/lógica do negócio, e a service mesh as disponibiliza prontamente para uso.
A maioria das implementações iniciais de microsserviços simplesmente ignoraram a complexidade das funções de rede oferecidas a partir de uma camada ESB central, e implementaram todas essas funcionalidades do princípio (“do zero”), a cada nível de microsserviço. Agora eles começaram a perceber a importância de ter uma funcionalidade compartilhada similar, como uma malha distribuída.
Plano de Controle da Service Mesh
Todos os service mesh proxies são gerenciados centralmente por um painel de controle. Isso é bastante útil para dar suporte aos recursos da service mesh, como controle de acesso, observabilidade, descoberta de serviço, etc.
Funcionalidades de uma Service Mesh
Como vimos anteriormente, a service mesh oferece um conjunto de funções de aplicações de rede, enquanto algumas funções (primitivas) de rede continuam a ser implementadas no próprio nível dos microsserviços. Não existe uma regra rigorosa sobre quais funcionalidades devem ser oferecidas por uma service mesh. Os recursos mais comumente oferecidos por uma service mesh são:
- Resiliência para comunicações entre serviços: Circuit breaking, retries e timeouts, injeção de falhas, gerenciamento de falhas, balanceamento de carga e failover;
- Descoberta de Serviço: Descoberta de endpoints de serviço por meio de um mecanismo de registro de serviço dedicado;
- Roteamento: Recursos primitivos de roteamento, mas nenhuma lógica de roteamento relacionada à funcionalidade do negócio do serviço;
- Observabilidade: métricas, monitoramento, logging distribuído, rastreamento distribuído;
- Segurança: Segurança no nível de transporte (TLS) e gerenciamento de chaves;
- Controle de acesso: controle de acesso baseado em blacklist e whitelist;
- Implantação: suporte nativo para contêineres. Docker e Kubernetes;
- Protocolos de comunicação entre serviços: HTTP1.x, HTTP2, gRPC
Implementações de Service Mesh
O Linkerd e o Istio são duas implementações populares de service mesh de código aberto. Ambos seguem uma arquitetura semelhante, mas diferentes mecanismos de implementação. Você pode encontrar uma comparação muito boa entre essas duas implementações de service mesh em [1] .
Service Mesh: Prós e Contras
Vamos dar uma rápida olhada nos prós e contras das service meshes.
Prós
- Os recursos mais comuns são implementados fora do código do microsserviço e são reutilizáveis;
- Resolve a maioria dos problemas na arquitetura de microsserviços para os quais costumávamos ter soluções ad-hoc: rastreamento distribuído, logging, segurança, controle de acesso, etc;
- Mais liberdade quando se trata de selecionar uma linguagem de implementação de microsserviços: você não precisa se preocupar se uma determinada linguagem suporta ou possui bibliotecas para construir funções da aplicação de rede.
Contras
- Complexidade: Ter uma service mesh aumenta drasticamente o número de instâncias em tempo de execução que você tem em uma determinada implementação do microsserviço;
- Adicionando saltos (hops) extras: Cada chamada de serviço tem que passar por um salto extra (através do sidecar proxy da service mesh);
- As service meshes tratam de um subconjunto de problemas: A service mesh aborda apenas um subconjunto de problemas de comunicação entre serviços, mas há muitos problemas complexos, como roteamento complexo, mapeamento de transformação/tipo, integração com outros serviços e sistemas, a serem resolvidos na lógica de negócio do seu microsserviço;
- Imatura: as tecnologias de service mesh são relativamente novas para serem declaradas como “prontas para plena produção” para implantação em larga escala.
Conclusão
Em resumo, a service mesh aborda alguns dos principais desafios quando se trata da concretização da arquitetura de microsserviços. Ela oferece a você mais liberdade para selecionar um conjunto diversificado de tecnologias de implementação de microsserviços, além de permitir que você se concentre mais na lógica do negócio, em vez de ter que investir tempo em funcionalidades comuns de comunicação entre serviços. No entanto, a service mesh não solucionará nenhum problema relacionado à lógica do negócio ou à integração/composição do serviço.
Referências
Microservices for the Enterprise: Designing, Developing, and Deploying
Kasun Indrasiri e Prabath Siriwardena
Fonte: https://medium.com/microservices-in-practice/service-mesh-for-microservices-2953109a3c9a
Autor: Kasun Indrasiri
