Architecture Microservices avec Spring

Découpage métier, communication interservices, API Gateway, versioning, résilience, observabilité et bonnes pratiques d’architecture pour construire des systèmes distribués.

Introduction

Les microservices permettent d’industrialiser des architectures distribuées, scalables et indépendamment déployables. Dans l’écosystème Spring, ils reposent sur un socle technique solide : Spring Boot, Spring Cloud, API Gateway, OpenFeign, Kafka et des solutions d’observabilité modernes.

Ce chapitre présente les piliers fondamentaux d’une architecture microservices professionnelle : découpage métier, communication, versioning, résilience, monitoring et bonnes pratiques d’exploitation.

Lexique essentiel

Découpage métier
Segmentation des services autour du domaine (DDD).

API Gateway
Point d’entrée unique pour router, sécuriser et versionner les API.

OpenFeign
Client HTTP typé pour communiquer entre microservices.

Service Registry
Annuaire des services (Eureka, Consul…).

Observabilité
Logs structurés, métriques, traces distribuées (OpenTelemetry).

Résilience
Circuit breakers, retry, timeouts (Resilience4j).

1. Découpage des microservices (DDD & Bounded Contexts)

Un bon découpage est métier, pas technique. Chaque microservice doit porter un Bounded Context clair, autonome et cohérent.

Exemple d’architecture e-commerce :

Service Commandes — création, statut, paiements
Service Catalogue — produits, stocks, prix
Service Clients — comptes, adresses, préférences
Service Paiements — facturation, transactions
Service Notifications — emails, SMS, événements

Bonnes pratiques :

Un microservice = un domaine métier.
Aucun partage de base de données.
API propre, versionnée, stable.
Éviter les microservices trop petits (anti-pattern : nano-services).

2. Communication interservices : synchro & asynchro

Deux grands types de communication : synchrone (HTTP/REST) et asynchrone (Kafka).

Communication HTTP via OpenFeign


@FeignClient(name = "catalog-service", path = "/products")
public interface ProductClient {

    @GetMapping("/{id}")
    ProductResponse getProduct(@PathVariable String id);
}

OpenFeign simplifie les échanges typés sans boilerplate.

Événements & asynchronisme avec Kafka


public record OrderCreatedEvent(Long orderId, String customerId) {}

Utiliser Kafka pour découpler les services et absorber les pics de charge.

Règles de communication :

HTTP pour : consultation, synchronisation rapide.
Kafka pour : workflows, notifications, événements métier.
Jamais de RPC, jamais de dépendance circulaire.

3. API Gateway : le centre de contrôle

L’API Gateway offre un point d’entrée unique, essentiel pour :

routage intelligent
authentification centralisée
versioning
rate limiting
mise en cache
observabilité des appels

Exemple Spring Cloud Gateway


@Bean
public RouteLocator routes(RouteLocatorBuilder builder) {
    return builder.routes()
        .route("orders", r -> r.path("/orders/**").uri("lb://order-service"))
        .route("catalog", r -> r.path("/catalog/**").uri("lb://catalog-service"))
        .build();
}

lb:// = discovery dynamique via Eureka ou Consul.

4. Versioning d’API (indispensable)

Une API microservices doit être versionnée pour permettre l’évolution :

/api/v1/products
/api/v2/products

Chaque version doit être stable, documentée et retirée proprement avec un plan de migration.

5. Observabilité : logs, métriques, traces distribuées

Les microservices sont distribués → impossible de diagnostiquer sans observabilité robuste.

Actuator + Micrometer


management.endpoints.web.exposure.include=health,metrics,prometheus

Traces distribuées (OpenTelemetry)

Chaque requête possède un traceId unique visible dans tous les services.

Logs structurés JSON

C’est indispensable pour exploiter Elasticsearch / Grafana / Loki.

Observabilité entreprise :

Actuator obligatoire.
Logs JSON → exploitables par la plateforme.
Traces distribuées pour chaque requête.
Métriques Prometheus pour détecter les dérives.

Quiz : Microservices Spring

Q1. Quelle règle doit être respectée absolument ?
- A. Services qui partagent la même base
- B. Un service = un domaine métier ✔
- C. Un service = une table
Q2. Pourquoi une API Gateway ?
- A. Déployer plus vite
- B. Sécuriser et router les API ✔
- C. Pour faire joli

Exercice d’application

Concevez une architecture microservices complète :
— 3 microservices métier
— Communication HTTP + Kafka
— API Gateway avec routes / versioning
— Observabilité (Actuator, traceId, logs JSON)
— Diagramme de séquence d’un workflow métier

Résumé

Une architecture microservices réussie repose sur un découpage métier clair, une communication maîtrisée (HTTP + événements), une Gateway robuste, un versioning propre et une observabilité complète. Avec Spring Boot et Spring Cloud, ces concepts deviennent opérationnels à grande échelle.

Navigation de la Formation

Spring Boot & Kafka →