Service Mesh para microservicios PHP: guía completa

¿Tus microservicios PHP se comunican en secreto? Es hora de amplificar la voz

Imagina: tienes 15 microservicios PHP. Uno gestiona la autenticación, otro los pagos, otro las notificaciones. Se comunican por HTTP, pero cada semana algo falla: timeouts, caídas, peticiones perdidas. Añades reintentos, circuit breakers, balanceo — y el código se convierte en un espagueti de lógica de red.

Aquí es donde entra Service Mesh: una capa de infraestructura que saca toda la magia de red de tu código PHP. No temas: no es magia, es arquitectura bien pensada. Y sí, los microservicios PHP pueden (y deben) usar Service Mesh.

¿Qué es Service Mesh y por qué lo necesita un desarrollador PHP?

Service Mesh es una capa de infraestructura dedicada a gestionar la comunicación entre servicios. En lugar de escribir en cada microservicio la lógica de balanceo, cifrado, trazabilidad y timeouts, delegas esto a un proxy sidecar (normalmente Envoy o Linkerd).

Para PHP es especialmente relevante porque:

\n
• Las aplicaciones PHP suelen funcionar con FastCGI o FPM, y añadir lógica de red en cada servicio es una sobrecarga
\n
• Service Mesh proporciona mTLS (autenticación mutua) sin cambiar el código
\n
• Obtienes un panel unificado para monitorizar todos los microservicios
\n
• Puedes implementar circuit breaker y retry directamente a nivel de proxy
\n

El stack más popular es Istio + Envoy. Pero lo veremos desde la perspectiva de un desarrollador PHP.

Cómo funciona: servicio PHP + sidecar

Supongamos que tienes un microservicio user-service en PHP. Escucha en el puerto 9000 (FPM). Sin Service Mesh, accedes directamente:

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

Con Service Mesh, se añade un proxy Envoy a tu pod (contenedor). Ahora todo el tráfico entrante y saliente pasa por él:

┌─────────────────┐       ┌──────────────┐\n│ Aplicación PHP   │ ──►   │ Envoy Proxy  │\n│ (user-service)   │       │ (sidecar)    │\n└─────────────────┘       └──────┬───────┘\n                                  │\n                                  ▼\n                          ┌──────────────┐\n                          │ Envoy Proxy  │\n                          │ (otro servicio)│\n                          └──────────────┘

Tu código PHP no sabe del proxy. Simplemente envía peticiones a localhost:80 o localhost:9000 — Envoy las intercepta y las enruta según las reglas de Istio.

Ejemplo práctico: microservicio PHP con Service Mesh en Istio

Paso 1. Configuración del servicio PHP (sin cambios en el código)

Supón que tienes un script PHP simple que devuelve datos de un usuario:

<?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']);

Empaquétalo en Docker:

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

Todo estándar. Sin cambios para Service Mesh.

Paso 2. Despliegue con sidecar en Kubernetes

Añade la anotación sidecar.istio.io/inject: "true" — Istio insertará Envoy automáticamente:

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"  # <-- línea clave\n    spec:\n      containers:\n      - name: php\n