Le modèle de conception Saga permet de maintenir la cohérence des données dans les systèmes distribués en coordonnant les transactions entre plusieurs services. Une saga est une séquence de transactions locales où chaque service effectue son opération et lance l’étape suivante dans les événements ou les messages. Si une étape de la séquence échoue, la saga exécute des transactions de compensation pour annuler les étapes terminées, en conservant la cohérence des données.
Contexte et problème
Une transaction représente une unité de travail, qui peut inclure plusieurs opérations. Dans une transaction, un événement fait référence à une modification d’état affectant une entité. Une commande encapsule toutes les informations nécessaires pour effectuer une action ou déclencher un événement suivant.
Les transactions doivent respecter les principes de l’atomicité, de la cohérence, de l’isolation et de la durabilité (ACID).
- Atomicity: toutes les opérations réussissent ou ne le font pas.
- cohérence: les données passent d’un état valide à un autre.
- isolation: les transactions simultanées produisent les mêmes résultats que les opérations séquentielles.
- durabilité: une fois validées, les modifications persistent même en cas d’échecs.
Dans un seul service, les transactions suivent les principes ACID, car elles fonctionnent dans une base de données unique. Toutefois, l’obtention de la conformité ACID entre plusieurs services est plus complexe.
Défis liés aux architectures de microservices
Les architectures de microservices attribuent généralement une base de données dédiée à chaque microservice, ce qui offre plusieurs avantages :
- Chaque service encapsule ses propres données.
- Chaque service peut utiliser la technologie et le schéma de base de données les plus appropriés pour ses besoins spécifiques.
- Mise à l’échelle indépendante des bases de données pour chaque service.
- Les échecs d’un service sont isolés des autres.
Malgré ces avantages, cette architecture complique la cohérence des données interservices. Les garanties de base de données traditionnelles comme ACID ne sont pas directement applicables à plusieurs magasins de données gérés indépendamment. En raison de ces limitations, les architectures qui s’appuient sur la communication interprocesseur (IPC) ou les modèles transactionnels traditionnels, comme le protocole de validation en deux phases (2PC), sont souvent mieux adaptées au modèle Saga.
Solution
Le modèle Saga gère les transactions en les cassant dans une séquence de transactions locales (voir la figure 1).
Figure 1. Une saga avec trois services.
Chaque transaction locale :
- Termine son travail atomiquement au sein d’un seul service.
- Met à jour la base de données du service.
- Lance la transaction suivante via un événement ou un message.
- Si une transaction locale échoue, la saga exécute une série de transactions de compensation pour inverser les modifications apportées par les transactions locales précédentes.
Concepts clés dans le modèle Saga
transactions compensables: transactions que d’autres transactions peuvent annuler ou compenser avec l’effet opposé. Si une étape de la saga échoue, la compensation des transactions annule les modifications apportées aux transactions compensables.
transaction pivot: la transaction pivot sert de « point de non retour » dans la saga. Une fois la transaction pivot réussie, les transactions compensables (qui peuvent être annulées) ne sont plus pertinentes. Toutes les actions suivantes doivent être effectuées pour que le système atteigne un état final cohérent. Une transaction pivot peut se trouver dans différents rôles en fonction du flux de la saga :
irréversible (noncompensable): elle ne peut pas être annulée ni retentée.
limite entre lesréversibles et validées : il peut s’agir de la dernière transaction non modifiable (compensable), ou il peut s’agir de la première opération retenable dans la saga.
transactions retenables: ces transactions suivent la transaction pivot. Les transactions retenables sont idempotentes et garantissent que la saga peut atteindre son état final, même si des défaillances temporaires se produisent. Il garantit que la saga atteint un état cohérent finalement.
Approches d’implémentation de Saga
Il existe deux approches courantes d’implémentation de saga, chorégraphie et d’orchestration. Chaque approche a son propre ensemble de défis et de technologies pour coordonner le flux de travail.
Chorégraphie
Dans la chorégraphie, les services échangent des événements sans contrôleur centralisé. Avec la chorégraphie, chaque transaction locale publie des événements de domaine qui déclenchent des transactions locales dans d’autres services (voir la figure 2).
Figure 2. Une saga qui utilise la chorégraphie.
| Avantages de la chorégraphie | Inconvénients de la chorégraphie |
|---|---|
| Bon pour les flux de travail simples avec peu de services et n’ont pas besoin d’une logique de coordination. | Le flux de travail peut devenir déroutant lors de l’ajout de nouvelles étapes. Il est difficile de suivre les participants de saga qui écoutent les commandes. |
| Aucun autre service n’est nécessaire pour la coordination. | Il y a un risque de dépendance cyclique entre les participants de saga parce qu’ils doivent consommer les commandes des uns des autres. |
| N’introduit pas de point de défaillance unique, car les responsabilités sont réparties entre les participants de la saga. | Les tests d’intégration sont difficiles, car tous les services doivent s’exécuter pour simuler une transaction. |
Orchestration
Dans l’orchestration, un contrôleur centralisé (orchestrateur) gère toutes les transactions et indique aux participants quelle opération effectuer en fonction des événements. L’orchestrateur exécute des requêtes saga, stocke et interprète les états de chaque tâche et gère la récupération des défaillances avec des transactions de compensation (voir la figure 3).
Figure 3. Saga qui utilise l’orchestration.
| avantages de l’orchestration | inconvénients de l’orchestration |
|---|---|
| Mieux adapté aux flux de travail complexes ou lors de l’ajout de nouveaux services. | Une autre complexité de conception nécessite une implémentation d’une logique de coordination. |
| Évite les dépendances cycliques, car l’orchestrateur gère le flux. | Introduit un point de défaillance, car l’orchestrateur gère le flux de travail complet. |
| La séparation claire des responsabilités simplifie la logique de service. |
Problèmes et considérations
Tenez compte des points suivants lors de l’implémentation du modèle Saga :
Shift dans la conception: l’adoption du modèle Saga nécessite un état d’esprit différent, en mettant l’accent sur la coordination des transactions et en garantissant la cohérence des données entre plusieurs microservices.
Complexité du débogage des sagas: les sagas de débogage peuvent être complexes, en particulier à mesure que le nombre de services participants augmente.
modifications de base de données locales irréversibles: les données ne peuvent pas être restaurées, car les participants saga valident les modifications apportées à leurs bases de données respectives.
Gestion des défaillances temporaires et de l’idempotence: le système doit gérer efficacement les défaillances temporaires et garantir l’idempotence, où la répétition de la même opération ne modifie pas le résultat. Pour plus d’informations, consultez traitement des messages Idempotent.
Besoin de surveillance et de suivi des sagas: la surveillance et le suivi du flux de travail d’une saga sont essentielles pour maintenir la supervision opérationnelle.
Limitations des transactions de compensation: les transactions de compensation risquent de ne pas toujours réussir, ce qui risque de laisser le système dans un état incohérent.
Anomalies potentielles des données dans les sagas
Les anomalies de données sont des incohérences qui peuvent se produire lorsque des sagas s’exécutent sur plusieurs services. Étant donné que chaque service gère ses propres données (données de participant), il n’existe aucune isolation intégrée entre les services. Cette configuration peut entraîner des incohérences de données ou des problèmes de durabilité, tels que des mises à jour ou des conflits partiellement appliqués entre les services. Les problèmes courants sont les suivants :
Mises à jour perdues: quand une saga modifie les données sans tenir compte des modifications apportées par une autre saga, elle entraîne un remplacement ou des mises à jour manquantes.
Dirty lit: lorsqu’une saga ou une transaction lit les données qu’une autre saga a modifiée, mais pas encore terminée.
lectures approximatives (non répécables): lorsque différentes étapes d’une saga lisent des données incohérentes, car les mises à jour se produisent entre les lectures.
Stratégies de résolution des anomalies de données
Pour réduire ou empêcher ces anomalies, tenez compte de ces contre-mesures :
verrou sémantique: utilisez des verrous au niveau de l’application où la transaction compensable d’une saga utilise un sémaphore pour indiquer qu’une mise à jour est en cours.
mises à jour commutatives: mises à jour de conception afin qu’elles puissent être appliquées dans n’importe quel ordre tout en produisant le même résultat, réduisant ainsi les conflits entre sagas.
vue pessimiste: réorganisez la séquence de la saga afin que les mises à jour des données se produisent dans des transactions retentables afin d’éliminer les lectures incorrectes. Sinon, une saga pourrait lire des données incorrectes (modifications non validées) tandis qu’une autre saga exécute simultanément une transaction compensable pour restaurer ses mises à jour.
valeurs de relecture: vérifiez que les données restent inchangées avant d’effectuer des mises à jour. Si les données changent, abandonnez l’étape actuelle et redémarrez la saga si nécessaire.
fichiers de version: conservez un journal de toutes les opérations sur un enregistrement et assurez-vous qu’elles sont exécutées dans la séquence appropriée pour éviter les conflits.
concurrence basée sur les risques (par valeur): choisissez dynamiquement le mécanisme d’accès concurrentiel approprié en fonction du risque commercial potentiel. Par exemple, utilisez des sagas pour les mises à jour à faible risque et les transactions distribuées pour celles à haut risque.
Quand utiliser ce modèle
Utilisez le modèle Saga lorsque vous devez :
- Vérifiez la cohérence des données dans un système distribué sans couplage serré.
- Restaurez ou compensez si l’une des opérations de la séquence échoue.
Le modèle Saga est moins adapté pour :
- Transactions étroitement couplées.
- Compensation des transactions qui se produisent dans les participants antérieurs.
- Dépendances cycliques.
Étapes suivantes
- de données distribuées
- Richardson, Chris. 2018 : modèles de microservices . Publications de Manning.
Ressources associées
Les modèles suivants peuvent également être utiles lors de l’implémentation de ce modèle :
- chorégraphique a chaque composant du système participer au processus décisionnel sur le flux de travail d’une transaction métier, au lieu de s’appuyer sur un point central de contrôle.
- transactions de compensation annuler le travail effectué par une série d’étapes, puis définir une opération cohérente si une ou plusieurs étapes échouent. Les 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 .
- nouvelle tentative permet à une application de gérer les défaillances temporaires lorsqu’elle tente de se connecter à un service ou à une ressource réseau, en réessayant de manière transparente l’opération ayant échoué. Une nouvelle tentative peut améliorer la stabilité de l’application.
- disjoncteur gère les erreurs qui prennent un temps variable pour récupérer, lors de la connexion à un service ou à une ressource distant. Le disjoncteur peut améliorer la stabilité et la résilience d’une application.
- surveillance des points de terminaison d’intégrité implémente des vérifications fonctionnelles dans une application que les outils externes peuvent accéder via des points de terminaison exposés à intervalles réguliers. La surveillance des points de terminaison d’intégrité peut vous aider à vérifier que les applications et les services fonctionnent correctement.