Architecture de microservices · Cartes mentales
Architecture de microservices. Une carte mentale modifiable avec des branches colorées, des idées secondaires et des liens. Les courbes montrent les liens; les flèches indiquent les relations où le sens compte.
Les microservices sont une architecture dans laquelle une application est construite à partir de nombreux petits services déployés indépendamment, chacun possédant ses propres données, coordonnées via une passerelle API et une messagerie plutôt que via un état partagé.
Architecture de microservices · Cartes mentales
Le canevas MindMap interactif de cette explication : chaque couloir, ligne et flèche ci-dessus appartient à un véritable diagramme QueryChart que vous pouvez ouvrir et modifier.
Comment lire cette carte mentale
- Commencez par le sujet central, puis suivez une branche colorée pour explorer ses idées.
- Les courbes montrent les liens; les flèches indiquent les relations où le sens compte.
Clients & gateway
Cette branche rassemble “Web and mobile clients”, “The gateway is the single entry point: it routes each request to the right service, handles authentication and often aggregates responses from several services.”.
Independent services
Cette branche rassemble “Orders service”, “Payments service”, “Teams deploy and scale services independently”, “Users service”.
Messaging
Cette branche rassemble “Services communicate by publishing events rather than calling each other directly — so one service's change or outage never blocks another.”.
Owned data
Cette branche rassemble “The defining rule of microservices: no shared schema. Each service's data is private to it, which is what allows teams to deploy independently.”.
Observability
Cette branche rassemble “Metrics, logs and traces feed one view”.
Liens entre les branches
Chaque service est déployable indépendamment : la propriété que tout le reste de l'architecture existe pour protéger.
Les services communiquent via le bus de messages et possèdent leurs propres bases de données ; l’état partagé est l’anti-modèle.
La passerelle API est la porte d'entrée unique du système ; les clients ne parlent jamais directement aux services.
L'indépendance doit être payée par l'observabilité : de nombreux services ne sont gérables que lorsqu'une seule vue les couvre tous.
Les microservices orchestrent les packages Docker des conteneurs : les deux visuels se connectent.
Relations et enseignements clés
- Chaque service est déployable indépendamment : la propriété que tout le reste de l'architecture existe pour protéger.
- Les services communiquent via le bus de messages et possèdent leurs propres bases de données ; l’état partagé est l’anti-modèle.
- La passerelle API est la porte d'entrée unique du système ; les clients ne parlent jamais directement aux services.
- L'indépendance doit être payée par l'observabilité : de nombreux services ne sont gérables que lorsqu'une seule vue les couvre tous.
- Les microservices orchestrent les packages Docker des conteneurs : les deux visuels se connectent.
Quand utiliser ce visuel
- Enseigner à une équipe pourquoi les microservices existent et quels sont réellement les compromis avant de les adopter.
- Documenter les limites des services d'un système existant, les sujets des messages et la propriété des données pour l'intégration.
- Audit des anti-modèles : une base de données partagée ou un service appelant directement un autre service est une fuite de limite.
Comment cela fonctionne
Adapter le sujet central
Renommez le sujet pour votre projet ou votre cours.
Développer les branches
Modifiez les idées et ajoutez des exemples ou des notes.
Relier les idées
Reliez les branches; utilisez une flèche lorsque le sens est important.
Questions fréquentes
Qu’est-ce que l’architecture des microservices ?
Il s'agit d'un style architectural dans lequel une application est construite à partir de nombreux petits services, chacun responsable d'une fonctionnalité métier, déployés indépendamment et possédant leurs propres données. Les services communiquent sur un réseau (généralement HTTP et un bus de messages) plutôt que de partager de la mémoire ou une base de données. Les avantages sont une déployabilité indépendante et l'autonomie de l'équipe ; les coûts sont la complexité du réseau et le besoin d’observabilité.
Pourquoi chaque microservice possède-t-il sa propre base de données ?
Parce que les données partagées sont le couplage qui rompt le déploiement indépendant. Si deux services lisent et écrivent la même table, ils ne peuvent pas modifier leur schéma, évoluer ou déployer sans coordination. Posséder son propre magasin de données est ce qui permet à un service d'évoluer et d'évoluer selon son propre calendrier : la règle "Chaque service possède sa propre base de données" dans le visuel s'applique.
Quel est le rôle de la passerelle API dans les microservices ?
La passerelle est le point d'entrée unique du système. Il achemine les requêtes vers le bon service, gère les problèmes transversaux tels que l'authentification et la limitation du débit, et peut regrouper les réponses de plusieurs services en un seul. Les clients communiquent avec la passerelle, jamais directement avec des services individuels, ce qui permet à la topologie du service de changer librement.
Quand ne devriez-vous PAS utiliser de microservices ?
Lorsque le système est petit ou que l’équipe est petite. Les microservices échangent la complexité architecturale (pannes de réseau, transactions distribuées, observabilité) contre une déployabilité indépendante, et cet échange ne porte ses fruits qu'une fois qu'une équipe est suffisamment grande pour que la déployabilité indépendante soit la contrainte contraignante. Les problèmes de nombreuses équipes sont résolus par un monolithe bien modularisé, qui fait l'objet du visuel d'architecture monolithique.
Modifier cette carte mentale dans QueryChart
Ouvrez cette carte mentale sur un espace modifiable. Déplacez les idées et ajoutez des branches et des liens.