Chapitre 1: Introduction aux Microservices

🎯 Objectifs du Chapitre

• Comprendre la différence entre monolithe et microservices
• Identifier les avantages et inconvénients de chaque approche
• Découvrir les patterns essentiels des microservices
• Maîtriser les principes de la 12-Factor App
• Savoir quand choisir quelle architecture

---

1. Architecture Monolithique

1.1 Définition

Un monolithe est une application où toutes les fonctionnalités sont déployées ensemble dans un seul processus.

1.2 Exemple: E-Commerce Monolithique

// Structure typique d'un monolithe
src/main/java/com/ecommerce/
├── EcommerceApplication.java
├── config/
│   └── SecurityConfig.java
├── controller/
│   ├── UserController.java
│   ├── ProductController.java
│   ├── OrderController.java
│   ├── PaymentController.java
│   └── InventoryController.java
├── service/
│   ├── UserService.java
│   ├── ProductService.java
│   ├── OrderService.java
│   ├── PaymentService.java
│   └── InventoryService.java
├── repository/
│   ├── UserRepository.java
│   ├── ProductRepository.java
│   ├── OrderRepository.java
│   └── ...
└── model/
    ├── User.java
    ├── Product.java
    ├── Order.java
    └── ...

1.3 Avantages du Monolithe

Avantage	Explication
Simplicité de développement	Un seul projet, un seul IDE
Déploiement simple	Un seul JAR/WAR à déployer
Tests faciles	Tests d'intégration simples
Transactions ACID	Une seule BD = transactions faciles
Debugging simple	Stack trace complète
Performance locale	Pas de latence réseau entre modules
Refactoring facile	IDE peut renommer partout

1.4 Inconvénients du Monolithe

Inconvénient	Explication
Scaling tout ou rien	Impossible de scaler un seul module
Déploiement risqué	Un bug = toute l'app down
Stack unique	Tout en Java (ou autre)
Temps de build long	Recompiler tout à chaque fois
Conflits d'équipe	Merges difficiles sur un gros projet
Dette technique	Difficile à moderniser
Onboarding long	Nouveau dev doit tout comprendre

1.5 Quand le Monolithe Devient Problématique

Année 1: Startup
- 3 développeurs
- 50K lignes de code
- Déploiement: 5 minutes
→ Monolithe PARFAIT ✅

Année 3: Croissance
- 30 développeurs
- 500K lignes de code
- Déploiement: 45 minutes
- Conflits Git quotidiens
→ Monolithe devient un frein ⚠️

Année 5: Scale
- 100 développeurs
- 2M lignes de code
- Déploiement: 2 heures
- Black Friday: tout crash
→ Monolithe = "Big Ball of Mud" ❌

---

2. Architecture Microservices

2.1 Définition

Les microservices sont une approche où l'application est divisée en petits services autonomes, chacun:

• Déployable indépendamment
• Avec sa propre base de données
• Communiquant via API (HTTP/REST ou messaging)
• Géré par une petite équipe

2.2 Caractéristiques Clés

1. Single Responsibility

Chaque service fait UNE chose bien:
- user-service: gestion utilisateurs UNIQUEMENT
- order-service: gestion commandes UNIQUEMENT
- inventory-service: gestion stock UNIQUEMENT

2. Autonomie

Chaque service:
- A son propre repo Git
- A sa propre BD (Database per Service)
- A son propre pipeline CI/CD
- Peut être déployé seul
- Peut utiliser une techno différente

3. Communication

Synchrone (HTTP/REST):
- Client attend la réponse
- Simple mais couplant

Asynchrone (Messaging):
- Fire and forget
- Découplé mais complexe

2.3 Avantages des Microservices

Avantage	Explication
Scaling ciblé	Scaler uniquement le service qui en a besoin
Isolation des pannes	Un service down ≠ tout down
Déploiement indépendant	Déployer 10x par jour par service
Polyglotte	Java, Node, Python, Go... selon le besoin
Équipes autonomes	"You build it, you run it"
Évolutivité	Ajouter un service sans toucher aux autres
Modernisation	Réécrire un service à la fois

2.4 Inconvénients des Microservices

Inconvénient	Explication
Complexité distribuée	Debugging difficile
Latence réseau	Appels HTTP entre services
Transactions distribuées	ACID impossible, Sagas nécessaires
Cohérence éventuelle	Données pas immédiatement synchronisées
Opérations complexes	Monitoring, logging, tracing
Coût infrastructure	Plus de serveurs, plus de BDs
Overhead	Chaque service = overhead mémoire

---

3. Comparaison Détaillée

3.1 Tableau Comparatif

Critère	Monolithe	Microservices
Complexité initiale	Faible	Élevée
Complexité à long terme	Élevée	Maîtrisée
Déploiement	Tout ou rien	Indépendant
Scaling	Vertical	Horizontal
Technologie	Unique	Polyglotte
Équipe	Une équipe	Équipes par service
Base de données	Partagée	Par service
Transactions	ACID simple	Sagas (complexe)
Debugging	Simple	Distribué (complexe)
Latence	Faible	Plus élevée
Coût initial	Faible	Élevé
Time to market	Rapide au début	Plus lent au début

3.2 Critères de Décision

---

4. Patterns Microservices Essentiels

4.1 API Gateway Pattern

Responsabilités:

• Routing des requêtes
• Authentication/Authorization
• Rate Limiting
• Load Balancing
• SSL Termination
• Caching
• Request/Response transformation

4.2 Service Discovery Pattern

Comment ça marche:

1. Service démarre → s'enregistre auprès d'Eureka
2. Client veut appeler Service A
3. Client demande à Eureka: "Où est Service A?"
4. Eureka retourne la liste des instances
5. Client choisit une instance (load balancing client-side)
6. Client appelle directement l'instance

4.3 Circuit Breaker Pattern

États:

• CLOSED: Normal, les appels passent
• OPEN: Trop d'échecs, appels bloqués → fallback
• HALF-OPEN: Test si le service est revenu

// Exemple avec Resilience4j
@CircuitBreaker(name = "userService", fallbackMethod = "getUserFallback")
public User getUser(Long id) {
    return userServiceClient.getUser(id); // Appel distant
}

public User getUserFallback(Long id, Exception ex) {
    return new User(id, "Unknown", "Service temporarily unavailable");
}

4.4 Saga Pattern (Transactions Distribuées)

Dans un monolithe:

@Transactional
public void createOrder(Order order) {
    orderRepository.save(order);      // ✅
    inventoryService.reserve(order);  // ✅
    paymentService.charge(order);     // ❌ Échec → ROLLBACK tout
}

Avec microservices (Saga Choreography):

4.5 Event Sourcing & CQRS

Événements au lieu d'états:

// Au lieu de: UPDATE orders SET status = 'SHIPPED'
// On stocke des événements:
OrderCreated { orderId: 1, items: [...], timestamp: ... }
PaymentReceived { orderId: 1, amount: 100, timestamp: ... }
OrderShipped { orderId: 1, trackingNumber: "ABC123", timestamp: ... }

---

5. The Twelve-Factor App

Les 12 facteurs sont des principes pour construire des applications cloud-native:

Les 12 Facteurs

#	Facteur	Description	Application Spring Boot
1	Codebase	Un repo = une app	Un repo Git par service
2	Dependencies	Déclarer explicitement	pom.xml / build.gradle
3	Config	Config dans l'environnement	application.yml + env vars
4	Backing Services	Traiter comme ressources attachées	DataSource configurable
5	Build, Release, Run	Séparer les étapes	CI/CD pipeline
6	Processes	Stateless	Session dans Redis
7	Port Binding	Exporter via port	Embedded Tomcat
8	Concurrency	Scale via processus	Instances multiples
9	Disposability	Démarrage/arrêt rapide	Graceful shutdown
10	Dev/Prod Parity	Environnements similaires	Docker
11	Logs	Traiter comme flux	stdout → collecteur
12	Admin Processes	Tâches admin one-off	Spring Batch

Exemple: Facteur 3 - Configuration

# ❌ Mauvais: Config hardcodée
spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/mydb
    username: admin
    password: secret123

# ✅ Bon: Config externalisée
spring:
  datasource:
    url: ${DATABASE_URL}
    username: ${DATABASE_USERNAME}
    password: ${DATABASE_PASSWORD}

Exemple: Facteur 6 - Processes Stateless

// ❌ Mauvais: État en mémoire
@RestController
public class CartController {
    private Map<Long, Cart> carts = new HashMap<>(); // État local!
    
    @PostMapping("/cart/{userId}/add")
    public void addItem(@PathVariable Long userId, @RequestBody Item item) {
        carts.computeIfAbsent(userId, Cart::new).add(item);
    }
}

// ✅ Bon: État externalisé (Redis)
@RestController
public class CartController {
    private final RedisTemplate<String, Cart> redis;
    
    @PostMapping("/cart/{userId}/add")
    public void addItem(@PathVariable Long userId, @RequestBody Item item) {
        String key = "cart:" + userId;
        Cart cart = redis.opsForValue().get(key);
        if (cart == null) cart = new Cart();
        cart.add(item);
        redis.opsForValue().set(key, cart);
    }
}

---

6. Domain-Driven Design (DDD) et Microservices

6.1 Bounded Context

Le Bounded Context définit les frontières d'un microservice:

6.2 Même Concept, Contextes Différents

// Dans Sales Context
public class Customer {
    private Long id;
    private String name;
    private String email;
    private List<Order> orders;
    private LoyaltyLevel loyaltyLevel;
}

// Dans Shipping Context
public class Customer {
    private Long id;
    private String name;
    private Address shippingAddress;
    private String phoneNumber;
}

// Dans Billing Context
public class Customer {
    private Long id;
    private String name;
    private PaymentMethod defaultPaymentMethod;
    private BillingAddress billingAddress;
}

---

7. Anti-Patterns à Éviter

7.1 Distributed Monolith

❌ ANTI-PATTERN: Monolithe distribué
- 10 services qui DOIVENT être déployés ensemble
- Schéma de BD partagé
- Couplage fort entre services
- Pire des deux mondes!

7.2 Nano-Services

❌ ANTI-PATTERN: Services trop petits
- Un service par entité
- UserService, UserAddressService, UserPreferenceService
- Overhead énorme
- Transactions impossibles

7.3 Shared Database

❌ ANTI-PATTERN: Base de données partagée
Service A ──┬──> PostgreSQL <──┬── Service B
            │                  │
            └──> orders table <┘

Problème:
- Couplage fort via le schéma
- Impossible de modifier une table
- Transactions croisées tentantes

7.4 Sync Everywhere

❌ ANTI-PATTERN: Tout en synchrone

Order Service
    ↓ HTTP sync
Inventory Service
    ↓ HTTP sync
Payment Service
    ↓ HTTP sync
Notification Service

Problème:
- Latence cumulée
- Un service lent = tout lent
- Cascade failures

---

8. Migration Monolithe → Microservices

8.1 Stratégie: Strangler Fig Pattern

8.2 Étapes de Migration

1. Identifier les Bounded Contexts dans le monolithe
2. Commencer par le moins risqué (ex: notifications)
3. Extraire dans un nouveau service
4. Router via API Gateway
5. Supprimer l'ancien code du monolithe
6. Répéter pour le prochain contexte

---

9. Résumé

Points Clés

✅ Monolithe = Simple mais ne scale pas
✅ Microservices = Complexe mais flexible
✅ Commencer monolithe si possible
✅ Migrer quand le monolithe devient un frein
✅ 12-Factor App = bonnes pratiques cloud-native
✅ DDD = aide à définir les frontières
✅ Patterns = Circuit Breaker, Saga, Event Sourcing

Checklist Avant Microservices

• Équipe expérimentée en DevOps?
• Infrastructure Kubernetes/Docker?
• Monitoring et logging centralisés?
• CI/CD mature?
• Bounded Contexts bien définis?
• Problèmes réels de scaling?

---

10. Quiz de Validation

Question 1

Quel pattern permet d'éviter la cascade de pannes entre services?

Voir la réponse

Circuit Breaker - Il détecte les échecs et "ouvre" le circuit pour retourner un fallback immédiatement au lieu d'attendre des timeouts.

Question 2

Pourquoi "Database per Service" est important?

Voir la réponse

• Découplage: Chaque service peut évoluer son schéma indépendamment
• Autonomie: Pas de dépendance sur un DBA central
• Technologie: PostgreSQL pour un service, MongoDB pour un autre
• Évite le couplage caché via le schéma partagé

Question 3

Qu'est-ce qu'un "Distributed Monolith"?

Voir la réponse

Un anti-pattern où on a plusieurs services mais:

• Ils doivent être déployés ensemble
• Ils partagent une base de données
• Ils sont fortement couplés

On a la complexité des microservices SANS les avantages.

---

Chapitre Suivant: Service Discovery avec Eureka →

Retour au Module 13