Microservices en PHP : architecture et pratique

Microservices en PHP : architecture et pratique

Dans le développement web moderne, l'architecture monolithique cède de plus en plus la place à l'architecture microservices. PHP, traditionnellement associé aux monolithes (WordPress, Laravel monolithique), est parfaitement adapté à la construction de systèmes distribués. Dans cet article, nous allons analyser les principes clés de l'architecture microservices en PHP, examiner des exemples pratiques de code et les outils qui vous aideront à passer du monolithe à un système flexible.

Que sont les microservices et pourquoi en a-t-on besoin en PHP

L'architecture microservices est une approche où l'application est divisée en plusieurs services indépendants. Chaque service est responsable de sa propre logique métier (authentification, paiements, notifications) et peut être développé, déployé et mis à l'échelle séparément.

Pourquoi PHP est adapté aux microservices :

• Démarrage rapide — les frameworks PHP (Laravel, Symfony, Lumen) permettent de créer un service en quelques minutes.
• Grande communauté — des milliers de paquets prêts à l'emploi pour travailler avec les files d'attente, les API et les bases de données.
• Flexibilité — on peut combiner PHP avec d'autres langages (Go, Python) dans un même système.

Cependant, rappelez-vous : les microservices ajoutent de la complexité. Il ne faut pas fragmenter le projet si vous avez une petite application. Commencez par un monolithe, puis extrayez les services au fur et à mesure de la croissance.

Architecture d'un microservice typique en PHP

Examinons la structure de base d'un service. Supposons que nous ayons un service UserService, responsable de l'inscription et de l'authentification des utilisateurs.

Structure du projet :

user-service/├── api/│   └── index.php          # point d'entrée (REST API)├── src/│   ├── Controllers/│   │   └── AuthController.php│   ├── Models/│   │   └── User.php│   ├── Services/│   │   └── AuthService.php│   └── Database/│       └── migrations/├── config/│   └── database.php├── composer.json├── Dockerfile└── .env

Chaque service :

• Possède son propre dépôt et sa propre base de données (souvent PostgreSQL ou MySQL).
• Communique avec le monde extérieur via REST API ou gRPC.
• Est empaqueté dans un conteneur Docker.

Exemple d'un contrôleur REST simple sur Lumen (micro-framework Laravel) :

<?php

namespace App\\Http\\Controllers;

use Illuminate\\Http\\Request;use App\\Models\\User;

class AuthController extends Controller{    public function register(Request $request)    {        // Validation        $this->validate($request, [            'email' => 'required|email|unique:users',            'password' => 'required|min:8'        ]);

        // Création de l'utilisateur        $user = User::create([            'email' => $request->input('email'),            'password' => app('hash')->make($request->input('password'))        ]);

        return response()->json(['user_id' => $user->id], 201);    }}

Échange de données entre services : synchrone et asynchrone

Les microservices ne peuvent pas exister isolément. Il existe deux méthodes principales de communication :

1. Synchrone (HTTP/REST)

Le service A appelle directement l'API du service B. Simple, mais crée un couplage fort.

<?php// Dans le service OrderService$httpClient = new \\GuzzleHttp\\Client();$response = $httpClient->post('http://user-service/api/validate', [    'json' => ['token' => $token]]);

if ($response->getStatusCode() === 200) {    // L'utilisateur est valide}

2. Asynchrone (files d'attente / RabbitMQ)

Le service envoie un message à un broker (RabbitMQ, Kafka), et un autre service le traite en arrière-plan. Cela réduit la charge et rend le système plus tolérant aux pannes.

Exemple d'envoi d'événement via RabbitMQ avec la bibliothèque php-amqplib :

<?phprequire_once __DIR__ . '/ve