--- title: Architecture Microservices created: 2026-06-06 updated: 2026-06-06 type: concept tags: [tech, architecture] confidence: high contested: false sources: [synthesized] --- # 🧩 Architecture Microservices ## Définition Courte Style d'architecture qui structure une application comme un ensemble de petits services autonomes, chacun exécutant un processus unique et communiquant via des API légères (souvent HTTP/REST ou gRPC). ## Explication Détaillée Contrairement au **monolithe** où toute la logique métier est dans un seul codebase, les microservices découpent l'application en services indépendants par domaine métier (auth, paiement, catalogue, etc.). Chaque service : - Possède sa propre base de données (Database per Service). - Est déployable indépendamment. - Communique via des API ou une messagerie asynchrone (Kafka, RabbitMQ, NATS). - Tolère la panne d'autres services (degraded mode). **Avantages** : scalabilité indépendante de chaque service, isolation des pannes, équipes autonomes, polyglotisme technologique. **Inconvénients** : complexité opérationnelle accrue, latence réseau, transactions distribuées difficiles, debugging distribué. ## Cas d'Usage - Applications à fort trafic avec des composants à scalabilités différentes (ex: Netflix, Amazon, Uber). - Équipes multiples travaillant en parallèle sur des domaines distincts. - Migration progressive d'un monolithe legacy. ## Outils Liés - **Orchestration** : Kubernetes, Nomad, Docker Swarm. - **Service Mesh** : Istio, Linkerd. - **API Gateway** : Kong, Traefik, Envoy. - **Messagerie** : Kafka, RabbitMQ, NATS. - **Observabilité** : Prometheus, Jaeger, OpenTelemetry. ## Pages Liées - [[patterns-architecture]] - [[docker]] - [[traefik]] ## Questions Ouvertes - Comment gérer les transactions distribuées sans SAGA ? - Quel est le bon découpage en microservices (taille idéale) ? - Comment éviter le "distributed monolith" (microservices trop couplés) ? ## Liens - [[message-queue]] - [[architecture-monolithique]] - [[comparatif-reverse-proxy]] - [[kubernetes]]