Modèle de transaction de compensation

Utilisez ce modèle pour annuler le travail quand une ou plusieurs étapes échouent dans une opération cohérente. Les applications hébergées dans le cloud qui implémentent des processus métier complexes et des workflows utilisent généralement des opérations qui suivent le modèle de cohérence éventuel.

Contexte et problème

Les applications cloud modifient fréquemment les données réparties entre différentes sources de données dans différents emplacements géographiques. Pour éviter la contention et améliorer les performances dans un environnement distribué, les applications doivent implémenter la cohérence éventuelle au lieu d’une cohérence transactionnelle forte. Dans le modèle de cohérence éventuelle, une opération métier type se compose d’une série d’étapes distinctes. Pendant ces étapes, la vue globale de l’état du système peut être incohérente. Toutefois, le système doit être de nouveau cohérent lorsque toutes les étapes se terminent.

La gestion des échecs d’étapes présente un défi clé dans le modèle de cohérence final. Après un échec, vous devrez peut-être annuler le travail à partir des étapes d’opération terminées. Toutefois, vous ne pouvez pas toujours restaurer les données, car d’autres instances d’application simultanées peuvent modifier les données. Même si les instances simultanées ne modifient pas les données, il peut être plus complexe d’annuler une étape que de restaurer l’état d’origine. Vous devrez peut-être appliquer des règles spécifiques à l’entreprise. Pour obtenir un exemple, consultez l’exemple de site web de voyage.

Lorsqu’une opération qui implémente une cohérence éventuelle s’étend sur plusieurs magasins de données, vous devez accéder à chaque magasin de données pour annuler les modifications. Pour empêcher le système de rester incohérent, vous devez annuler de manière fiable le travail dans chaque magasin de données.

Une opération qui implémente la cohérence éventuelle ne stocke pas toujours ses données affectées dans une base de données. Par exemple, dans un environnement d’architecture orientée service (SOA), une opération peut appeler une action dans un service et modifier l’état que le service contient. Pour annuler l’opération, vous devez également annuler cette modification d’état, ce qui peut impliquer l’appel du service à nouveau pour inverser les effets de la première action.

Solution

Implémentez une transaction de compensation qui annule les effets des étapes terminées dans l’opération d’origine. Vous pouvez penser que vous pouvez simplement restaurer le système à son état d’origine, mais cette approche peut remplacer les modifications d’autres instances d’application simultanées. Au lieu de cela, la transaction de compensation doit tenir compte intelligemment du travail simultané. Ce processus est généralement spécifique à l’application et dépend de l’opération d’origine.

Vous pouvez utiliser un flux de travail pour implémenter une opération cohérente qui nécessite une compensation. À mesure que l’opération d’origine s’exécute, le système enregistre des informations sur chaque étape et comment l’annuler. En cas d’échec de l’opération, le flux de travail revient en arrière à travers les étapes terminées et annule chaque étape.

Diagramme montrant un workflow avec des étapes progressives et des actions de compensation. Un utilisateur lance une opération qui exécute l’étape 1, l’étape 2 et l’étape 3 séquentiellement. Si toutes les étapes réussissent, le processus se termine. Si une défaillance se produit après une étape, les actions de compensation s’exécutent en sens inverse pour annuler le travail terminé, aboutissant à un état compensé.

Bien que chaque étape soit une action distincte, elles forment ensemble une opération cohérente. Le système doit effectuer les étapes et les opérations d’annulation correspondantes pour chaque étape. Si le client annule, ces opérations d’annulation peuvent s’exécuter en tant que transaction de compensation.

Une défaillance en une seule étape ne vous oblige pas toujours à restaurer l’ensemble du système à l’aide d’une transaction de compensation. Par exemple, dans le cadre d'un site web de voyage, un client réserve des vols F1, F2 et F3, mais ne parvient pas à réserver une chambre à l’hôtel H1. Offrir au client une chambre à un autre hôtel est préférable à annuler les vols. Le client peut toujours choisir d’annuler, ce qui déclenche la transaction de compensation pour annuler les réservations de vol. Toutefois, le client doit prendre cette décision, et non le système. Lorsque les décisions ont un impact élevé ou difficile à automatiser de manière fiable, incluez un humain dans le processus de prise de décision.

Tenez compte de ces points importants :

• Une transaction de compensation n’a peut-être pas besoin d’annuler le travail dans l’ordre inverse exact de l’opération d’origine.

• Vous pouvez peut-être effectuer certaines étapes d’annulation en parallèle.

• Vous devrez peut-être appliquer des règles spécifiques à l’entreprise. Par exemple, l’annulation d’une réservation de vol peut ne pas donner droit au client à un remboursement complet.

Cette approche est similaire au modèle de transactions distribuées Saga.

Les transactions de compensation sont finalement cohérentes et peuvent échouer. Le système doit enregistrer la progression afin qu’il puisse reprendre la transaction de compensation à partir du point de défaillance. Une étape peut s’exécuter plusieurs fois lorsqu’elle a été retentée. Concevez donc chaque étape en tant que commande idempotente.

Parfois, l’intervention manuelle est le seul moyen de récupérer à partir d’une étape ayant échoué. Dans ces situations, le système doit déclencher une alerte qui inclut des informations détaillées sur la raison de l’échec.

Problèmes et considérations

Tenez compte des points suivants lorsque vous décidez comment implémenter ce modèle :

• Il n’est pas toujours facile de déterminer quand une étape d’une opération qui implémente la cohérence éventuelle a échoué. Une étape peut ne pas échouer immédiatement, mais à la place se bloquer. Vous devrez peut-être implémenter un mécanisme de délai d’expiration.

• Il n’est pas facile de généraliser la logique de compensation. Une transaction de compensation est spécifique à l’application. Elle s’appuie sur l’application disposant d’informations suffisantes pour annuler les effets de chaque étape dans une opération ayant échoué.

• Les transactions de compensation ne fonctionnent pas toujours. Définissez les étapes d’une transaction de compensation en tant que commandes idempotentes afin de pouvoir les répéter si la transaction de compensation elle-même échoue.

• L’infrastructure qui gère les étapes doit répondre aux critères suivants :

  • Elle est résiliente à la fois dans l’opération d’origine et dans la transaction de compensation.

  • Il ne perd pas les informations requises pour compenser une étape défaillante.

  • Il surveille de manière fiable la progression de la logique de compensation. Les transactions de compensation s’exécutent après la validation des opérations d’origine, et d’autres transactions peuvent modifier les états intermédiaires. Par conséquent, assurez-vous que vous pouvez mettre en corrélation et auditer l’opération d’origine et sa compensation de bout en bout.

• Une transaction de compensation ne rétablit pas forcément l’état des données dans le système tel qu’il l’était au début de l’opération d’origine. Au lieu de cela, la transaction compense le travail que l’opération a accompli correctement avant son échec.

• Les étapes de transaction de compensation n’inversent pas toujours l’opération d’origine dans l’ordre inverse exact. Par exemple, si un magasin de données est plus sensible aux incohérences qu’une autre, annulez d’abord les modifications apportées à ce magasin.

• Certaines mesures peuvent vous aider à améliorer les taux de réussite. Vous pouvez placer un verrou à court terme avec un délai d’expiration sur chaque ressource requise pour effectuer une opération. Vous pouvez acquérir ces ressources à l’avance, puis effectuer le travail uniquement après avoir acquis toutes les ressources. Finalisez toutes les actions avant l’expiration des verrous.

• La logique de nouvelle tentative qui traite davantage d’erreurs comme temporaire peut aider à réduire les défaillances qui déclenchent une transaction de compensation. Lorsqu’une étape d’une opération qui implémente une cohérence éventuelle échoue, gérez-la en tant qu’exception temporaire et réessayez l’étape. Arrêtez uniquement l’opération et déclenchez une compensation si l’étape échoue à plusieurs reprises ou que vous ne pouvez pas la récupérer. Pour plus d’informations sur les stratégies de nouvelle tentative, consultez Gestion des erreurs temporaires.

• Lorsque vous implémentez une transaction de compensation, vous rencontrez de nombreux défis similaires à l’implémentation de la cohérence éventuelle. Pour plus d’informations, consultez Réduire la coordination.

• Définissez des points clairs sans retour et des étapes irréversibles. Dans les flux de travail complexes, vous ne pouvez pas annuler de manière sécurisée ou significative certaines opérations, telles que des effets secondaires externes ou des actions de liaison légale. Identifiez les étapes compensables et irréversibles. Concevez le flux de travail afin que les étapes irréversibles se produisent uniquement après que toutes les validations critiques réussissent.

Quand utiliser ce modèle

Utilisez ce modèle dans les situations suivantes :

• Une opération métier s’étend sur plusieurs étapes, services ou magasins de données et doit être annulée si une étape ultérieure échoue. Ce scénario se produit souvent dans des workflows de longue durée qui suivent un modèle de cohérence éventuel et ne peuvent pas s’appuyer sur des transactions atomiques.

• La récupération de la défaillance requiert souvent une logique spécifique au domaine au lieu d'une simple restauration des données. Utilisez des actions de compensation lorsque revenir sur le travail vous oblige à appliquer des règles commerciales, telles que l’annulation de réservations ou l’émission de remboursements partiels.

Ce modèle peut ne pas convenir lorsque :

• Les opérations peuvent être retentées en toute sécurité et la plupart des échecs sont temporaires. La logique de nouvelle tentative seule est souvent suffisante dans ces cas, et les transactions de compensation ajoutent une complexité inutile.

• Le système ne peut pas tolérer d’incohérence temporaire, ou une compensation ne peut pas restaurer de manière fiable un état valide. Utilisez plutôt des mécanismes de cohérence forts ou des transactions atomiques dans toutes les étapes.

Conception de la charge de travail

Évaluez comment utiliser la transaction de compensation dans la conception d'une charge de travail pour répondre aux objectifs et principes abordés dans les piliers Azure Well-Architected Framework. Le tableau suivant fournit des conseils sur la façon dont ce modèle prend en charge les objectifs de chaque pilier.

Pilier	Comment ce modèle soutient les objectifs des piliers.
Les décisions de conception de fiabilité aident votre charge de travail à devenir résiliente au dysfonctionnement et à s’assurer qu’elle se rétablit dans un état entièrement opérationnel après une défaillance.	Les actions de compensation résolvent les dysfonctionnements dans les chemins de charge de travail critiques à l’aide de processus tels que la restauration directe des modifications de données, la rupture des verrous de transaction ou même l’exécution du comportement du système natif pour inverser l’effet. - RE :02 Flux critiques - RE :09 reprise d’activité après sinistre

Si ce modèle introduit des compromis au sein d’un pilier, considérez-les contre les objectifs des autres piliers.

Exemple

Le diagramme suivant montre une implémentation pratique Azure du modèle de transaction de compensation. D’autres implémentations peuvent également fonctionner pour vos exigences de traitement. Un orchestrateur qui s’exécute dans Azure Container Apps coordonne chaque étape d’un workflow de longue durée en envoyant des commandes via Azure Service Bus. À mesure que chaque étape avant réussit, l’orchestrateur enregistre à la fois l’état d’exécution et l’action de compensation correspondante dans Azure Cosmos DB afin que le flux de travail puisse être repris, corrélé et audité.

Diagramme montrant un flux de travail dans un environnement Azure Container Apps. Un client envoie une requête à un conteneur d’orchestration, qui coordonne le Service A et le Service B et enregistre les opérations. Les messages de l’étape 1 et de l’étape 2 transitent par Service Bus. En cas d’échec d’une étape, les actions de compensation s’exécutent dans l’ordre inverse. Les messages en échec sont déplacés vers une file d'attente des lettres mortes. L’environnement s’intègre à Microsoft Entra ID pour l’identité et Application Insights et Azure Monitor pour l’observabilité.

Ce modèle utilise d’abord des nouvelles tentatives pour conserver la progression vers l’avant. Si une étape échoue, l’orchestrateur applique une logique de nouvelle tentative pour les erreurs temporaires et tente de poursuivre l’opération d’origine. La compensation n’est appelée que lorsque la progression vers l’avant devient impossible, par exemple lorsque les nouvelles tentatives sont épuisées ou que l’échec est classé comme nontransient.

Les règles spécifiques à l’entreprise peuvent également préférer la progression par rapport à la compensation immédiate. En cas d’échec d’une étape, l’orchestrateur peut sélectionner un autre chemin, tel que la substitution d’un service équivalent ou d’une option de secours, au lieu de restaurer le flux de travail. Pour les cas à impact élevé ou ambiguë, vous pouvez suspendre le flux de travail pour la révision humaine avant de décider si vous souhaitez continuer sur un autre chemin ou déclencher une compensation. Cette approche traite la compensation comme un dernier recours et permet aux règles de domaine de prendre des décisions de récupération.

Dans une séquence classique, l’orchestrateur envoie des messages d’étape via Service Bus (étapes 1 et 2), reçoit des résultats réussis et stocke les métadonnées de transfert et de compensation dans Azure Cosmos DB.

Vous pouvez déclencher une compensation de deux manières :

• Quand une étape ultérieure de la même charge de travail échoue et que vous devez annuler les étapes précédentes réussies. Cette compensation peut se produire immédiatement lorsqu’une étape retourne une erreur métier telle qu’un échec de validation de règle ou une fois les nouvelles tentatives techniques épuisées et le message est déplacé vers la file d’attente de lettres mortes.

• Lorsqu’un client suivant demande explicitement d’annuler une opération terminée.

Dans les deux cas, l’orchestrateur lit les enregistrements de compensation stockés et envoie des commandes de compensation au service correspondant. En cas d’échec temporaire d’une étape de compensation, Service Bus peut effectuer de nouvelles tentatives pour la réaliser sans augmenter l'incident.

Si les nouvelles tentatives répétées échouent toujours, Service Bus déplace le message vers une file d’attente de lettres mortes et conserve les détails de l’échec. L’orchestrateur, ou un processeur de lettres mortes dédié, déclenche une alerte et émet des données de télémétrie structurées, notamment la raison de l'échec et les IDs de corrélation, à Azure Monitor et Log Analytics, qui peuvent apparaître dans Application Insights. Ce chemin opérationnel aide les équipes à diagnostiquer les défaillances, à déterminer la nécessité d’une intervention manuelle et à maintenir la traçabilité dans les flux d’origine et de compensation.

Le flux de travail peut démarrer automatiquement la compensation pour des conditions claires, à faible risque ou suspendre l’examen humain lorsque la situation est ambiguë, à fort impact ou nécessite une décision manuelle.

Utilisez des identités managées et une autorisation basée sur Microsoft Entra ID entre les composants pour éviter les secrets partagés et appliquer l’accès avec des privilèges minimum. Lorsque vous créez un diagramme de référence simplifié, traitez ces contrôles d’identité et d’autorisation comme des préoccupations d’implémentation de référence plutôt que des étapes de flux explicites. Gardez le diagramme axé sur l’orchestration, la nouvelle tentative, la compensation et la gestion des défaillances.

Ressources associées

• Considérations relatives aux données pour les microservices : découvrez pourquoi la cohérence et l’échec partiel éventuels sont inhérents aux systèmes distribués. Le modèle transaction de compensation fournit un mécanisme concret pour gérer ces défaillances lorsque les opérations s’étendent sur plusieurs services.

• modèle Transactional Outbox avec Azure Cosmos DB : utilisez ce modèle lorsque des transactions compensatoires doivent publier des événements ou des commandes de manière fiable. Il permet de s’assurer que les modifications d’état et les messages sont enregistrés atomiquement, ce qui empêche la perte de messages.

• Conception pour la réparation automatique : utilisez des transactions de compensation dans le cadre d’une approche d’auto-guérison pour vos applications.

• Modèle superviseur de l’agent planificateur : utilisez ce modèle pour implémenter des systèmes résilients qui effectuent des opérations métier entre les services et ressources distribués. Ces systèmes nécessitent parfois des transactions de compensation pour annuler le travail.

• Modèle de nouvelle tentative : utilisez ce modèle pour gérer les défaillances temporaires et réduire le besoin de transactions de compensation.

• Modèle de transactions distribuées Saga : utilisez ce modèle pour gérer la cohérence des données entre les microservices dans les transactions distribuées. Saga utilise des transactions de compensation pour la récupération après échec.

• Modèle canaux et filtres : utilisez ce modèle avec le modèle transaction de compensation comme alternative aux transactions distribuées lorsque vous décomposez des tâches complexes en étapes réutilisables.