Architecture de microservices : de nombreux petits services, un seul système
Architecture de microservices sur un canevas interactif : la couche client, la passerelle API, les services déployés indépendamment, la messagerie, les magasins de données par service et l'observabilité.
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 : de nombreux petits services, un seul système
Le canevas FlowJam 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 ce visuel
- Lisez d'abord la colonne de gauche de haut en bas : clients vers la passerelle vers les services. C'est le chemin de la demande.
- Suivez les flèches de chaque service : vers le bus de messages, vers sa propre base de données et vers l'observabilité.
- Les bandes de droite représentent l'infrastructure partagée du système (messagerie, données et observabilité), c'est pourquoi chaque service y pointe.
Le chemin de la requête
Les « clients Web et mobiles » démarrent le flux, et les « routages et agrégats de passerelle API » constituent le point d'entrée unique : acheminer chaque requête vers le bon service, gérer l'authentification et, souvent, rassembler les réponses de plusieurs services. La passerelle est le seul composant que chaque client voit, c'est pourquoi elle se situe entre la couche client et les services.
Les prestations
Le « Service des commandes », le « Service des utilisateurs » et le « Service des paiements » sont les unités déployées indépendamment. Chacun appartient à sa propre équipe et expédie à sa propre cadence. Le visuel connecte chaque service au bus de messages (les services communiquent par événements plutôt que par appels directs) et à sa propre base de données, car posséder ses données est ce qui rend un service déployable de manière indépendante.
L'infrastructure partagée
"Le bus de messages découple les services" permet à un service de publier un événement sans savoir qui le consomme. "Chaque service possède sa propre base de données" est la règle qui empêche le couplage à état partagé. « Les métriques, les journaux et les traces alimentent une seule vue » est l'observabilité qui rend un système composé de nombreux services opérationnel : sans cela, une défaillance est invisible au-delà des frontières. Ces trois bandes constituent le prix et la récompense de l'architecture.
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
Renommez les services sur votre système
Remplacez les commandes, les utilisateurs et les paiements par vos services réels et ajoutez ceux que les trois génériques manquent, chacun comme sa propre case dans la bande Services.
Nommez les sujets de vos messages
Annotez le bus de messages avec les événements réels que vos services publient et auxquels vous souscrivez, afin que le découplage soit concret plutôt qu'affirmé.
Cartographier la propriété des données
À la limite de chaque service par rapport à sa base de données, notez le magasin réel (PostgreSQL, un cache, un index de recherche) et ce qu'il possède, pour vérifier que la règle d'une base de données par service est respectée.
Ajouter les branches d'échec et de mise à l'échelle
Insérez les chemins réels (nouvelle tentative d'un service et disjoncteur sur le bus, réplique évolutive d'un service actif), chacun se terminant par un état explicite.
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 ce visuel dans QueryChart (FlowJam)
Ouvrez ce canevas de microservices exact en tant que votre propre graphique, renommez les services de votre système et cartographiez vos véritables limites.