Service Mesh et PHP : comment les microservices deviennent plus intelligents

Vos microservices PHP communiquent à voix basse ? Il est temps d'activer le haut-parleur

Imaginez : vous avez 15 microservices PHP. L'un gère l'authentification, un autre les paiements, un troisième les notifications. Ils communiquent via HTTP, mais chaque semaine, quelque chose se casse : timeouts, plantages, requêtes perdues. Vous ajoutez des retries, des circuit breakers, de l'équilibrage de charge — et le code se transforme en spaghetti de logique de communication réseau.

C'est là qu'intervient Service Mesh — une couche d'infrastructure qui extrait toute la magie réseau de votre code PHP. N'ayez crainte : ce n'est pas de la magie, mais une architecture réfléchie. Et oui, les microservices PHP peuvent (et doivent) utiliser Service Mesh.

Qu'est-ce que Service Mesh et pourquoi un développeur PHP en a-t-il besoin ?

Service Mesh est une couche d'infrastructure dédiée à la gestion des communications inter-services. Au lieu d'écrire dans chaque microservice la logique d'équilibrage de charge, de chiffrement, de traçage et de timeouts, vous déléguez cela à un proxy sidecar (généralement Envoy ou Linkerd).

C'est particulièrement pertinent pour PHP car :

\n
• Les applications PHP fonctionnent souvent via FastCGI ou FPM, et ajouter de la logique réseau dans chaque service est un overhead
\n
• Service Mesh fournit mTLS (authentification mutuelle) sans modification du code
\n
• Vous obtenez un tableau de bord unique pour surveiller tous les microservices
\n
• Vous pouvez implémenter circuit breaker et retry directement au niveau du proxy
\n

La stack la plus populaire est Istio + Envoy. Mais nous allons l'examiner du point de vue d'un développeur PHP.

Comment ça fonctionne : service PHP + sidecar

Supposons que vous ayez un microservice user-service en PHP. Il écoute sur le port 9000 (FPM). Sans Service Mesh, vous y accédez directement :

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

Avec Service Mesh, un proxy Envoy est ajouté à votre pod (conteneur). Désormais, tout le trafic entrant et sortant passe par lui :

┌─────────────────┐       ┌──────────────┐\n│ Application PHP  │ ──►   │ Envoy Proxy  │\n│ (user-service)   │       │ (sidecar)    │\n└─────────────────┘       └──────┬───────┘\n                                  │\n                                  ▼\n                          ┌──────────────┐\n                          │ Envoy Proxy  │\n                          │ (autre service)│\n                          └──────────────┘

Votre code PHP ne sait pas qu'il y a un proxy. Il envoie simplement des requêtes vers localhost:80 ou localhost:9000 — Envoy les intercepte et les achemine selon les règles d'Istio.

Exemple pratique : microservice PHP avec Service Mesh sur Istio

Étape 1. Configuration du service PHP (sans modification du code)

Supposons que vous ayez un simple script PHP qui renvoie les données d'un utilisateur :

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

Placez-le dans un Docker :

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

Tout est standard. Aucune modification pour Service Mesh.

Étape 2. Déploiement avec sidecar dans Kubernetes

Ajoutez l'annotation sidecar.istio.io/inject: "true" — Istio insérera automatiquement Envoy :

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"  # <-- ligne clé\n    spec:\n      containers:\n      - name: php\n