Service Mesh und PHP: Wie Mikroservices intelligenter werden

Ihre PHP-Mikroservices flüstern sich etwas zu? Zeit, die Freisprecheinrichtung einzuschalten

Stellen Sie sich vor: Sie haben 15 PHP-Mikroservices. Einer ist für die Autorisierung zuständig, ein anderer für Zahlungen, ein dritter für Benachrichtigungen. Sie kommunizieren über HTTP, aber jede Woche geht etwas kaputt: Timeouts, Abstürze, verlorene Anfragen. Sie fügen Retries, Circuit Breaker, Lastverteilung hinzu – und der Code verwandelt sich in Spaghetti aus Netzwerklogik.

Hier kommt Service Mesh ins Spiel – eine Infrastrukturschicht, die die gesamte Netzwerk-Magie aus Ihrem PHP-Code auslagert. Keine Angst: Das ist keine Magie, sondern eine durchdachte Architektur. Und ja, PHP-Mikroservices können (und sollten) Service Mesh verwenden.

Was ist Service Mesh und warum braucht ein PHP-Entwickler es?

Service Mesh ist eine dedizierte Infrastrukturebene zur Verwaltung der Kommunikation zwischen Diensten. Anstatt in jedem Mikroservice Logik für Lastverteilung, Verschlüsselung, Tracing und Timeouts zu schreiben, delegieren Sie dies an einen Sidecar-Proxy (normalerweise Envoy oder Linkerd).

Für PHP ist dies besonders relevant, weil:

\n
• PHP-Anwendungen oft über FastCGI oder FPM laufen und das Hinzufügen von Netzwerklogik in jeden Dienst ein Overhead ist
\n
• Service Mesh mTLS (gegenseitige Authentifizierung) ohne Codeänderungen bietet
\n
• Sie ein einheitliches Dashboard zur Überwachung aller Mikroservices erhalten
\n
• Sie Circuit Breaker und Retry direkt auf Proxy-Ebene implementieren können
\n

Der beliebteste Stack ist Istio + Envoy. Aber wir betrachten ihn aus der Perspektive eines PHP-Entwicklers.

Wie es funktioniert: PHP-Dienst + Sidecar

Angenommen, Sie haben einen Mikroservice user-service in PHP. Er hört auf Port 9000 (FPM). Ohne Service Mesh greifen Sie direkt darauf zu:

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

Mit Service Mesh wird Ihrem Pod (Container) ein Envoy-Proxy hinzugefügt. Nun läuft der gesamte eingehende und ausgehende Datenverkehr durch ihn:

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

Ihr PHP-Code weiß nichts vom Proxy. Er sendet einfach Anfragen an localhost:80 oder localhost:9000 – Envoy fängt sie ab und routet sie gemäß den Istio-Regeln.

Praktisches Beispiel: PHP-Mikroservice mit Service Mesh auf Istio

Schritt 1. Einrichtung des PHP-Dienstes (ohne Codeänderungen)

Angenommen, Sie haben ein einfaches PHP-Skript, das Benutzerdaten zurückgibt:

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

Packen Sie es in Docker:

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

Alles Standard. Keine Änderungen für Service Mesh.

Schritt 2. Deployment mit Sidecar in Kubernetes

Fügen Sie die Annotation sidecar.istio.io/inject: "true" hinzu – Istio fügt Envoy automatisch ein:

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"  # <-- Schlüsselzeile\n    spec:\n      containers:\n      - name: php\n