Arquitetura de software · Comunicação · 6 min de leitura
Service mesh: rede entre microsserviços com sidecars
Uma camada de proxies ao lado de cada serviço cuida de mTLS, retries, timeouts e métricas — sem mudar o código das aplicações.
Arraste para o lado para ver o diagrama inteiro.
O problema
Com dezenas de microsserviços, cada um precisaria implementar criptografia entre serviços, retries com limite, timeouts, circuit breaker, métricas e rastreamento — em várias linguagens. O service mesh tira isso do código e coloca na infraestrutura.
Como funciona
- Plano de dados: um proxy (como o Envoy) ao lado de cada instância intercepta o tráfego de entrada e saída.
- Plano de controle: distribui rotas, políticas e certificados para os proxies (Istio, Linkerd).
- Recursos: mTLS automático, divisão de tráfego para canários, retries e timeouts, autorização entre serviços e telemetria uniforme.
Variantes mais recentes evitam um sidecar por pod, usando um proxy por nó.
Vale a pena?
Adiciona latência (pequena), consumo de memória e complexidade operacional. Faz sentido com muitos serviços e exigências de segurança zero-trust; para poucos serviços, bibliotecas de cliente e um API gateway resolvem.
Em resumo
- Proxies ao lado de cada serviço.
- mTLS, retries e métricas sem mudar código.
- Plano de dados x plano de controle.
- Só compensa com muitos serviços.
Vantagens e custos
- Segurança e observabilidade uniformes
- Canários por configuração
- Latência e memória extras
- Mais uma peça complexa para operar