Module 13: Spring Cloud et Microservices
🎯 Objectifs du Module
À la fin de ce module, vous serez capable de :
- ✅ Comprendre l'architecture microservices vs monolithique
- ✅ Configurer un Service Discovery avec Eureka
- ✅ Centraliser la configuration avec Spring Cloud Config
- ✅ Créer une API Gateway avec Spring Cloud Gateway
- ✅ Implémenter la communication inter-services avec Feign
- ✅ Appliquer les patterns de résilience avec Resilience4j
- ✅ Comprendre les patterns: Circuit Breaker, Retry, Rate Limiter
📋 Prérequis
Avant de commencer ce module, assurez-vous de maîtriser :
- ✅ Module 1-6: Bases de Spring Boot et Spring Data JPA
- ✅ Module 7: Transactions et configuration
- ✅ Module 8: Spring Security (pour sécuriser les services)
- ✅ Module 12: Docker et déploiement (pour orchestrer les services)
- ✅ Concepts REST API
- ✅ Docker et Docker Compose (essentiel!)
🏗️ Architecture du Module
📚 Plan du Module
Chapitres Théoriques
| # | Chapitre | Durée | Description |
|---|---|---|---|
| 1 | Introduction aux Microservices | 45 min | Monolith vs Microservices, patterns, 12-Factor App |
| 2 | Service Discovery - Eureka | 1h | Eureka Server/Client, Load Balancing |
| 3 | Configuration Centralisée | 1h | Spring Cloud Config, Git backend, Refresh |
| 4 | API Gateway | 1h15 | Spring Cloud Gateway, Routes, Filters |
| 5 | Communication Inter-Services | 1h30 | Feign, Resilience4j, Circuit Breaker |
Travaux Pratiques
| # | TP | Durée | Description |
|---|---|---|---|
| 1 | Eureka Server et Clients | 1h30 | Créer le registre de services |
| 2 | Config Server | 1h | Configuration centralisée Git |
| 3 | API Gateway | 1h30 | Gateway avec routing et filters |
| 4 | Feign + Resilience4j | 2h | Communication résiliente |
Durée totale estimée: ~12 heures
🎬 Avant / Après ce Module
❌ AVANT (Architecture Monolithique)
┌─────────────────────────────────────────────┐
│ MONOLITH APPLICATION │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Users │ │Products │ │ Orders │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ ┌─────────────────────────────────┐ │
│ │ SINGLE DATABASE │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────────────┘
Problèmes:
- Un bug = toute l'app down
- Scaling: tout ou rien
- Déploiement: tout redéployer
- Technologies: une seule stack
- Équipes: conflits de merge
✅ APRÈS (Architecture Microservices)
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Users │ │ Products │ │ Orders │
│ Service │ │ Service │ │ Service │
│ :8081 │ │ :8082 │ │ :8083 │
└────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │
│ ┌─────────┴─────────┐ │
└────┤ Eureka Server ├────┘
│ :8761 │
└─────────┬─────────┘
│
┌─────────┴─────────┐
│ API Gateway │
│ :8080 │
└───────────────────┘
Avantages:
- Isolation des pannes
- Scaling indépendant
- Déploiement continu
- Polyglotte (Java, Node, Python...)
- Équipes autonomes
🧩 Composants Spring Cloud
🏢 Cas d'Usage: E-Commerce Microservices
Tout au long de ce module, nous construirons une plateforme e-commerce:
Services à Créer
| Service | Responsabilité | Port | Base de données |
|---|---|---|---|
| eureka-server | Registre des services | 8761 | - |
| config-server | Configuration centralisée | 8888 | Git repo |
| api-gateway | Point d'entrée unique | 8080 | - |
| user-service | Gestion utilisateurs | 8081 | PostgreSQL |
| product-service | Catalogue produits | 8082 | PostgreSQL |
| order-service | Gestion commandes | 8083 | PostgreSQL |
| inventory-service | Stock produits | 8084 | PostgreSQL |
| notification-service | Emails/SMS | 8085 | - |
Flux d'une Commande
🔑 Concepts Clés
1. Service Discovery (Pourquoi?)
Sans Service Discovery:
- URLs hardcodées: http://192.168.1.10:8081
- Si le service bouge → tout casse
- Load balancing manuel
Avec Eureka:
- Services s'enregistrent: "Je suis user-service"
- Clients demandent: "Où est user-service?"
- Eureka répond avec toutes les instances
- Load balancing automatique
2. Configuration Centralisée (Pourquoi?)
Sans Config Server:
- Chaque service a son application.properties
- Changer un mot de passe DB = modifier 10 fichiers
- Redéployer tous les services
Avec Config Server:
- Configuration dans Git
- Un seul endroit à modifier
- Refresh sans redémarrage
- Encryption des secrets
3. API Gateway (Pourquoi?)
Sans Gateway:
- Client connaît tous les services
- CORS à gérer partout
- Auth à implémenter partout
- Rate limiting impossible
Avec Gateway:
- Point d'entrée unique
- Auth centralisée
- Rate limiting
- Logging centralisé
- Transformation requests/responses
4. Circuit Breaker (Pourquoi?)
Sans Circuit Breaker:
- Service A appelle Service B
- Service B est down
- Service A attend... timeout
- Cascade failure → tout down
Avec Circuit Breaker:
- Détecte les échecs
- "Ouvre" le circuit
- Retourne fallback immédiat
- "Ferme" quand B revient
📦 Stack Technique
Dépendances Maven (BOM)
<!-- Dans le parent POM -->
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>2023.0.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
Versions Compatibles
| Spring Boot | Spring Cloud | Java |
|---|---|---|
| 3.2.x | 2023.0.x (Leyton) | 17+ |
| 3.1.x | 2022.0.x (Kilburn) | 17+ |
| 3.0.x | 2022.0.x (Kilburn) | 17+ |
⚠️ Quand Utiliser les Microservices?
✅ Bonnes Raisons
- Application large avec équipes multiples
- Besoin de scaling différent par composant
- Domaines métier bien définis (Bounded Contexts)
- Besoin de résilience (isolation des pannes)
- Déploiements fréquents et indépendants
❌ Mauvaises Raisons
- "C'est la mode"
- Petit projet / petite équipe
- MVP / Prototype
- Équipe sans expérience DevOps
- Infrastructure limitée
💡 Règle d'Or
"Si vous n'avez pas les problèmes d'un monolithe, vous n'avez pas besoin de microservices."
— Martin Fowler
🗺️ Progression du Module
🚀 Prêt à Commencer?
Ce module est avancé et nécessite une bonne maîtrise des modules précédents. Si vous êtes prêt:
- Installez Docker (essentiel pour ce module)
- Assurez-vous d'avoir 16GB+ de RAM (plusieurs services)
- Préparez un IDE avec support Spring (IntelliJ recommandé)
Commencer le Chapitre 1: Introduction aux Microservices →