Identifier les limites des microservices
Les architectes et les développeurs luttent pour définir la taille correcte d’un microservice. Les conseils mettent souvent l’accent sur l’évitement des extrêmes trop grands ou trop petits, mais ces conseils peuvent être vagues dans la pratique. Toutefois, si vous commencez à partir d’un modèle de domaine soigneusement conçu, vous pouvez définir plus facilement la taille et l’étendue correctes de chaque microservice.
Cet article utilise un service de livraison de drone comme exemple en cours d’exécution. Vous pouvez en savoir plus sur le scénario et l’implémentation de référence correspondante ici.
Du modèle de domaine aux microservices
Dans l’article précédent, nous avons défini un ensemble de contextes délimités pour une application Drone Delivery. Ensuite, nous avons examiné plus étroitement l’un de ces contextes délimités, le contexte englobant expédition et identifié un ensemble d’entités, d’agrégats et de services de domaine pour ce contexte limité.
Nous sommes maintenant prêts à passer du modèle de domaine à la conception d’application. Voici une approche que vous pouvez utiliser pour dériver des microservices du modèle de domaine.
Commencez par un contexte limité. En général, les fonctionnalités d’un microservice ne doivent pas s’étendre sur plusieurs contextes délimités. Par définition, un contexte délimité marque la limite d’un modèle de domaine spécifique. Si vous constatez qu’un microservice combine différents modèles de domaine ensemble, vous devrez peut-être revenir en arrière et affiner votre analyse de domaine.
Ensuite, examinez les agrégats dans votre modèle de domaine. Les agrégats sont souvent de bons candidats pour les microservices. Un agrégat bien conçu présente de nombreuses caractéristiques d’un microservice bien conçu :
- Un agrégat est dérivé des exigences métier, plutôt que des préoccupations techniques telles que l’accès aux données ou la messagerie.
- Un agrégat devrait avoir une cohésion fonctionnelle élevée.
- Un agrégat est une limite de persistance.
- Les agrégats doivent être faiblement couplés.
Les services de domaine sont également de bons candidats pour les microservices. Les services de domaine sont des opérations sans état sur plusieurs agrégats. Un exemple classique est un flux de travail qui comprend plusieurs microservices. L’application Drone Delivery montre un exemple.
Tenez compte des exigences non fonctionnelles. Examinez des facteurs tels que la taille de l’équipe, les types de données, les technologies, les exigences de scalabilité, les exigences de disponibilité et les exigences de sécurité. Ces facteurs peuvent entraîner la rupture d’un microservice en plusieurs services plus petits. Dans d’autres cas, ils peuvent vous amener à fusionner plusieurs microservices en un seul microservice.
Après avoir identifié les microservices dans votre application, validez votre conception par rapport aux critères suivants :
Chaque service a une responsabilité unique.
Il n’y a pas d’appels bavards entre les services. Si le fractionnement des fonctionnalités en deux services les amène à être trop bavards, il peut s’agir d’un symptôme que ces fonctions appartiennent au même service.
Chaque service est suffisamment petit pour qu’il puisse être créé par une petite équipe travaillant indépendamment.
Il n’y a pas d’interdépendances qui nécessitent le déploiement de deux services ou plus ensemble. Chaque service doit être déployé indépendamment, sans avoir à redéployer d’autres personnes.
Les services ne sont pas étroitement couplés et peuvent évoluer indépendamment.
Les limites de service sont conçues pour éviter les problèmes de cohérence ou d’intégrité des données. Dans certains cas, la maintenance de la cohérence des données signifie regrouper les fonctionnalités associées en un seul microservice. Toutefois, la cohérence forte n’est pas toujours nécessaire. Les systèmes distribués fournissent des stratégies de gestion de la cohérence éventuelle, et les avantages de la décomposition des services l’emportent souvent sur la complexité de la gestion.
Surtout, il est important d’être pragmatique et de se rappeler que la conception pilotée par le domaine est un processus itératif. En cas de doute, commencez par des microservices plus grossières. Le fractionnement d’un microservice en deux services plus petits est plus facile que la refactorisation des fonctionnalités sur plusieurs microservices existants.
Exemple : Définition de microservices pour l’application Drone Delivery
L’équipe de développement a précédemment identifié les quatre agrégats, Livraison, Package, Drone et Account, et deux services de domaine, Scheduler et Superviseur.
La livraison et le package sont des candidats évidents pour les microservices. Le planificateur et le superviseur coordonnent les activités effectuées par d’autres microservices. Il est donc judicieux d’implémenter ces services de domaine en tant que microservices.
Drone et Account sont intéressants parce qu’ils appartiennent à d’autres contextes délimités. L’une des options est que le planificateur appelle directement les contextes délimités drone et compte. Une autre option consiste à créer des microservices drone et compte à l’intérieur du contexte englobant expédition. Ces microservices médiatraient entre les contextes délimités, en exposant des API ou des schémas de données plus adaptés au contexte d’expédition.
Les détails des contextes délimités drone et compte dépassent le cadre de ces conseils. Nous avons donc créé des services fictifs pour eux dans notre implémentation de référence. Mais voici quelques facteurs à prendre en compte dans cette situation :
Quelle est la surcharge réseau de l’appel directement dans l’autre contexte limité ?
Le schéma de données pour l’autre contexte délimité convient-il à ce contexte, ou est-il préférable d’avoir un schéma adapté à ce contexte délimité ?
L’autre contexte limité est-il un système hérité ? Si c’est le cas, vous pouvez créer un service qui agit comme une couche anti-corruption pour traduire entre le système hérité et l’application moderne.
Qu’est-ce que la structure d’équipe ? Est-il facile de communiquer avec l’équipe responsable de l’autre contexte limité ? Si ce n’est pas le cas, la création d’un service qui communique entre les deux contextes peut contribuer à atténuer le coût de la communication entre les équipes.
Jusqu’à présent, l’équipe n’a pas pris en compte les exigences non fonctionnelles. Après avoir évalué les besoins en débit de l’application, l’équipe de développement crée un microservice d’ingestion distinct pour gérer les demandes du client. Ce microservice implémente le nivellement de charge en plaçant les requêtes entrantes dans une mémoire tampon pour le traitement. Le planificateur lit ensuite les requêtes de la mémoire tampon et implémente le flux de travail.
Les exigences non fonctionnelles mènent également l’équipe à créer un service supplémentaire. Les services existants se concentrent sur la planification et la livraison de packages en temps réel. Toutefois, le système doit également stocker l’historique de livraison dans le stockage à long terme pour l’analyse des données. Au départ, l’équipe a envisagé de faire partie de cette tâche du service de livraison. Toutefois, les exigences de stockage des données pour l’analyse historique diffèrent des exigences en matière d’opérations en cours d’exécution. Pour plus d’informations, consultez Considérations relatives aux données. Par conséquent, l’équipe a créé un service d’historique de livraison distinct. Ce service écoute les événements DeliveryTracking du service de livraison et les écrit dans le stockage à long terme.
Le diagramme suivant illustre la conception à ce stade :
Téléchargez un fichier Visio de cette architecture.
Étapes suivantes
À ce stade, vous devez avoir une compréhension claire de l’objectif et des fonctionnalités de chaque microservice dans votre conception. Vous pouvez maintenant concevoir le système.