Quels sont les modèles de conception de microservice ?

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.

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 :

1. Communication et découverte de services
2. Gestion des données et des transactions
3. Résilience et traitement des défaillances
4. Architecture et intégration
5. Événement et communication

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 plateformes de commerce électronique s'appuient sur des modèles de conception de microservices pour gérer l'équilibrage de charge lors des événements de vente et gérer les stocks complexes dans plusieurs entrepôts. Ils coordonnent également les opérations de paiement, d'expédition et de service client sur différents systèmes afin d'améliorer les résultats commerciaux et l'expérience client.
• Les services de streaming utilisent des modèles de microservices pour diffuser du contenu dans le monde entier tout en gérant les préférences et les recommandations des utilisateurs, ce qui leur permet de gérer des charges d'utilisateurs simultanées massives avec un minimum de mise en mémoire tampon et des expériences personnalisées.
• Les services financiers mettent en œuvre ces modèles pour séparer les opérations de négociation, de gestion des risques, d'authentification et de contact avec les clients tout en maintenant une conformité réglementaire stricte et des normes de sécurité requises par les institutions financières.
• Les systèmes de santé utilisent ces modèles pour intégrer les dossiers des patients, la prise de rendez-vous et les systèmes de facturation tout en maintenant la conformité HIPAA et en se connectant à diverses API d'appareils médicaux de différents professionnels de santé.
• Les plateformes de médias sociaux utilisent des modèles de conception de microservice pour dimensionner la messagerie, les flux de contenu et le traitement des médias indépendamment, ce qui leur permet de gérer des milliards d’interactions quotidiennes avec les utilisateurs tout en maintenant des performances réactives sur toutes les fonctionnalités.

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 :

• Réduction de la complexité : des approches normalisées et testées pour répondre à des défis communs permettent d'obtenir des résultats plus prévisibles, de faciliter le dépannage et d'accélérer l'intégration de l'équipe.
• Agilité et délais de mise sur le marché plus rapides : les équipes peuvent développer, déployer et faire évoluer des services de manière indépendante, réduisant ainsi les problèmes de coordination et accélérant la fourniture de fonctionnalités.
• Tolérance accrue aux pannes : les techniques d'isolation empêchent les défaillances de se répercuter en cascade sur l'ensemble du système, ce qui réduit considérablement les temps d'arrêt et améliore la fiabilité globale du système.
• Amélioration de l'évolutivité et de la flexibilité : les entreprises peuvent allouer des ressources précisément là où elles sont nécessaires et s'adapter rapidement à l'évolution des besoins de l'entreprise sans devoir procéder à des révisions majeures du système. Les équipes peuvent développer des services dans différents langages de programmation, tels que Java™ ou Python, en fonction de besoins spécifiques.
• Rentabilité : une mise à l'échelle ciblée et une optimisation des Ressources, associées à la possibilité de choisir les piles optimales pour des services spécifiques, permettent de créer des systèmes plus économiques.
• Diversité technologique : les équipes peuvent sélectionner les meilleurs outils et cadres des exigences pour les exigences spécifiques de chaque service, ce qui permet d'obtenir des solutions plus efficaces et plus faciles à maintenir. Par exemple, vous pouvez sélectionner Java Spring Boot pour les microservices pour base de données en tant que service (DBaaS) ou Python pour l’analytique.

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.