Modèle Disjoncteur

Le modèle Disjoncteur permet de gérer les erreurs qui peuvent prendre différents délais de récupération lorsqu’une application se connecte à un service ou une ressource distant. Un disjoncteur bloque temporairement l’accès à un service défectueux après qu’il détecte les défaillances. Cette action empêche les tentatives infructueuses répétées afin que le système puisse récupérer efficacement. Ce modèle peut améliorer la stabilité et la résilience d’une application.

Contexte et problème

Dans un environnement distribué, les appels aux ressources et services distants peuvent échouer en raison d’erreurs temporaires. Les erreurs temporaires incluent les ressources surcommises ou temporairement indisponibles, les connexions réseau lentes ou les délais d’attente. Ces erreurs se corrigent généralement après une courte période de temps. Pour faciliter la gestion de ces erreurs, vous devez concevoir une application cloud pour utiliser une stratégie, telle que le modèle Nouvelle tentative.

Les événements imprévus peuvent créer des erreurs qui prennent plus de temps pour corriger. Ces erreurs peuvent être de gravité allant d’une perte partielle de connectivité à une défaillance complète du service. Dans ces situations, une application ne doit pas réessayer continuellement une opération qui est peu susceptible de réussir. Au lieu de cela, l’application doit rapidement reconnaître l’opération ayant échoué et gérer l’échec en conséquence.

Si un service est occupé, une défaillance dans une partie du système peut entraîner des défaillances en cascade. Par exemple, vous pouvez configurer une opération qui appelle un service pour implémenter un délai d’attente. Si le service ne répond pas pendant cette période, l’opération répond avec un message d’échec.

Toutefois, cette stratégie peut bloquer les requêtes simultanées pour la même opération jusqu’à l’expiration du délai. Ces requêtes bloquées peuvent contenir des ressources système critiques, telles que la mémoire, les threads et les connexions de base de données. Ce problème peut épuiser les ressources, ce qui peut échouer dans d’autres parties non liées du système qui doivent utiliser les mêmes ressources.

Dans ces situations, une opération doit échouer immédiatement et tenter d’appeler le service uniquement s’il est susceptible de réussir. Pour résoudre ce problème, définissez un délai d’attente plus court. Mais assurez-vous que le délai d’attente est suffisamment long pour que l’opération réussisse la plupart du temps.

Solution

Le modèle Disjoncteur permet d’empêcher une application de tenter à plusieurs reprises d’exécuter une opération susceptible d’échouer. Ce modèle permet à l’application de continuer à s’exécuter sans attendre que l’erreur soit corrigée ou de perdre des cycles d’UC pour déterminer que l’erreur est persistante. Le modèle Disjoncteur permet également à une application de détecter quand l’erreur est résolue. Si l’erreur est résolue, l’application peut réessayer d’appeler l’opération.

Remarque

Le modèle Disjoncteur a un objectif différent de celui du modèle de Réessai. Le modèle nouvelle tentative permet à une application de réessayer une opération avec l’attente qu’elle aboutit. Le modèle de Circuit Breaker empêche une application d’effectuer une opération qui est susceptible d’échouer. Une application peut combiner ces deux modèles en utilisant le modèle Nouvelle tentative pour appeler une opération par le biais d’un disjoncteur. Toutefois, la logique de nouvelle tentative doit être sensible aux exceptions que le disjoncteur renvoie et arrêter les tentatives de réessai si le disjoncteur indique qu'une faute n'est pas transitoire.

Un disjoncteur agit comme un proxy pour les opérations qui risquent d’échouer. Le proxy doit surveiller le nombre d’échecs récents et utiliser ces informations pour décider s’il faut autoriser l’opération à continuer ou à retourner immédiatement une exception.

Vous pouvez implémenter le proxy en tant qu’ordinateur d’état qui inclut les états suivants. Ces états imitent la fonctionnalité d’un disjoncteur électrique :

• Fermé: La requête de l’application est acheminée vers l’opération. Le proxy maintient un compte des défaillances récentes. Si l’appel à l’opération échoue, le proxy incrémente ce nombre. Si le nombre d’échecs récents dépasse un seuil spécifié dans une période donnée, le proxy est placé dans l’état Open et démarre un minuteur de délai d’attente. Lorsque le minuteur expire, le proxy est placé dans l’état Demi-ouverture .

  Remarque

  Pendant le délai d’attente, le système tente de résoudre le problème qui a provoqué l’échec avant de permettre à l’application de réessayer l’opération.

• Ouvrir: La demande de l’application échoue immédiatement et une exception est retournée à l’application.

• Semi-ouvert: Un nombre limité de requêtes de l'application sont autorisées à passer et à invoquer l'opération. Si ces requêtes réussissent, le disjoncteur suppose que l’erreur qui a provoqué l’échec est corrigée et que le disjoncteur bascule vers l’état fermé . Le compteur d’échec est réinitialisé. Si une requête échoue, le disjoncteur suppose que l’erreur est toujours présente, de sorte qu’elle revient à l’état Ouvert . Il redémarre la minuterie d'attente afin que le système puisse se rétablir suite à la défaillance.

  Remarque

  L’état demi-ouvert permet d’empêcher un service de récupération d’être soudainement inondé de requêtes. Lorsqu’un service se rétablit, il peut être en mesure de prendre en charge un volume limité de requêtes jusqu’à ce que le rétablissement soit complet. Mais pendant que la récupération est en cours, un afflux de tâches peut entraîner l'interruption ou l'échec du service.

Le diagramme suivant montre les opérations de compteur pour chaque état.

Le diagramme montre trois sections étiquetées fermées, demi-ouvertes et ouvertes. L’état fermé inclut l’action pour réinitialiser le compteur d’échec. Si l’opération réussit, elle retourne un résultat ; sinon, le compteur d’échec de l’incrément renvoie un échec. L’état demi-ouvert inclut l’action pour réinitialiser le compteur de réussite. Si l’opération réussit, le compteur de réussite d’incrément retourne un résultat ; sinon, il retourne un échec. L’état ouvert inclut les actions permettant de démarrer le minuteur de délai d’attente, puis de renvoyer un échec. Une flèche de l’état fermé à ouvert indique que le seuil d’échec est atteint. Une flèche de l'état ouvert à l'état demi-ouvert indique que le minuteur de timeout a expiré. Une flèche de l’état demi-ouvert à l’état fermé indique que le seuil de nombre de réussites est atteint. Une flèche allant de l'état semi-ouvert à l'état ouvert indique que l’opération a échoué.

Le compteur d’échec pour l’état Fermé est basé sur le temps. Il réinitialise automatiquement à intervalles périodiques. Cette conception permet d’empêcher le disjoncteur d’entrer dans l’état Open s’il rencontre des défaillances occasionnelles. Le seuil d’échec déclenche l’état Open uniquement lorsqu’un nombre spécifié d’échecs se produit pendant un intervalle spécifié.

Le compteur de réussite de l’état Half-Open enregistre le nombre de tentatives réussies d’appel de l’opération. Le disjoncteur revient à l’état fermé après un nombre spécifié d’appels d’opération consécutifs réussis. Si un appel échoue, le disjoncteur entre immédiatement dans l’état Open et le compteur de réussite réinitialise la prochaine fois qu’il entre dans l’état Demi-Ouverture .

Remarque

La récupération du système est basée sur des opérations externes, telles que la restauration ou le redémarrage d’un composant défaillant ou la réparation d’une connexion réseau.

Le modèle Disjoncteur assure la stabilité pendant que le système récupère après un échec, et il réduit l’impact sur les performances. Il peut aider à maintenir le temps de réponse du système. Ce modèle rejette rapidement une demande d’une opération susceptible d’échouer, plutôt que d’attendre que l’opération expire ou ne revienne jamais. Si le disjoncteur déclenche un événement chaque fois qu’il change d’état, ces informations peuvent aider à surveiller l’intégrité du composant système protégé ou à alerter un administrateur lorsqu’un disjoncteur bascule vers l’état Ouvert .

Vous pouvez personnaliser et adapter ce modèle à différents types d’échecs. Par exemple, vous pouvez appliquer un minuteur de délai d’attente croissant à un disjoncteur. Vous pouvez placer le disjoncteur dans l’état Open pendant quelques secondes au départ. Si l’échec n’est pas résolu, augmentez le délai d’attente à quelques minutes et ajustez en conséquence. Dans certains cas, au lieu de retourner un échec et de déclencher une exception, l’état Open peut retourner une valeur par défaut significative à l’application.

Remarque

Traditionnellement, les disjoncteurs s’appuient sur des seuils préconfigurés, tels que le nombre d’échecs et la durée d’expiration. Cette approche a entraîné un comportement déterministe mais parfois non optimal.

Les techniques adaptatives qui utilisent l’IA et le Machine Learning peuvent ajuster dynamiquement les seuils en fonction des modèles de trafic en temps réel, des anomalies et des taux d’échec historiques. Cette approche améliore la résilience et l’efficacité.

Problèmes et considérations

Tenez compte des facteurs suivants lorsque vous implémentez ce modèle :

• Gestion des exceptions : Une application qui appelle une opération par le biais d’un disjoncteur doit être en mesure de gérer les exceptions si l’opération n’est pas disponible. La gestion des exceptions est basée sur l’application. Par exemple, une application peut dégrader temporairement ses fonctionnalités, appeler une autre opération pour essayer d’effectuer la même tâche ou obtenir les mêmes données, ou signaler l’exception à l’utilisateur et lui demander de réessayer ultérieurement.

• Types d’exceptions : Les raisons d’un échec de demande peuvent varier en gravité. Par exemple, une demande peut échouer, car un service distant se bloque et nécessite plusieurs minutes pour récupérer, ou parce qu’un service surchargé provoque un délai d’attente. Un disjoncteur peut être en mesure d’examiner les types d’exceptions qui se produisent et d’ajuster sa stratégie en fonction de la nature de ces exceptions. Par exemple, il peut nécessiter un plus grand nombre d’exceptions de délai d’attente pour déclencher le disjoncteur à l’état Open par rapport au nombre d’échecs causés par le service indisponible.

• Surveillance: Un disjoncteur doit fournir une observabilité claire dans les demandes ayant échoué et réussies afin que les équipes d’exploitation puissent évaluer l’intégrité du système. Utilisez le suivi distribué pour une visibilité de bout en bout entre les services.

• Recouvrabilité: Vous devez configurer le disjoncteur pour qu’il corresponde au modèle de récupération probable de l’opération qu’il protège. Par exemple, si le disjoncteur reste dans l’état Open pendant une longue période, il peut déclencher des exceptions même si la raison de l’échec est résolue. De même, un disjoncteur peut varier et réduire les temps de réponse des applications s’il passe de l’état Open à l’état Demi-Ouverture trop rapidement.

• Échec des tests d’opérations : Dans l’état Ouvrir , au lieu d’utiliser un minuteur pour déterminer quand basculer vers l’état Demi-Ouverture , un disjoncteur peut effectuer régulièrement un test ping sur le service distant ou la ressource pour déterminer s’il est disponible. Ce test ping peut tenter d'invoquer une opération ayant échoué précédemment ou d'utiliser une opération spéciale de vérification de l'état de santé, fournie par le service distant. Pour plus d’informations, consultez Modèle Supervision de point de terminaison d’intégrité.

• Commande manuelle : Si le temps de récupération d’une opération défaillante est extrêmement variable, vous devez fournir une option de réinitialisation manuelle qui permet à un administrateur de fermer un disjoncteur et de réinitialiser le compteur d’échec. De même, un administrateur peut forcer un disjoncteur dans l’état Ouvert et redémarrer le minuteur de délai d’attente si l’opération protégée n’est pas disponible temporairement.

• Concurrence: Un grand nombre d’instances simultanées d’une application peut accéder au même disjoncteur. L’implémentation ne doit pas bloquer les demandes simultanées, ni ajouter une surcharge excessive à chaque appel à une opération.

• Différenciation des ressources : Soyez prudent lorsque vous utilisez un disjoncteur unique pour un type de ressource s’il peut y avoir plusieurs fournisseurs indépendants sous-jacents. Par exemple, dans un entrepôt de données qui contient plusieurs partitions, une partition peut être entièrement accessible alors qu'une autre subit un problème temporaire. Si les réponses d’erreur dans ces scénarios sont fusionnées, une application peut essayer d’accéder à certaines partitions même en cas d’échec. Et l’accès à d’autres fragments peut être bloqué même s’il est probable qu’il réussisse.

• Rupture de circuit accélérée : Parfois, une réponse d’échec peut contenir suffisamment d’informations pour que le disjoncteur se déclenche immédiatement et reste en position déclenchée pendant une durée minimale. Par exemple, la réponse d’erreur d’une ressource partagée surchargée peut indiquer que l’application doit réessayer en quelques minutes, au lieu de réessayer immédiatement.

• Déploiements multirégions : Vous pouvez concevoir un disjoncteur pour des déploiements à une seule région ou à plusieurs régions. Pour concevoir des déploiements multirégions, utilisez des équilibreurs de charge globaux ou des stratégies de rupture de circuit personnalisées prenant en charge les régions qui permettent de garantir le basculement contrôlé, l’optimisation de la latence et la conformité réglementaire.

• Disjoncteurs de maillage de service : Vous pouvez implémenter des disjoncteurs au niveau de la couche application ou en tant que fonctionnalité croisée et abstraite. Par exemple, les maillages de service prennent souvent en charge la rupture de circuit en tant que side-car ou en tant que fonctionnalité autonome sans modifier le code de l’application.

  Remarque

  Un service peut retourner HTTP 429 (trop de requêtes) s’il limite le client ou HTTP 503 (service indisponible) si le service n’est pas disponible. La réponse peut inclure d’autres informations, telles que la durée prévue du délai.

• Échec de la relecture de la demande : Dans l’état Open , au lieu d’échouer rapidement, un disjoncteur peut également enregistrer les détails de chaque requête dans un journal et organiser la relecture de ces demandes lorsque la ressource ou le service distant devient disponible.

• Délais d’attente inappropriés sur les services externes : Un disjoncteur peut ne pas protéger entièrement les applications contre les défaillances dans les services externes qui ont des périodes d’attente longues. Si le délai d’attente est trop long, un thread qui exécute un disjoncteur peut être bloqué pendant une période prolongée avant que le disjoncteur indique que l’opération a échoué. Pendant ce temps, de nombreuses autres instances d’application peuvent également essayer d’appeler le service via le disjoncteur et de lier de nombreux threads avant qu’ils ne échouent.

• Adaptabilité à la diversification du calcul : Les disjoncteurs doivent tenir compte des différents environnements de calcul, de serverless à des charges de travail conteneurisées, où les facteurs tels que les démarrages à froid et la scalabilité affectent la gestion des défaillances. Les approches adaptatives peuvent ajuster dynamiquement des stratégies basées sur le type de calcul, ce qui permet de garantir la résilience entre les architectures hétérogènes.

Quand utiliser ce modèle

Utilisez ce modèle dans les situations suivantes :

• Vous souhaitez éviter les défaillances en cascade en arrêtant des appels de service distant excessifs ou des demandes d’accès à une ressource partagée si ces opérations risquent d’échouer.

• Vous souhaitez router le trafic intelligemment en fonction des signaux d’échec en temps réel afin d’améliorer la résilience multirégion.

• Vous souhaitez vous protéger contre les dépendances lentes afin de pouvoir maintenir vos objectifs de niveau de service et éviter une dégradation des performances des services à latence élevée.

• Vous souhaitez gérer les problèmes de connectivité intermittents et réduire les échecs de requête dans les environnements distribués.

Ce modèle peut ne pas convenir lorsque :

• Vous devez gérer l’accès aux ressources privées locales dans une application, telles que les structures de données en mémoire. Dans cet environnement, un disjoncteur ajoute une surcharge à votre système.

• Vous devez l’utiliser comme substitut de la gestion des exceptions dans la logique métier de vos applications.

• Les algorithmes de nouvelle tentative connus sont suffisants et vos dépendances sont conçues pour gérer les mécanismes de nouvelle tentative. Dans ce scénario, un disjoncteur dans votre application peut ajouter une complexité inutile à votre système.

• Attendre qu’un disjoncteur se réinitialise peut entraîner des retards inacceptables.

• Vous disposez d’une architecture pilotée par les messages ou les événements, car elle route souvent les messages ayant échoué vers une file d’attente de messages morts pour un traitement manuel ou différé. L’isolation des défaillances intégrées et les mécanismes de nouvelle tentative sont souvent suffisants.

• La récupération après échec est gérée au niveau de l’infrastructure ou de la plateforme, par exemple avec des vérifications de l’état de santé dans les équilibreurs de charge globaux ou les maillages de service.

Conception de la charge de travail

Évaluez comment utiliser le modèle de disjoncteur dans la conception d'une charge de travail pour assurer les objectifs et principes définis 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.

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.	Ce modèle permet d’empêcher une dépendance défaillante de surcharger. Utilisez ce modèle pour déclencher une dégradation normale dans la charge de travail. Coupler des disjoncteurs avec récupération automatique pour garantir l'auto-préservation et l'auto-guérison. - RE :03 Analyse du mode d’échec - Erreurs temporaires - RE :07 Auto-conservation
L’efficacité des performances permet à votre charge de travail de répondre efficacement aux demandes par le biais d’optimisations de la mise à l’échelle, des données et du code.	Ce modèle évite l’approche de réessai en cas d'erreur, ce qui peut entraîner une utilisation excessive des ressources pendant la récupération des dépendances et peut surcharger les performances d'une dépendance en cours de récupération. - PE :07 Code et infrastructure - PE :11 Réponses aux problèmes en direct

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

Exemple :

Cet exemple implémente le modèle Circuit Breaker pour aider à empêcher le dépassement de quota en utilisant l'offre gratuite à vie d'Azure Cosmos DB. Ce niveau est principalement destiné aux données non critiques et fonctionne sous un plan de capacité qui alloue un quota spécifique d’unités de ressources par seconde. Pendant les événements saisonniers, la demande peut dépasser la capacité fournie, ce qui peut entraîner des réponses 429.

Lorsque des pics de demande se produisent, Les alertes Azure Monitor avec des seuils dynamiques détectent et notifient de manière proactive les équipes d’exploitation et de gestion que la base de données nécessite plus de capacité. Simultanément, un disjoncteur paramétré à l’aide de modèles d’erreur historiques permet d’éviter les défaillances en cascade. Dans cet état, l’application dégrade correctement en retournant les réponses par défaut ou mises en cache. L’application informe les utilisateurs de l’indisponibilité temporaire de certaines données tout en préservant la stabilité globale du système.

Cette stratégie améliore la résilience qui s’aligne sur la justification métier. Il contrôle les augmentations de capacité afin que les équipes de charge de travail puissent gérer les augmentations de coûts délibérément et maintenir la qualité du service sans augmenter de façon inattendue les dépenses d’exploitation. Une fois que la demande diminue ou qu'une augmentation de la capacité est confirmée, le disjoncteur se réinitialise et l'application retourne à pleine fonctionnalité, qui s'aligne avec les objectifs techniques et budgétaires.

Le diagramme comporte trois sections principales. La première section contient deux icônes de navigateur web. La première icône affiche une interface utilisateur entièrement fonctionnelle, et la deuxième icône montre une expérience utilisateur détériorée qui a un avertissement à l’écran pour indiquer le problème aux utilisateurs. La deuxième section est entourée d’un rectangle en pointillés, divisé en deux groupes. Le groupe supérieur inclut les ressources de charge de travail, App Service et Azure Cosmos DB. Les flèches des deux icônes de navigateur web pointent vers l’instance App Service, représentant les requêtes entrantes du client. En outre, les flèches de l’instance App Service pointent vers Azure Cosmos DB, ce qui indique les interactions de données entre les services d’application et la base de données. Une autre flèche effectue une boucle de l’instance App Service vers elle-même, symbolisant le mécanisme de délai d’expiration du disjoncteur. Cette boucle signifie que lorsqu’une réponse 429 Trop de requêtes est détectée, le système revient à traiter les réponses mises en cache, ce qui dégrade l’expérience utilisateur jusqu’à ce que la situation soit résolue. Le groupe inférieur de cette section se concentre sur l’observabilité et les alertes. Azure Monitor collecte des données à partir des ressources Azure dans le groupe supérieur. Azure Monitor se connecte également à une icône de règle d’alerte. La troisième section montre le flux de travail d’extensibilité déclenché lorsque l’alerte est déclenchée. Une flèche connecte l’icône d’alerte aux approbateurs, ce qui indique que la notification est envoyée pour révision. Une autre flèche mène des approbateurs à une console de développement, ce qui signifie le processus d’approbation pour la mise à l’échelle de la base de données. Enfin, une flèche suivante s’étend de la console de développement à Azure Cosmos DB, qui représente l’action de la mise à l’échelle de la base de données en réponse à la condition de surcharge.

Téléchargez un fichier Visio de cette architecture.

Flux A : État fermé

• Le système fonctionne normalement et toutes les requêtes atteignent la base de données sans retourner de 429 réponses HTTP.

• Le disjoncteur reste fermé et aucune réponse par défaut ou mise en cache n’est nécessaire.

Flux B : État ouvert

1. Lorsque le disjoncteur reçoit la première 429 réponse, il se rend à un état Open .

2. Les demandes suivantes sont immédiatement court-circuitées, qui retournent des réponses par défaut ou mises en cache et informent les utilisateurs d’une dégradation temporaire. L’application est protégée contre une surcharge supplémentaire.

3. Azure Monitor reçoit les journaux de système et les données de télémétrie et les évalue par rapport aux seuils dynamiques. Une alerte se déclenche si les conditions de la règle d’alerte sont remplies.

4. Un groupe d’actions avertit de manière proactive l’équipe des opérations de la condition de surcharge.

5. Après approbation de l’équipe de charge de travail, l’équipe des opérations peut augmenter le débit approvisionné pour atténuer la surcharge ou retarder la mise à l’échelle si la charge diminue naturellement.

Flux C : état Half-Open

1. Après un délai d’attente prédéfini, le disjoncteur entre dans un état demi-ouvert qui autorise un nombre limité de demandes d’essai.

2. Si ces demandes d’évaluation réussissent sans renvoyer 429 de réponses, le disjoncteur est réinitialisé à un état fermé et les opérations normales sont rétablies dans Flow A. Si les défaillances persistent, le disjoncteur revient à l’état Open ou Flow B.

Composants

• Azure App Service héberge l’application web qui sert de point d’entrée principal pour les demandes clientes. Le code de l’application implémente la logique qui applique des stratégies de disjoncteur et fournit des réponses par défaut ou mises en cache lorsque le circuit est ouvert. Cette architecture permet d’empêcher la surcharge sur les systèmes en aval et de maintenir l’expérience utilisateur pendant les pics de demande ou les défaillances.

• Azure Cosmos DB est l’un des magasins de données de l’application. Il sert des données non critiques via le niveau gratuit, qui est idéal pour les charges de travail de petite production. Le mécanisme de disjoncteur permet de limiter le trafic vers la base de données pendant les périodes à forte demande.

• Azure Monitor fonctionne comme solution de supervision centralisée. Il agrège tous les journaux d’activité pour garantir une observabilité complète et de bout en bout. Azure Monitor reçoit des journaux et des données de télémétrie d'Azure App Service et des métriques clés d'Azure Cosmos DB (par exemple, le nombre de réponses 429) pour l'agrégation et l'analyse.

• alertes Azure Monitor peser les règles d’alerte par rapport aux seuils dynamiques pour identifier les pannes potentielles en fonction des données historiques. Les alertes prédéfinies informent l’équipe des opérations lorsque des seuils sont enfreints.

  Parfois, l’équipe de charge de travail peut approuver une augmentation du débit provisionné, mais l’équipe des opérations prévoit que le système peut récupérer seul, car la charge n’est pas trop élevée. Dans ce cas, le délai d’expiration du disjoncteur s’écoule naturellement. Pendant ce temps, si les réponses 429 cessent, le calcul du seuil détecte les pannes prolongées et les exclut de l’algorithme d’apprentissage. Par conséquent, la prochaine fois qu’une surcharge se produit, le seuil attend un taux d’erreur plus élevé dans Azure Cosmos DB, ce qui retarde la notification. Cet ajustement permet au disjoncteur de gérer le problème sans alerte immédiate, ce qui améliore le coût et l’efficacité opérationnelle.

Ressources associées

• Le modèle Web App Fiable applique le modèle du Disjoncteur aux applications web qui convergent dans le cloud.

• Le modèle nouvelle tentative décrit comment une application peut gérer les échecs temporaires anticipés lorsqu’elle tente de se connecter à un service ou à une ressource réseau en réessayant de manière transparente une opération ayant échoué précédemment.

• Le modèle de surveillance de l’intégrité des points de terminaison décrit comment un disjoncteur peut vérifier l’état de santé d’un service en envoyant une requête à un point de terminaison que le service expose. Le service doit retourner des informations qui indiquent son état.