Chapitre 10 : Architecture Microservices

Introduction

L'architecture microservices est devenue le standard pour construire des systèmes complexes, scalables et résilients. Ce chapitre explore la transition du monolithe vers les microservices, les stratégies de décomposition, les modes de communication, et la gestion des données distribuées.

---

10.1 Du monolithe aux microservices

10.1.1 Architecture monolithique

Un monolithe est une application où tous les composants sont interconnectés et déployés comme une seule unité.

Diagramme en cours de génération...

Avantages :

• Développement initial rapide
• Déploiement simple
• Transactions ACID faciles
• Tests intégrés simplifiés

Inconvénients :

• Limite de scalabilité (tout doit scaler ensemble)
• Complexité croissante avec la taille
• Frein à la vélocité des équipes
• Stack technique unique imposé

10.1.2 Architecture microservices

Diagramme en cours de génération...

Avantages :

• Scalabilité indépendante
• Déploiement indépendant
• Équipes autonomes (ownership)
• Résilience (isolation des pannes)
• Choix technologiques par service

Inconvénients :

• Complexité distribuée
• Gestion des transactions complexe
• Débogage et monitoring difficiles
• Communication réseau (latence)
• Déploiement et orchestration complexes

10.1.3 Le "Conway's Law"

"Les organisations qui conçoivent des systèmes sont contraintes de produire des designs qui sont des copies des structures de communication de ces organisations." — Melvin Conway, 1968

Diagramme en cours de génération...

Principe Inverse de Conway : Structurez vos équipes pour correspondre à l'architecture souhaitée.

---

10.2 Stratégies de décomposition

10.2.1 Décomposition par domaine métier

La méthode la plus courante utilise les Bounded Contexts du DDD (cf. ch. 11).

Diagramme en cours de génération...

10.2.2 Décomposition par sous-domaine (Strategy Domain)

• Core Domain : Avantage concurrentiel, investissement max
• Supporting Domain : Nécessaire mais pas stratégique
• Generic Domain : Solutions existantes, achèter plutôt que construire

10.2.3 Décomposition par capabilities métier

Identifier les capacités métier de l'organisation et mapper un service par capacité.

Capacités métier d'un e-commerce :
├── Gestion des produits (catalogue, prix, inventaire)
├── Gestion des commandes (création, suivi, historique)
├── Gestion des paiements (transaction, remboursement)
├── Gestion des expéditions (livraison, tracking)
├── Gestion des clients (compte, authentification)
└── Gestion des avis (notation, commentaires)

10.2.4 Patterns de décomposition

Diagramme en cours de génération...

10.2.5 Strangler Fig Pattern

Le Strangler Fig Pattern permet une migration progressive du monolithe vers les microservices :

1. Identifier un module à extraire
2. Créer le microservice correspondant
3. Router les nouvelles requêtes vers le microservice
4. Supprimer le code correspondant dans le monolithe
5. Répéter jusqu'à disparition totale du monolithe

---

10.3 Frontends (BFF, API Gateway)

10.3.1 API Gateway

L'API Gateway est un point d'entrée unique qui route les requêtes clients vers les microservices.

Diagramme en cours de génération...

Fonctions :

• Routage
• Authentification / Autorisation
• Rate Limiting
• Cache
• Transformation de protocole
• Agrégation de réponses
• Monitoring

10.3.2 Backend For Frontend (BFF)

Chaque client a son propre backend adapté :

Diagramme en cours de génération...

Avantages du BFF :

• API optimisée par client
• Pas de surcharge de données (over-fetching)
• Pas de sous-ensemble (under-fetching)
• Équipes spécialisées par client

10.3.3 API Gateway vs BFF

10.3.4 GraphQL comme alternative

GraphQL permet au client de spécifier exactement les données nécessaires :

query {
    commande(id: "123") {
        numero
        date
        total
        articles {
            nom
            prix
            quantite
        }
    }
}

---

10.4 Communication synchrone

10.4.1 REST (Representational State Transfer)

REST est le standard le plus répandu pour les APIs synchrones.

Principes :

• Ressources identifiées par URI
• Méthodes standard (GET, POST, PUT, DELETE, PATCH)
• Stateless (pas de session côté serveur)
• HATEOAS (Hypermedia as the Engine of Application State)

Diagramme en cours de génération...

10.4.2 gRPC

gRPC est un framework RPC haute performance développé par Google.

Avantages :

• Protobuf (sérialisation binaire rapide)
• Streaming bidirectionnel
• Contrats forts (fichiers .proto)
• Génération de code automatique

syntax = "proto3";

service CommandeService {
    rpc GetCommande (CommandeRequest) returns (CommandeResponse);
    rpc ListCommandes (ClientRequest) returns (stream CommandeResponse);
}

message CommandeRequest {
    string id = 1;
}

message CommandeResponse {
    string id = 1;
    string clientId = 2;
    double total = 3;
    repeated Article articles = 4;
}

10.4.3 Comparaison REST vs gRPC

---

10.5 Communication asynchrone

10.5.1 Event-Driven Architecture

Les services communiquent via des événements, sans couplage direct :

Diagramme en cours de génération...

10.5.2 Message Brokers

10.5.3 Patterns asynchrones

Event Notification : Un service notifie un changement sans attendre de réponse.

Diagramme en cours de génération...

Event Carried State Transfer : L'événement contient les données nécessaires.

CQRS + Events : Les événements alimentent les modèles de lecture (cf. 10.6.3).

---

10.6 Data Management

10.6.1 Database per Service

Chaque microservice possède sa propre base de données :

Diagramme en cours de génération...

Avantages : Indépendance, isolation, choix technologiques Inconvénients : Transactions distribuées, requêtes cross-service

10.6.2 Saga Pattern

Le Saga Pattern gère les transactions distribuées via une séquence d'étapes locales avec compensation.

Diagramme en cours de génération...

Types de Saga :

• Choreography-based : Chaque service produit un événement qui déclenche le suivant
• Orchestration-based : Un orchestrateur central coordonne les étapes

Choreography-based :

Diagramme en cours de génération...

10.6.3 CQRS (Command Query Responsibility Segregation)

CQRS sépare les opérations de lecture (Query) et d'écriture (Command).

Diagramme en cours de génération...

Avantages :

• Optimisation des lectures et écritures séparément
• Scalabilité indépendante (n lecteurs, 1 écrivain)
• Modèles de données spécialisés

10.6.4 Event Sourcing

Au lieu de stocker l'état actuel, on stocke la séquence des événements qui ont conduit à cet état.

Diagramme en cours de génération...

Avantages :

• Traçabilité complète
• Rejeu d'événements (debug, analytics)
• Time-travel (état à une date donnée)
• Source de vérité unique

Inconvénients :

• Courbe d'apprentissage
• Évolution du schéma des événements
• Performance des lectures (projections)

Architecture CQRS + Event Sourcing + Saga :

Diagramme en cours de génération...

---

10.7 Diagrammes d'architecture avec Mermaid

10.7.1 Architecture globale d'une plateforme e-commerce

Diagramme en cours de génération...

10.7.2 Orchestration Saga pour une commande

Diagramme en cours de génération...

10.7.3 CQRS avec Event Sourcing

Diagramme en cours de génération...

---

Références

• Sam Newman — Building Microservices (O'Reilly, 2015)
• Chris Richardson — Microservices Patterns (Manning, 2019)
• Martin Fowler — Microservices Resource Guide (martinfowler.com)
• Udi Dahan — CQRS and Event Sourcing
• Caitie McCaffrey — Saga Pattern in Practice