Patterns et Anti-Patterns des Microservices
Les microservices promettent le déploiement indépendant, l'autonomie des équipes et la flexibilité technologique. Ils apportent aussi la complexité des systèmes distribués, la non-fiabilité du réseau et une charge opérationnelle élevée. Connaître les bons patterns -- et éviter les anti-patterns -- sépare les implémentations réussies des monolithes distribués.
Stratégies de décomposition
Comment vous découpez un monolithe compte plus que le fait de le découper.
| Stratégie | Approche | Quand l'utiliser |
|---|---|---|
| Par capacité métier | Aligner les services sur les domaines métier | Frontières de domaine stables |
| Par sous-domaine (DDD) | Utiliser les bounded contexts du DDD | Domaines complexes avec séparations claires |
| Strangler fig | Extraire progressivement des services du monolithe | Migration incrémentale |
| Par équipe | Un service par équipe (loi de Conway inverse) | Alignement organisationnel |
Communication inter-services
| Pattern | Protocole | Cas d'usage | Compromis |
|---|---|---|---|
| REST synchrone | HTTP/JSON | Opérations CRUD simples | Couplage fort, pannes en cascade |
| gRPC synchrone | HTTP/2 + Protobuf | APIs internes haute performance | Gestion de schémas, moins lisible |
| Messaging async | AMQP, Kafka | Workflows event-driven | Consistance éventuelle, debug plus difficile |
| Request-reply async | IDs de corrélation sur files | Opérations longues | Complexité de suivi |
Le pattern Saga pour les transactions distribuées
Les transactions ACID classiques ne couvrent pas plusieurs services. Le pattern saga coordonne les opérations multi-services :
Saga basée sur la chorégraphie :
- Chaque service publie des événements et écoute ceux des autres
- Pas de coordinateur central
- Simple pour 2-3 services, complexe au-delà
Saga basée sur l'orchestration :
- Un orchestrateur central dirige le workflow
- Chaque service expose une action compensatoire pour le rollback
- Plus facile à comprendre, mais l'orchestrateur concentre la logique
| Aspect | Chorégraphie | Orchestration |
|---|---|---|
| Couplage | Faible | Moyen (vers l'orchestrateur) |
| Visibilité | Flux difficile à tracer | Définition de workflow claire |
| Complexité à l'échelle | Croît exponentiellement | Croît linéairement |
| Idéal pour | Workflows simples | Processus multi-étapes complexes |
Extrait de la fiche « AWS Step Functions: Orchestrating Serverless Workflows » · Demander la fiche complète
Service Mesh
Un service mesh gère les préoccupations transversales au niveau infrastructure :
- Gestion du trafic -- routage, load balancing, déploiements canary
- Sécurité -- TLS mutuel, politiques d'autorisation
- Observabilité -- tracing distribué, métriques, logs d'accès
- Résilience -- retries, circuit breakers, timeouts
Options populaires : Istio (riche, complexe), Linkerd (léger, plus simple), Consul Connect (écosystème HashiCorp).
Extrait de la fiche « Web Application and Microservices Architecture » · Demander la fiche complète
Anti-patterns critiques
| Anti-Pattern | Symptôme | Correction |
|---|---|---|
| Monolithe distribué | Les services doivent être déployés ensemble | Appliquer des contrats d'API, réduire les BDD partagées |
| BDD partagée | Plusieurs services écrivent dans les mêmes tables | Une BDD par service, événements pour la sync |
| Services bavards | Centaines d'appels inter-services par requête | APIs agrégées, pattern BFF |
| Nano-services | Services trop petits pour justifier l'overhead | Fusionner les services liés |
| Service dieu | Un service gère trop de logique | Décomposer par bounded context |
| Chaine synchrone | A appelle B appelle C appelle D en synchrone | Messaging async, event-driven |
Quand le monolithe est préférable
- Petite équipe (< 10 ingénieurs) -- la charge opérationnelle dépasse les bénéfices
- Produit en phase initiale -- les frontières de domaine ne sont pas encore claires
- Domaine simple -- les apps CRUD n'ont pas besoin de complexité distribuée
- Faible échelle -- si un seul serveur gère la charge, ne la distribuez pas
- Latence stricte -- chaque saut réseau ajoute de la latence
Un monolithe modulaire bien structuré peut offrir la plupart des bénéfices organisationnels des microservices sans la taxe systèmes distribués.
Microservices ou monolithe
tadataPros
- Independent deploy and scaling per service
- Team autonomy and clear ownership
- Fault isolation if boundaries are right
- Polyglot: right tool per service
Cons
- Distributed systems are hard: partial failure, latency
- Data consistency across services (no cross-service transactions)
- Operational overhead: many pipelines, dashboards
- Bigger attack surface: every service is a network endpoint
Extrait de la fiche « Web Application and Microservices Architecture » · Demander la fiche complète