Service Mesh

Uma camada de infraestrutura para a comunicação entre serviços: cada workload ganha um proxy sidecar, e os sidecars cuidam de mTLS com identidade por serviço, política de autorização, retry e telemetria. Os serviços falam HTTP simples com localhost e não têm uma linha de TLS, retry ou autorização. Use com muitos microsserviços, ou quando a rede exige mTLS estrito (PCI-DSS, BACEN).

Veja também: service-design/sidecar e service-design/ambassador — um proxy só, sem malha.

passos: 5
arquivos: 5
testes: 0
tecnologias: 6

Infraestrutura realTypeScriptBunElysiaEnvoyOpenSSLDocker

Cenário Relações Comparar

Baixar cartão

Cenário

O serviço de pagamentos consulta o antifraude antes de aprovar cada PIX ou TED. A regulação exige tráfego cifrado e autenticado entre serviços, e só pagamentos pode pedir score — um serviço de relatórios, mesmo com certificado emitido pela mesma CA, não. O antifraude às vezes falha na primeira tentativa (pod reiniciando), e ninguém quer retry espalhado pelo código.

Planta

Fluxo

6/6

6 passos — reproduza para seguir o fluxo

chamada
resposta ou assíncrono
falha
passo
toque num nó para focar
Outras plantas de fluxo

Como funciona

5 passos

Proxies cuidam do tráfego entre serviços.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

payments+2

per_try_timeout+1

Ambassador

/stats+1

Ambassador

01
mesh-ca faz o papel de identidade do plano de controle: emite a CA e um certificado por workload, com a identidade como URI SPIFFE (spiffe://bank.local/sa/payments) no SAN
02
Pagamentos chama http://127.0.0.1:15001/score; o sidecar dele abre mTLS apresentando a identidade payments e só aceita o par se o SAN for spiffe://bank.local/sa/fraud
03
O sidecar do antifraude exige certificado de cliente e aplica RBAC: só a identidade payments, só POST /score; qualquer outra identidade recebe 403 e cliente sem certificado nem completa o handshake
04
A identidade do chamador chega ao antifraude em x-forwarded-client-cert, escrita pelo sidecar (SANITIZE_SET) — o cliente não consegue forjá-la
05
Retry com per_try_timeout no sidecar de pagamentos absorve a falha de primeira tentativa; retries, handshakes e decisões de RBAC saem do /stats dos Envoys

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

mTLS e identidade por serviço sem código nos serviços
Autorização por identidade, não por IP
Retry, timeout e telemetria iguais em toda a malha
Política muda na malha, sem deploy dos serviços

Custos

Um proxy por workload: CPU, memória e latência a mais
Plano de controle e emissão de certificados para operar
Depurar atravessa sidecars dos dois lados
Abaixo de alguns serviços, a complexidade não se paga

apps/api/service-mesh

5 arquivos

mesh/

ca.shinfraCA da malha: emite os certificados com identidade SPIFFE
envoy-payments.yamlinfraSidecar de pagamentos: saída com mTLS, verificação da identidade do par e retry
envoy-fraud.yamlinfraSidecar do antifraude: entrada com mTLS obrigatório e RBAC por identidade

src/