Service Mesh: o que é, como funciona e quando adotar

Quando uma aplicação evolui de dois ou três microsserviços para algumas dezenas, a comunicação entre eles deixa de ser detalhe de arquitetura e vira o maior foco de problemas em produção. Retries, timeouts, mTLS, descoberta de serviços e coleta de métricas passam a ser implementados em cada repositório, em cada linguagem, de forma levemente diferente.

É exatamente esse tipo de dor que um service mesh se propõe a resolver. Em vez de cada time duplicar a mesma camada de rede dentro do código da aplicação, o mesh centraliza essas responsabilidades em uma camada de infraestrutura dedicada, invisível para o desenvolvedor.

Este guia explica o que é service mesh, como a arquitetura sidecar funciona por baixo, quais são as principais ferramentas do mercado, o overhead real em latência e memória e, principalmente, como avaliar se o seu ambiente realmente precisa de um mesh ou se ele vai apenas adicionar complexidade.

O que é service mesh?

Service mesh é uma camada de infraestrutura dedicada ao gerenciamento da comunicação entre microsserviços. Ele atua no tráfego leste-oeste, ou seja, entre os serviços internos de uma aplicação distribuída, tratando roteamento, resiliência, segurança e telemetria de forma uniforme.

Na prática, um service mesh injeta um proxy leve ao lado de cada instância de serviço. Esse proxy intercepta todo o tráfego de entrada e saída e aplica políticas definidas centralmente, sem que a aplicação precise saber disso. O resultado é uma infraestrutura de comunicação consistente, independente da linguagem ou framework usado em cada microsserviço.

Essa abordagem ganhou tração com a adoção massiva de Kubernetes e padrões cloud-native. Em ambientes com dezenas ou centenas de serviços, automatizar mTLS, retries, observabilidade e roteamento avançado na plataforma é mais seguro e barato do que manter bibliotecas e middlewares replicados em cada base de código.

Por que service mesh surgiu

Em arquiteturas monolíticas, chamadas entre componentes eram invocações de método dentro do mesmo processo. Quando a aplicação é quebrada em microsserviços, essas chamadas viram requisições HTTP ou gRPC pela rede, e a rede falha. Pacotes se perdem, latências variam, serviços caem e se reconectam.

Cada microsserviço passou a precisar de código para retries com backoff exponencial, timeouts configuráveis, circuit breakers, service discovery, autenticação mútua e emissão de métricas e traces. Quando o time tem três serviços em Java, esse esforço ainda é tolerável. Com trinta serviços em Java, Go, Python e Node, vira uma fonte constante de inconsistência.

A primeira tentativa de solução foram as bibliotecas como Netflix Hystrix e Ribbon. O problema é que bibliotecas obrigam todos os serviços a usar a mesma linguagem ou versão, acoplam a funcionalidade ao ciclo de deploy da aplicação e são invisíveis para quem não tem acesso ao repositório. O service mesh resolve o mesmo conjunto de problemas fora do processo da aplicação, em um proxy externo, o que o torna agnóstico de linguagem e centralizado operacionalmente.

Como funciona a arquitetura de um service mesh

A arquitetura de um service mesh é dividida em dois componentes lógicos: o data plane, que lida com o tráfego real, e o control plane, que configura e orquestra os proxies do data plane.

Data plane: o sidecar proxy

O data plane é formado pelos sidecars, proxies injetados automaticamente em cada pod de uma aplicação que roda em containers Docker ou Kubernetes. O proxy mais usado é o Envoy, desenvolvido originalmente pela Lyft e hoje mantido pela CNCF. Ele intercepta todo o tráfego TCP e HTTP que entra ou sai do pod, aplicando políticas sem exigir mudanças no código da aplicação.

Cada sidecar roda no mesmo namespace de rede que o container principal, o que permite interceptar conexões localhost. Para a aplicação, continua parecendo que ela está conversando com outro serviço diretamente. Na realidade, o tráfego passa primeiro pelo sidecar local, vai pela rede até o sidecar do destino e só então chega ao serviço remoto.

Control plane: o cérebro do mesh

O control plane é onde os operadores definem políticas, como regras de roteamento, versões de TLS, timeouts padrão e configurações de autorização. No Istio, esse componente é o istiod. No Linkerd, é um conjunto de controladores incluindo o destination e o identity service.

O control plane não processa o tráfego real. Ele traduz as políticas declarativas em configurações específicas para cada sidecar e entrega essas configurações via xDS ou protocolos equivalentes. Isso significa que uma falha no control plane não derruba o tráfego imediatamente; os sidecars continuam operando com a última configuração recebida.

Principais funcionalidades de um service mesh

Um service mesh entrega três grandes famílias de funcionalidades: traffic management, segurança e observabilidade. Todas elas passam a existir por padrão para qualquer serviço que esteja dentro do mesh.

Em traffic management, o mesh permite roteamento baseado em headers, pesos, versões ou identidade do chamador. Estratégias como canary release, blue-green deployment, fault injection e mirroring de tráfego para ambientes de teste saem de código customizado e viram configuração declarativa.

Em segurança, o destaque é o mTLS automático. O mesh emite certificados de curta duração para cada serviço, rotaciona automaticamente e cifra todo o tráfego leste-oeste. Políticas de autorização fine-grained permitem, por exemplo, que apenas o serviço checkout possa chamar o serviço payments.

Em observabilidade, o mesh emite métricas RED (rate, errors, duration) para todo par de serviços que conversa entre si, gera spans para tracing distribuído e produz access logs estruturados, tudo sem instrumentação manual. Esse ganho é enorme para times que ainda não têm maturidade completa nos pilares da observabilidade.

O exemplo abaixo mostra uma regra de canary do Istio enviando 90% do tráfego para a versão estável e 10% para a nova versão:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: checkout
spec:
  hosts:
  - checkout
  http:
  - route:
    - destination:
        host: checkout
        subset: v1
      weight: 90
    - destination:
        host: checkout
        subset: v2
      weight: 10

Service mesh x API gateway: quando cada um atua

É comum confundir service mesh com API gateway, porque ambos lidam com tráfego de rede. A diferença principal é o sentido do tráfego que cada um gerencia e a superfície de responsabilidades.

Um API gateway atua no tráfego norte-sul, entre clientes externos (navegador, app mobile, parceiros) e a borda da aplicação. Ele cuida de autenticação de usuário, rate limiting por API key, transformação de payloads, versionamento de API pública e agregação de chamadas. Já o service mesh atua no tráfego leste-oeste, entre os serviços internos da aplicação, após a requisição já ter atravessado o gateway.

Na prática, as duas ferramentas coexistem. O API gateway expõe o contrato externo e protege a borda; o service mesh cuida da malha interna. A tabela abaixo resume as diferenças:

Comparativo das principais ferramentas de service mesh

O ecossistema de service mesh amadureceu desde 2018 e hoje conta com quatro projetos principais: Istio, Linkerd, Consul Connect e Kuma. Cada um tem um perfil próprio de complexidade, performance e filosofia de design.

Istio é o mais completo e o mais complexo. Usa Envoy como data plane, tem o maior ecossistema de integrações e é o mais flexível para cenários enterprise. Em contrapartida, consome mais recursos e tem curva de aprendizado íngreme. Quem quer entender as capacidades completas pode começar pela documentação oficial do Istio.

Linkerd foi redesenhado do zero com proxies ultraleves escritos em Rust. Tipicamente consome cerca de 10 MB de memória por sidecar e adiciona latência significativamente menor que o Istio. Tem mTLS habilitado por padrão e superfície de configuração reduzida, priorizando simplicidade. Vale visitar a página introdutória do projeto Linkerd antes de decidir.

Consul Connect, da HashiCorp, é a melhor opção quando já se usa Consul para service discovery em ambientes híbridos, com máquinas virtuais além de Kubernetes. Kuma, patrocinado pela Kong, também foca em cenários multi-zona e multi-mesh, com suporte nativo a VMs e Kubernetes lado a lado.

Para um panorama atualizado dos projetos cloud-native do ecossistema, o CNCF Landscape é o melhor recurso.

Overhead e trade-offs do sidecar

A maior crítica ao modelo sidecar é o custo. Cada chamada entre dois serviços passa agora por dois proxies, um do lado do chamador e um do lado do receptor. Em benchmarks públicos, isso adiciona tipicamente 1ms a 5ms de latência por chamada, um número aceitável para a maioria das aplicações web e inaceitável para certos workloads de baixa latência, como trading de alta frequência.

Além da latência, existe o custo de memória e CPU. Um cluster com 200 pods passa a ter 200 sidecars adicionais. Com Istio e Envoy, é comum ver consumo de 50 a 100 MB por sidecar; com Linkerd, a faixa cai para cerca de 10 a 20 MB. Esse custo é linear com o número de pods, o que tem impacto direto em ambientes com muitos serviços pequenos.

Há também custo operacional. Um mesh adiciona componentes novos no control plane, novos CRDs, novos pontos de falha e nova superfície de observabilidade a ser monitorada. Para um time que ainda está aprendendo a operar Kubernetes, adotar service mesh pode acelerar mais incidentes do que resolver. Antes de decidir, vale entender bem os impactos em latência em aplicações distribuídas.

Quando adotar service mesh e quando evitar

Service mesh não é uma ferramenta neutra. Ela compensa claramente em alguns cenários e adiciona complexidade desnecessária em outros. Um checklist prático ajuda a decidir de forma objetiva.

Três ou mais indicadores a favor sinalizam que o mesh provavelmente compensa o esforço. Três ou mais contra sugerem que o time deve investir em bibliotecas leves e padronizações de código antes de adotar uma nova camada de infraestrutura.

Como monitorar um service mesh em produção

O mesh que melhora a observabilidade dos serviços também precisa ser monitorado. Isso tem duas frentes: saúde dos componentes do mesh propriamente dito e aproveitamento dos dados que ele gera para observar o resto da aplicação.

No control plane, os sinais críticos são: disponibilidade do istiod ou equivalente, latência de distribuição de configuração para os sidecars, taxa de erros em push de xDS e tempo de emissão de certificados mTLS. Atrasos nesses indicadores antecedem incidentes em que sidecars antigos ficam com configuração desatualizada.

No data plane, as métricas clássicas são as RED para cada par de serviços: taxa de requisições, taxa de erros e distribuição de duração. Como o mesh já emite Prometheus metrics nativamente, aplicar o método RED sobre o tráfego leste-oeste fica trivial. Também é importante acompanhar reinícios de sidecars, consumo de memória por pod e spans gerados por segundo.

Integrar esses sinais ao stack de monitoração existente, via Prometheus, Grafana, Zabbix ou coletor OpenTelemetry, é o que garante que o investimento em o que é observabilidade se paga. Em ambientes que já rodam monitoramento de Kubernetes, o mesh se torna uma nova categoria de dashboards e alertas, não uma ilha separada.

Conclusão

Service mesh é uma peça poderosa para ambientes com muitos microsserviços, linguagens diversas e exigências de segurança e observabilidade que não cabem em código de aplicação. Ele centraliza mTLS, roteamento avançado, métricas RED e traces em uma camada de infraestrutura declarativa, reduzindo duplicação e aumentando consistência.

Ao mesmo tempo, o mesh não é grátis. O overhead de latência, o consumo de memória por sidecar e a complexidade operacional tornam a adoção apenas recomendável quando os ganhos superam claramente os custos. Em cenários pequenos ou em times ainda aprendendo Kubernetes, bibliotecas e padrões de código simples entregam valor com menos risco.

Se sua operação já está no ponto de avaliar service mesh, vale tratar o projeto como um investimento em plataforma, com observabilidade e monitoração desenhadas desde o dia um. Para discutir como estruturar monitoração de service mesh alinhada ao seu serviço de observabilidade e ao restante do seu ambiente, fale com um especialista da OpServices.