Les modèles de conception des microservices servent de stratégies pour créer des logiciels en utilisant l'architecture des microservices, une approche qui décompose les applications individuelles en composants ou services plus petits.
Ces modèles d'architecture fournissent des solutions standardisées aux défis quotidiens auxquels les équipes de développement sont confrontées lors de la mise en œuvre de systèmes informatiques distribués, notamment la communication des services, la cohérence des données, la tolérance aux pannes et l'évolutivité du système.
La plupart des expériences en ligne sur lesquelles repose le monde sont rendues possibles grâce à des modèles de conception de microservices et peuvent être observées dans de nombreux cas d’utilisation. Par exemple, si vous regardez une émission en streaming sur Netflix, vous faites appel à des centaines de services distincts qui travaillent ensemble pour fournir du contenu, gérer les profils des utilisateurs et suggérer ce qu'il faut regarder ensuite.
De même, Amazon coordonne les stocks, les paiements et l’expédition par le biais de services distincts. Dans le secteur financier, les banques et autres institutions s'appuient également sur des modèles de conception de microservices pour séparer la gestion des risques et les services client, en gardant l'argent sécurisé et accessible.
Selon l’enquête IBM, Microservices dans l’entreprise, 2021, 88 % des entreprises déclarent que les microservices offrent de nombreux avantages aux équipes de développement. Ces avantages incluent une augmentation de 20 à 50 % de la productivité des développeurs grâce à une meilleure organisation du code, une maintenance plus facile et des cycles de déploiement plus rapides.
Restez au fait des tendances les plus étonnantes du secteur dans le domaine de l’IA, de l’automatisation, des données et bien d’autres avec la newsletter Think. Consultez la Déclaration de confidentialité d’IBM.
L'architecture microservice est une méthode cloud natif qui décompose les applications en services indépendants et faiblement couplés, déployés dans des conteneurs gérés par des plateformes d'orchestration comme Kubernetes.
Chaque service fonctionne de manière indépendante avec sa propre pile technologique, y compris des bases de données dédiées et des modèles de gestion des données. La communication entre les services s’effectue par le biais d'API REST, de plateformes de streaming d’événements, comme Apache Kafka, et de courtiers de messages, tandis que les équipes conçoivent des services autour de fonctionnalités métier avec des limites claires appelées contextes délimités.
Cette approche moderne du développement de logiciels prend en charge la flexibilité opérationnelle requise pour les initiatives de transformation numérique modernes, comme l’automatisation DevOps et les pipelines CI/CD, la migration vers le cloud, la modernisation des applications et l’intégration de l'intelligence artificielle (IA).
Bien que les microservices offrent des avantages significatifs pour les applications modernes, pour comprendre quand choisir cette architecture, il faut la comparer aux approches traditionnelles monolithiques.
L'architecture monolithique conçoit une application comme une unité unique et déployable où toutes les fonctions commerciales sont intégrées et partagent le même code, la même base de données et le même environnement d’exécution. L'architecture de microservices décompose une application en services indépendants plus petits qui communiquent via des interfaces de programmation d’application (API), chacun possédant potentiellement sa propre base de données et son propre cycle de déploiement.
La principale différence entre ces méthodes de conception est le couplage, c’est-à-dire le degré de connexion entre les différentes parties du système. Les monolithes ont un couplage interne élevé mais un déploiement simple, tandis que les microservices ont un couplage lâche entre les services mais des exigences d'infrastructure informatique plus complexes.
Les ingénieurs logiciels choisissent souvent une architecture monolithique pour des applications plus petites et plus simples, par exemple pour les petites entreprises ou les start-ups qui cherchent à contrôler les coûts et à accélérer le développement. Dans les scénarios complexes qui nécessitent une évolutivité, une résilience et une flexibilité élevées (par exemple, les plateformes de médias sociaux, les applications bancaires), les microservices sont le meilleur choix.
Lorsqu'elles décident de l'approche à adopter, les entreprises doivent évaluer chacune d'elles en fonction de leurs besoins spécifiques, notamment la taille de l'équipe, la complexité de l'application, les besoins d'évolutivité et les niveaux de maturité DevOps.
En savoir plus sur l'architecture monolithique par rapport aux microservices.
Les modèles de conception de microservices se répartissent en cinq domaines clés qui offrent des solutions éprouvées pour aider les équipes à relever les défis de l'architecture distribuée :
Modèle de registre de service
Le modèle de registre de service crée un répertoire central où les services enregistrent leurs points de terminaison et leur état de santé, éliminant ainsi le besoin d'adresses fixes. Lorsque les services ont besoin de communiquer, ils consultent le registre pour trouver les instances de serveur disponibles. Par exemple, lorsqu'un service de paiement doit contacter un service de stock, il consulte le registre pour localiser les instances de stock saines.
Modèle de API Gateway
Un modèle de API Gateway crée un point d’entrée unique entre les clients et plusieurs microservices dorsaux. Au lieu que les clients fassent des appels distincts à différents services, l'API Gateway reçoit une seule requête, la route vers les microservices appropriés et combine les réponses en un seul résultat.
Par exemple, lors du chargement d'une page produit, la passerelle peut simultanément récupérer les détails du produit, la tarification, le stock et les avis de différents services. Il renvoie ensuite toutes ces informations au client dans une réponse unique et consolidée.
Modèles de découverte de services
Un modèle de découverte de services résout le problème de la localisation des services dans des environnements dynamiques. Au fur et à mesure que les microservices évoluent ou sont mis à jour vers une nouvelle version, leurs emplacements réseau changent constamment. Les modèles de découverte de services fournissent des mécanismes automatisés permettant aux services de s'enregistrer et de trouver d'autres services avec lesquels ils doivent communiquer, ce qui élimine la nécessité d'utiliser des adresses codées en dur.
Modèle de base de données par service
Le modèle de base de données par service garantit que chaque microservice possède et gère sa propre base de données, éliminant ainsi les dépendances entre les données partagées entre les services. Cette approche empêche l'accès direct aux données entre les services et réduit le couplage, bien qu'elle oblige les services à communiquer par le biais d'API lorsqu'ils ont besoin d'informations provenant d'autres sources d'information. Par exemple, dans un système de planification des ressources d'entreprise (ERP) , le service de comptabilité gère les données financières indépendamment de la base de données des employés du service RH.
Modèle Saga
Un modèle saga gère les transactions qui s’étendent sur plusieurs microservices en les divisant en étapes coordonnées. Chaque service termine sa transaction locale et déclenche l'étape suivante dans la chaîne. Si une étape échoue, le modèle exécute automatiquement des actions pour annuler les étapes précédentes. Par exemple, lors du traitement d'une commande en ligne, si le paiement échoue après la réservation du stock, la saga libère automatiquement les articles réservés.
CQRS (modèle de ségrégation de responsabilité de requête de commande)
Le modèle CQRS sépare la modification des données (commandes) de la récupération des données (requêtes) en utilisant des modèles dédiés pour chacune. Cette division permet au système d'optimiser chaque chemin indépendamment, en minimisant les conflits d'écriture côté commande et en réduisant la latence des requêtes côté lecture. Dans un système de commerce électronique, le passage d’une commande utilise le modèle de commande optimisé en écriture, tandis que la génération d’un rapport de vente utilise le modèle de requête optimisé en lecture.
Modèle de disjoncteur
Le modèle de disjoncteur empêche les défaillances dans un service de se propager à l’ensemble du système en surveillant les appels aux services en aval et en arrêtant les requêtes lorsque des défaillances sont détectées. Lorsqu’un service devient insensible, le disjoncteur « se déclenche » et bloque d’autres appels, ce qui protège les ressources du système et prévient les défaillances en cascade.
Par exemple, si un service de stock tombe en panne, le disjoncteur empêche le service de commande d'effectuer des demandes répétées et infructueuses. Cela permet au reste du système de continuer à fonctionner tout en fournissant des réponses de repli aux clients.
Modèle de cloisonnement
Le modèle de cloisonnement isole les ressources du système afin d'empêcher les défaillances dans un domaine d'affecter l'ensemble du système. À l'instar des compartiments dans la coque d'un navire, le cloisonnement sépare les différentes fonctions afin que, en cas de défaillance de l’une d’elles, les autres restent opérationnelles. Le modèle limite le nombre de demandes simultanées ou de ressources allouées à des services spécifiques.
Modèle services Backend pour le Frontend (BFF)
Le modèle de services Backend pour le Frontend (BFF) crée un service backend dédié adapté à chaque interface frontend. Étant donné que les applications mobiles ont des exigences différentes des applications Web (par exemple, des écrans plus petits, une bande passante limitée et des capacités de performance variables), le modèle BFF permet aux développeurs d'optimiser chaque backend pour son interface frontale.
Les modèles d’entité et d’agrégat
Un modèle d'entité et d'agrégat organise les données connexes en unités logiques basées sur les concepts de conception orientée domaine (DDD). Une entité représente un objet distinct doté d'une identité unique, comme un compte client identifié par une adresse e-mail. Un agrégat combine des entités connexes qui doivent être mises à jour ensemble, comme une seule unité.
Par exemple, dans un système de commerce électronique, un agrégat de commande comprend les détails de la commande, les articles et les informations relatives à l'expédition, qui doivent tous rester synchronisés en cas de modification.
Le modèle Strangler
Un modèle Strangler permet de gérer le processus de refactorisation d’une application monolithique en une architecture de microservices plus facile à entretenir. De nouveaux microservices sont progressivement créés parallèlement au monolithe existant, pour prendre progressivement les fonctionnalités jusqu'à ce que l'ancien système soit complètement remplacé. Le nom vient de la métaphore d’une vigne (les microservices) qui pousse progressivement autour d’un arbre (l’application monolithique) et finit par l’étrangler.
Modèle orienté événements
Le modèle orienté événement permet aux microservices de communiquer de façon asynchrone en publiant et en consommant des événements au lieu de faire des appels de service directs. Lorsqu'un service termine une action, il diffuse un événement que les autres services intéressés peuvent écouter et réagir en conséquence. Cette approche crée un couplage souple entre les services, ce qui leur permet de fonctionner de façon indépendante tout en coordonnant leurs activités à travers un système d'événements partagé.
Modèle sidecar
Un modèle sidecar fait référence au déploiement d'un conteneur secondaire (le sidecar) à côté d'une application ou d'un service principal au sein d’un même environnement d'exécution. Ce sidecar répond à des préoccupations transversales (par exemple, l'enregistrement, la surveillance, la sécurité, l' observabilité), en étendant les fonctionnalités de l'application principale sans modifier sa base de code.
Les modèles d’adaptateurs
Un modèle d'adaptateur de microservice permet la communication entre des systèmes ou des interfaces incompatibles. Tout comme un adaptateur de voyage vous permet de brancher votre appareil sur des prises étrangères, les modèles d'adaptateur convertissent entre les différents formats de données, protocoles ou API. Ce modèle est utile lors de l'intégration avec des systèmes d'héritage ou des services tiers qui utilisent des normes de communication différentes.
Les modèles de conception de microservices sont particulièrement utiles dans les secteurs qui exigent une grande évolutivité, une logique commerciale complexe et des performances de système fiables. Les principaux cas d’utilisation sont les suivants :
Les modèles de conception de microservices proposent les bonnes pratiques pour gérer les systèmes distribués complexes d'aujourd'hui et offrent ces nombreux avantages :
La sélection de modèles appropriés dépend des exigences spécifiques de votre système et des capacités de votre organisation. L’utilisation d’une approche systématique peut guider ces décisions architecturales.
Commencez par l'API gateway et la découverte de services avant d’implémenter des modèles complexes tels que l’approvisionnement en événements ou le CQRS. Ces modèles de base établissent l'infrastructure de communication nécessaire à des mises en œuvre plus sophistiquées.
Prenez en compte votre expérience des systèmes distribués, votre maturité opérationnelle et vos pratiques DevOps. Les équipes nouvelles en microservices bénéficient initialement d'un modèle plus simple, tandis que les équipes expérimentées peuvent adopter des modèles de coordination plus avancés qui nécessitent des connaissances opérationnelles plus approfondies.
Chaque modèle introduit une complexité que votre équipe doit gérer à long terme. Une base de données par service nécessite des stratégies de synchronisation des données. Les modèles pilotés par les événements ont besoin d’une infrastructure de courtage de messages. Assurez-vous d’avoir la capacité nécessaire pour prendre en charge les modèles choisis.
Commencez par quelques services à l’aide de modèles de base, acquérez de l’expérience, puis élargissez votre expertise au fur et à mesure que votre expertise se développe. Cette approche progressive permet d'éviter une ingénierie excessive et de tirer des enseignements des premières mises en œuvre.
Exploitez le pouvoir de l’IA et de l’automatisation pour résoudre de manière proactive les problèmes de la pile d’applications.
Utilisez les logiciels et outils DevOps pour construire, déployer et gérer des applications cloud natives sur plusieurs appareils et environnements.
Renforcez l’agilité et la croissance de votre entreprise. Modernisez en continu vos applications sur n’importe quelle plateforme grâce à nos services de conseil cloud.