06 - Glossaire
Tous les termes rencontres dans cette serie sur les microservices, classes par ordre alphabetique.
A
API Gateway
Un point d'entree unique pour tous les clients externes. Il recoit les requêtes HTTP, les route vers le bon service, gere l'authentification, le rate limiting et l'aggregation de réponses. Envoy, Kong et Traefik sont des API gateways courants. Voir le comparatif gRPC vs REST pour l'architecture hybride.
B
Bounded Context
Un concept du Domain-Driven Design. C'est le perimetre dans lequel un modèle de donnees a un sens precis. "User" dans le contexte auth (login, password) n'est pas le meme "User" que dans le contexte facturation (adresse, moyen de paiement). Chaque microservice devrait correspondre a un bounded context. Voir l'article sur la decoupe.
C
Choreography (Choregraphie)
Un pattern de coordination ou les services reagissent aux événements des autres services sans coordinateur central. Le service "commandes" publie "commande créée", le service "stock" écoûte et reserve les produits, le service "email" écoûte et envoie la confirmation. Pas de chef d'orchestre, chaque service sait ce qu'il doit faire.
Circuit Breaker
Un pattern de resilience qui coupe les appels vers un service defaillant. Comme un disjoncteur electrique : apres N échecs, le circuit "s'ouvre" et les appels suivants echouent immédiatement sans contacter le service. Apres un delai, il teste a nouveau. Ca empeche une defaillance de se propager.
CQRS (Command Query Responsibility Segregation)
La séparation des opérations de lecture et d'écriture en deux modèles distincts. Les commandes (write) passent par un modèle optimise pour la validation et la persistence. Les queries (read) passent par un modèle optimise pour l'affichage. Utile quand les patterns de lecture et d'écriture sont tres différents.
D
Database per Service
Le principe selon lequel chaque microservice a sa propre base de donnees. Pas de requêtes SQL entre services, pas de tables partagees. Si le service A a besoin de donnees du service B, il fait un appel API ou écoûte des événements. C'est le prix de l'independance. Voir l'article sur les erreurs.
Distributed Monolith (Monolithe distribue)
Le pire des deux mondes. Tu as 10 "microservices" mais ils ne peuvent pas etre déployés indépendamment, partagent la meme base de donnees, et chaque changement en cascade sur les autres. C'est un monolithe avec de la latence réseau en plus. Voir erreur 7.
Distributed Tracing
La capacité de suivre une requête à travers plusieurs services. Un ID unique est propage d'un service a l'autre. Jaeger, Zipkin et OpenTelemetry permettent de visualiser le chemin complet d'une requête, les latences par service, et ou ca bloque.
E
Event Sourcing
Un pattern ou l'état d'une entité est stocke sous forme de sequence d'événements plutot que sous forme d'état courant. Au lieu de UPDATE orders SET status = 'paid', tu stockes l'événement OrderPaid { orderId, amount, date }. L'état actuel est reconstruit en rejouant les événements. Complexe mais puissant pour l'auditabilite.
Event-Driven (Architecture evenementielle)
Une architecture ou les services communiquent par événements asynchrones plutot que par appels directs. Le service A publie un événement sur un message broker, les services interesses le consomment. Voir l'article sur la communication.
Eventual Consistency (Coherence a terme)
Le fait que les donnees entre services ne sont pas immédiatement synchronisees. Apres un événement "commande créée", le service stock met à jour ses donnees... quelques millisecondes ou secondes plus tard. Le système converge vers un état coherent, mais pas instantanement.
F
Fault Isolation (Isolation des pannes)
La capacité d'un système a contenir une panne dans un seul service sans affecter les autres. Si le service "recommandations" tombe, le service "commandes" continue de fonctionner. C'est un des avantages principaux des microservices par rapport au monolithe.
H
Health Check
Un endpoint (/health ou /healthz) qui indique si un service est operationnel. Le load balancer ou l'orchestrateur interroge ce endpoint régulièrement. Si un service ne répond plus, le trafic est redirige vers les instances saines. Voir aussi le health check gRPC.
I
Idempotency (Idempotence)
La propriété d'une opération qui produit le meme résultat si elle est exécutée plusieurs fois. En microservices, les messages peuvent etre delivres en double. Si le handler "créer commande" est idempotent (il vérifié si la commande existe deja), le doublon ne pose pas de problème.
M
Message Broker
Un intermediaire qui recoit, stocke et distribue les messages entre services. RabbitMQ, Kafka, NATS, Redis Streams sont des message brokers. Le producteur publie un message, le broker le garde, le consommateur le lit quand il est pret. Ca découplé les services dans le temps.
Microservice
Un service autonome qui implemente une capacité métier precise, avec sa propre base de donnees et son propre cycle de déploiement. Il communique avec les autres services via des APIs ou des événements. Ni trop gros (monolithe), ni trop petit (nano-service). Voir l'introduction de la serie.
Monolith (Monolithe)
Une application ou tout le code tourne dans un seul processus et se deploie en une seule unité. C'est le point de depart normal. Un monolithe bien structure (modulaire) est souvent préférable a des microservices mal decoupes. Voir l'article sur les erreurs et le cas paltemps.fr.
O
Orchestration
Un pattern de coordination ou un service central (l'orchestrateur) dirige le workflow. Il appelle les services dans l'ordre, gere les erreurs et les compensations. L'inverse de la choregraphie. Plus facile a comprendre et a debugger, mais l'orchestrateur est un point de couplage.
S
Saga
Un pattern pour gerer les transactions qui traversent plusieurs services. Comme il n'y a pas de transaction distribuee (pas de COMMIT global), une saga exécuté une sequence d'étapes locales. Si une étape echoue, les étapes précédentes sont "compensees" (annulees). Exemple : reservation du stock, puis paiement. Si le paiement echoue, on libéré le stock.
Service Discovery
Le mecanisme par lequel un service trouve l'adresse des autres services. Au lieu de coder en dur http://user-service:3000, un registre (Consul, etcd, DNS interne Kubernetes) maintient la liste des services et leurs adresses. Quand un service démarré ou s'arrêté, le registre se met à jour.
Service Mesh
Une couche d'infrastructure qui gere la communication entre services de facon transparente. Chaque service a un proxy sidecar (Envoy, Linkerd) qui intercepte le trafic et ajoute le mTLS, le load balancing, le circuit breaking, le tracing. Le code applicatif n'a pas besoin de gerer tout ca.
Sidecar
Un container qui tourne a cote de ton service et lui ajoute des fonctionnalités : proxy réseau, collecte de logs, monitoring. Dans un service mesh, le sidecar (souvent Envoy) intercepte tout le trafic entrant et sortant du service. Ton code ne sait meme pas qu'il est la.
Strangler Fig Pattern
Une stratégie de migration progressive d'un monolithe vers des microservices. Tu extrais un service a la fois, en routant le trafic vers le nouveau service. Le monolithe retrecit progressivement, comme un arbre etouffe par un figuier. C'est l'approche la plus sure pour migrer sans big bang.
Sources
- Sam Newman - Building Microservices, 2nd édition -- la référencé sur les microservices
- Martin Fowler - Microservices Resource Guide -- collection d'articles et patterns
- Chris Richardson - Microservices Patterns -- catalogue de patterns avec exemples
Retrouve d'autres articles techniques sur paltemps.fr.
Article précédent : 05 - Les 7 erreurs classiques
Début de la serie : 00 - Introduction