Service Mesh para Microsserviços

A arquitetura de microsserviços tem evoluído muito nos últimos dois anos e há alguns novos conceitos e padrões surgindo. O conceito de ‘Service Mesh’ está ficando bastante popular. Neste post, estou planejando abordar os principais conceitos relacionados ao Service Mesh e como ele é usado em implementações de microsserviços na prática.

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

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 eles 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 de maneira resiliente e expor a funcionalidade como um outro serviço (composto). Como mostrado na figura 1, com a arquitetura ESB, você pode aproveitar facilmente os recursos internos do ESB, para construir serviços e funcionalidades virtuais/compostos, como circuit breakers, timeouts e descoberta de serviços, etc., ú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 de 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, aplicam padrões 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 zero é um pesadelo. Ao invés de focar 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 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, 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 infra-estrutura 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 em cima de um componente de software chamado service mesh (ou side-car 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 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 ainda trabalhar 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 de um determinado serviço. Isso inclui lógica relacionada às suas funções de negócios, cálculos, integração com outros serviços/sistemas (incluindo legado, proprietário 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, um determinado serviço deve conter as interações básicas de rede de alto nível para conectar-se ao service mesh/side-car proxy. Portanto, uma determinada implementação de serviço terá que usar uma determinada 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 service mesh). Na maioria dos casos, a estrutura de desenvolvimento de 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 de aplicação que se acoplam fortemente à rede, como circuit breaking, timeouts, descoberta de serviços, etc. Essas são explicitamente separadas do código de serviço/lógica do negócio, e a service mesh disponibiliza essas funcionalidades prontas para uso.

A maioria das implementações iniciais de microsserviços simplesmente ignoram a complexidade das funções de rede oferecidas a partir de uma camada ESB central, e implementaram todas essas funcionalidades do zero a cada nível de microsserviço. Agora eles começaram a perceber a importância de ter uma funcionalidade compartilhada similar a 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 ao 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 do microsserviços. Não existe uma regra rigorosa sobre quais funcionalidades devem ser oferecidas a partir de uma service mesh. Esses são os recursos mais comuns oferecidos em uma service mesh.

  • Resiliência para comunicações entre serviços: Circuit-breaking, retries and 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 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 de commodity são implementados fora do código de microsserviço e são reutilizáveis.
  • Resolve a maioria dos problemas na arquitetura de Microsserviços que usamos para 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 de 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 meshs 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ço. 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 mais tempo em funções de rede 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

 

Autor: Kasun Indrasiri

 

fique atualizado

Assine nossa newsletter e acompanhe as nossas novidades.

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