Dans le contexte de l'architecture des microservices, le terme « Microservices Saga » fait référence à un modèle de transaction distribué qui permet de maintenir la cohérence des données sur plusieurs services faiblement couplés au sein d'un système. L'objectif principal du modèle Saga est de relever les défis liés à la gestion des transactions dans un système basé sur des microservices, où les microservices individuels sont responsables de leurs propres données et disposent de leurs propres bases de données. Le terme « Saga » provient du domaine des systèmes de gestion de bases de données, où il a été introduit pour la première fois par Hector Garcia-Molina et Kenneth Salem en 1987 pour désigner une séquence d'opérations exécutées dans le cadre d'une transaction de longue durée.
L'architecture de microservices a gagné en popularité grâce à sa capacité à accroître la flexibilité, l'évolutivité et la résilience dans le développement de logiciels. Cependant, comme pour toute approche d’architecture logicielle, il existe des compromis. L’un des défis notables de l’architecture des microservices consiste à maintenir la cohérence des données entre les services, en particulier lorsqu’une seule opération commerciale s’étend sur plusieurs microservices. Ce problème est encore intensifié par le fait que chaque microservice possède généralement son magasin de données respectif, ce qui entraîne des limites transactionnelles distinctes pour chaque service.
Pour relever ce défi, le modèle Microservices Saga propose une solution qui combine une série de transactions locales, chaque transaction appartenant à un seul microservice. Ces transactions sont coordonnées via des messages ou des événements de manière asynchrone, remplaçant ainsi les transactions distribuées traditionnelles qui reposent sur des protocoles de validation en deux phases. Dans le modèle Saga, chaque transaction locale est suivie d'un événement qui déclenche la transaction locale suivante dans la séquence ou déclenche la transaction compensatoire en cas d'échec. Les transactions compensatoires sont essentiellement des opérations « d'annulation » qui visent à annuler les modifications apportées par les transactions locales précédentes, afin de maintenir la cohérence des données entre les services lorsqu'un problème survient.
Une saga de microservices peut être mise en œuvre à l'aide de deux modèles principaux : la chorégraphie et l'orchestration. Dans la chorégraphie, chaque microservice est chargé de comprendre à quels événements il doit réagir et quelles actions il doit effectuer en réponse. Lorsqu'une transaction locale est terminée, le microservice émet un événement et d'autres microservices écoutent cet événement et agissent en conséquence. Le principal avantage de cette approche est qu’elle favorise un contrôle décentralisé et nécessite peu ou pas de coordination centrale.
Dans le modèle d'orchestration, un composant central appelé orchestrateur est chargé de coordonner l'exécution des transactions locales dans la saga des microservices. L'orchestrateur reçoit des événements de services individuels et envoie des commandes aux services pour exécuter leurs transactions locales. Cette approche centralisée permet une gestion efficace des exceptions et augmente la visibilité sur le processus global de la saga. Cependant, cela peut introduire des goulots d’étranglement potentiels et nécessiter des efforts supplémentaires en matière d’infrastructure et de maintenance.
Chez AppMaster, la puissante plateforme no-code, la mise en œuvre des modèles Microservices Saga a été facilitée grâce au concepteur visuel de processus métiers (BP), qui permet de créer des applications backend, mobiles et Web avec des éléments entièrement interactifs. La plateforme génère du code source, des tests, des scripts de migration et bien plus encore pour chaque projet, qui s'intègre parfaitement dans l'architecture des microservices, garantissant la cohérence des données et l'exécution efficace des transactions distribuées. De plus, l'approche d' AppMaster élimine la dette technique en régénérant les applications à chaque modification, permettant même aux développeurs individuels de créer des solutions logicielles complètes de manière efficace et efficiente.
À titre d'exemple, considérons une plateforme de commerce électronique proposant des services distincts pour l'inventaire, le paiement et l'expédition. Lorsqu'une commande est passée, une saga de microservices est lancée, qui consiste à réserver du stock à partir du service d'inventaire, à facturer le client via le service de paiement et à générer une expédition via le service d'expédition. Si l'une de ces étapes échoue, des transactions compensatoires sont exécutées pour annuler toutes les opérations précédemment réussies, garantissant ainsi la cohérence des données dans l'ensemble du système. En mettant en œuvre le modèle Microservices Saga, cette plate-forme de commerce électronique peut fournir une gestion fiable des transactions au sein de son architecture de microservices, favorisant ainsi la résilience et la rationalisation des opérations.
En conclusion, la Microservices Saga est un modèle de transaction distribué qui répond aux défis liés au maintien de la cohérence des données dans les systèmes basés sur des microservices. Il permet de coordonner une série de transactions locales sur plusieurs services via une messagerie ou des événements asynchrones, remplaçant les transactions distribuées traditionnelles et garantissant une architecture logicielle plus flexible, évolutive et résiliente. La mise en œuvre de modèles Microservices Saga avec la plateforme no-code d' AppMaster permet un développement d'applications plus rapide et rentable sans le fardeau de la dette technique, permettant aux développeurs de créer des solutions logicielles complètes qui adhèrent aux pratiques d'architecture logicielle modernes.
