introduction
Comme vous le savez, le passage d'une architecture monolithique à une architecture de microservices entraîne un certain nombre de difficultés liées à la fois à la partie technique du projet et au facteur humain. L'un des défis techniques les plus difficiles est d'assurer la cohérence dans un système distribué.
La dernière fois, nous avons discuté des causes des problèmes de cohérence dans une architecture de microservices, de l'approche optimiste de la cohérence et de la cohérence à l'aide d'un commit en deux phases.
Motif de la saga
Saga est un mécanisme permettant d'assurer la cohérence des données dans une architecture de microservices sans utiliser de transactions distribuées.
Pour chaque commande système qui a besoin de mettre à jour des données dans plusieurs services, une saga est créée. La saga est une sorte de «check-list» constituée de transactions ACID locales séquentielles, dont chacune met à jour les données dans un service. Une transaction de compensation est appliquée pour gérer les échecs. Ces transactions sont exécutées en cas d'échec sur tous les services sur lesquels les transactions locales se sont terminées avec succès.
Il existe plusieurs types de transactions dans la saga, jusqu'à quatre:
- Compensation - Annule une modification apportée par une transaction locale.
- Un remboursement est une transaction qui doit être remboursée (annulée) en cas d'échec des transactions ultérieures.
- Tournage - une transaction qui détermine le succès de toute la saga. Si cela réussit, la saga est garantie d'atteindre la fin.
- Répétable - va après le pivot et est garanti de réussir.
Vous pouvez organiser une saga en utilisant la chorégraphie ou l'orchestration.
Dans le cas de la saga chorégraphique, il n'y a pas d'orchestrateur dédié. En utilisant le service de commande et les utilisateurs comme exemple, cela pourrait ressembler à ceci: le service de commande reçoit une demande et crée une commande dans l'état PENDING, puis publie l'événement "Commande créée". Un gestionnaire d'événements du service utilisateur traite cet événement, tente de réserver un élément et publie le résultat en tant qu'événement. Le service de commande traite cet événement en confirmant ou en annulant la commande en fonction du résultat de la lecture.
La saga orchestrée semble un peu plus intéressante. En utilisant les services ci-dessus à titre d'exemple, cela pourrait ressembler à ceci: le service de commande reçoit une demande, crée une saga qui crée une commande dans l'état PENDING, puis envoie une commande pour réserver des marchandises pour le service utilisateur. Le service utilisateur tente de réserver le produit et envoie un message de réponse indiquant le résultat. La saga approuve ou annule la commande.
Le modèle de saga permet à une application de maintenir la cohérence des données sur plusieurs services sans utiliser de transactions distribuées (validations en deux phases) et en évitant les problèmes évoqués dans l'article précédent. Mais d'un autre côté, le modèle de programmation est très compliqué: par exemple, le développeur de chaque transaction doit écrire une transaction de compensation qui annule les modifications apportées précédemment dans la saga.
La saga nous permet de réaliser un modèle ACD (Atomicité + Consistance + Durabilité en termes ACID), mais nous avons perdu une lettre. L'absence de la lettre I conduit aux problèmes bien connus du manque d'isolement. Celles-ci incluent: mises à jour perdues - une saga écrase les modifications apportées par une autre sans les lire, lectures incorrectes - une transaction ou une saga lit les mises à jour inachevées d'une autre saga, floue / lectures non répétables) - deux étapes différentes de la saga lisent les mêmes données, mais obtiennent des résultats différents car une autre saga a apporté des modifications. Il existe un certain nombre de modèles qui permettent de corriger certaines anomalies: verrouillage sémantique, mises à jour commutatives, représentation pessimiste, relecture d'une valeur, fichier de modifications et par valeur.La question de l’isolement reste ouverte.
Un autre problème intéressant est l'impossibilité de mettre à jour atomique la base de données et de publier un message sur le courtier de messages pour déclencher d'autres étapes de la saga.
Conclusion
Nous avons parlé des moyens d'organiser une saga en utilisant la chorégraphie et l'orchestration, ainsi que les problèmes que ce modèle entraîne. Ensuite, nous parlerons des moyens de corriger certaines anomalies et d'envoyer des messages de manière transactionnelle au courtier de messages.
