Cours sur le Développement Microservices
Transféré par
shetoubelvaCours sur le Développement Microservices
Transféré par
shetoubelvaCours de développement d’applications Microservices
SUPPORT DE COURS
DEVELOPPEMENT D’APPLICATIONS
MICROSERVICES
GENIE LOGICIEL
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Table des matières
Chapitre 1 - Introduction aux Architectures Logicielles ...................................................... 6
Objectifs pédagogiques ....................................................................................................................... 6
1.1. Définition et rôle d’une architecture logicielle ............................................................................. 6
1.2. Brève évolution historique des architectures logicielles .............................................................. 7
1.3. Architecture monolithique vs microservices ................................................................................ 9
1.4. Principes fondamentaux d’une architecture microservices ........................................................ 10
1.5. Éléments constitutifs d’une architecture microservices ............................................................. 10
1.6. Critères de choix d’une architecture ........................................................................................... 10
1.7. Avantages et limites des microservices ...................................................................................... 11
1.8. Microservices et DevOps : un couple indissociable ................................................................... 11
1.9. Exemple d’évolution : d’un monolithe vers les microservices................................................... 12
1.10. Panorama technologique actuel ................................................................................................ 13
1.11. Étude de cas : Netflix, pionnier des microservices ................................................................... 13
1.12. Synthèse du chapitre ................................................................................................................. 14
1.13. Exercices et mini-projet............................................................................................................ 14
Chapitre 2 - Concepts Fondamentaux des Microservices .................................................. 16
Objectifs pédagogiques ..................................................................................................................... 16
2.1. Introduction ................................................................................................................................ 16
2.2. Les principes fondateurs des microservices ............................................................................... 17
2.3. Les propriétés d’un système distribué ........................................................................................ 19
2.4. Communication interservices ..................................................................................................... 20
2.5. Patterns fondamentaux des microservices .................................................................................. 21
2.6. Gestion de la cohérence et de la fiabilité .................................................................................... 24
2.7. Résilience et observabilité .......................................................................................................... 24
2.8. Sécurité des communications interservices ................................................................................ 25
2.9. Scalabilité et tolérance aux pannes ............................................................................................. 26
2.10. Anti-patterns courants .............................................................................................................. 26
2.11. Étude de cas : architecture simplifiée d’une plateforme e-commerce ...................................... 27
2.12. Exercices et mini-projet............................................................................................................ 27
Chapitre 3 - Domain Driven Design (DDD) et Découpage Logique des Microservices ... 28
Objectifs pédagogiques ..................................................................................................................... 28
3.1. Introduction ................................................................................................................................ 28
3.2. Concepts fondamentaux de DDD ............................................................................................... 29
3.3. Découpage fonctionnel en microservices ................................................................................... 31
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
3.4. Modélisation stratégique avec DDD .......................................................................................... 31
3.5. Stratégies pour découper un monolithe existant ......................................................................... 33
3.6. Pratiques avancées de conception .............................................................................................. 33
3.7. Cas pratique : plateforme e-commerce ....................................................................................... 34
3.8. Bonnes pratiques ........................................................................................................................ 34
3.9. Exercices et mini-projet.............................................................................................................. 35
Chapitre 4 - Communication entre Microservices et Patterns Avancés ........................... 36
Objectifs pédagogiques ..................................................................................................................... 36
4.1. Introduction ................................................................................................................................ 36
4.2. Modes de communication interservices ..................................................................................... 37
4.3. Patterns avancés de résilience .................................................................................................... 39
4.4. Architecture Event-Driven et Messaging Patterns ..................................................................... 41
4.5. Observabilité et monitoring ........................................................................................................ 42
4.6. Patterns de communication avancés ........................................................................................... 42
4.7. Bonnes pratiques ........................................................................................................................ 43
4.8. Cas pratique : Plateforme e-commerce....................................................................................... 43
4.9. Exercices et mini-projet.............................................................................................................. 43
Chapitre 5 - Déploiement et Orchestration des Microservices .......................................... 45
5.1. Introduction ................................................................................................................................ 45
5.2. Conteneurisation avec Docker .................................................................................................... 45
5.3. Orchestration des conteneurs ...................................................................................................... 47
5.4. Déploiement d’un microservice sur Kubernetes ........................................................................ 48
5.5. Communication et découverte de services ................................................................................. 49
5.6. Mise à l’échelle et résilience ...................................................................................................... 49
5.7. CI/CD (Intégration et Déploiement Continus) ........................................................................... 50
5.8. Service Mesh : Sécurité et Observabilité.................................................................................... 51
5.9. Monitoring et Logging ............................................................................................................... 51
5.10. Sécurité du déploiement ........................................................................................................... 52
5.11. Bonnes pratiques ...................................................................................................................... 52
5.12. Exercices et mini-projet............................................................................................................ 52
Chapitre 6 - Sécurité, Observabilité et Gestion des Données dans les Microservices ...... 54
6.1. Introduction ................................................................................................................................ 54
6.2. Sécurité des Microservices ......................................................................................................... 54
6.3. Gestion des Données dans une Architecture Microservices ....................................................... 57
6.4. Observabilité des Microservices................................................................................................. 59
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
6.5. Audit et conformité .................................................................................................................... 61
6.6. Mini-projet : Observabilité et sécurité intégrées ........................................................................ 61
6.7. Conclusion .................................................................................................................................. 61
Chapitre 7 - Tests, Performance et Maintenance des Microservices................................. 63
7.1. Introduction ................................................................................................................................ 63
7.2. La pyramide des tests pour microservices .................................................................................. 63
7.3. Tests unitaires ............................................................................................................................. 64
7.4. Tests d’intégration ...................................................................................................................... 65
7.5. Tests de contrat (Contract Testing) ............................................................................................ 66
7.6. Tests End-to-End (E2E) ............................................................................................................. 67
7.7. Tests de performance et de charge ............................................................................................. 67
7.8. Tests de résilience (Chaos Testing) ............................................................................................ 68
7.9. Maintenance et évolutivité ......................................................................................................... 69
7.10. Stratégies de déploiement et mise à jour .................................................................................. 69
7.11. Observabilité continue et feedback .......................................................................................... 70
7.12. Mini-projet pratique : pipeline complet de validation .............................................................. 71
7.13. Conclusion ................................................................................................................................ 71
Chapitre 8 - Cas pratiques et architecture complète d’une application microservices
(Spring Boot + NestJS + Kubernetes + Kafka) .................................................................... 72
8.1. Objectifs pédagogiques .............................................................................................................. 72
8.2. Cas pratique : plateforme e-commerce distribuée ...................................................................... 72
8.3. Architecture fonctionnelle .......................................................................................................... 73
8.4. Schéma global d’architecture ..................................................................................................... 74
8.5. Diagramme UML de cas d’utilisation ........................................................................................ 74
8.6. Diagramme de séquence – Processus de commande .................................................................. 75
8.7. Schéma des bases de données..................................................................................................... 75
8.8. Exemple de communication asynchrone (Kafka)....................................................................... 76
8.9. Sécurité et gestion des accès....................................................................................................... 77
8.10. Déploiement sur Kubernetes .................................................................................................... 77
8.11. CI/CD automatisé ..................................................................................................................... 79
8.12. Observabilité et monitoring ...................................................................................................... 79
8.13. Bonnes pratiques finales ........................................................................................................... 80
8.14. Résumé du chapitre .................................................................................................................. 80
8.15. Travaux pratiques (TP) ............................................................................................................. 81
Chapitre 9 - Sécurité, conformité et observabilité avancée dans les architectures
microservices ........................................................................................................................... 82
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
9.1. Objectifs pédagogiques .............................................................................................................. 82
9.2. Les enjeux de sécurité dans les architectures microservices ...................................................... 82
9.3. Sécurité d’accès et authentification ............................................................................................ 83
9.4. Autorisation et fédération d’identité........................................................................................... 84
9.5. Sécurisation des communications interservices ......................................................................... 85
9.6. Protection des secrets et variables sensibles ............................................................................... 86
9.7. Observabilité avancée................................................................................................................. 87
9.8. Conformité et journalisation ....................................................................................................... 88
9.9. Sécurité des conteneurs et du déploiement ................................................................................. 89
9.10. Résumé du chapitre .................................................................................................................. 89
9.11. Exercices & TP......................................................................................................................... 90
Chapitre 10 - CI/CD, Performances, Scalabilité et Bonnes Pratiques de Production des
Microservices .......................................................................................................................... 91
10.1. Introduction .............................................................................................................................. 91
10.2. Le concept de CI/CD ................................................................................................................ 91
10.3. Architecture d’un pipeline CI/CD microservices ..................................................................... 92
10.4. Stratégies de déploiement avancées ......................................................................................... 94
10.5. Optimisation des performances ................................................................................................ 94
10.6. Scalabilité et haute disponibilité............................................................................................... 95
10.7. Sécurité et conformité .............................................................................................................. 96
10.8. Observabilité et supervision ..................................................................................................... 97
10.9. Bonnes pratiques générales en production ............................................................................... 97
10.10. Mini-projet final (Synthèse du cours)..................................................................................... 98
10.11. Conclusion générale du cours ................................................................................................. 98
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Chapitre 1 - Introduction aux Architectures
Logicielles
Objectifs pédagogiques
À la fin de ce chapitre, l’étudiant devra être capable de :
Comprendre les principaux types d’architectures logicielles existants.
Identifier les limites des architectures monolithiques.
Expliquer l’évolution vers le modèle microservices.
Comprendre les critères de choix d’une architecture selon les besoins d’une
application.
Situer les microservices dans l’écosystème des architectures distribuées modernes.
1.1. Définition et rôle d’une architecture logicielle
Une architecture logicielle désigne la manière dont les composants d’un logiciel sont organisés
et interagissent entre eux.
Elle répond à des questions structurantes telles que :
Comment le code est-il organisé ?
Comment les différents modules communiquent-ils ?
Comment assurer la maintenance, la sécurité et l’évolutivité du système ?
Définition (IEEE 1471)
L’architecture d’un système logiciel correspond à “l’organisation fondamentale d’un système,
définie par ses composants, leurs relations, et les principes qui guident sa conception et son
évolution”.
L’architecture n’est pas seulement technique ; elle influence la performance, la scalabilité, la
robustesse, la sécurité, et la productivité des équipes.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
1.2. Brève évolution historique des architectures logicielles
1.2.1. Les débuts : architecture monolithique
Dans les années 1990–2000, la majorité des applications étaient monolithiques :
toutes les fonctionnalités étaient intégrées dans une seule base de code, un seul déploiement,
une seule base de données.
Exemple : une application e-commerce monolithique contient dans le même serveur :
la gestion des utilisateurs,
les produits,
les commandes,
les paiements,
les notifications.
Avantages :
Simplicité de développement et de déploiement.
Une seule base de données et un seul environnement.
Débogage et tests unitaires plus simples au départ.
Inconvénients :
Couplage fort entre les modules : une modification impacte tout le système.
Difficulté de montée en charge (scalabilité horizontale).
Déploiement lent et risqué.
Difficulté d’adoption de nouvelles technologies (tout le système dépend du même
langage ou framework).
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
1.2.2. L’émergence du modèle client-serveur
Avec l’essor du web, l’architecture client-serveur est apparue :
Un client (navigateur, application mobile) communique avec un serveur via HTTP.
Le serveur exécute la logique métier et retourne des réponses.
Cela a permis la séparation entre :
Frontend : interface utilisateur.
Backend : logique métier, base de données, gestion des requêtes.
Mais le backend restait souvent monolithique.
1.2.3. Le modèle N-tiers
Pour améliorer la modularité, l’architecture N-tiers (ou multi-couches) a introduit une
séparation logique :
Couche présentation (UI)
Couche métier (service)
Couche données (DAO / Repository)
Bien que plus structurée, cette approche restait déployée comme un seul bloc.
1.2.4. L’approche SOA (Service-Oriented Architecture)
Vers le milieu des années 2000, les grandes entreprises adoptent le SOA (Service-Oriented
Architecture) :
Les applications sont divisées en services réutilisables, communiquant via des
protocoles standardisés (SOAP, XML, WSDL).
Chaque service correspond à une fonction métier (facturation, authentification, gestion
client, etc.).
Objectif : réutilisation, interopérabilité et découplage entre les systèmes d’entreprise.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Mais SOA était souvent complexe à mettre en œuvre (gouvernance lourde, protocoles verbeux,
dépendance aux ESB – Enterprise Service Bus).
1.2.5. L’avènement du modèle microservices
Les géants du web (Netflix, Amazon, Google) ont cherché à accélérer l’innovation et déployer
en continu.
C’est dans ce contexte qu’est née l’architecture microservices :
Une architecture microservices consiste à décomposer une application en un ensemble de petits
services indépendants, chacun exécutant une tâche spécifique et communiquant avec les autres
via des API légères (REST, gRPC, etc.).
1.3. Architecture monolithique vs microservices
Critère Monolithique Microservices
Déploiement Unique fichier ou conteneur Services indépendants
Technologie Unique stack (ex : Java) Stack hétérogène possible
Verticale (augmenter les ressources Horizontale (répliquer uniquement le
Scalabilité
d’un serveur) service nécessaire)
Maintenance Difficile avec la taille Facile car découplée
Résilience Une panne = tout le système down Une panne = service isolé
Base de données Unique Une base par service
Complexité Élevée (orchestration, communication,
Faible
initiale sécurité)
Conclusion :
Le modèle microservices apporte de la flexibilité, mais exige une infrastructure solide, une
culture DevOps, et une maturité d’équipe.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
1.4. Principes fondamentaux d’une architecture
microservices
1. Découplage : chaque service est autonome.
2. Responsabilité unique : un service = un domaine fonctionnel clair.
3. Communication légère : via HTTP/REST, gRPC, ou messages asynchrones.
4. Indépendance technologique : chaque service peut être écrit dans un langage différent.
5. Déploiement indépendant : chaque service peut être mis à jour sans impacter les autres.
6. Résilience et tolérance aux pannes : un service en panne ne bloque pas le système
complet.
7. Observabilité : traçabilité, logging et monitoring distribués.
1.5. Éléments constitutifs d’une architecture microservices
Une architecture microservices comprend généralement :
Services métiers : implémentant la logique fonctionnelle.
API Gateway : point d’entrée unique pour les clients.
Service Discovery : registre des services disponibles (ex : Eureka).
Configuration Centralisée : gestion cohérente des variables d’environnement (Spring
Cloud Config).
Message Broker : communication asynchrone (Kafka, RabbitMQ).
Base de données indépendante : chaque service possède sa propre persistance.
Monitoring et observabilité : Prometheus, Grafana, ELK stack.
Infrastructure DevOps : Docker, Kubernetes, CI/CD.
1.6. Critères de choix d’une architecture
Avant de choisir une architecture, il faut analyser :
1. La taille et la complexité du projet.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
o Petits projets → monolithique plus simple.
o Applications évolutives → microservices préférable.
2. La maturité technique de l’équipe.
o Microservices demandent DevOps, monitoring, tests distribués.
3. Le budget et l’infrastructure.
o Microservices nécessitent orchestration et supervision.
4. Les besoins de performance et disponibilité.
o Si haute disponibilité = microservices recommandés.
1.7. Avantages et limites des microservices
Avantages :
Déploiement rapide et indépendant.
Évolutivité horizontale fine.
Résilience accrue.
Indépendance technologique.
Meilleure répartition des équipes par domaine fonctionnel.
Limites :
Complexité de mise en œuvre.
Besoin d’un outillage solide (monitoring, CI/CD, observabilité).
Communication interservices difficile à tester.
Cohérence transactionnelle compliquée.
Risque de fragmentation excessive.
1.8. Microservices et DevOps : un couple indissociable
Les microservices ne fonctionnent bien qu’avec une approche DevOps :
Intégration Continue (CI) : tests et builds automatiques.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Déploiement Continu (CD) : livraison rapide et fréquente.
Infrastructure as Code : gestion automatisée des environnements (Terraform,
Ansible).
Conteneurisation : Docker et orchestration Kubernetes.
DevOps permet de gérer la complexité et de fiabiliser la livraison des services.
1.9. Exemple d’évolution : d’un monolithe vers les
microservices
Prenons une application de gestion de commandes :
Monolithe :
├── Authentification
├── Produits
├── Commandes
├── Paiements
└── Notifications
En microservices :
Microservices :
├── Auth-Service
├── Product-Service
├── Order-Service
├── Payment-Service
└── Notification-Service
Chaque service a :
sa base de données propre,
sa logique métier dédiée,
et communique via REST ou message broker.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
1.10. Panorama technologique actuel
Domaine Technologies clés
Frameworks Spring Boot, Micronaut, NestJS, Quarkus, [Link]
Communication REST, gRPC, RabbitMQ, Kafka
Service Discovery Eureka, Consul, Zookeeper
API Gateway Spring Cloud Gateway, Kong, NGINX, Traefik
Conteneurisation Docker, Podman
Orchestration Kubernetes, OpenShift
Monitoring Prometheus, Grafana, ELK
Sécurité OAuth2, Keycloak, JWT
CI/CD Jenkins, GitHub Actions, GitLab CI
1.11. Étude de cas : Netflix, pionnier des microservices
Netflix a migré dès 2009 d’un monolithe Java vers une architecture microservices distribuée,
afin de :
supporter plus de 200 millions d’utilisateurs,
assurer la disponibilité mondiale,
déployer des centaines de fois par jour.
Ils ont développé des outils aujourd’hui open source :
Eureka (Service Discovery)
Zuul (API Gateway)
Hystrix (Circuit Breaker)
Ribbon (Load Balancer)
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
1.12. Synthèse du chapitre
Élément clé Description
Les architectures monolithiques deviennent rigides et difficiles à faire
Problème
évoluer.
Solution Le découpage en microservices indépendants.
Objectif Scalabilité, agilité, disponibilité, résilience.
Conditions de
Infrastructure DevOps, monitoring, culture de tests, CI/CD.
succès
1.13. Exercices et mini-projet
Questions de révision et d’approfondissement
1. Quelle est la principale limite d’une architecture monolithique ?
2. Quel protocole est souvent utilisé pour la communication entre microservices ?
3. Quel outil Spring gère la découverte de services ?
4. Citez deux avantages de la conteneurisation.
5. Qu’est-ce qu’une API Gateway ?
Activité pratique
Objectif : Identifier les services potentiels d’une application de gestion d’université.
Exercice : Décomposez l’application monolithique suivante en services potentiels :
Authentification
Étudiants
Inscriptions
Notes
Paiements
Décrivez pour chaque service :
Ses responsabilités principales
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Sa base de données
Ses interactions avec les autres services
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Chapitre 2 - Concepts Fondamentaux des
Microservices
Objectifs pédagogiques
À la fin de ce chapitre, l’étudiant devra être capable de :
Expliquer les principes fondamentaux qui régissent les microservices.
Identifier les propriétés nécessaires à la conception d’un système distribué fiable.
Comprendre les modèles de communication interservices (synchrone / asynchrone).
Appliquer les principaux design patterns microservices (Circuit Breaker, Saga, etc.).
Comprendre la problématique de cohérence, de scalabilité et de résilience dans les
environnements distribués.
2.1. Introduction
Les microservices ne sont pas qu’un découpage d’une application : c’est une philosophie
architecturale complète qui s’appuie sur des principes techniques, organisationnels et
culturels.
Une application microservices est un système distribué, où chaque composant (service) doit
être conçu pour être :
indépendant,
faiblement couplé,
hautement disponible,
et résilient face aux défaillances.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
2.2. Les principes fondateurs des microservices
Martin Fowler et James Lewis (2014) ont popularisé les principes de base d’une architecture
microservices moderne.
a. Autonomie
Chaque microservice :
est indépendant dans son développement, son déploiement et sa maintenance,
dispose de sa propre base de données et de sa logique métier,
peut être développé dans un langage différent.
Exemple :
User-Service (Spring Boot + PostgreSQL)
Payment-Service (NestJS + MongoDB)
b. Cohésion forte et couplage faible
Un service doit être fortement cohésif (toutes ses fonctionnalités sont étroitement liées à un
domaine précis) et faiblement couplé (il dépend le moins possible des autres services).
Ce principe permet :
une évolution indépendante,
une réduction des effets de bord,
une maintenance facilitée.
c. Responsabilité unique
Un service doit avoir une seule responsabilité métier bien définie. Cette approche découle du
Single Responsibility Principle (SRP) du génie logiciel.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
d. Indépendance technologique
Chaque service peut utiliser :
un langage différent (Java, [Link], Go, etc.),
une base de données adaptée à son besoin (SQL, NoSQL, in-memory).
C’est le principe du polyglot programming et du polyglot persistence.
e. Scalabilité indépendante
Chaque service peut être mis à l’échelle indépendamment selon la charge :
Exemple : le service de paiement peut être répliqué sur 10 instances, alors que celui
d’authentification reste sur 2.
f. Résilience
Chaque service doit être conçu pour survivre à des pannes :
mise en place de timeouts,
retries avec backoff,
utilisation de circuit breakers,
stockage asynchrone des messages si un autre service est indisponible.
g. Déploiement continu
Les microservices encouragent la livraison fréquente, grâce à :
des pipelines CI/CD automatisés,
des tests unitaires et d’intégration systématiques,
un versioning des API.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
2.3. Les propriétés d’un système distribué
Une architecture microservices étant distribuée, elle hérite des défis classiques des systèmes
distribués.
2.3.1. Le théorème CAP
Le théorème CAP (Consistency, Availability, Partition tolerance) indique qu’un système
distribué ne peut garantir que deux propriétés sur trois simultanément.
Propriété Description
Consistency (C) Tous les nœuds voient les mêmes données au même moment.
Availability (A) Le système répond toujours, même en cas de panne partielle.
Le système continue de fonctionner malgré la perte de communication
Partition tolerance (P)
entre nœuds.
En microservices, on cherche souvent un équilibre entre cohérence et disponibilité.
2.3.2. Le principe BASE (opposé à ACID)
Contrairement aux bases de données relationnelles (ACID), les systèmes distribués suivent
souvent le modèle BASE :
ACID (Transactions SQL) BASE (Microservices / NoSQL)
Atomicité Basically Available
Cohérence Soft-state
Isolation Eventually consistent
Durabilité –
Cela signifie qu’une mise à jour n’est pas immédiatement visible par tous les services, mais
le sera à terme (eventual consistency).
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
2.4. Communication interservices
Les microservices doivent collaborer pour accomplir des tâches complexes.
Deux grands types de communication existent :
2.4.1. Communication synchrone
Le service A appelle directement le service B et attend une réponse :
Protocoles : HTTP REST, gRPC, GraphQL, Thrift.
Simple à comprendre et à implémenter, mais introduit une dépendance temporelle.
Exemple (Spring Boot) :
@FeignClient(name = "payment-service")
public interface PaymentClient {
@PostMapping("/payments")
PaymentResponse process(@RequestBody PaymentRequest request);
}
Exemple (NestJS) :
@Injectable()
export class PaymentClient {
constructor(private readonly http: HttpService) {}
processPayment(dto: PaymentDto) {
return [Link]('[Link] dto);
}
}
Limite : si payment-service est indisponible, la requête échoue.
2.4.2. Communication asynchrone
Le service A envoie un message via un broker (Kafka, RabbitMQ) sans attendre de réponse
immédiate.
Le service B consomme le message plus tard.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Avantages :
Découplage temporel,
Résilience accrue,
Meilleure scalabilité.
Exemple (RabbitMQ – Spring Boot)
@RabbitListener(queues = "[Link]")
public void handleOrder(OrderEvent event) {
// traitement du message
}
Exemple (NestJS + RabbitMQ)
@MessagePattern('[Link]')
handleOrder(data: OrderCreatedEvent) {
[Link]('Nouvelle commande reçue:', data);
}
2.5. Patterns fondamentaux des microservices
Les design patterns aident à résoudre les problèmes communs des architectures distribuées.
2.5.1. API Gateway Pattern
L’API Gateway est le point d’entrée unique pour tous les clients (mobile, web).
Elle :
redirige les requêtes vers les bons services,
applique la sécurité (authentification, rate limiting),
gère la transformation des réponses.
Exemples :
Spring Cloud Gateway
Kong
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
NGINX
Traefik
Avantages :
Simplifie la communication côté client.
Centralise la gestion des cross-cutting concerns.
2.5.2. Service Discovery Pattern
Permet à un service de découvrir dynamiquement les autres sans connaître leur adresse IP.
Exemples :
Netflix Eureka
Consul
Zookeeper
Principe :
Les services s’enregistrent automatiquement auprès du serveur de découverte.
Les autres les retrouvent via ce registre.
2.5.3. Circuit Breaker Pattern
Inspiré des circuits électriques : coupe la communication vers un service instable pour éviter
une cascade de pannes.
Exemple avec Resilience4j (Spring Boot) :
@CircuitBreaker(name = "paymentService", fallbackMethod =
"fallbackPayment")
public PaymentResponse processPayment(PaymentRequest req) {
return [Link](req);
}
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
2.5.4. Saga Pattern
Résout la cohérence des transactions distribuées :
chaque microservice exécute localement sa transaction et publie un événement.
Si un service échoue, les autres effectuent une compensation (rollback local).
Types :
Chorégraphie : chaque service réagit à des événements (pas de coordination
centrale).
Orchestration : un service “coordinateur” gère le flux (plus structuré).
Exemple :
Création de commande → Réservation stock → Paiement → Confirmation
Si paiement échoue → annuler la commande + libérer le stock.
2.5.5. CQRS (Command Query Responsibility Segregation)
Sépare les commandes (écriture) des requêtes (lecture) :
Les écritures mettent à jour un modèle métier.
Les lectures s’appuient sur une vue optimisée (cache, base NoSQL, etc.)
Avantage : Performance et flexibilité accrues pour les lectures massives.
2.5.6. Event Sourcing Pattern
Chaque changement d’état est sauvegardé comme un événement plutôt qu’un état final.
L’état actuel est reconstruit en rejouant tous les événements.
Exemple : UserCreated → PasswordChanged → EmailUpdated
Rejouer ces événements permet de reconstituer l’état complet d’un utilisateur.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
2.6. Gestion de la cohérence et de la fiabilité
2.6.1. Cohérence des données
Chaque microservice a sa propre base : la cohérence forte n’est plus garantie.
On applique donc :
Eventual consistency via messages asynchrones,
Saga pattern pour gérer les transactions distribuées.
2.6.2. Idempotence
Un service doit supporter les appels répétés sans effet secondaire.
Exemple : si une commande est traitée deux fois, elle ne doit pas être payée deux fois.
2.6.3. Timeout & Retry
Tout appel à un service externe doit être :
limité dans le temps (timeout),
éventuellement retenté avec un délai (retry + backoff).
2.7. Résilience et observabilité
2.7.1. Résilience
Les microservices doivent être capables de résister aux pannes :
Retry, Timeout, Circuit Breaker.
Mise en cache locale.
Fallback automatique.
2.7.2. Observabilité
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Un système observable doit offrir :
Logging centralisé (ELK, Fluentd)
Tracing distribué (Zipkin, Jaeger)
Metrics (Prometheus, Grafana)
Exemple (Spring Boot) :
management:
endpoints:
web:
exposure:
include: "*"
Exemple (NestJS + Prometheus) :
@Interval(5000)
collectMetrics() {
[Link]('orders_count', [Link]);
}
2.8. Sécurité des communications interservices
2.8.1. Authentification et Autorisation
Authentification via OAuth2 / Keycloak / JWT.
Transmission du token JWT entre services via en-têtes HTTP.
2.8.2. Communication sécurisée
Utilisation de TLS/HTTPS.
Signature et chiffrement des messages (Kafka, RabbitMQ).
Ségrégation des réseaux (service mesh avec Istio).
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
2.9. Scalabilité et tolérance aux pannes
2.9.1. Scalabilité horizontale
Répliquer un service sur plusieurs instances :
via Docker/Kubernetes (pods répliqués),
load balancing (NGINX, Traefik, Ribbon).
2.9.2. Tolérance aux pannes
Chaque service doit prévoir :
sauvegarde de messages non livrés,
redémarrage automatique,
désactivation dynamique des instances défaillantes.
2.10. Anti-patterns courants
Anti-pattern Description Conséquence
Service trop gros Un microservice gère plusieurs domaines Monolithe déguisé
Couplage de base de données Plusieurs services partagent une même base Perte d’indépendance
Communication circulaire Services dépendants mutuellement Deadlocks, lenteur
Absence de monitoring Pas de visibilité sur les pannes Temps de réaction élevé
Manque de versioning API Rupture de compatibilité Erreurs client
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
2.11. Étude de cas : architecture simplifiée d’une
plateforme e-commerce
Service Responsabilité Technologie Communication
User-Service Authentification, profils Spring Boot + PostgreSQL REST
Product-Service Gestion des produits NestJS + MongoDB REST
Order-Service Commandes, stock Spring Boot + RabbitMQ Async
Payment-Service Paiements NestJS + Stripe API REST
Notification-Service Emails, SMS [Link] + Kafka Async
Tous les services sont orchestrés via un API Gateway (Spring Cloud Gateway) et
enregistrés dans Eureka.
2.12. Exercices et mini-projet
Questions de réflexion
1. Quelle différence entre un circuit breaker et un retry ?
2. Comment gérer la cohérence des données entre plusieurs services ?
3. Pourquoi la communication asynchrone améliore-t-elle la résilience ?
4. Quelles sont les limites du modèle REST dans une architecture microservices ?
5. Pourquoi chaque microservice doit avoir sa propre base de données ?
Mini-projet
Objectif : Mettre en œuvre deux microservices simples qui communiquent via RabbitMQ.
Étapes :
1. Créer un Order-Service (Spring Boot) qui publie un événement “[Link]”.
2. Créer un Notification-Service (NestJS) qui écoute cet événement et envoie un
message “Commande reçue”.
3. Implémenter un mécanisme de retry si RabbitMQ est indisponible.
4. Ajouter des logs et un health check sur chaque service.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Chapitre 3 - Domain Driven Design (DDD) et
Découpage Logique des Microservices
Objectifs pédagogiques
À la fin de ce chapitre, l’étudiant devra être capable de :
Comprendre les concepts fondamentaux du Domain Driven Design (DDD).
Identifier les bounded contexts et les domaines fonctionnels.
Découper une application monolithique en microservices cohérents.
Utiliser des modèles UML et diagrammes stratégiques pour la conception.
Appliquer des principes de modélisation stratégique dans le développement
d’applications distribuées.
3.1. Introduction
Le Domain Driven Design (DDD) est une approche méthodologique proposée par Eric Evans
(2004) pour gérer la complexité des systèmes logiciels.
L’idée centrale : placer le domaine métier au cœur de la conception logicielle, et non
l’infrastructure.
Dans le contexte des microservices, DDD est un outil essentiel pour :
éviter les services trop gros ou mal définis,
garantir l’indépendance des services,
faciliter la communication entre équipes métier et développement.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
3.2. Concepts fondamentaux de DDD
3.2.1. Domaine métier (Domain)
Le domaine représente la zone de connaissance et d’activité de l’entreprise que le logiciel
doit couvrir.
Exemple : e-commerce - domaines : utilisateurs, produits, commandes, paiements.
3.2.2. Bounded Context (Contexte Délimité)
Un bounded context est un espace où un modèle métier s’applique avec des règles précises,
isolé des autres contextes.
Chaque microservice correspond idéalement à un bounded context.
Délimite :
o la responsabilité métier,
o la terminologie utilisée,
o les règles métier propres.
Exemple :
Order-Service → contexte “Gestion des commandes”
Payment-Service → contexte “Paiement et facturation”
Chaque contexte a ses propres modèles et entités.
3.2.3. Entités (Entities)
Objets ayant une identité unique et dont l’état évolue dans le temps.
class Order {
UUID orderId;
List<Item> items;
Customer customer;
Status status;
}
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
3.2.4. Objets valeur (Value Objects)
Objets immuables, définis par leurs attributs.
class Address {
String street;
String city;
String postalCode;
}
3.2.5. Agrégats (Aggregates)
Un agrégat est un ensemble d’entités et d’objets valeur traités comme une unité cohérente
pour la persistance et les transactions.
Racine de l’agrégat : entité principale, seule accessible de l’extérieur.
Règle : les autres entités de l’agrégat sont manipulées uniquement via la racine.
Exemple :
Agrégat Order → racine Order, entités internes Item, Payment.
3.2.6. Repositories
Les repositories sont des interfaces permettant de consulter et persister les agrégats, cachant
la complexité de la base de données.
interface OrderRepository {
Order findById(UUID id);
void save(Order order);
}
3.2.7. Services métier (Domain Services)
Services qui contiennent une logique métier non attachée à une seule entité ou agrégat.
Exemple : calcul des frais de livraison ou validation des promotions.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
3.3. Découpage fonctionnel en microservices
Le découpage fonctionnel consiste à transformer un monolithe en microservices cohérents.
Étapes :
1. Identification des domaines métiers
o Recueillir les besoins de l’entreprise.
o Lister les fonctionnalités principales (ex : e-commerce → commandes,
paiements, livraison).
2. Détermination des bounded contexts
o Définir les limites fonctionnelles de chaque service.
o Associer chaque contexte à un microservice.
3. Isolation des modèles et bases
o Chaque service doit avoir son modèle de données propre.
o Éviter le partage de base de données.
4. Définition des interactions
o Déterminer comment les services communiquent (REST, events).
5. Validation des responsabilités
o Chaque service doit répondre à une seule responsabilité métier.
3.4. Modélisation stratégique avec DDD
3.4.1. Diagramme de contexte (Context Map)
Le Context Map permet de représenter visuellement les bounded contexts et leurs relations.
Exemple simplifié pour une plateforme e-commerce :
[User-Service] ---> [Order-Service] ---> [Payment-Service]
| | |
v v v
[Notification-Service] [Inventory-Service] [Billing-Service]
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Flèches - communication (synchrone ou asynchrone).
Chaque bloc - bounded context/microservice.
3.4.2. Types de relations entre contextes
Type de relation Description Exemple
Partnership Deux contextes collaborent Order-Service et Payment-Service
Shared Kernel Partage d’un sous-modèle commun User-Service et Notification-Service
Customer- Un contexte fournit un service à un Billing-Service fournit factures à Order-
Supplier autre Service
3.4.3. Diagrammes UML pratiques
1. Diagramme de classes pour un bounded context
Order
├─ orderId : UUID
├─ items : List<Item>
├─ status : Status
└─ customer : Customer
Item
├─ productId : UUID
├─ quantity : int
└─ price : float
2. Diagramme de séquence pour la création de commande
Client -> API Gateway -> Order-Service : createOrder()
Order-Service -> Inventory-Service : checkStock()
Inventory-Service -> Order-Service : stockAvailable()
Order-Service -> Payment-Service : processPayment()
Payment-Service -> Order-Service : paymentConfirmed()
Order-Service -> Notification-Service : sendConfirmation()
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
3.5. Stratégies pour découper un monolithe existant
3.5.1. Approche par fonctionnalités
Identifier les modules métiers du monolithe.
Extraire chaque module en microservice.
3.5.2. Approche par entités agrégées
Identifier les agrégats principaux (ex : commande, paiement, utilisateur).
Créer un service par agrégat.
3.5.3. Approche par équipe
Découper en fonction de l’organisation des équipes pour favoriser l’autonomie.
3.5.4. Approche par événements
Identifier les événements métiers importants.
Définir des services autour de ces événements.
3.6. Pratiques avancées de conception
3.6.1. Modélisation des événements
Les services doivent publier des événements quand un état change.
Exemple : OrderCreated, PaymentReceived, InventoryUpdated.
3.6.2. Gestion des invariants
Chaque service doit garantir ses propres invariants métiers.
Exemple : un service de paiement ne doit jamais autoriser un paiement supérieur au
montant de la commande.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
3.6.3. Gestion des dépendances
Les microservices ne doivent pas connaître les modèles internes des autres services.
La communication se fait via interfaces ou events.
3.6.4. Domain Events et Event Sourcing
Les événements peuvent être persistés pour reconstruire l’état des agrégats.
Favorise l’auditabilité et la résilience.
3.7. Cas pratique : plateforme e-commerce
Bounded contexts proposés :
Microservice Bounded context Responsabilités
User-Service Gestion utilisateurs Auth, profil, rôles
Product-Service Catalogue produit CRUD produit, stock
Order-Service Gestion commandes Création, suivi, validation
Payment-Service Paiement Paiement en ligne, remboursement
Notification-Service Notifications Emails, SMS, push
Inventory-Service Gestion stock Disponibilité, approvisionnement
Chaque service possède sa propre base (PostgreSQL, MongoDB, Redis).
Les événements principaux :
o OrderCreated → déclenche check stock + paiement
o PaymentCompleted → déclenche confirmation notification
3.8. Bonnes pratiques
1. Limiter la taille des services : un service trop gros = monolithe déguisé.
2. Respecter les bounded contexts : éviter les fuites de modèle.
3. Documenter les API et events : Swagger, AsyncAPI.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
4. Testabilité : chaque service doit être testable indépendamment.
5. Observabilité dès le départ : logs, métriques et tracing.
3.9. Exercices et mini-projet
Questions théoriques
1. Qu’est-ce qu’un bounded context ?
2. Quelle est la différence entre entité et objet valeur ?
3. Expliquez le pattern Saga et son lien avec DDD.
4. Pourquoi chaque microservice devrait avoir sa propre base de données ?
5. Quels diagrammes UML sont les plus utiles pour le découpage logique ?
Mini-projet pratique
Objectif : Découper un monolithe “Gestion Université” en microservices.
Étapes :
1. Identifier les domaines métiers : Étudiants, Cours, Inscriptions, Notes, Paiements.
2. Définir bounded contexts pour chaque domaine.
3. Dessiner un Context Map montrant les relations entre services.
4. Créer un diagramme de classes pour le service “Inscriptions”.
5. Définir les événements principaux (EnrollmentCreated, PaymentProcessed,
GradeUpdated).
Ce chapitre fournit une base solide pour transformer n’importe quelle application
monolithique en microservices bien délimités, avec un focus pratique sur la modélisation
stratégique et DDD.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Chapitre 4 - Communication entre Microservices et
Patterns Avancés
Objectifs pédagogiques
À la fin de ce chapitre, l’étudiant devra être capable de :
Comprendre les différents modes de communication entre microservices.
Mettre en œuvre des communications synchrones et asynchrones.
Appliquer des patterns de résilience comme Circuit Breaker, Retry, Timeout, Bulkhead.
Utiliser les architectures basées sur les événements (Event-Driven Architecture, Event
Sourcing, CQRS).
Implémenter l’observabilité et la gestion des logs distribués dans des systèmes
microservices.
Évaluer et choisir les patterns les plus adaptés selon le contexte métier et technique.
4.1. Introduction
Dans une architecture microservices, la communication entre services est cruciale.
Chaque service étant indépendant, il doit échanger des données et coordonner des actions
sans créer de couplage fort ni introduire de points de défaillance critiques.
Les enjeux principaux :
Scalabilité et performance,
Résilience et tolérance aux pannes,
Cohérence des données distribuées,
Observabilité pour le debug et le monitoring.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
4.2. Modes de communication interservices
4.2.1. Communication synchrone
Le service A appelle directement le service B et attend une réponse.
Protocoles :
HTTP REST (JSON/HTTP)
gRPC (protocol buffers, plus rapide que REST)
GraphQL (requêtes flexibles, unifiée)
Exemple Spring Boot (REST) :
@FeignClient(name = "payment-service")
public interface PaymentClient {
@PostMapping("/payments")
PaymentResponse process(@RequestBody PaymentRequest request);
}
Exemple NestJS (gRPC) :
@Injectable()
export class PaymentClient {
private client: ClientGrpc;
constructor(@Inject('PAYMENT_PACKAGE') private readonly grpcClient:
ClientGrpc) {
[Link] = [Link]<PaymentService>('PaymentService');
}
processPayment(dto: PaymentDto) {
return [Link](dto);
}
}
Avantages :
Simple à implémenter,
Facile à comprendre,
Bonne traçabilité.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Limites :
Couplage temporel → si B est indisponible, A échoue,
Difficultés de scalabilité sous forte charge,
Propagation de panne possible.
4.2.2. Communication asynchrone
Le service A publie un message sur un broker, B le consomme plus tard.
Brokers populaires :
RabbitMQ (queue)
Kafka (log d’événements distribué)
NATS, ActiveMQ
Exemple RabbitMQ (Spring Boot) :
@RabbitListener(queues = "[Link]")
public void handleOrder(OrderEvent event) {
// traitement du message
}
Exemple Kafka (NestJS) :
@EventPattern('[Link]')
handleOrderEvent(@Payload() data: OrderCreatedEvent) {
[Link]('Nouvelle commande :', data);
}
Avantages :
Découplage temporel,
Résilience et tolérance aux pannes,
Scalabilité horizontale.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Limites :
Complexité de gestion (ordering, retries, idempotence),
Traçabilité plus difficile.
4.3. Patterns avancés de résilience
Dans un système distribué, les services peuvent échouer. Plusieurs patterns permettent de
gérer ces situations.
4.3.1. Circuit Breaker
Principe :
Interrompt les appels vers un service défaillant pour éviter une cascade de pannes.
Reprend automatiquement lorsque le service est stable.
Exemple Spring Boot + Resilience4j :
@CircuitBreaker(name = "paymentService", fallbackMethod =
"fallbackPayment")
public PaymentResponse processPayment(PaymentRequest req) {
return [Link](req);
}
public PaymentResponse fallbackPayment(PaymentRequest req, Throwable t) {
return new PaymentResponse("Paiement temporairement indisponible");
}
Avantages :
Prévention des pannes en cascade,
Amélioration de la résilience globale.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
4.3.2. Retry / Timeout / Backoff
Retry : réessayer automatiquement un appel en cas d’échec.
Timeout : arrêter un appel si pas de réponse dans un délai donné.
Backoff : augmenter progressivement le délai entre retries.
Exemple :
RetryConfig config = [Link]()
.maxAttempts(3)
.waitDuration([Link](2))
.build();
4.3.3. Bulkhead Pattern
Principe :
Isolation des ressources d’un service pour éviter que la défaillance d’une partie ne
bloque le reste.
Exemple :
Isoler les pools de threads pour chaque service dans Kubernetes.
Limiter le nombre de connexions simultanées vers un service externe.
4.3.4. Fallbacks et Idempotence
Fallback : réponse alternative si le service est indisponible.
Idempotence : répéter un appel sans effet secondaire.
Exemple :
Création de commande → si duplicate event reçu → ignorer ou mettre à jour.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
4.4. Architecture Event-Driven et Messaging Patterns
4.4.1. Event-Driven Architecture (EDA)
Les microservices communiquent via événements métier, souvent stockés dans un broker.
Exemple :
OrderCreated → InventoryService | PaymentService
PaymentCompleted → NotificationService
Avantages :
Découplage fort,
Scalabilité,
Traçabilité et auditabilité.
4.4.2. Event Sourcing
Chaque changement d’état est enregistré comme un événement.
L’état actuel est reconstruit en rejouant tous les événements.
Exemple :
UserCreated → PasswordChanged → EmailUpdated
Avantages :
Audit complet,
Relecture facile pour reconstruire l’état.
4.4.3. CQRS (Command Query Responsibility Segregation)
Séparation Commandes (Write) / Requêtes (Read).
Lecture optimisée avec une base dédiée (ex : Redis ou ElasticSearch).
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Écriture via agrégats et events.
Exemple :
Commande : [Link]()
Lecture : [Link]()
4.5. Observabilité et monitoring
Dans une architecture distribuée, la traçabilité est critique.
4.5.1. Logs centralisés
Collecter tous les logs dans un serveur central (ELK Stack, Graylog).
Structure recommandée : JSON + timestamp + service + traceId.
4.5.2. Metrics
Collecte de métriques : nombre de requêtes, latence, taux d’erreur.
Outils : Prometheus + Grafana, Micrometer.
4.5.3. Tracing distribué
Chaque requête a un traceId unique.
Permet de suivre le flux d’une requête à travers plusieurs services.
Outils : Zipkin, Jaeger, OpenTelemetry.
4.6. Patterns de communication avancés
Pattern Description Usage
Request-Reply Synchrone REST, gRPC
Publish-Subscribe Asynchrone Kafka, RabbitMQ
Event Sourcing État via événements Audit, replay
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Saga Transactions distribuées Commandes + paiement
CQRS Lecture/écriture séparée Optimisation performance
Bulkhead Isolation des ressources Résilience
Circuit Breaker Protection contre défaillances Haute disponibilité
4.7. Bonnes pratiques
1. Choisir le type de communication adapté : REST pour simples appels, messaging
pour découplage et scalabilité.
2. Garantir l’Idempotence des services.
3. Publier des events pour la cohérence eventual.
4. Surveiller et tracer chaque appel.
5. Isoler les services sensibles via Bulkhead.
6. Versionner les APIs et events pour éviter les ruptures.
4.8. Cas pratique : Plateforme e-commerce
Microservices et events principaux :
o OrderCreated → InventoryService
o OrderCreated → PaymentService
o PaymentCompleted → NotificationService
o InventoryUpdated → OrderService
Patterns appliqués :
o Saga → paiement + validation stock
o Circuit breaker → PaymentService
o Retry/Timeout → tous les appels externes
o Bulkhead → InventoryService
CQRS - Read service optimisé pour catalogues
4.9. Exercices et mini-projet
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Questions de réflexion
1. Quand utiliser REST vs messaging pour un microservice ?
2. Explique le pattern Bulkhead et donne un exemple concret.
3. Pourquoi le tracing distribué est essentiel dans les microservices ?
4. Différence entre Event Sourcing et simple Event-Driven Architecture.
5. Comment gérer les transactions distribuées avec Saga ?
Mini-projet pratique
Objectif : Implémenter une architecture microservices avec communication asynchrone et
résilience.
Étapes :
1. Créer Order-Service (Spring Boot) → publie OrderCreated sur Kafka.
2. Créer Payment-Service (NestJS) → consomme OrderCreated, traite paiement, publie
PaymentCompleted.
3. Créer Notification-Service ([Link]) → consomme PaymentCompleted et envoie email/SMS.
4. Ajouter Circuit Breaker sur Payment-Service.
5. Implémenter logging centralisé + traceId sur tous les services.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Chapitre 5 - Déploiement et Orchestration des
Microservices
5.1. Introduction
Une fois que les microservices sont développés et testés localement, ils doivent être déployés
et orchestrés dans un environnement de production.
Contrairement aux applications monolithiques, les microservices impliquent :
plusieurs conteneurs et environnements,
des dépendances multiples (bases de données, brokers, caches),
une exigence de disponibilité, de scalabilité et d’observabilité.
Objectif :
Assurer que chaque microservice :
soit facilement déployable, monitoré, scalable et remplaçable,
interagisse correctement avec les autres services,
respecte les principes de DevOps et CI/CD.
5.2. Conteneurisation avec Docker
5.2.1. Qu’est-ce qu’un conteneur ?
Un conteneur est une unité légère d’exécution d’application isolée, créée à partir d’une image
Docker.
Contrairement aux machines virtuelles, un conteneur partage le noyau du système hôte, ce qui
le rend plus rapide et plus léger.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Type Isolement Démarrage Taille Cas d’usage
VM Complet (OS) Lent >1 Go Isolation forte
Conteneur Processus Rapide <300 Mo Microservices
5.2.2. Dockerfile
Un Dockerfile décrit la recette de construction d’une image.
Exemple : microservice users-service (Spring Boot)
FROM openjdk:17-jdk-slim
WORKDIR /app
COPY target/[Link] .
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "[Link]"]
Exemple : microservice orders-service (NestJS)
FROM node:20-alpine
WORKDIR /usr/src/app
COPY package*.json ./
RUN npm install --only=production
COPY . .
EXPOSE 3000
CMD ["npm", "run", "start:prod"]
5.2.3. Construction et exécution
docker build -t users-service .
docker run -d -p 8080:8080 users-service
Chaque microservice doit être conteneurisé indépendamment, avec :
sa propre image,
ses variables d’environnement,
son port exposé.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
5.3. Orchestration des conteneurs
5.3.1. Pourquoi l’orchestration ?
Quand on a des dizaines de microservices, les gérer manuellement devient ingérable :
redémarrage automatique,
scalabilité dynamique,
communication interne,
mises à jour sans interruption.
C’est le rôle d’un orchestrateur comme Kubernetes ou Docker Swarm.
5.3.2. Introduction à Kubernetes (K8s)
Kubernetes est un orchestrateur de conteneurs open-source créé par Google, devenu le
standard industriel pour gérer les déploiements microservices.
Principaux concepts
Concept Rôle
Pod Unité de déploiement (1 ou plusieurs conteneurs)
Deployment Gère la création, la mise à jour et la réplication de pods
Service Expose un pod à d’autres pods ou à l’extérieur
ConfigMap / Secret Gère la configuration et les données sensibles
Ingress Point d’entrée HTTP/HTTPS du cluster
Namespace Espace logique de regroupement des ressources
ReplicaSet Gère le nombre d’instances (scaling horizontal)
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
5.4. Déploiement d’un microservice sur Kubernetes
5.4.1. Exemple : users-service
Deployment YAML
apiVersion: apps/v1
kind: Deployment
metadata:
name: users-deployment
spec:
replicas: 3
selector:
matchLabels:
app: users-service
template:
metadata:
labels:
app: users-service
spec:
containers:
- name: users-service
image: myrepo/users-service:latest
ports:
- containerPort: 8080
env:
- name: SPRING_PROFILES_ACTIVE
value: prod
Service YAML
apiVersion: v1
kind: Service
metadata:
name: users-service
spec:
selector:
app: users-service
ports:
- port: 8080
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
targetPort: 8080
type: ClusterIP
5.4.2. Commandes principales
kubectl apply -f [Link]
kubectl get pods
kubectl get services
kubectl logs pod-name
5.5. Communication et découverte de services
5.5.1. Service Discovery
Kubernetes intègre un DNS interne : chaque service enregistré est accessible par son nom
([Link]).
5.5.2. API Gateway
Une API Gateway centralise les appels extérieurs :
authentification commune,
limitation de débit,
agrégation de réponses.
Exemples : Spring Cloud Gateway, Kong, Traefik, NGINX Ingress.
5.6. Mise à l’échelle et résilience
5.6.1. Horizontal Pod Autoscaler (HPA)
Kubernetes peut ajuster dynamiquement le nombre d’instances selon la charge
CPU/mémoire.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
kubectl autoscale deployment users-deployment --min=2 --max=10 --cpu-
percent=70
5.6.2. Stratégies de redémarrage
Rolling update : mise à jour progressive sans downtime
Blue-Green deployment : deux environnements parallèles (actif et standby)
Canary release : mise à jour progressive à un sous-ensemble d’utilisateurs
5.7. CI/CD (Intégration et Déploiement Continus)
5.7.1. Objectif
Automatiser :
1. Compilation et tests
2. Création d’image Docker
3. Déploiement sur Kubernetes
5.7.2. Exemple GitHub Actions
name: CI-CD Microservice
on:
push:
branches: [ "main" ]
jobs:
build-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build Docker Image
run: docker build -t myrepo/users-service:${{ [Link] }} .
- name: Push to Docker Hub
run: docker push myrepo/users-service:${{ [Link] }}
- name: Deploy to Kubernetes
run: kubectl apply -f k8s/
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
5.8. Service Mesh : Sécurité et Observabilité
5.8.1. Définition
Un Service Mesh (ex : Istio, Linkerd) ajoute une couche réseau transparente pour :
la sécurité (mTLS, authentification inter-services),
la résilience (retries, timeouts, circuit breakers),
la télémétrie (traces, logs, métriques).
Chaque microservice communique via un sidecar proxy (généralement Envoy).
5.8.2. Exemple : Istio
istioctl install → déploie la mesh
kubectl label namespace default istio-injection=enabled → injecte les
sidecars
Les dashboards (Kiali, Jaeger, Grafana) offrent une vision complète des flux entre
services.
5.9. Monitoring et Logging
5.9.1. Stack ELK
Elasticsearch + Logstash + Kibana :
Logstash collecte les logs,
Elasticsearch les indexe,
Kibana les visualise.
5.9.2. Stack Prometheus / Grafana
Prometheus collecte les métriques Kubernetes et applicatives,
Grafana les affiche en tableaux de bord visuels (CPU, mémoire, latence).
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
5.9.3. Exemple de métriques exposées (Spring Boot)
[Link]=health,info,metrics,prometheus
[Link]=true
5.10. Sécurité du déploiement
Utiliser des Secrets Kubernetes pour stocker les credentials :
kubectl create secret generic db-secret --from-literal=password=mydbpass
Ne jamais stocker de mots de passe dans les fichiers YAML.
Restreindre les accès avec RBAC (Role-Based Access Control).
Scanner les images Docker avec Trivy ou Clair.
5.11. Bonnes pratiques
Un microservice = un conteneur = un dépôt Git
Ne jamais coupler deux services dans un même pod
Versionner les images Docker
Automatiser la CI/CD
Implémenter un observability stack complet
Toujours tester localement avant push
Utiliser des namespaces par environnement : dev, staging, prod
5.12. Exercices et mini-projet
Questions
1. Quelle est la différence entre un Pod et un Deployment ?
2. Quelle est la fonction d’un Service Mesh ?
3. Décris les étapes d’un rolling update.
4. Pourquoi Kubernetes est-il plus adapté que Docker Compose en production ?
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
5. Quelle est la différence entre HPA et ReplicaSet ?
Mini-projet pratique : Déploiement complet
Objectif : Déployer une architecture microservices complète (Users, Orders, Payments) sur
Kubernetes.
Étapes :
1. Conteneuriser les 3 services avec Docker.
2. Pousser les images sur Docker Hub.
3. Créer les fichiers Deployment et Service YAML.
4. Configurer un Ingress pour exposer une API Gateway.
5. Activer le monitoring avec Prometheus + Grafana.
6. Implémenter un rolling update sur orders-service.
7. Tester la résilience via des redémarrages de pods.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Chapitre 6 - Sécurité, Observabilité et Gestion
des Données dans les Microservices
6.1. Introduction
Les microservices s’exécutent dans un écosystème distribué : chaque requête traverse plusieurs
services, chaque service gère ses propres données et communique sur le réseau.
Dans un tel contexte :
la sécurité doit être garantie à plusieurs niveaux (authentification, communication,
données),
la gestion des données devient complexe (transactions distribuées, cohérence
éventuelle, CQRS, Event Sourcing),
l’observabilité devient essentielle pour diagnostiquer, auditer et assurer la fiabilité du
système.
6.2. Sécurité des Microservices
6.2.1. Principes fondamentaux
La sécurité des microservices repose sur quatre piliers :
1. Authentification : vérifier l’identité de l’utilisateur.
2. Autorisation : contrôler les ressources accessibles.
3. Confidentialité : chiffrer les échanges.
4. Intégrité : garantir que les données ne sont pas altérées.
Chaque microservice doit être zéro-trust : il ne fait confiance à aucune requête sans preuve
d’identité.
6.2.2. Authentification centralisée
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
L’authentification doit être déléguée à un Identity Provider (IdP) unique :
Keycloak, Auth0, Okta, Cognito…
Supporte OAuth 2.0 et OpenID Connect (OIDC).
Architecture typique :
Client → API Gateway → Auth Service → Microservices
Étapes :
1. L’utilisateur s’authentifie auprès de l’IdP.
2. L’IdP émet un Jeton JWT signé.
3. Le client envoie ce jeton dans l’en-tête Authorization: Bearer <token>.
4. Chaque microservice valide la signature et les rôles avant traitement.
6.2.3. Structure du JWT
{
"sub": "user123",
"roles": ["USER", "ADMIN"],
"iss": "[Link]
"exp": 1739272927
}
Header : type de jeton et algorithme de signature.
Payload : revendications utilisateur (claims).
Signature : garantie d’intégrité.
6.2.4. Autorisation (RBAC & ABAC)
RBAC : Role-Based Access Control → accès selon les rôles.
ABAC : Attribute-Based Access Control → accès selon les attributs (âge, pays, type de
compte).
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Exemple Spring Security
@PreAuthorize("hasRole('ADMIN')")
@GetMapping("/users")
public List<User> getUsers() { ... }
Exemple NestJS
@UseGuards(RolesGuard)
@Roles('admin')
@Get('users')
findAll() { ... }
6.2.5. Sécurisation des communications
Utiliser HTTPS/TLS partout.
Activer le mutual TLS (mTLS) entre microservices (via Istio ou Linkerd).
Éviter d’exposer les ports internes au public.
Mettre à jour régulièrement les certificats et images Docker.
6.2.6. Sécurité des API Gateway
L’API Gateway doit :
vérifier les tokens JWT,
appliquer le rate limiting,
journaliser les accès,
détecter les anomalies (IP suspectes).
Exemples : Kong, Traefik, Spring Cloud Gateway.
6.2.7. Sécurité des données
Chiffrement au repos : base de données chiffrée (AES-256).
Chiffrement en transit : TLS 1.3.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Ne jamais stocker de mots de passe → utiliser des hash (bcrypt, Argon2).
Stocker les secrets dans :
o Kubernetes Secrets,
o Vault (HashiCorp),
o AWS Secrets Manager.
6.3. Gestion des Données dans une Architecture
Microservices
6.3.1. Base de données par microservice
Principe : Database per service - Chaque microservice possède sa propre base et son schéma.
Avantages :
indépendance technologique (PostgreSQL, MongoDB, Redis, etc.),
meilleure scalabilité,
isolement des pannes.
Inconvénient : complexité accrue pour les transactions inter-services.
6.3.2. Transactions distribuées
Les microservices ne partagent pas de transaction globale.
On adopte la cohérence éventuelle via des patterns :
a. Pattern Saga
Chaque service exécute une étape et publie un événement pour déclencher l’étape suivante.
En cas d’échec, on exécute une compensation.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Exemple :
OrderService → PaymentService → ShippingService
|success| |success| |success|
|failure|←Rollback←|failure|←Rollback←|
b. Pattern Outbox
Chaque service publie ses événements dans une table Outbox avant commit, consommée
ensuite par un broker Kafka/RabbitMQ pour garantir la fiabilité.
6.3.3. CQRS (Command Query Responsibility Segregation)
Séparer les modèles de lecture (Query) et d’écriture (Command).
Lecture : base optimisée (Redis, ElasticSearch).
Écriture : base transactionnelle (PostgreSQL).
Accélère les lectures et simplifie la scalabilité.
6.3.4. Event Sourcing
Au lieu d’enregistrer l’état actuel, on enregistre la suite des événements.
Exemple :
UserCreated
UserEmailUpdated
UserPasswordChanged
L’état est reconstruit en rejouant tous les événements.
Avantages :
audit complet,
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
rollback temporel,
traçabilité métier.
6.3.5. Réplication et synchronisation
Eventual Consistency : cohérence atteinte après propagation des événements.
CDC (Change Data Capture) : outils comme Debezium détectent les changements
DB et les publient sur Kafka.
Cache distribué : Redis ou Hazelcast pour réduire la latence.
6.4. Observabilité des Microservices
6.4.1. Trois piliers de l’observabilité
1. Logs : événements textuels de l’application.
2. Métriques : données chiffrées sur l’état du système.
3. Traces : suivi d’une requête à travers plusieurs services.
6.4.2. Centralisation des logs
Utiliser la stack ELK :
Elasticsearch : stockage et indexation,
Logstash : agrégation,
Kibana : visualisation.
Exemple : log JSON structuré
{
"timestamp": "2025-10-19T12:45:10Z",
"service": "orders-service",
"level": "INFO",
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
"traceId": "c93b3a12d",
"message": "Order created successfully"
}
6.4.3. Monitoring des métriques
Prometheus collecte les métriques exposées par les services
Grafana les visualise en temps réel.
Exemples :
Latence moyenne des requêtes HTTP,
Nombre d’erreurs 5xx,
Utilisation CPU/RAM,
Nombre d’événements Kafka.
Spring Boot Actuator :
[Link]=health,metrics,prometheus
6.4.4. Tracing distribué
Chaque requête porte un identifiant unique traceId. Des outils comme Jaeger ou Zipkin
reconstituent le parcours complet.
Exemple de requête :
API Gateway → Auth-Service → Orders-Service → Payment-Service → Notification-
Service
Chaque microservice ajoute des spans au même traceId, permettant :
l’analyse des goulots d’étranglement,
le diagnostic des erreurs inter-services.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
6.4.5. Alerting et SLA
Définir des indicateurs SLI/SLO/SLA : latence < 200 ms, 99.9 % uptime.
Prometheus Alertmanager notifie les anomalies (email, Slack, webhook).
Grafana peut générer des alertes visuelles sur dépassement de seuils.
6.5. Audit et conformité
Enregistrer toutes les actions sensibles (login, suppression, paiement).
Conserver les journaux d’audit dans une base immuable (WORM).
Respecter le RGPD : anonymisation et consentement explicite.
Mettre en place des rétentions temporelles (90 jours, 6 mois, etc.).
6.6. Mini-projet : Observabilité et sécurité intégrées
Objectif : Sécuriser et observer une architecture microservices complète.
Étapes :
1. Ajouter Keycloak comme Identity Provider (JWT + OAuth 2).
2. Protéger l’API Gateway et les services internes avec TLS.
3. Intégrer Prometheus + Grafana pour métriques.
4. Configurer Jaeger pour le tracing distribué.
5. Centraliser les logs via ELK.
6. Ajouter des alertes Prometheus sur erreurs 5xx.
6.7. Conclusion
La sécurité, la gestion des données et l’observabilité forment le socle de la fiabilité des
microservices.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Un système non observé est incontrôlable.
Un système non sécurisé est vulnérable.
Un système mal conçu en données est incohérent.
L’ingénieur logiciel doit :
penser sécurité dès la conception,
adopter la cohérence éventuelle et non la transaction globale,
instrumenter son système pour la transparence opérationnelle.
Souhaites-tu que je poursuive avec le Chapitre 7 : Tests, Performance et Maintenance des
Microservices,
où je traiterai :
les types de tests (unitaires, intégration, contractuels, end-to-end),
les tests de performance et de charge,
la maintenance évolutive et corrective,
les stratégies de mise à jour et d’observabilité continue ?
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Chapitre 7 - Tests, Performance et Maintenance
des Microservices
7.1. Introduction
Tester et maintenir une architecture microservices est beaucoup plus complexe qu’un
monolithe. Chaque service évolue indépendamment, communique avec d’autres, et dépend
d’éléments externes (brokers, API, bases de données, etc.).
L’objectif de ce chapitre est de :
garantir la fiabilité, la performance et la maintenabilité d’un système distribué,
maîtriser les types de tests, les stratégies de validation et les outils d’observabilité
continue,
comprendre comment automatiser la surveillance, la correction et la mise à jour.
7.2. La pyramide des tests pour microservices
Les microservices nécessitent une approche de test à plusieurs niveaux :
Niveau Objectif Portée Outils typiques
Vérifier le comportement interne JUnit, Jest,
Tests unitaires Très local
d’une fonction ou classe Mocha
Vérifier la collaboration entre Service Spring Test,
Tests d’intégration
composants internes individuel Supertest
Tests de contrat Vérifier la compatibilité entre Pact, Spring
Entre services
(Contract Tests) consommateurs et producteurs d’API Cloud Contract
Tests end-to-end Vérifier le fonctionnement global du Système Cypress,
(E2E) système complet Postman, K6
Tests de
Vérifier la scalabilité et la résistance JMeter, Gatling,
performance et Infrastructure
du système Locust
charge
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
7.3. Tests unitaires
7.3.1. Objectif
Valider la logique métier interne,
Détecter rapidement les régressions,
Maintenir une couverture minimale (80 % recommandée).
7.3.2. Exemple (Spring Boot)
@SpringBootTest
class UserServiceTest {
@Autowired
private UserService userService;
@Test
void shouldCreateUser() {
User user = [Link]("Alice", "alice@[Link]");
assertEquals("Alice", [Link]());
}
}
7.3.3. Exemple (NestJS)
describe('UserService', () => {
let service: UserService;
beforeEach(async () => {
const module = await [Link]({
providers: [UserService],
}).compile();
service = [Link]<UserService>(UserService);
});
it('should create a user', () => {
const user = [Link]('Alice');
expect([Link]).toBe('Alice');
});
});
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
7.4. Tests d’intégration
7.4.1. Objectif
Vérifier les interactions entre :
le code métier,
les bases de données,
les API externes,
les files de messages.
7.4.2. Exemple avec base de données
@DataJpaTest
class UserRepositoryTest {
@Autowired
private UserRepository repository;
@Test
void shouldSaveAndRetrieveUser() {
[Link](new User("Alice"));
assertEquals(1, [Link]().size());
}
}
7.4.3. Exemple NestJS (avec Supertest)
it('POST /users should create a user', async () => {
await request([Link]())
.post('/users')
.send({ name: 'Alice' })
.expect(201);
});
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
7.5. Tests de contrat (Contract Testing)
7.5.1. Contexte
Les microservices communiquent via des API. Le test de contrat garantit que les
modifications d’un producteur (API) ne cassent pas les consommateurs.
7.5.2. Outil principal : Pact
Le consommateur définit un contrat (les attentes de l’API).
Le producteur valide qu’il respecte ce contrat.
Exemple (PactJS)
const provider = new Pact({
consumer: 'OrderService',
provider: 'UserService',
});
[Link]({
uponReceiving: 'a request for a user',
withRequest: {
method: 'GET',
path: '/users/1',
},
willRespondWith: {
status: 200,
body: { id: 1, name: 'Alice' },
},
});
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
7.6. Tests End-to-End (E2E)
7.6.1. Objectif
Vérifier le parcours complet d’une requête à travers plusieurs microservices et composants
externes.
7.6.2. Exemple : flux “commande”
Client → API Gateway → Auth-Service → Order-Service → Payment-Service →
Notification-Service
7.6.3. Outils
Postman/Newman pour suites de requêtes automatisées,
Cypress pour front-end + backend intégré,
K6 ou Gatling pour tests de performance simulés.
7.7. Tests de performance et de charge
7.7.1. Objectif
Évaluer la résilience et la scalabilité du système sous contrainte.
Type de test Objectif Exemple
Load Test Vérifier la charge normale 1000 req/min
Stress Test Identifier le point de rupture 10 000 req/min
Spike Test Tester les pics soudains 5000 req en 10 s
Endurance Test Vérifier la tenue dans le temps 12 h d’exécution continue
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
7.7.2. Exemple avec K6
import http from 'k6/http';
import { sleep } from 'k6';
export let options = {
vus: 50,
duration: '30s',
};
export default function () {
[Link]('[Link]
sleep(1);
}
Résultats analysés :
taux d’erreur,
latence moyenne,
percentiles (p95, p99),
taux de requêtes par seconde.
7.8. Tests de résilience (Chaos Testing)
7.8.1. Objectif
Simuler des pannes pour vérifier la robustesse du système.
Exemples :
arrêter un service au hasard,
injecter une latence réseau,
saturer la mémoire ou le CPU.
7.8.2. Outils
Chaos Monkey (Netflix),
Gremlin, LitmusChaos.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
7.8.3. Exemple (LitmusChaos)
kubectl apply -f [Link]
Supprime aléatoirement un Pod, observe si les autres se rétablissent.
7.9. Maintenance et évolutivité
7.9.1. Maintenance corrective
Corriger les bugs détectés par les tests automatisés et la surveillance.
Utiliser des feature flags pour activer/désactiver des fonctionnalités sans
redéploiement.
7.9.2. Maintenance évolutive
Ajouter de nouvelles fonctionnalités sans impacter les autres services.
Suivre les principes de versioning d’API (/v1, /v2).
7.9.3. Maintenance préventive
Mise à jour régulière des dépendances et images Docker.
Suppression des warnings et améliorations de performance.
7.10. Stratégies de déploiement et mise à jour
7.10.1. Blue-Green Deployment
Deux environnements :
Blue (actif)
Green (nouvelle version) : Redirection instantanée du trafic une fois validée.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
7.10.2. Canary Release
Déploiement progressif d’une nouvelle version à un sous-ensemble d’utilisateurs (5 %, 25 %,
50 %, 100 %).
7.10.3. Rolling Update
Mise à jour progressive des Pods Kubernetes sans interruption :
kubectl rollout restart deployment orders-deployment
7.11. Observabilité continue et feedback
7.11.1. Boucle de feedback DevOps
1. Monitoring → détecter les anomalies,
2. Alerting → notifier les équipes,
3. Correction rapide via pipeline CI/CD,
4. Tests automatisés → validation du correctif,
5. Déploiement → nouvelle version stable.
7.11.2. Indicateurs clés (KPI)
MTTR : Mean Time To Recovery
MTTD : Mean Time To Detect
Coverage tests > 80 %
Uptime ≥ 99.9 %
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
7.12. Mini-projet pratique : pipeline complet de validation
Objectif :
Mettre en place une chaîne CI/CD automatisée pour valider, tester et déployer des
microservices.
Étapes :
1. Créer 3 microservices (users, orders, payments).
2. Intégrer les tests unitaires et d’intégration.
3. Ajouter Pact pour les tests de contrat.
4. Lancer des tests E2E avec K6.
5. Exécuter les pipelines GitHub Actions :
o build → test → docker push → deploy → monitor.
6. Déployer sur Kubernetes et vérifier les métriques Prometheus.
7. Simuler une panne via Chaos Monkey et mesurer la résilience.
7.13. Conclusion
Le succès d’une architecture microservices dépend :
de tests automatisés à tous les niveaux,
d’un pipeline CI/CD robuste,
d’une surveillance proactive,
et d’une maintenance disciplinée.
En combinant tests, performance, et maintenance continue, on garantit :
la stabilité,
la scalabilité,
et la durabilité du système à long terme.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Chapitre 8 - Cas pratiques et architecture
complète d’une application microservices
(Spring Boot + NestJS + Kubernetes + Kafka)
8.1. Objectifs pédagogiques
À la fin de ce chapitre, l’étudiant sera capable de :
Concevoir une architecture microservices complète répondant à un besoin métier
concret.
Définir les flux de communication (REST, Kafka, API Gateway, etc.).
Déployer et orchestrer des services sur Docker & Kubernetes.
Mettre en place une chaîne CI/CD et un monitoring de production.
Appliquer les bonnes pratiques de résilience, scalabilité et sécurité.
8.2. Cas pratique : plateforme e-commerce distribuée
Nous allons concevoir une plateforme e-commerce simplifiée appelée ShopFlow.
Cette application gère les commandes, les utilisateurs, les paiements, et les notifications.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
8.3. Architecture fonctionnelle
Microservice Rôle Stack
Gère les comptes utilisateurs et Spring Boot +
User-Service
l’authentification PostgreSQL
Product-Service Gère le catalogue de produits NestJS + MongoDB
Gère la création et le suivi des
Order-Service Spring Boot + Kafka
commandes
Payment-Service Simule le paiement des commandes NestJS + Redis
Notification-
Envoie les emails/SMS après paiement NodeJS + RabbitMQ
Service
API Gateway Point d’entrée unique pour le client Spring Cloud Gateway
Centralise la configuration des
Config-Service Spring Cloud Config
microservices
Spring Cloud Netflix
Discovery-Service Service d’enregistrement (Eureka)
Eureka
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
8.4. Schéma global d’architecture
┌──────────────────┐
│ API Gateway │
└──────┬───────────┘
│
┌───────────────┼──────────────────┐
│ │ │
┌────────▼──────┐ ┌──────▼────────┐ ┌──────▼────────┐
│ User-Service │ │ Product-Serv. │ │ Order-Service │
│ (Spring Boot) │ │ (NestJS) │ │ (Spring Boot) │
└────────┬──────┘ └──────┬────────┘ └──────┬────────┘
│ │ │
│ │ ┌───────▼────────┐
│ │ │ Payment-Service│
│ │ │ (NestJS) │
│ │ └───────┬────────┘
│ │ │
│ │ ┌───────▼────────────┐
│ │ │ Notification-Serv. │
│ │ │ (NodeJS + MQ) │
│ │ └────────────────────┘
│ │
┌────▼───────┐ ┌────▼────────┐
│ PostgreSQL │ │ MongoDB │
└────────────┘ └─────────────┘
Kafka & RabbitMQ assurent la communication asynchrone.
8.5. Diagramme UML de cas d’utilisation
Acteurs
Client : passe une commande, consulte ses produits.
Admin : ajoute/modifie des produits, gère les commandes.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Cas d’utilisation
1. Créer un compte / Se connecter
2. Parcourir le catalogue
3. Passer une commande
4. Effectuer le paiement
5. Recevoir une notification de confirmation
8.6. Diagramme de séquence - Processus de commande
Client → API Gateway → User-Service → Order-Service → Payment-Service →
Notification-Service
Étapes
1. Le client passe une commande.
2. Order-Service vérifie la disponibilité du produit via Product-Service.
3. Order-Service envoie un message Kafka au Payment-Service.
4. Payment-Service traite le paiement (mock).
5. En cas de succès, il publie un événement vers Notification-Service.
6. Notification-Service envoie un email/SMS de confirmation.
8.7. Schéma des bases de données
User-Service (PostgreSQL)
TABLE users (
id SERIAL PRIMARY KEY,
name VARCHAR(100),
email VARCHAR(100) UNIQUE,
password VARCHAR(255),
role VARCHAR(20)
);
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Product-Service (MongoDB)
{
"_id": "uuid",
"name": "Laptop HP",
"price": 550000,
"stock": 10
}
Order-Service (PostgreSQL)
TABLE orders (
id SERIAL PRIMARY KEY,
user_id INT,
product_id VARCHAR(36),
quantity INT,
status VARCHAR(20),
total DECIMAL(10,2)
);
8.8. Exemple de communication asynchrone (Kafka)
Publication d’un événement (Spring Boot – OrderService)
@Service
public class OrderEventProducer {
private final KafkaTemplate<String, OrderEvent> kafkaTemplate;
public void publishOrderCreated(Order order) {
OrderEvent event = new OrderEvent([Link](), "ORDER_CREATED");
[Link]("order-topic", event);
}
}
Consommation (NestJS – PaymentService)
@KafkaListener('order-topic')
async handleOrderCreated(event: OrderEvent) {
const payment = await [Link]([Link]);
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
if ([Link]) {
[Link]('payment-success-topic', { orderId: [Link] });
}
}
8.9. Sécurité et gestion des accès
JWT (JSON Web Tokens) pour authentifier les utilisateurs.
Spring Security côté User-Service.
Role-based Access Control (RBAC) :
o ROLE_USER → accès au catalogue, commandes.
o ROLE_ADMIN → gestion des produits, statistiques.
8.10. Déploiement sur Kubernetes
8.10.1. Structure des manifestes
/k8s
├── [Link]
├── [Link]
├── [Link]
├── [Link]
├── [Link]
├── [Link]
├── [Link]
└── [Link]
8.10.2. Exemple de déploiement
apiVersion: apps/v1
kind: Deployment
metadata:
name: order-deployment
spec:
replicas: 3
selector:
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
matchLabels:
app: order-service
template:
metadata:
labels:
app: order-service
spec:
containers:
- name: order-service
image: shopflow/order-service:1.0
ports:
- containerPort: 8082
8.10.3. Exposition via Ingress
apiVersion: [Link]/v1
kind: Ingress
metadata:
name: shopflow-ingress
spec:
rules:
- host: [Link]
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: api-gateway
port:
number: 8080
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
8.11. CI/CD automatisé
8.11.1. Étapes du pipeline GitHub Actions
name: CI/CD
on: [push]
jobs:
build-test-deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Setup Java
uses: actions/setup-java@v3
with:
java-version: '17'
- name: Run tests
run: mvn test
- name: Build Docker images
run: docker-compose build
- name: Push to Docker Hub
run: docker push ${{ secrets.DOCKER_USERNAME }}/shopflow
- name: Deploy to Kubernetes
run: kubectl apply -f k8s/
8.12. Observabilité et monitoring
8.12.1. Stack recommandée
Composant Rôle
Prometheus Collecte des métriques
Grafana Tableaux de bord
ELK Stack (Elasticsearch, Logstash, Kibana) Centralisation des logs
Jaeger Traçage distribué des requêtes entre services
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
8.12.2. Exemple de métriques Prometheus (Spring Boot)
management:
endpoints:
web:
exposure:
include: health, metrics, prometheus
8.13. Bonnes pratiques finales
1. Chaque microservice doit être autonome : base de données, logique métier, API
propres.
2. Automatiser les tests et les déploiements.
3. Isoler les fautes : un service défaillant ne doit pas bloquer les autres.
4. Utiliser des files de messages (Kafka/RabbitMQ) pour découpler les
communications.
5. Surveiller activement (logs, métriques, alertes).
6. Documenter les API avec OpenAPI / Swagger.
7. Prévoir la montée en charge horizontale (scaling automatique des Pods).
8.14. Résumé du chapitre
Domaine Technologies principales
Backend Spring Boot, NestJS
Messaging Kafka, RabbitMQ
Bases de données PostgreSQL, MongoDB, Redis
Authentification JWT, Spring Security
Orchestration Docker, Kubernetes
Monitoring Prometheus, Grafana, ELK
CI/CD GitHub Actions, Jenkins
Résilience Circuit Breaker, Retry, Bulkhead, Chaos Engineering
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
8.15. Travaux pratiques (TP)
TP : Implémentation et déploiement de ShopFlow
Étapes à réaliser :
1. Créer les microservices users, products, orders, payments.
2. Mettre en place Kafka et RabbitMQ.
3. Configurer une API Gateway (Spring Cloud Gateway).
4. Intégrer la sécurité JWT.
5. Ajouter des tests unitaires et E2E.
6. Conteneuriser chaque service (Docker).
7. Déployer sur Kubernetes local (Minikube / Kind).
8. Ajouter un dashboard Grafana pour suivre les métriques.
Bonus :
Implémenter une fonction de remboursement automatique.
Ajouter un cache Redis pour les produits.
Mettre en place un chaos test pour simuler une panne de Payment-Service.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Chapitre 9 - Sécurité, conformité et
observabilité avancée dans les architectures
microservices
9.1. Objectifs pédagogiques
À la fin de ce chapitre, l’étudiant sera capable de :
Comprendre les menaces et failles typiques dans une architecture microservices.
Mettre en œuvre une sécurité de bout en bout (API Gateway → microservices
→ bases de données).
Intégrer JWT, OAuth2, OpenID Connect, Keycloak, Vault pour la protection et la
conformité.
Implémenter la traçabilité complète via OpenTelemetry et observabilité distribuée.
Garantir la conformité RGPD et la journalisation des accès.
9.2. Les enjeux de sécurité dans les architectures
microservices
Les microservices introduisent de nouveaux défis en matière de sécurité, car :
Il existe de multiples points d’entrée réseau.
Chaque service peut avoir sa propre vulnérabilité.
Les communications transitent souvent par des canaux asynchrones (Kafka,
RabbitMQ).
La surface d’attaque est démultipliée par rapport à un monolithe.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Les principales menaces :
1. Vol d’identifiants ou de tokens JWT.
2. Injection (SQL, NoSQL, Command Injection).
3. Man-in-the-middle sur les flux interservices.
4. Escalade de privilèges entre services mal configurés.
5. Fuite de secrets dans le code source ou les images Docker.
9.3. Sécurité d’accès et authentification
9.3.1. JSON Web Tokens (JWT)
JWT est un standard (RFC 7519) pour transporter des identités signées numériquement
entre services.
Un token JWT contient trois parties :
[Link]
Exemple :
{
"alg": "HS256",
"typ": "JWT"
}
{
"sub": "user123",
"role": "USER",
"exp": 1729968000
}
Dans Spring Boot :
public String generateToken(UserDetails user) {
return [Link]()
.setSubject([Link]())
.claim("role", "USER")
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
.setExpiration(new Date([Link]() + 86400000))
.signWith(SignatureAlgorithm.HS256, SECRET_KEY)
.compact();
}
Dans NestJS :
const token = [Link]({ sub: [Link], role: 'USER' });
9.3.2. Validation des tokens dans l’API Gateway
L’API Gateway agit comme point d’entrée unique. Elle vérifie le JWT avant de rediriger la
requête vers le microservice cible.
@Bean
public SecurityWebFilterChain securityFilterChain(ServerHttpSecurity http) {
return http
.authorizeExchange()
.pathMatchers("/auth/**").permitAll()
.anyExchange().authenticated()
.and()
.oauth2ResourceServer(OAuth2ResourceServerSpec::jwt)
.build();
}
9.4. Autorisation et fédération d’identité
9.4.1. OAuth2 et OpenID Connect
OAuth2 gère les autorisations (accès à des ressources).
OpenID Connect ajoute une couche d’authentification au-dessus d’OAuth2.
Ensemble, ils permettent la connexion unique (SSO) et la délégation de droits entre
services.
Flux typique OAuth2 :
1. Le client envoie une requête d’accès à l’API Gateway.
2. L’API Gateway redirige vers un fournisseur d’identité (Keycloak).
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
3. L’utilisateur s’authentifie et obtient un access_token.
4. Le token est vérifié sur chaque requête entrante.
9.4.2. Keycloak (Open Source IAM)
Keycloak fournit :
Gestion des utilisateurs et rôles.
Authentification multi-facteurs (MFA).
Tokens OAuth2 et JWT.
Intégration avec LDAP, Active Directory ou réseaux sociaux.
Exemple de configuration Spring Boot :
spring:
security:
oauth2:
resourceserver:
jwt:
issuer-uri: [Link]
9.5. Sécurisation des communications interservices
9.5.1. TLS / HTTPS
Tous les échanges entre microservices doivent passer par HTTPS (port 443).
Les certificats peuvent être gérés via Cert-Manager sur Kubernetes.
9.5.2. Mutual TLS (mTLS)
Chaque service possède son certificat client et serveur.
Permet une authentification bidirectionnelle entre services.
Exemple de configuration Istio mTLS :
apiVersion: [Link]/v1beta1
kind: PeerAuthentication
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
metadata:
name: default
spec:
mtls:
mode: STRICT
9.6. Protection des secrets et variables sensibles
9.6.1. HashiCorp Vault
Vault gère :
Les clés API, tokens, mots de passe, certificats.
Le renouvellement automatique de secrets.
Le chiffrement à la demande (Encryption as a Service).
Exemple d’accès à un secret :
vault kv get secret/db-credentials
9.6.2. Intégration avec Spring Boot
spring:
cloud:
vault:
uri: [Link]
authentication: token
token: s.XYZ123TOKEN
kv:
enabled: true
backend: secret
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
9.7. Observabilité avancée
9.7.1. Définition
L’observabilité regroupe logs, métriques et traces pour comprendre le comportement global
du système.
9.7.2. OpenTelemetry
C’est le standard unifié d’observabilité soutenu par la CNCF.
Architecture :
Application → OpenTelemetry SDK → Collector → Exporters (Prometheus, Jaeger,
Grafana)
Instrumentation dans Spring Boot :
<dependency>
<groupId>[Link]</groupId>
<artifactId>opentelemetry-spring-boot-starter</artifactId>
</dependency>
Instrumentation dans NestJS :
import { OpenTelemetryModule } from 'nestjs-otel';
@Module({
imports: [[Link]()],
})
export class AppModule {}
9.7.3. Tracing distribué avec Jaeger
Chaque requête reçoit un traceId unique :
visible dans les logs,
transmis entre services (headers HTTP),
corrélé dans Jaeger.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Exemple de propagation d’ID dans HTTP headers :
X-Request-ID: 234abc12d
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
9.8. Conformité et journalisation
9.8.1. RGPD et gestion des données personnelles
Minimiser la collecte : ne conserver que les données nécessaires.
Consentement explicite des utilisateurs.
Droit à l’oubli et portabilité.
Traçabilité des accès et des modifications.
9.8.2. Audit Logging
Chaque modification critique doit être loguée :
{
"timestamp": "2025-10-19T04:15:33",
"user": "admin@[Link]",
"action": "DELETE_PRODUCT",
"entity": "Product",
"id": "123",
"result": "SUCCESS"
}
Spring Boot fournit @Audited (Hibernate Envers) pour enregistrer automatiquement les
changements d’entités :
@Entity
@Audited
public class Product { ... }
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
9.9. Sécurité des conteneurs et du déploiement
9.9.1. Bonnes pratiques Docker
1. Utiliser des images minimales (distroless, alpine).
2. Ne pas exécuter en tant que root.
3. Scanner les images avec Trivy ou Clair.
4. Mettre à jour régulièrement les dépendances.
9.9.2. Sécurité Kubernetes
Network Policies pour limiter les flux inter-Pods.
RBAC (Role-Based Access Control) pour restreindre les permissions.
PodSecurityPolicy / OPA Gatekeeper pour valider les déploiements.
Secrets encryptés dans etcd.
9.10. Résumé du chapitre
Domaine Outils / Protocoles
Authentification JWT, OAuth2, OpenID Connect
Gestion d’identité Keycloak
Protection des secrets HashiCorp Vault
Communication sécurisée TLS, mTLS, Istio
Observabilité OpenTelemetry, Prometheus, Jaeger, Grafana
Conformité RGPD, Audit Logging
Sécurité des conteneurs Trivy, Kubernetes RBAC
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
9.11. Exercices & TP
TP : Sécurisation et observabilité de ShopFlow
Étapes :
1. Ajouter l’authentification Keycloak à l’API Gateway.
2. Sécuriser les communications internes via HTTPS/mTLS.
3. Intégrer Vault pour gérer les credentials des bases de données.
4. Configurer OpenTelemetry + Jaeger pour le tracing.
5. Créer un dashboard Grafana affichant le temps moyen de traitement des commandes.
6. Mettre en place un audit log sur le Product-Service.
Bonus :
Déployer Istio et activer mTLS automatique.
Ajouter un système d’alertes Prometheus + Slack.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
Chapitre 10 - CI/CD, Performances, Scalabilité
et Bonnes Pratiques de Production des
Microservices
10.1. Introduction
L’un des défis majeurs des architectures microservices réside dans la gestion de la complexité
opérationnelle.
Une application peut être composée de plusieurs dizaines de services, chacun versionné, testé,
déployé, et monitoré indépendamment.
Ce chapitre explore :
La mise en place d’un pipeline d’intégration et de déploiement continu (CI/CD),
Les techniques d’optimisation et de scalabilité,
La gestion des performances et de la fiabilité,
Et les bonnes pratiques pour la maintenance et l’observabilité en production.
10.2. Le concept de CI/CD
10.2.1. Définitions
Concept Description
CI (Continuous Processus d’intégration continue qui vérifie, compile et teste
Integration) automatiquement le code après chaque commit.
CD (Continuous Automatisation de la livraison vers des environnements
Delivery) intermédiaires (staging, UAT) après validation.
CD (Continuous Automatisation du déploiement vers la production dès que les
Deployment) tests sont passés avec succès.
L’objectif final est de livrer rapidement du code stable, avec une boucle de feedback courte.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
10.3. Architecture d’un pipeline CI/CD microservices
10.3.1. Étapes standards
1. Commit & Build
o Chaque service dispose de son propre dépôt Git.
o Build indépendant via Maven/Gradle (Spring Boot) ou npm (NestJS).
2. Tests unitaires et d’intégration
o JUnit/Testcontainers pour Spring Boot.
o Jest/Supertest pour NestJS.
o Test de compatibilité inter-services via contract testing ([Link]).
3. Analyse de qualité
o SonarQube pour code smells et couverture.
o OWASP Dependency Check pour la sécurité.
4. Build image Docker
o Chaque microservice est packagé dans une image Docker unique.
o Tag basée sur le commit ou la version (order-service:v1.3.2).
5. Push vers le registre
o DockerHub, GitHub Container Registry, ou Harbor privé.
6. Déploiement automatisé
o Via Helm charts, Kubernetes manifests, ou ArgoCD.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
10.3.2. Exemple de pipeline GitHub Actions
name: CI-CD Pipeline
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup Java
uses: actions/setup-java@v4
with:
distribution: temurin
java-version: '17'
- name: Build and Test
run: mvn clean verify
- name: Build Docker image
run: docker build -t [Link]/myorg/order-service:${{ [Link] }} .
- name: Push to Registry
run: docker push [Link]/myorg/order-service:${{ [Link] }}
deploy:
runs-on: ubuntu-latest
needs: build
steps:
- name: Deploy to Kubernetes
uses: azure/k8s-deploy@v4
with:
manifests: manifests/[Link]
images: [Link]/myorg/order-service:${{ [Link] }}
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
10.4. Stratégies de déploiement avancées
10.4.1. Rolling Update
Déploiement progressif sans interruption :
1. Nouvelle version déployée
2. Ancienne version arrêtée progressivement.
10.4.2. Blue/Green Deployment
Deux environnements (Blue et Green) coexistent :
Blue : version en production.
Green : nouvelle version testée. Une fois validée, le routage bascule vers Green.
10.4.3. Canary Release
Déploiement auprès d’un petit pourcentage d’utilisateurs.
Surveillance des métriques avant généralisation.
10.4.4. Feature Toggles
Activation de fonctionnalités à la volée sans redéploiement.
Utilisation : Unleash, LaunchDarkly, Spring Cloud Config.
10.5. Optimisation des performances
10.5.1. Métriques clés
Indicateur Description
Latency (p95, p99) Temps de réponse maximal observé sur 95% ou 99% des requêtes.
Throughput (RPS) Nombre de requêtes traitées par seconde.
CPU & Memory Usage Surveillance des ressources par pod/service.
Error Rate Pourcentage de requêtes échouées.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
10.5.2. Techniques d’optimisation
1. Caching
o Redis, Hazelcast, ou Spring Cache abstractions.
o Cache côté client (HTTP headers ETag, Cache-Control).
2. Compression & Serialization
o gRPC > REST pour gros volumes de données.
o Utiliser JSON-Binary (protobuf) au lieu de JSON brut.
3. Database Optimization
o Indices pertinents, partitionnement, read replicas.
o Connection pooling via HikariCP.
4. Thread Pool Management
o Ajuster les pools (@Async, ExecutorService, EventLoop).
5. Reactive Programming
o Utiliser Spring WebFlux ou NestJS RxJS pour les services à fort I/O.
10.6. Scalabilité et haute disponibilité
10.6.1. Types de scalabilité
Type Description
Verticale (scale-up) Augmentation des ressources sur un même nœud (RAM, CPU).
Horizontale (scale-out) Multiplication des instances d’un service. Recommandée.
10.6.2. Auto-scaling Kubernetes
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: order-service-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
name: order-service
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 60
Kubernetes crée automatiquement de nouvelles instances si la charge CPU > 60%.
10.6.3. Load Balancing
Ingress Controller (NGINX, Traefik)
API Gateway (Kong, Spring Cloud Gateway)
DNS-based (Round Robin)
10.7. Sécurité et conformité
1. Secrets Management
o Ne jamais stocker de secrets dans le code.
o Utiliser HashiCorp Vault ou AWS Secrets Manager.
2. TLS/HTTPS partout
o Certificats via Let’s Encrypt.
o Communication interservices chiffrée (mTLS).
3. Authentification & Autorisation
o OpenID Connect, OAuth2 (Keycloak, Auth0).
o JWT Tokens, API Gateway Policy Enforcement.
4. Audit et traçabilité
o Journaux d’accès, ID utilisateur, timestamp, IP.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
10.8. Observabilité et supervision
10.8.1. Centralisation des logs
ELK Stack (Elasticsearch, Logstash, Kibana).
Corrélation des logs avec traceId propagé via headers (X-Correlation-ID).
10.8.2. Monitoring et alertes
Prometheus → collecte des métriques.
Grafana → tableaux de bord.
AlertManager → notifications (Slack, Email, PagerDuty).
10.8.3. Tracing distribué
Outils : Jaeger, Zipkin, OpenTelemetry.
Permet de suivre une requête à travers tous les microservices impliqués.
10.9. Bonnes pratiques générales en production
Automatiser tout : build, tests, déploiements, monitoring.
Isoler les environnements : dev, test, staging, prod.
Versionner les API et schémas de données.
Mettre en place du chaos engineering (Simian Army, Gremlin).
Limiter le couplage : chaque service doit être modifiable sans impact majeur.
Mettre à jour en continu (rolling releases) sans interruption.
Tester en production de manière contrôlée (canary releases).
Backups planifiés et tests de restauration.
M. ABDEL-KALIF BEN HAMADOU
Cours de développement d’applications Microservices
10.10. Mini-projet final (Synthèse du cours)
Objectif : Créer, containeriser, déployer et monitorer un système microservices complet.
Étapes :
1. Concevoir 3 microservices : User-Service, Order-Service, Payment-Service.
2. Implémenter communication via Kafka.
3. Déployer via Kubernetes + Helm.
4. Ajouter pipeline CI/CD (GitHub Actions + ArgoCD).
5. Mettre en place observabilité complète (Prometheus + Grafana + Jaeger).
6. Activer autoscaling + Canary deployment.
10.11. Conclusion générale du cours
À travers ce cours, l’étudiant a acquis :
La vision complète de la conception microservices (DDD, découpage,
communication, sécurité),
Les compétences pratiques pour déployer et maintenir des applications distribuées,
Et une culture DevOps solide intégrant automatisation, scalabilité, et résilience.
Ce module constitue ainsi une base robuste pour toute carrière en ingénierie logicielle
moderne, particulièrement dans les domaines Cloud-Native, DevOps, et Software
Architecture.
M. ABDEL-KALIF BEN HAMADOU
Vous aimerez peut-être aussi
- Introduction aux Microservices en SOAPas encore d'évaluationIntroduction aux Microservices en SOA42 pages
- Filière Data and Software Engineering & Master Systèmes D'information Et Systèmes IntelligentsPas encore d'évaluationFilière Data and Software Engineering & Master Systèmes D'information Et Systèmes Intelligents146 pages
- Introduction aux microservices et défisPas encore d'évaluationIntroduction aux microservices et défis5 pages
- Architecture Microservices : Concepts ClésPas encore d'évaluationArchitecture Microservices : Concepts Clés62 pages
- Migration vers microservices éducatifsPas encore d'évaluationMigration vers microservices éducatifs91 pages
- Comprendre l'architecture microservicesPas encore d'évaluationComprendre l'architecture microservices5 pages
- Introduction à l'architecture microservicesPas encore d'évaluationIntroduction à l'architecture microservices44 pages
- Limites de l'Architecture MonolithiquePas encore d'évaluationLimites de l'Architecture Monolithique26 pages
- Introduction à l'architecture microservicesPas encore d'évaluationIntroduction à l'architecture microservices10 pages
- Guide Complet sur les Microservices .NET 8Pas encore d'évaluationGuide Complet sur les Microservices .NET 818 pages
- Séminaire sur l'Architecture MicroservicesPas encore d'évaluationSéminaire sur l'Architecture Microservices36 pages
- Guide sur l'architecture microservicesPas encore d'évaluationGuide sur l'architecture microservices15 pages
- Architectures Microservices avec Spring BootPas encore d'évaluationArchitectures Microservices avec Spring Boot39 pages
- Cours sur les Architectures MicroservicesPas encore d'évaluationCours sur les Architectures Microservices43 pages
- Concepts clés de l'architecture logiciellePas encore d'évaluationConcepts clés de l'architecture logicielle15 pages
- Microservices - Principes Avantages Et Défis 4 1Pas encore d'évaluationMicroservices - Principes Avantages Et Défis 4 121 pages
- Architecture des Systèmes DistribuésPas encore d'évaluationArchitecture des Systèmes Distribués20 pages
- Monolithique vs Microservices : ComparatifPas encore d'évaluationMonolithique vs Microservices : Comparatif31 pages
- Architectures Microservices en JavaPas encore d'évaluationArchitectures Microservices en Java41 pages
- How To Build and Scale With Microservices FrenchPas encore d'évaluationHow To Build and Scale With Microservices French17 pages
- Avantages et défis des MicroservicesPas encore d'évaluationAvantages et défis des Microservices68 pages
- Avantages et inconvénients des monolithesPas encore d'évaluationAvantages et inconvénients des monolithes37 pages
- Microservices et architectures comparéesPas encore d'évaluationMicroservices et architectures comparées16 pages
- Applications Web Distribuées et MicroservicesPas encore d'évaluationApplications Web Distribuées et Microservices5 pages
- Architectures Cloud Native et MicroservicesPas encore d'évaluationArchitectures Cloud Native et Microservices105 pages
- Architectures Microservices avec JavaPas encore d'évaluationArchitectures Microservices avec Java35 pages
- 1 - Formation Microservice - Les ConceptsPas encore d'évaluation1 - Formation Microservice - Les Concepts32 pages
- Architecture SOA et Microservices en JavaEEPas encore d'évaluationArchitecture SOA et Microservices en JavaEE37 pages
- Architecture des Microservices expliquéePas encore d'évaluationArchitecture des Microservices expliquée8 pages
- Conception d'Architectures MicroservicesPas encore d'évaluationConception d'Architectures Microservices4 pages
- Importance de l'architecture logiciellePas encore d'évaluationImportance de l'architecture logicielle7 pages
- Placement de microservices en nuage-périphériePas encore d'évaluationPlacement de microservices en nuage-périphérie90 pages
- Développement d'un site web pour LTSAPas encore d'évaluationDéveloppement d'un site web pour LTSA46 pages
- Concepts Clés du DevOps et Outils AssociésPas encore d'évaluationConcepts Clés du DevOps et Outils Associés1 page
- Diagramme de cas d'utilisation UMLPas encore d'évaluationDiagramme de cas d'utilisation UML151 pages
- Développement d'applications microservicesPas encore d'évaluationDéveloppement d'applications microservices34 pages
- Tableau de bord enseignant et étudiantPas encore d'évaluationTableau de bord enseignant et étudiant2 pages
- Application de Navigation CollaborativePas encore d'évaluationApplication de Navigation Collaborative4 pages
- Cahier des charges plateforme pédagogiquePas encore d'évaluationCahier des charges plateforme pédagogique6 pages
- Cahier des Charges UX/UI Navigation RoutièrePas encore d'évaluationCahier des Charges UX/UI Navigation Routière2 pages
- Cahier des charges pour site web BTPPas encore d'évaluationCahier des charges pour site web BTP6 pages
- Comprendre les interruptions en microprocesseurPas encore d'évaluationComprendre les interruptions en microprocesseur14 pages
- Assurance Maladie MR ZOUINI OUSSAMAPas encore d'évaluationAssurance Maladie MR ZOUINI OUSSAMA2 pages
- Exercice sur le processus technologiquePas encore d'évaluationExercice sur le processus technologique7 pages
- Travaux Dirigés C++ : Exercices PratiquesPas encore d'évaluationTravaux Dirigés C++ : Exercices Pratiques2 pages
- Analyse des Commandes et Livraisons SQLPas encore d'évaluationAnalyse des Commandes et Livraisons SQL6 pages
- Animation CSS par étapes et spritesPas encore d'évaluationAnimation CSS par étapes et sprites9 pages
- Aide à la saisie par autocomplétionPas encore d'évaluationAide à la saisie par autocomplétion2 pages
- Conception de FSM en Systèmes EmbarquésPas encore d'évaluationConception de FSM en Systèmes Embarqués1 page
- Convocation Baccalauréat 2024 Côte d'IvoirePas encore d'évaluationConvocation Baccalauréat 2024 Côte d'Ivoire1 page
- Formalisme Entité-Association en InformatiquePas encore d'évaluationFormalisme Entité-Association en Informatique25 pages
- Modélisation numérique avec PFC ItascaPas encore d'évaluationModélisation numérique avec PFC Itasca3 pages
- Développeur web à Abidjan : projets clésPas encore d'évaluationDéveloppeur web à Abidjan : projets clés1 page
- Types de Langages Algorithmiques et MéthodologiePas encore d'évaluationTypes de Langages Algorithmiques et Méthodologie2 pages
- Essai ultrasonore : normes ISO 12715Pas encore d'évaluationEssai ultrasonore : normes ISO 127151 page
- Architectures Client-Serveur et N-TiersPas encore d'évaluationArchitectures Client-Serveur et N-Tiers5 pages
- 1070T5-Matériels Et Méthodes D'auscultation Des Chaussees UrbainesPas encore d'évaluation1070T5-Matériels Et Méthodes D'auscultation Des Chaussees Urbaines9 pages
- Modifier les droits des fichiers LinuxPas encore d'évaluationModifier les droits des fichiers Linux5 pages
- Cours d'informatique pour Tles A au Cameroun100% (4)Cours d'informatique pour Tles A au Cameroun129 pages
- Sécurisation des données : normes et NACPas encore d'évaluationSécurisation des données : normes et NAC16 pages
- Rôle des périphériques et protocoles réseauPas encore d'évaluationRôle des périphériques et protocoles réseau59 pages
- Automate Programmable TSX 37 : Guide CompletPas encore d'évaluationAutomate Programmable TSX 37 : Guide Complet33 pages
- Formation en Ingénierie Chimique PICPas encore d'évaluationFormation en Ingénierie Chimique PIC2 pages