Modèle de superviseur de l’agent du planificateur

Coordonnez un ensemble d’actions distribuées en tant qu’opération logique unique afin que l’opération dans son ensemble réussisse ou échoue. Gérez les défaillances de manière transparente ou annulez le travail terminé. Cette approche ajoute la résilience aux systèmes distribués en récupérant des exceptions temporaires, des erreurs durables et des défaillances de processus qui interrompent les flux de travail multistep orchestrés entre les services et ressources distants.

Contexte et problème

Les applications effectuent souvent des tâches qui s’étendent sur plusieurs étapes, et certaines étapes peuvent appeler des services distants ou accéder aux ressources distantes sous l’orchestration de la logique d’application. L’interaction avec tout ce qui se trouve en dehors du processus local expose la tâche à une plage de modes d’échec. La logique d’orchestration doit gérer ces modes d’échec sans perdre l’intégrité de l’opération dans son ensemble.

Vous pouvez gérer des situations simples, telles que des erreurs temporaires qui se résolvent elles-mêmes, à l’aide d’approches telles que le modèle Nouvelle tentative. Lorsque les erreurs sont plus permanentes ou lorsque l’orchestrateur lui-même échoue, le système doit restaurer un état cohérent à partir d’enregistrements durables et garantir l’intégrité de l’opération globale.

Solution

Le modèle superviseur de l’agent planificateur coordonne une tâche distribuée à plusieurs étapes via trois acteurs logiques. Ces acteurs orchestrent les étapes à effectuer dans le cadre de la tâche globale et gèrent les exécutions réussies et ayant échoué.

Scheduler

Le planificateur organise les étapes qui composent la tâche et orchestre leur exécution. Le planificateur est chargé de combiner les étapes dans un pipeline ou un flux de travail et de les exécuter dans l’ordre correct. À mesure que chaque étape progresse, le planificateur enregistre son état, tel que l’étape non encore démarrée, l’exécution de l’étape ou l’étape terminée. L’état inclut également une heure limite de fin qui limite le temps alloué à l’étape.

Lorsqu’une étape a besoin d’un service ou d’une ressource distant, le planificateur appelle un agent approprié et lui transmet les détails du travail. L’ordonnanceur communique généralement avec les agents via une messagerie asynchrone de type requête/réponse, souvent implémentée à l’aide de files d’attente. Vous pouvez utiliser d’autres technologies de messagerie distribuée à la place.

Agent

Un agent encapsule un appel à un service distant ou accède à une ressource distante référencée par une étape de tâche. Chaque agent encapsule généralement les appels à un seul service ou ressource et implémente la logique appropriée de gestion des erreurs et de nouvelle tentative dans le délai d’exécution imposé par le Planificateur. Lorsque la logique de nouvelle tentative est impliquée, l’Agent transmet un identificateur stable à toutes les tentatives de nouvelle tentative. Un service en aval peut l’utiliser pour la déduplication.

Si différentes étapes du flux de travail utilisent différents services ou ressources, chaque étape peut référencer un agent différent. Ce mappage est un détail d’implémentation du modèle. Pour obtenir des conseils sur la conception de stratégies de nouvelle tentative, consultez les meilleures pratiques pour la gestion des erreurs temporaires.

Superviseur

Le superviseur surveille l’état des étapes effectuées par le Planificateur. Le superviseur s’exécute régulièrement à une fréquence spécifiée par la charge de travail et il examine l’état de l’étape enregistré par le Scheduler. Si le superviseur trouve les étapes qui ont expiré ou échoué, il organise l’agent approprié pour récupérer l’étape, ou déclenche une autre action corrective qui peut inclure la modification de l’état de l’étape. Le superviseur demande uniquement ces actions de récupération. Le planificateur et les agents les implémentent.

Interactions

Le planificateur, l’agent et le superviseur sont des composants logiques, et leur implémentation physique dépend de la technologie que vous utilisez. Par exemple, vous pouvez implémenter plusieurs agents logiques au sein d’un seul service web ou comme activités au sein du même processus de travail hébergé.

Le Planificateur gère la progression des tâches et l’état par étape dans un magasin de données durable appelé magasin d’état. Le superviseur utilise ces informations pour déterminer si une étape a échoué. Le diagramme suivant montre la relation entre le planificateur, les agents, le superviseur et le magasin d’état.

• Le planificateur organise et exécute les étapes qui composent la tâche en tant que flux de travail.
• Une étape du flux de travail peut envoyer une demande à un agent pour accéder à une ressource distante ou appeler un service distant. Les demandes et les réponses sont généralement envoyées de manière asynchrone.
• Un agent accède à la ressource ou au service distant. L’agent doit inclure la gestion des erreurs et la logique de nouvelle tentative.
• Le Scheduler gère l’état de chaque étape dans le magasin d’état, à mesure qu’elles démarrent et se terminent.
• Le superviseur surveille l’état des étapes dans le magasin d’état et peut demander la mise à jour de l’état d’une étape.
• Le superviseur demande au planificateur de retenter une étape ayant échoué.

Quand l’application est prête à exécuter une tâche, elle soumet une requête au planificateur. Le planificateur enregistre l’état initial de la tâche et de ses étapes, par exemple étape non démarrée, dans le magasin d’état, puis commence à exécuter les opérations définies par le flux de travail. Lorsque le planificateur démarre chaque étape, il met à jour l’état de cette étape, par exemple étape en cours d’exécution, dans le stockage d’état.

Si une étape référence une ressource ou un service distant, le planificateur envoie un message à l’agent approprié. Le message contient les informations dont l’Agent a besoin pour invoquer le service ou accéder à la ressource, ainsi que l’échéance et le nombre de tentatives autorisées pour l’opération.

Un agent peut implémenter la logique de nouvelle tentative appropriée pour son travail, mais si l’agent ne termine pas son travail dans le temps complet, le Planificateur suppose que l’opération a échoué et cesse d’attendre une réponse. L’Agent doit observer l’échéance et ne doit pas commencer de nouveaux effets secondaires après l’expiration du délai, bien que le travail déjà en cours puisse continuer.

Si l’agent accomplit son opération avec succès, il renvoie une réponse au planificateur. Le planificateur met à jour l’état, à l’étape terminée par exemple, et commence l’étape suivante. Ce processus se poursuit jusqu’à ce que la tâche entière soit terminée.

Le planificateur doit ignorer toute réponse tardive, et l’agent ne doit pas tenter la récupération du flux de travail par elle-même. Si l’agent lui-même échoue, le planificateur ne reçoit pas non plus de réponse. L’état dans le stockage d’état ne fait volontairement pas la distinction entre une étape qui dépasse le délai imparti et une étape qui échoue.

Lorsqu’une étape dépasse le délai imparti ou échoue, l’enregistrement du stockage d’état indique toujours que l’étape est en cours d’exécution, mais avec une échéance d’achèvement expirée. Le superviseur analyse les enregistrements dans cette condition et organise la récupération.

Le superviseur doit également empêcher la même étape de réessayer indéfiniment. Le superviseur gère un décompte de nouvelles tentatives pour chaque étape, en même temps que les informations d’état, dans le magasin d’état. Si le nombre dépasse un seuil prédéfini, le superviseur peut être défini pour attendre une période prolongée avant de demander au planificateur de réessayer l’étape, en cas d’effacement de l’erreur sous-jacente pendant cet intervalle.

Une stratégie possible du Superviseur consiste à prolonger la valeur « complete-by » et à envoyer un message au Planificateur indiquant l’étape ayant expiré, afin que le Planificateur puisse la relancer. Cette conception nécessite que la logique d’étape soit idempotente, car le même travail peut être effectué plusieurs fois.

Vous pouvez également demander au planificateur d’annuler toute la tâche en déclenchant une transaction de compensation. Cette approche dépend du planificateur et des agents fournissant suffisamment d’informations pour implémenter des opérations de compensation pour chaque étape qui s’est déjà terminée avec succès. Le journal de compensation a besoin de classement et de durabilité, car les opérations de compensation s’exécutent généralement dans l’ordre inverse des étapes terminées. Une opération de compensation qui échoue elle-même laisse la tâche dans un état où elle n’est ni terminée ni correctement annulée. Le magasin d’état doit être en mesure de déclarer cette condition afin que les opérateurs puissent la localiser et l’analyser.

Dans une implémentation réelle de ce modèle, plusieurs instances du Planificateur peuvent s’exécuter simultanément, chacune gérant un sous-ensemble de tâches. Le système peut également exécuter plusieurs instances de chaque agent ou plusieurs superviseurs. Lorsque plusieurs superviseurs sont actifs, les superviseurs doivent coordonner afin qu’ils ne soient pas en concurrence pour récupérer la même étape ou tâche ayant échoué. Le modèle d’élection du chef est un moyen de coordonner les superviseurs.

Le principal avantage de ce modèle est que le système reste résilient aux défaillances temporaires et irrécupérables, et que vous pouvez le construire pour être auto-guérisseur. Si un agent ou le planificateur échoue, vous pouvez démarrer une nouvelle instance et le superviseur peut organiser la reprise de la tâche affectée. Si le Superviseur lui-même tombe en panne, une autre instance peut reprendre là où la précédente s’est arrêtée. Lorsque le superviseur s’exécute selon une planification, une nouvelle instance démarre automatiquement à l’intervalle suivant. Vous pouvez également répliquer le magasin d’état afin d’améliorer la résilience.

Problèmes et considérations

Prenez en compte les points suivants lorsque vous choisissez comment implémenter ce modèle :

• Complexité de l’implémentation. Ce modèle est difficile à implémenter et nécessite des tests approfondis de chaque mode d’échec que le système peut rencontrer. Planifiez les tests d’injection de panne, ainsi que les tests fonctionnels.

• Réessayer l’amplification. Les limites indépendantes de nouvelles tentatives au niveau des couches agent, runtime d’orchestration, bibliothèque de client, messaging et supervision multiplient le nombre d’appels à une dépendance défaillante. Désignez l’ordonnanceur comme responsable d’un budget durable de tentatives de nouvelle exécution de bout en bout, et configurez ou désactivez les tentatives de nouvelle exécution dans les autres couches afin que leur cumul maximal ne dépasse pas ce budget.

• Contrôle d’admission. Le modèle ne limite pas la quantité de travail possible en vol à la fois. Étant donné que le planificateur est conçu pour ne jamais perdre les tâches qu’il accepte, un service en aval lent ou défaillant entraîne une accumulation croissante d’enregistrements en cours de traitement plutôt qu’un signal visible de saturation pour l’émetteur. Le chemin de soumission doit disposer de son propre contrôle d’admission, par exemple une file d’attente bornée, un plafond du nombre de tâches simultanées en cours de traitement, ou le rejet de nouvelles soumissions lorsque la file d’attente dépasse un seuil. Cette régulation permet de garantir qu’un incident en aval ne provoque pas silencieusement une accumulation sans limite dans le magasin d’état.

• Durabilité de l’état de récupération. La logique de récupération et de nouvelle tentative du Planificateur est complexe et dépend de l’état conservé dans le magasin d’état. Vous devrez peut-être également enregistrer les informations nécessaires pour générer une transaction de compensation dans un magasin durable, et la transaction de compensation elle-même peut échouer. Traitez le stockage d’état et tout journal de transactions compensatoires comme des actifs durables à part entière. Ces ressources doivent survivre au Scheduler, aux agents et au superviseur, et elles doivent être récupérables indépendamment des travailleurs qui les écrivent.

  Important

  Le journal de compensation doit hériter de la classification des données dont il a besoin pour effectuer le suivi. Si une étape accepte les données client ou de paiement, le journal des transactions de compensation hérite de cette sensibilité et des règles de rétention associées.

• Problème de double écriture. L’envoi d’une tâche implique généralement plusieurs écritures durables. Par exemple, une tâche peut devoir écrire à la fois un enregistrement de l’application dans une base de données métier et un enregistrement initial dans le magasin d’état. Ces écritures ne font pas partie de la même transaction. Par conséquent, si une seule des deux écritures aboutit, un enregistrement d’application peut se retrouver sans enregistrement dans le magasin d’état, ou un enregistrement dans le magasin d’état peut se retrouver sans enregistrement d’application. Le modèle actuel lui-même ne résout pas ce problème de double écriture. Les solutions courantes consistent notamment à effectuer les écritures dans une orchestration durable avec une suppression compensatoire en cas d’échec, à appliquer le modèle Transactional Outbox, ou à utiliser un identifiant stable, tel que l’ID de tâche propre à l’application, pour rendre chaque écriture répétable en toute sécurité.

• Gestion des versions de flux de travail et d’état. Les tâches longues peuvent s’étendre sur les déploiements, de sorte que les modifications apportées à la logique de flux de travail ou à l’état persistant peuvent empêcher la relecture, la récupération ou la compensation du travail en cours d’exécution. Versionnez les deux contrats et maintenez un code et une gestion d’état compatibles jusqu’à ce qu’aucune tâche active ne dépende d’eux.

• Résultats de compensation. Une transaction compensatoire peut s’achever, échouer ou se bloquer en cours d’exécution. L’ordinateur d’état que le Planificateur gère doit représenter tous ces états. Si l’erreur est le seul état terminal, une compensation bloquée ressemble à une étape qui a échoué avant l’exécution de la compensation, et les opérateurs perdent le signal qu’ils doivent intervenir. Il faut distinguer Compensation en cours, Compensation terminée et Échec de la compensation dans le schéma du magasin d’état plutôt que de réduire les trois au seul état Erreur.

• Rythme du superviseur. La fréquence à laquelle exécuter le superviseur est un compromis délibéré. Il doit s’exécuter assez souvent pour que les étapes en échec ou ayant expiré ne bloquent pas le travail pendant une période prolongée, mais pas au point de générer de la charge et des coûts pour le magasin d’état. Ajustez l’intervalle par rapport à la durée de l’étape classique et le délai de détection acceptable pour une étape bloquée, puis réexétez-le à mesure que le volume de flux de travail augmente.

• Idempotency d’étape. Un agent peut exécuter une étape plusieurs fois. Par exemple, le superviseur peut repousser l’échéance et demander au planificateur de relancer une étape dont la première exécution a déjà eu un effet, sans que le planificateur en ait jamais eu connaissance. Par conséquent, la logique qui implémente chaque étape doit être idempotente.

• Visibilité opérationnelle. Le comportement d’exécution du modèle est en transitions de magasin d’état plutôt qu’en réponses synchrones. Les opérateurs ne peuvent voir que ce que le magasin d’état et les travailleurs émettent. Déterminez ce que le planificateur, les agents et le superviseur doivent émettre, et quels seuils doivent déclencher des alertes.

• Redémarrage et récupération du planificateur. Si le planificateur redémarre après un échec ou si le workflow en cours d’exécution se termine de façon inattendue, le planificateur doit être en mesure de déterminer l’état de toute tâche qu’il gérait en cas d’échec et de reprise de la tâche à partir de ce point. Les détails de l’implémentation de cette récupération sont généralement spécifiques au système. Par exemple, un planificateur basé sur un runtime d’orchestration avec points de contrôle peut s’appuyer sur le runtime pour rejouer l’historique et reprendre l’exécution, tandis qu’un planificateur personnalisé doit reconstruire lui-même l’état des opérations en cours à partir du magasin d’état. Si une tâche ne peut pas être récupérée, le travail déjà effectué pour cette tâche peut avoir besoin d’être annulé, ce qui peut nécessiter une transaction de compensation.

Quand utiliser ce modèle

Utilisez ce modèle dans les situations suivantes :

• Un processus s’exécute dans une charge de travail distribuée et doit rester résilient aux défaillances de communication et aux défaillances opérationnelles entre les services et les ressources qu’il coordonne.

• Les travaux en arrière-plan orchestrent des flux de travail à plusieurs étapes dont les étapes impliquent des services ou des ressources distants, et les flux de travail dans son ensemble doivent être terminés ou annulés correctement. Les exemples courants incluent le traitement des commandes et le provisionnement des ressources. Pour plus d’informations, consultez Les meilleures pratiques pour les travaux en arrière-plan.

Ce modèle peut ne pas convenir lorsque :

• La tâche n’appelle pas les services distants ni n’accède aux ressources distantes. Il n’existe aucun point de défaillance distribué à atténuer pour les rôles Planificateur, Agent et Superviseur. La surcharge de coordination du modèle ajoute des coûts sans avantage de résilience.

Conception de la charge de travail

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

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

Exemple

Cet exemple déploie une application web qui implémente un système de commerce électronique sur Microsoft Azure. Les utilisateurs parcourent les produits et passent des commandes via une interface web, tandis que les processus en arrière-plan du flux de traitement des commandes appellent un service distant sujet à des défaillances transitoires et plus durables. Le traitement des commandes implémente le modèle superviseur de l’agent planificateur à l’aide de Durable Functions, de Azure Service Bus et de Azure Cosmos DB.

Une activité de soumission écrit dans la base de données des commandes et dans un magasin d’état Cosmos DB, un orchestrateur Durable Functions prend en charge les enregistrements d’état en attente et répartit le travail vers un agent via une paire de files d’attente Service Bus de requêtes et de réponses, et un superviseur analyse le magasin d’état à la recherche de durées CompleteBy expirées.

Le diagramme suivant montre une vue générale de la solution Azure.

1. L’application envoie une requête à une file d’attente pour traiter la commande.
2. Le processus de soumission récupère les demandes, insère les détails de la commande dans la base de données des commandes et génère un enregistrement de la commande dans le magasin d’état.
3. Le Scheduler recherche dans le magasin d’état une commande avec LockedBy défini sur null, et la logique de workflow du Scheduler traite la commande.
4. La logique de flux de travail envoie des requêtes à des agents et reçoit des réponses des agents par le biais de files d’attente de messages.
5. Les tâches de flux de travail utilisent des agents pour appeler le service distant.
6. Le superviseur recherche les commandes avec une valeur expirée CompleteBy et met à jour cette valeur pour permettre au planificateur de réattemper le processus.

Soumission

Lorsqu’un client passe une commande, le front-end web publie un message de commande vers une file d’attente Service Bus. Une fonction de soumission reçoit le message en mode PeekLock, insère les détails de la commande dans la base de données des commandes et crée un enregistrement dans le magasin d’état pour le traitement de la commande.

Étant donné que la base de données de commandes et la base de données créée avec Azure Cosmos DB sont des ressources différentes et ne partagent pas de transaction, la fonction traite chaque écriture comme idempotente indépendamment. La fonction utilise l’ID d’ordre comme clé stable, crée l’un ou l’autre enregistrement lorsqu’il est manquant et accepte un enregistrement existant uniquement après avoir vérifié que ses données de commande immuables correspondent au message. En présence de données contradictoires, la fonction place le message dans la file de lettres mortes et alerte un opérateur, au lieu d’écraser un enregistrement.

L’enregistrement contient les champs suivants :

Lorsque l’activité de soumission écrit l’enregistrement pour la première fois, elle copie OrderID depuis la nouvelle commande, définit CompleteBy et Pending sur LockedBy, définit ProcessState sur null et définit FailureCount sur 0.

Ordonnancement

Le planificateur est un orchestrateur Durable Functions. Une fonction de démarrage interroge Azure Cosmos DB pour les enregistrements où LockedBy est null et ProcessState est Pending. La fonction crée un ID d’instance d’orchestration propre à une tentative à partir de OrderID et du numéro de tentative suivant. Une mise à jour conditionnelle définit ProcessState sur Processing et LockedBy sur cet ID d’instance avant que le démarreur ne planifie l’orchestration. Cette réclamation empêche deux débutants de planifier la même tentative.

Chaque mise à jour de l’orchestration vérifie également que LockedBy correspond toujours à son ID d’instance. Cette vérification empêche une tentative expirée de modifier l’état d’une tentative de remplacement. Le parallélisme inter-ordre provient de l’exécution simultanée de nombreuses instances d’orchestration, pas du parallélisme à l’intérieur d’un ordre. L’orchestration définit CompleteBy et pilote le flux de travail.

L’orchestrateur récupère les détails de la commande à partir de la base de données de commandes et exécute le flux de travail sous la forme d’une séquence de fonctions d’activité. Lorsqu’une étape a besoin du service distant, elle appelle un agent.

Execution

L’Agent peut être une fonction d’activité lorsque le travail est de courte durée et s’exécute dans la même application de fonction, ou il peut s’agir d’un processus de travail distinct accessible via une paire de files d’attente requête/réponse Service Bus lorsqu’il s’exécute dans un environnement d’exécution différent ou au-delà d’une frontière de confiance. Dans les deux cas, l’orchestrateur applique un retardateur durable à la réponse de l’agent pour détecter l’échéance CompleteBy.

Lorsque l’agent est joint via Service Bus, une fonction déclenchée par la file d’attente reçoit la réponse et utilise le client Durable Functions pour lever un événement externe qui comprend l’ID de l’instance d’orchestration et un ID d’événement stable. L’orchestrateur déduplique les événements externes en activant la détection dupliquée et en définissant une stabilité MessageId sur chaque requête, afin que Service Bus puisse ignorer les doublons introduits par des nouvelles tentatives.

Si l’Agent reçoit une réponse du service distant avant le déclenchement du minuteur durable, l’Agent retourne le résultat à l’orchestrateur. L’orchestrateur termine l’étape et met à jour ProcessState en Processed uniquement si LockedBy identifie toujours l’orchestration actuelle. Si le temporisateur se déclenche en premier, l’orchestrateur considère l’étape comme ayant échoué, cesse d’attendre et s’achève sans modifier l’enregistrement d’état.

L’agent cesse de manière coopérative de lancer de nouveaux effets secondaires une fois sa propre échéance atteinte, mais toute opération déjà en cours peut se poursuivre. L’enregistrement du magasin d’état reste ensuite à l’état Processing avec une valeur CompleteBy expirée, ce qui permet au superviseur d’organiser la récupération. Utilisez l’idempotence ou un jeton de délimitation imposé par la cible pour empêcher toute tentative se chevauchant de dupliquer un effet secondaire ou d’entrer en conflit avec celui-ci.

Si l’agent détecte une erreur irrécupérable et non temporaire lors du contact avec le service distant, elle retourne une réponse d’erreur à l’orchestrateur. L’orchestrateur définit ProcessStateError et déclenche un événement qui alerte un opérateur, qui peut examiner l’échec et soumettre à nouveau l’étape de traitement ayant échoué.

Surveillance

Le superviseur interroge régulièrement le magasin d’état Azure Cosmos DB pour les commandes dans l’état Processing avec une date d’expirationCompleteBy. Étant donné que OrderID est la clé de partition, cette requête interroge toutes les partitions physiques, même si ProcessState et CompleteBy sont indexés. Le processus délimite chaque analyse au moyen d’une CompleteBy fenêtre temporelle, d’un nombre maximal de résultats et d’une pagination à l’aide d’un jeton de continuation, et surveille sa consommation en unités de requête (RU).

Les charges de travail importantes conservent un index de récupération distinct ou une file d’attente distincte, partitionnés selon le schéma d’accès du Superviseur. Lorsque le superviseur trouve un enregistrement expiré, il utilise une mise à jour conditionnelle qui vérifie la valeur expirée LockedBy avant d’incrémenter FailureCount. Si FailureCount est inférieur à un seuil configuré, le superviseur réinitialise null à LockedBy, met à jour CompleteBy avec une nouvelle heure d’expiration et redéfinit ProcessState à Pending, ce qui permet au démarreur de planifier une nouvelle tentative. Si FailureCount dépasse le seuil, le superviseur considère la défaillance comme non transitoire, définit ProcessState sur Error et déclenche un événement qui alerte un opérateur.

Rapports d’état

L’orchestrateur peut également avoir besoin de conserver l’application qui a envoyé l’ordre informé de la progression et de l’état final, que le diagramme n’affiche pas. L’application et l’orchestrateur sont délibérément découplés. L’application ne sait pas quelle instance d’orchestration gère l’ordre et l’orchestration ne sait pas quelle instance d’application l’a publiée. En raison de ce découplage, l’orchestrateur ne peut pas renvoyer des mises à jour de progression de manière synchrone.

Pour renvoyer l’état de la commande, chaque application émettrice fournit sa propre file d’attente de réponses Service Bus privée, avec contrôle d’accès. La requête envoyée à l’activité de soumission inclut l’identifiant de cette file d’attente, que l’activité de soumission enregistre dans l’enregistrement du magasin d’état de la commande afin que l’orchestrateur puisse publier dans la bonne file d’attente plutôt que de diffuser. L’orchestrateur publie ensuite dans cette file d’attente des messages d’état tels que demande reçue, commande terminée ou échec de la commande, y compris le OrderID afin que l’application puisse associer chaque message à la demande d’origine.

Technologies de prise en charge

Mappez les rôles logiques du modèle aux services qui correspondent à vos besoins opérationnels et de flux de travail :

• Planificateur : Utilisez Durable Functions pour une orchestration axée sur le code ou Azure Logic Apps pour des flux de travail visuels et une intégration basée sur des connecteurs.

• Messagerie d’agent : Utilisez les files d’attente Service Bus pour les échanges asynchrones de requêtes et de réponses.

• Magasin d’état : Utilisez Azure Cosmos DB pour l’état du document ou Azure SQL Database pour les transactions d’état relationnel et d’enregistrement croisé.

• Superviseur : Utilisez un déclencheur de minuteur Functions pour les analyses légères ou un travail Container Apps lorsque vous avez besoin d’un runtime de conteneur.

• Journal de compensation : stockez les enregistrements de compensation avec l’état de la tâche ou bien dans le Stockage Table Azure ou le Stockage Blob.

Étapes suivantes

• Choisissez entre Azure Functions et Azure Logic Apps pour l’orchestration de flux de travail.
• Versionnez les orchestrations Durable Functions pour protéger les flux de travail en cours d’exécution pendant les déploiements.
• Empêchez la perte de messages et le traitement en double dans Azure Service Bus en combinant le règlement des messages, l’idempotency et la gestion des lettres mortes.

Ressources associées

Les modèles suivants peuvent également être pertinents lors de l’implémentation de ce modèle :

• Schéma de Réessai. Un agent peut utiliser ce modèle pour réessayer de manière transparente une opération qui accède à un service ou une ressource distant et a échoué précédemment. Utilisez-la lorsque la cause de l’échec est censée être temporaire et peut être corrigée par une nouvelle tentative.

• Modèle Circuit Breaker. Un agent se connectant à un service distant ou à une ressource peut utiliser ce modèle pour gérer les erreurs qui prennent un certain temps pour corriger, de sorte que les appels répétés ne s’empilent pas sur une dépendance qui est peu susceptible de répondre.

• Modèle de transaction de compensation. Si un planificateur ne peut pas terminer son workflow correctement, le travail déjà effectué peut être annulé. Le modèle de transaction de compensation décrit comment annuler ce travail pour les opérations qui suivent le modèle de cohérence éventuelle, qui est courant dans les processus métier longs coordonnés par un Scheduler.

• Modèle d’élection du responsable. Lorsque plusieurs instances de superviseur s’exécutent simultanément, elles doivent coordonner afin qu’elles ne soient pas en concurrence pour récupérer la même étape ayant échoué. Le modèle d’élection du chef décrit comment choisir un coordinateur unique pour ce travail.