“One thing most software architects fail to realize is that a software architect is also a leader.” — Richard Monson-Haefel

Les schémas de conception de microservices sont un ensemble de principes et de meilleures pratiques utilisés pour développer et maintenir des systèmes logiciels composés de petits services indépendamment déployables. Dans cet article, nous discuterons des 5 schémas de conception de microservices importants qui peuvent être utilisés pour créer des architectures de microservices robustes et efficaces.

Passerelle d'API (API Gateway) :

L'une des premières techniques abordées est la Passerelle d'API (API Gateway), qui agit comme une interface pour les microservices. Elle reçoit les demandes des clients et les dirige vers le service approprié. Cette passerelle permet également de gérer des fonctions telles que la limitation de débit, la mise en cache et l'authentification.

La Passerelle d'API (API Gateway) peut également effectuer d'autres fonctions telles que la limitation du débit, la mise en cache et l'authentification. Par exemple, elle peut limiter le nombre de demandes qu'un client peut faire à un service dans un laps de temps donné. Elle peut également mettre en cache les réponses des services pour réduire la charge sur les services sous-jacents.

Circuit Breaker

Le schéma du Circuit Broker est une méthode pour détecter les échecs dans un système distribué et éviter ainsi les défaillances en cascade. Il peut "couper" le flux de trafic vers un service en échec pour éviter de surcharger le système et rediriger le trafic vers des composants de secours.

Le schéma du Circuit Broker fonctionne en surveillant l'état d'un composant du système et en agissant lorsqu'il détecte une défaillance. Le disjoncteur possède trois états : fermé, ouvert et mi-ouvert.

État fermé : Dans l'état fermé, le disjoncteur permet au trafic de circuler normalement vers le composant du système. Le disjoncteur surveille les temps de réponse et les taux d'erreur du composant du système.

État ouvert : Si le circuit Broker détecte une défaillance du composant du système, il se déclenche et passe à l'état ouvert. Dans l'état ouvert, le disjoncteur arrête tout le trafic vers le composant du système et redirige le trafic vers un composant de secours ou renvoie un message d'erreur au client.

État mi-ouvert : Après un certain laps de temps, le circuit broker passe à l'état mi-ouvert. Dans l'état mi-ouvert, le disjoncteur permet à un flux limité de trafic de circuler vers le composant du système. Si le composant du système répond avec succès au trafic, le Circuit Broker revient à l'état fermé. Si le composant du système ne parvient pas à répondre avec succès, le disjoncteur retourne à l'état ouvert.

CQRS (Command Query Responsibility Segregation)

Le modèle CQRS sépare les opérations de lecture et d'écriture dans des modèles distincts. Le modèle de commande gère les opérations d'écriture et la mise à jour de l'état du système, tandis que le modèle de requête gère les opérations de lecture et renvoie les données au client. Cela permet une meilleure évolutivité et des performances optimisées pour les opérations de lecture.

Lorsqu'un client envoie une commande au système, elle est traitée par le modèle de commande. Le modèle de commande traite la commande et met à jour l'état du système. Si la commande réussit, elle renvoie un message de réussite au client.

Lorsqu'un client envoie une requête au système, elle est traitée par le modèle de requête. Le modèle de requête récupère les données du système et les renvoie au client. Le modèle de requête peut être optimisé pour les opérations de lecture, ce qui peut améliorer les performances du système.

Event Sourcing

Le Event sourcing consiste à stocker une séquence d'événements qui décrivent les changements d'état d'une application. Au lieu de stocker l'état actuel, le système stocke ces événements, ce qui permet de reconstruire l'état actuel de l'application en rejouant les événements dans l'ordre.

Le schéma du Event sourcing fonctionne en stockant une séquence d'événements qui décrivent les modifications de l'état d'une application. Chaque événement est stocké sous la forme d'un enregistrement distinct dans un magasin d'événements, qui est une base de données optimisée pour stocker un grand nombre d'événements.

Lorsqu'un utilisateur interagit avec le système, le système génère un événement qui décrit l'action de l'utilisateur. Par exemple, si un utilisateur passe une commande, le système générerait un événement décrivant les détails de la commande. L'événement serait stocké dans le magasin d'événements, et le système mettrait à jour l'état de l'application en fonction de l'événement.

Lorsque l'état de l'application doit être interrogé, le système lit tous les événements du magasin d'événements et les applique en séquence pour reconstruire l'état actuel de l'application. Ce processus est appelé rejeu d'événements.

Saga Pattern

Le schéma de la saga est utilisé pour maintenir la cohérence entre plusieurs transactions impliquant plusieurs services dans un système distribué. Il divise une transaction en transactions plus petites, appelées transactions compensatoires, qui sont exécutées dans un ordre spécifique pour annuler les effets de la transaction précédente en cas d'erreur.

Dans un système distribué, il est courant qu'une seule transaction implique plusieurs services. Par exemple, dans un système de e-commerce, une seule commande peut nécessiter des mises à jour du service de gestion des stocks, du service de paiement et du service d'expédition. Si l'un de ces services échoue, cela peut entraîner des incohérences dans les données. Le schéma de la saga contribue à garantir que la transaction est menée à bien ou annulée en cas d'erreurs.

En conclusion, les schémas de conception de microservices offrent des avantages considérables pour la création de systèmes logiciels flexibles, évolutifs et résilients. Cependant, il est important de choisir les schémas appropriés en fonction des besoins spécifiques de chaque application et de tenir compte des contraintes techniques et de l'expertise de l'équipe de développement.