Service Mesh para microsserviços PHP: guia completo

Seus microsserviços PHP se comunicam em sussurros? Hora de aumentar o volume

Imagine: você tem 15 microsserviços PHP. Um cuida da autenticação, outro dos pagamentos, um terceiro das notificações. Eles se comunicam via HTTP, mas toda semana algo quebra: timeouts, quedas, requisições perdidas. Você adiciona retries, circuit breakers, balanceamento — e o código vira um espaguete de lógica de rede.

É aqui que entra o Service Mesh — uma camada de infraestrutura que remove toda a complexidade de rede do seu código PHP. Não se preocupe: não é mágica, é arquitetura bem pensada. E sim, microsserviços PHP podem (e devem) usar Service Mesh.

O que é Service Mesh e por que um dev PHP precisa disso?

Service Mesh é uma camada de infraestrutura dedicada para gerenciar a comunicação entre serviços. Em vez de escrever lógica de balanceamento, criptografia, tracing e timeouts em cada microsserviço, você delega isso a um sidecar proxy (geralmente Envoy ou Linkerd).

Para PHP, isso é especialmente relevante porque:

\n
• Aplicações PHP geralmente rodam via FastCGI ou FPM, e adicionar lógica de rede em cada serviço gera overhead
\n
• Service Mesh oferece mTLS (autenticação mútua) sem alterar o código
\n
• Você ganha um dashboard unificado para monitorar todos os microsserviços
\n
• Pode implementar circuit breaker e retry diretamente no nível do proxy
\n

O stack mais popular é Istio + Envoy. Mas vamos analisar isso do ponto de vista de um desenvolvedor PHP.

Como funciona: serviço PHP + sidecar

Suponha que você tenha um microsserviço user-service em PHP. Ele escuta na porta 9000 (FPM). Sem Service Mesh, você acessa diretamente:

GET http://user-service:9000/api/users/1

Com Service Mesh, um proxy Envoy é adicionado ao seu pod (contêiner). Agora, todo tráfego de entrada e saída passa por ele:

┌─────────────────┐       ┌──────────────┐\n│ Aplicação PHP    │ ──►   │ Envoy Proxy  │\n│ (user-service)   │       │ (sidecar)    │\n└─────────────────┘       └──────┬───────┘\n                                  │\n                                  ▼\n                          ┌──────────────┐\n                          │ Envoy Proxy  │\n                          │ (outro serviço)│\n                          └──────────────┘

Seu código PHP não sabe da existência do proxy. Ele simplesmente envia requisições para localhost:80 ou localhost:9000 — o Envoy as intercepta e roteia conforme as regras do Istio.

Exemplo prático: microsserviço PHP com Service Mesh no Istio

Passo 1. Configuração do serviço PHP (sem alterações no código)

Digamos que você tenha um script PHP simples que retorna dados do usuário:

<?php\n// user-service/index.php\n$userId = $_GET['id'] ?? 0;\n$users = [\n    1 => ['name' => 'Alice', 'email' => 'alice@example.com'],\n    2 => ['name' => 'Bob', 'email' => 'bob@example.com'],\n];\n\nheader('Content-Type: application/json');\necho json_encode($users[$userId] ?? ['error' => 'User not found']);

Empacote em Docker:

# Dockerfile\nFROM php:8.2-fpm\nCOPY index.php /var/www/html/index.php\nCMD ["php-fpm"]

Tudo padrão. Nenhuma alteração necessária para o Service Mesh.

Passo 2. Deploy com sidecar no Kubernetes

Adicione a anotação sidecar.istio.io/inject: "true" — o Istio injetará o Envoy automaticamente:

apiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: user-service\nspec:\n  replicas: 2\n  selector:\n    matchLabels:\n      app: user-service\n  template:\n    metadata:\n      labels:\n        app: user-service\n      annotations:\n        sidecar.istio.io/inject: "true"  # <-- linha chave\n    spec:\n      containers:\n      - name: php\n