Modèle de chorégraphie de saga - AWS Conseils prescriptifs
IntentionMotivationApplicabilitéProblèmes et considérationsMise en œuvreContenu connexe

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Modèle de chorégraphie de saga

Intention

Le modèle de chorégraphie de saga permet de préserver l’intégrité des données dans les transactions distribuées qui couvrent plusieurs services en utilisant des abonnements à des événements. Dans une transaction distribuée, plusieurs services peuvent être appelés avant qu’une transaction ne soit terminée. Lorsque les services stockent des données dans différents magasins de données, il peut être difficile de maintenir la cohérence des données entre ces magasins de données.

Motivation

Une transaction est une unité de travail unique qui peut impliquer plusieurs étapes, toutes les étapes étant entièrement exécutées ou aucune étape n’étant exécutée, ce qui permet à un magasin de données de conserver son état cohérent. Les termes atomicité, cohérence, isolement et durabilité (ACID) définissent les propriétés d’une transaction. Les bases de données relationnelles fournissent des transactions ACID pour maintenir la cohérence des données.

Pour maintenir la cohérence d’une transaction, les bases de données relationnelles utilisent la méthode de validation en deux phases (2PC). Il s’agit d’une phase de préparation et d’une phase de validation.

  • Au cours de la phase de préparation, le processus de coordination demande aux processus participants à la transaction (participants) de promettre de valider ou d’annuler la transaction.

  • Dans la phase de validation, le processus de coordination demande aux participants de valider la transaction. Si les participants ne parviennent pas à s’engager lors de la phase de préparation, la transaction est annulée.

Dans les systèmes distribués qui suivent un modèle de database-per-service conception, la validation en deux phases n'est pas une option. En effet, chaque transaction est distribuée entre différentes bases de données et aucun contrôleur ne peut coordonner un processus similaire à la validation en deux phases dans les magasins de données relationnels. Dans ce cas, une solution consiste à utiliser le modèle de chorégraphie de saga.

Applicabilité

Utilisez le modèle de chorégraphie de saga lorsque :

  • Votre système a besoin de l’intégrité et de la cohérence des données dans les transactions distribuées qui s’étendent sur plusieurs magasins de données.

  • Le magasin de données (par exemple, une base de données NoSQL) ne propose pas le 2PC pour fournir des transactions ACID, vous devez mettre à jour plusieurs tables au cours d’une seule transaction, et l’implémentation du 2PC dans les limites de l’application serait une tâche complexe.

  • Un processus de contrôle central qui gère les transactions des participants pourrait devenir un point de défaillance unique.

  • Les participants à la saga sont des services indépendants et doivent être couplés de manière faible.

  • Il existe une communication entre des contextes délimités dans un domaine métier.

Problèmes et considérations

  • Complexité : à mesure que le nombre de microservices augmente, la chorégraphie de saga peut devenir difficile à gérer en raison du nombre d’interactions entre les microservices. En outre, les transactions compensatoires et les nouvelles tentatives ajoutent de la complexité au code de l’application, ce qui peut entraîner des frais de maintenance. La chorégraphie convient lorsque la saga ne compte que quelques participants et que vous avez besoin d’une implémentation simple, sans point de défaillance unique. Lorsque d’autres participants sont ajoutés, il devient plus difficile de suivre les dépendances entre les participants en utilisant ce modèle.

  • Mise en œuvre résiliente : dans la chorégraphie de saga, il est plus difficile d’implémenter des délais d’attente, des nouvelles tentatives et d’autres modèles de résilience à l’échelle mondiale que dans le cas d’une orchestration de saga. La chorégraphie doit être mise en œuvre sur des composants individuels plutôt qu’au niveau de l’orchestrateur.

  • Dépendances cycliques : les participants consomment des messages diffusés les uns par les autres. Cela peut entraîner des dépendances cycliques, puis des complexités du code et des frais de maintenance, ainsi que d’éventuels blocages.

  • Problème d’écritures doubles : le microservice doit mettre à jour la base de données de manière atomique et diffuser un événement. L’échec de l’une ou l’autre opération peut entraîner un état incohérent. Une façon de résoudre ce problème consiste à utiliser le modèle de boîte d’envoi transactionnelle.

  • Préservation des événements : les participants à la saga agissent en fonction des événements diffusés. Il est important d’enregistrer les événements dans l’ordre dans lequel ils se produisent à des fins d’audit, de débogage et de rediffusion. Vous pouvez utiliser le modèle d’approvisionnement d’événement pour conserver les événements dans un magasin d’événements au cas où une rediffusion de l’état du système serait nécessaire pour rétablir la cohérence des données. Les magasins d’événements peuvent également être utilisés à des fins d’audit et de dépannage, car ils reflètent chaque modification apportée au système.

  • Cohérence à terme : le traitement séquentiel des transactions locales aboutit à une cohérence à terme, ce qui peut être un défi dans les systèmes nécessitant une forte cohérence. Vous pouvez résoudre ce problème en définissant les attentes de vos équipes métier en ce qui concerne le modèle de cohérence ou en réévaluant le cas d’utilisation et en optant pour une base de données offrant une forte cohérence.

  • Idempotence : les participants à la saga doivent être idempotents pour permettre des exécutions répétées en cas de défaillances transitoires causées par des pannes inattendues ou des défaillances de l’orchestrateur.

  • Isolement des transactions : le modèle de saga ne permet pas d’isoler les transactions, ce qui est l’une des quatre propriétés des transactions ACID. Le degré d’isolement d’une transaction détermine dans quelle mesure les autres transactions simultanées peuvent affecter les données sur lesquelles la transaction opère. L’orchestration simultanée de transactions peut entraîner l’obsolescence des données. Nous vous recommandons d’utiliser le verrouillage sémantique pour gérer de tels scénarios.

  • Observabilité : l’observabilité fait référence à la journalisation et au suivi détaillés pour résoudre les problèmes liés au processus de mise en œuvre et d’orchestration. Cela devient important lorsque le nombre de participants à la saga augmente, ce qui complique le débogage. nd-to-end La surveillance électronique et le reporting sont plus difficiles à réaliser dans le cadre d'une chorégraphie de saga que dans le cas d'une orchestration de saga.

  • Problèmes de latence : les transactions compensatoires peuvent ajouter de la latence au temps de réponse global lorsque la saga comporte plusieurs étapes. Si les transactions émettent des appels synchrones, cela peut encore augmenter la latence.

Mise en œuvre

Architecture de haut niveau

Dans le schéma d’architecture suivant, la chorégraphie de saga compte trois participants : le service de commande, le service d’inventaire et le service de paiement. Trois étapes sont nécessaires pour terminer la transaction : T1, T2 et T3. Trois transactions compensatoires rétablissent les données dans leur état initial : C1, C2 et C3.

Architecture de haut niveau de la chorégraphie de saga

  • Le service de commande exécute une transaction locale, T1, qui met à jour de manière atomique la base de données et diffuse un message Order placed à l’agent de messages.

  • Le service d’inventaire s’abonne aux messages du service de commande et reçoit le message indiquant qu’une commande a été créée.

  • Le service d’inventaire exécute une transaction locale, T2, qui met à jour de manière atomique la base de données et diffuse un message Inventory updated à l’agent de messages.

  • Le service de paiement s’abonne aux messages du service d’inventaire et reçoit le message indiquant que l’inventaire a été mis à jour.

  • Le service de paiement exécute une transaction locale, T3, qui met à jour de manière atomique la base de données avec les informations de paiement et diffuse un message Payment processed à l’agent de messages.

  • Si le paiement échoue, le service de paiement exécute une transaction compensatoire, C1, qui annule le paiement de manière atomique dans la base de données et diffuse un message Payment failed à l’agent de messages.

  • Les transactions compensatoires C2 et C3 sont exécutées pour rétablir la cohérence des données.

Mise en œuvre à l’aide des services AWS

Vous pouvez implémenter le modèle de chorégraphie de la saga en utilisant Amazon EventBridge. EventBridgeutilise des événements pour connecter les composants de l'application. Il traite les événements par le biais de bus ou de pipelines d’événements. Un bus d’événements est un routeur qui reçoit des événements et les transmet à zéro ou plusieurs destinations, ou cibles. Les règles associées au bus d’événements évaluent les événements au fur et à mesure qu’ils arrivent et les envoient aux cibles pour traitement.

Dans l’architecture suivante :

  • Les microservices (service de commande, service d’inventaire et service de paiement) sont implémentés sous forme de fonctions Lambda.

  • Il existe trois EventBridge bus personnalisés : le bus Orders d'événement, le bus d'Inventoryévénement et le bus Payment d'événement.

  • Les règles Orders, Inventory et Payment correspondent aux événements envoyés au bus d’événements correspondant et invoquent les fonctions Lambda.

Architecture de chorégraphie de saga utilisant les services AWS

Dans un scénario réussi, lorsqu’une commande est passée :

  1. Le service de commande traite la demande et envoie l’événement au bus d’événements Orders.

  2. Les règles Orders correspondent aux événements et démarrent le service d’inventaire.

  3. Le service d’inventaire met à jour l’inventaire et envoie l’événement au bus d’événements Inventory.

  4. Les règles Inventory correspondent aux événements et démarrent le service de paiement.

  5. Le service de paiement traite le paiement et envoie l’événement au bus d’événements Payment.

  6. Les règles Payment correspondent aux événements et envoient la notification de l’événement Payment processed à l’écouteur.

    Par ailleurs, en cas de problème dans le traitement des commandes, les EventBridge règles lancent les transactions compensatoires pour annuler les mises à jour des données afin de maintenir la cohérence et l'intégrité des données.

  7. Si le paiement échoue, les règles Payment traitent l’événement et démarrent le service d’inventaire.Le service d’inventaire exécute des transactions compensatoires pour rétablir l’inventaire.

  8. Lorsque l’inventaire a été rétabli, le service d’inventaire envoie l’événement Inventory reverted au bus d’événements Inventory.Cet événement est traité par des règles Inventory.Il lance le service de commande, qui exécute la transaction compensatoire pour supprimer la commande.

Contenu connexe