O que é Service Mesh?

Introdução ao Service Mesh

O service mesh é uma infraestrutura configurável usada para gerenciar as comunicações entre serviços em sistemas de microsserviços. Seu objetivo é processar o tráfego entre microsserviços, também chamado de tráfego leste-oeste.

Em aplicações nativas da nuvem, uma aplicação pode consistir em centenas de serviços. Cada serviço pode ter várias instâncias, e cada uma dessas instâncias pode estar em constante mudança. Em um ambiente de execução tão complexo, como fornecer acesso confiável aos usuários e manter os serviços funcionando de forma estável tornou-se um grande desafio. Assim, surgiu uma solução chamada service mesh.

O service mesh é como o TCP/IP entre microsserviços, lidando com funções entre serviços, como chamadas de rede, limitação de taxa, monitoramento, etc. Aplicamos principalmente o service mesh na plataforma Kubernetes. Além disso, o padrão mais clássico é chamado de sidecar, que abstrai algumas funções gerais para o contêiner sidecar e o monta junto com o contêiner de serviço no mesmo pod. A imagem abaixo demonstra por que ele é chamado de service mesh.

O sidecar não é o único padrão que aplica o service mesh; além disso, temos o padrão DaemonSet e o padrão Ambient mesh:

• A diferença entre o padrão DaemonSet e o padrão sidecar é que o padrão DaemonSet permite que cada nó no cluster Kubernetes execute apenas um pod, e esse pod funciona como um proxy sidecar. Comparado ao padrão sidecar, o padrão DaemonSet usa muito menos recursos de máquina, mas tem desvantagens como isolamento ruim, chamadas de recursos difíceis de prever, etc. Você pode encontrar mais diferenças neste artigo: Sidecars e DaemonSets: Batalha dos padrões de conteinerização.

• Ambient mesh é um novo modo de plano de dados introduzido pelo Istio em 7 de setembro de 2022. Para resolver o problema de acoplamento da infraestrutura e implantação do mesh, o Ambient mesh separa o proxy do plano de dados do pod de aplicação para que ele possa ser implantado separadamente.

O Ambient mesh divide o plano de dados em uma camada de sobreposição segura e uma camada de processamento L7: A camada de sobreposição segura lida com funções como roteamento TCP, métricas de monitoramento, registro de acesso, túnel mTLS; além de todas as funções da camada de sobreposição segura, a camada de processamento L7 tem muitas outras funções, como controle de tráfego sobre roteamento HTTP, observabilidade e implementação de políticas de autorização L7 ricas.

Além disso, o Ambient mesh usa um agente compartilhado chamado ztunnel (túnel de confiança zero), que é executado em cada nó dentro do cluster Kubernetes e conecta e autentica de forma segura as cargas de trabalho dentro do mesh. Você pode ler este artigo se quiser saber mais sobre o modo Ambient mesh: Introducing Ambient Mesh

Por que precisamos de service mesh?

Antes que o service mesh se tornasse popular, a governança de serviços em muitas arquiteturas de microsserviços era alcançada através da colaboração entre o framework de microsserviços e a plataforma de controle. No entanto, esse método tem os seguintes problemas:

1. Acoplamento forte entre o framework e o serviço, o que aumenta a dificuldade e a complexidade de manutenção. Além disso, os desenvolvedores precisam entender bibliotecas públicas, o que os impede de se concentrar na implementação dos serviços.
2. É necessário manter um framework multi-idioma, aumentando os custos de manutenção.
3. O microsserviço tem um alto custo de atualização e geralmente precisa reiniciar o serviço durante a atualização.
4. Existem frameworks com muitas versões diferentes em produção, forçando as pessoas a considerar complexas questões de compatibilidade.

Para resolver os problemas acima, o ex-engenheiro do Twitter Willian Morgan, um dos fundadores do Linkerd, propôs o conceito de "Service Mesh". O service mesh usa um padrão sidecar para desacoplar a infraestrutura da lógica do serviço sem afetar a aplicação, o que permite uma atualização e operação unificada em termos de linguagem.

O service mesh move funções como controle de tráfego, observabilidade e comunicações seguras para os componentes básicos; assim, os desenvolvedores não precisam se preocupar com as implementações concretas da camada de comunicação e gerenciamento de serviços. Os desenvolvedores podem deixar todo o trabalho sujo relacionado à comunicação para o service mesh e se concentrar no desenvolvimento de serviços. Com base nessas características, o service mesh pode nos ajudar a resolver os problemas mencionados anteriormente.

Como o service mesh funciona?

O service mesh não adiciona novas funções ao ambiente de execução da aplicação, então todas as aplicações dentro de um framework ainda precisam de regras correspondentes para especificar como enviar solicitações de A para B. A diferença é que o service mesh extrai as comunicações entre serviços da gestão de lógicas e as abstrai em uma camada de infraestrutura.

Atualmente, a maioria dos service meshes usa a arquitetura de plano de dados + plano de controle, conforme mostrado abaixo:

O plano de controle

O plano de controle gerencia e configura o plano de dados e conduz estratégias durante a execução do serviço. Todas as instâncias dentro do plano de controle com um único service mesh compartilham os mesmos recursos de configuração.

O plano de controle foca mais em entrega e estratégias como segurança, observabilidade e controle de tráfego. Ele também coleta e reúne dados de telemetria do plano de dados para que os DevOps possam usá-los.

O plano de dados

O plano de dados geralmente funciona como um proxy e consiste em muitos proxies sidecar. O sidecar é executado em paralelo com as instâncias do serviço e controla o tráfego da aplicação de serviço interceptando o fluxo de dados do serviço.

Como mencionamos anteriormente, o service mesh é alcançado implementando um padrão sidecar no Kubernetes e encapsulando-o como um contêiner. O sidecar sugere o uso de um contêiner extra para expandir e fortalecer o contêiner principal, e esse contêiner extra é chamado de contêiner sidecar, que é alocado no mesmo pod que o contêiner de serviço. Por outro lado, o service mesh é uma rede em malha composta por esses proxies sidecar.

Aplicações do service mesh

Na arquitetura de microsserviços, os engenheiros geralmente criptografam serviços públicos expostos ou limitam o acesso para proteger o serviço, mas ignoram a segurança da comunicação dentro dos clusters. Até agora, muitas aplicações de microsserviços ainda carecem de criptografia na comunicação entre serviços, e o tráfego interno do cluster é transferido até mesmo em formato de dados brutos. Como resultado, o tráfego interno é muito suscetível a ataques de espionagem e MITM (Man-in-the-middle attack).

Para evitar ataques ao tráfego interno do cluster, usamos mTLS para criptografar os dados de tráfego. O mTLS pode garantir a segurança da comunicação entre microsserviços dentro do service mesh. Ele usa tecnologia de criptografia para autenticar cada microsserviço e criptografar o tráfego entre serviços mutuamente.

Embora possamos definir diretamente a estratégia de segurança de comunicação dentro do microsserviço e implementar autenticação de identidade e criptografia, ainda é muito ineficiente implementar a mesma função individualmente em cada microsserviço. Adicionar uma nova função exige modificar os códigos do serviço e invadir a lógica do serviço. Além disso, mesmo que possamos implementar a nova função, as iterações, atualizações e testes posteriores ainda exigirão que os desenvolvedores gastem mais tempo em manutenção. Assim, os desenvolvedores não conseguem se concentrar no desenvolvimento da função do serviço.

Em vez disso, se usarmos o service mesh, podemos fornecer comunicação mTLS sem que o serviço original precise estar ciente disso. Portanto, no service mesh, movemos todas as funções relacionadas à comunicação para os proxies sidecar.

Quando dois microsserviços precisam se comunicar, o proxy sidecar primeiro estabelece uma conexão mTLS e envia tráfego criptografado por meio dessa conexão mTLS. O sidecar troca certificados e autentica mutuamente pela autoridade certificadora. Antes de conectar, o sidecar examina a estratégia de autenticação enviada pelo plano de controle para determinar se permite que o microsserviço se comunique. Se a comunicação for permitida, o sidecar usará a chave de comunicação gerada para estabelecer conexões seguras e criptografar os dados de comunicação entre os microsserviços. Durante todo o processo, as aplicações de serviço não serão afetadas, reduzindo os incômodos dos desenvolvedores.

A partir desse cenário, todos podem entender por que o service mesh pode expandir as funções atuais sem afetar o serviço atual. Mas, é claro, além de alcançar a função de configuração de segurança de tráfego interno, semelhante ao mTLS, o service mesh também pode expandir rapidamente funções como controle de tráfego, observabilidade e protocolo de codec modificando a configuração do plano de controle.

Conclusão

Este artigo introduz brevemente os conceitos básicos do service mesh, seu princípio de funcionamento e os benefícios que ele nos traz. O service mesh revoluciona a arquitetura de microsserviços e ajuda os desenvolvedores a se livrarem do complexo ambiente de execução de microsserviços para se concentrarem no desenvolvimento de funções de serviço.

Embora o service mesh resolva muitos pontos problemáticos na arquitetura de microsserviços, ele ainda tem limitações. A complexidade do desenvolvimento de software é eterna e é apenas transferida de uma parte para outra. Quando abstraímos a gestão de serviços em uma camada separada, temos que enfrentar dificuldades adicionais de operação e manutenção e aumentos nos links de tráfego. Além disso, o service mesh precisa ser usado em um ambiente nativo da nuvem, o que estabelece um padrão mais alto para a capacidade profissional e experiência de trabalho dos DevOps. É por isso que dizemos que a tecnologia é apenas uma ferramenta para resolver problemas, mas precisamos pesar os benefícios que o service mesh traz de acordo com sua aplicação prática.

Com o desenvolvimento explosivo da nuvem nativa e a otimização do service mesh, é provável que o service mesh substitua completamente a arquitetura de microsserviços no futuro e se torne a primeira escolha de cada empresa para a reconstrução de arquiteturas de microsserviços e nuvem nativa.

Se você quiser saber mais sobre gerenciamento de API, entre em contato conosco quando quiser: https://api7.ai/contact.