Le modèle de conception Saga est un moyen de gérer la cohérence des données entre les microservices dans des scénarios de transaction distribuée. Un saga est une séquence de transactions qui met à jour chaque service et publie un message ou un événement pour déclencher l’étape suivante de la transaction. Si une étape échoue, la saga exécute des transactions de compensation qui contrent les transactions précédentes.
Contexte et problème
Une transaction est une unité de logique ou de travail, parfois constituée de plusieurs opérations. Dans une transaction, un événement est un changement d’état d’une entité, et une commande encapsule toutes les informations nécessaires pour exécuter une action ou déclencher un événement ultérieur.
Chaque transaction peut être atomique, cohérente, isolée et durable (ACID) . Les transactions au sein d’un même service sont ACID, mais la cohérence des données entre les services requiert une stratégie de gestion des transactions entre les services.
Dans les architectures de multiservices :
- L’atomicité est un ensemble indivisible et irréductible d’opérations qui doivent toutes se produire, sans quoi aucune ne se produit.
- La cohérence signifie que la transaction amène les données d’un état valide à un autre état valide.
- L’isolation garantit que des transactions simultanées produisent le même état de données que des transactions exécutées séquentiellement auraient produites.
- La durabilité garantit que des transactions validées restent validées, même en cas de défaillance du système ou de panne de courant.
Un modèle de base-de-données-par-microservice présente de nombreux avantages pour les architectures de microservices. L’encapsulation de données de domaine permet à chaque service d’utiliser le type et le schéma de son meilleur magasin de données, de mettre à l’échelle son propre magasin de données si nécessaire, et d’être isolé des défaillances d’autres services. Toutefois, garantir la cohérence des données entre les bases de données spécifiques du service pose des problèmes.
Des transactions distribuées, telles que le protocole de validation en deux phases (2PC) requièrent que tous les participants à une transaction valident ou annulent la transaction avant qu’elle se poursuive. Toutefois, certaines implémentations de participants, telles que des bases de données NoSQL et la répartition de messages, ne prennent pas en charge ce modèle.
Une autre limitation de transaction distribuée est la synchronicité et la disponibilité de communication entre processus (IPC). L’IPC fournie par le système d’exploitation permet à des processus distincts de partager des données. Pour que des transactions distribuées soient validées, tous les services participants doivent être disponibles, ce qui peut réduire la disponibilité globale du système. Des implémentations architecturales avec communication entre processus ou des limitations de transaction sont de bonnes candidates pour le modèle Saga.
Solution
Le modèle Saga fournit une gestion des transactions à l’aide d’une séquence de transactions locales. Une transaction locale est l’effort de travail atomique effectué par un participant à la saga. Chaque transaction locale met à jour la base de données et publie un message ou un événement pour déclencher la transaction locale suivante dans la saga. En cas de défaillance d’une transaction locale, le saga exécute une série de transactions de compensation qui annulent les modifications apportées par les transactions locales précédentes.
Dans les modèles Saga :
- Les transactions compensables sont des transactions qui peuvent être inversées en traitant une autre transaction avec l’effet opposé.
- Une transaction pivot est le point go/no-go dans une saga. Si la transaction pivot est validée, le saga s’exécute jusqu’à la fin. Une transaction pivot peut être une transaction qui n’est ni compensable, ni renouvelable, ou qui peut être la dernière transaction compensable ou la première transaction renouvelable dans la saga.
- Les transactions renouvelables sont des transactions qui suivent la transaction pivot et dont la réussite est garantie.
Il existe deux approches d’implémentation de la saga courantes, chorégraphie et orchestration. Chaque approche a son propre ensemble de défis et de technologies pour coordonner le flux de travail.
Chorégraphie
Une chorégraphie est un moyen de coordonner des sagas, où les participants échangent des événements sans point de contrôle centralisé. Avec une chorégraphie, chaque transaction locale publie des événements de domaine qui déclenchent des transactions locales dans d’autres services.
Avantages
- Convient pour des flux de travail simples nécessitant peu de participants et n’ayant pas besoin d’une logique de coordination.
- Ne nécessite pas d’implémentation et de maintenance de service supplémentaires.
- N’introduit pas de point de défaillance unique parce que les responsabilités sont réparties entre les participants à la saga.
Inconvénients
- Le flux de travail peut devenir confus lors de l’ajout d’étapes, car il est difficile de suivre quels participants à la saga écoutent quelles commandes.
- Il existe un risque de dépendance cyclique entre les participants à la saga parce qu’ils doivent consommer les commandes les uns des autres.
- Le test d’intégration est difficile parce que, pour simuler une transaction, tous les services doivent être en cours d’exécution.
Orchestration
Une orchestration est un moyen de coordonner sagas quand un contrôleur centralisé indique aux participants à la saga les transactions locales à exécuter. L’orchestrateur de saga gère toutes les transactions et indique aux participants l’opération à effectuer en fonction des événements. L’orchestrateur exécute des demandes de la saga, stocke et interprète les états de chaque tâche, et gère la récupération en cas de défaillance à l’aide de transactions de compensation.
Avantages
- Convient pour des flux de travail complexes impliquant de nombreux participants ou l’ajout de nouveaux participants au fil du temps.
- Approprié quand un contrôle est exercé sur chaque participant au processus et sur le flux des activités.
- N’introduit pas de dépendances cycliques, car l’orchestrateur dépend unilatéralement des participants à la saga.
- Les participants à la saga n’ont pas besoin de connaître les commandes pour d’autres participants. Une séparation claire des préoccupations simplifie la logique métier.
Inconvénients
- Une complexité de conception supplémentaire nécessite l’implémentation d’une logique de coordination.
- Il y a un point de défaillance supplémentaire parce que l’orchestrateur gère le flux de travail complet.
Problèmes et considérations
Lorsque vous implémentez ce modèle Saga, considérez les points suivants :
- Le modèle Saga peut être difficile au départ, car il nécessite une nouvelle façon de penser la manière de coordonner une transaction et de maintenir la cohérence des données pour un processus commercial couvrant plusieurs microservices.
- Le modèle Saga est particulièrement difficile à déboguer, et la complexité augmente en même temps que le nombre de participants.
- Les données ne peuvent pas être restaurées, car les participants à la saga valident les modifications apportées à leurs bases de données locales.
- L’implémentation doit être en mesure de gérer un ensemble de défaillances temporaires potentielles, et d’offrir une idempotence pour réduire les effets secondaires et garantir la cohérence des données. L’idempotence d’une opération signifie que celle-ci peut être répétée plusieurs fois sans que cela change le résultat initial. Pour plus d’informations, consultez les conseils sur la garantie de l’idempotence lors du traitement des messages et de la mise à jour de l’état en même temps.
- Il est préférable d’implémenter l’observabilité pour surveiller et suivre le flux de travail de la saga.
- L’absence d’isolation des données des participants impose des défis en matière de durabilité. L’implémentation de la saga doit inclure des contre-mesures pour réduire les anomalies.
À défaut de mesures appropriées, les anomalies suivantes peuvent se produire :
- Mises à jour perdues quand une saga écrit sans lire les modifications apportées par un autre.
- Lectures erronées quand une transaction ou un saga lit les mises à jour apportées par une saga qui n’a pas encore terminé ces mises à jour.
- Lectures approximatives/non reproductibles quand différentes étapes de la saga lisent des données différentes, car une mise à jour des données se produit entre les lectures.
Les contre-mesures suggérées pour réduire ou empêcher les anomalies sont les suivantes :
- Verrou sémantique au niveau de l’application où une transaction compensable d’une saga utilise un sémaphore pour indiquer qu’une mise à jour est en cours.
- Mises à jour commutatives pouvant être exécutées dans n’importe quel ordre et produisant le même résultat.
- Vue pessimiste : Il est possible qu’une saga lise des données erronées, tandis qu’une autre exécute une transaction compensable pour annuler l’opération. Une vue pessimiste réordonne la saga de façon à ce que les données sous-jacentes soient mises à jour dans le cadre d’une transaction renouvelable, éliminant ainsi la possibilité d’une lecture erronée.
- Une valeur relue vérifie que les données sont inchangées, puis met à jour l’enregistrement. Si l’enregistrement a changé, les étapes s’interrompent et la saga peut redémarrer.
- Un fichier de version enregistre les opérations sur un enregistrement à mesure qu’elles arrivent, puis les exécute dans le bon ordre.
- Par valeur utilise le risque de chaque demande pour sélectionner de manière dynamique le mécanisme de concurrence. Les demandes à faible risque favorisent les sagas, tandis que les demandes à haut risque favorisent les transactions distribuées.
Quand utiliser ce modèle
Utilisez le modèle Saga lorsque vous devez :
- garantir la cohérence des données dans un système distribué sans couplage étroit ;
- annuler ou compenser si l’une des opérations de la séquence échoue.
Le modèle Saga est moins adapté en présence de :
- transactions étroitement couplées ;
- transactions de compensation qui se produisent pour des participants antérieurs ;
- dépendances cycliques.
Exemple
Une saga basée sur orchestration sans serveur est une référence d’implémentation de saga utilisant l’approche de l’orchestration qui simule un scénario de transfert d’argent avec des flux de travail réussis et échoués.
Étapes suivantes
- Distributed data
- Richardson, Chris. 2018: Microservices Patterns. Manning Publications.
Ressources associées
Les modèles suivants peuvent également être utiles lors de l’implémentation de ce modèle :
- Une chorégraphie fait participer chaque composant du système au processus décisionnel concernant le flux de travail d’une transaction, au lieu de s’appuyer sur un point de contrôle central.
- Des transactions de compensation annulent le travail effectué par une série d’étapes, et définissent éventuellement une opération cohérente en cas de défaillance d’une ou de plusieurs étapes. Des applications hébergées dans le cloud qui implémentent des processus métier et des flux de travail complexes suivent souvent ce modèle de cohérence éventuelle.
- Une nouvelle tentative permet à une application de gérer des défaillances temporaires quand elle tente de se connecter à un service ou à une ressource réseau, en réessayant en toute transparence d’exécuter l’opération qui a échoué. Une nouvelle tentative peut améliorer la stabilité de l’application.
- Un disjoncteur gère les erreurs dont la récupération peut prendre un temps variable lors de la connexion à un service ou à une ressource distants. Un disjoncteur peut améliorer la stabilité et la résilience d’une application.
- Une surveillance de point de terminaison d’intégrité Implémente des contrôles fonctionnels dans une application à laquelle des outils externes peuvent accéder par le biais de points de terminaison exposés à intervalles réguliers. Une surveillance de point de terminaison d’intégrité peut aider à vérifier que les applications et les services fonctionnent correctement.