```html
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
``` Aperçu Apprenez à rendre vos appels de microservices résilients à l'aide du modèle Circuit Breaker avec   et   — démo complète, commandes étape par étape, explications classe par classe, exemples de sorties, cas d'utilisation réels et conseils de production. Resilience4j Spring Boot Pourquoi est-ce important Dans les systèmes distribués, une défaillance d'un service en aval peut se propager et entraîner des pannes globales du système. Le modèle   : Circuit Breaker 
 
 
 
 
 Détecte une dépendance défaillante, Arrête de lui envoyer des requêtes (pour éviter de gaspiller des ressources), Retourne une réponse de repli gracieuse, Teste périodiquement la dépendance et rétablit le fonctionnement normal lorsqu'elle est saine. Cela réduit les temps d'arrêt, protège les pools de threads, maintient une expérience utilisateur raisonnable et empêche les tempêtes de tentatives de nouvelle connexion. Résumé de la démo (ce que vous avez) Une démo Maven à deux services : 
 
 
 
  (port  ) — un simple fournisseur REST qui échoue intentionnellement de manière intermittente. hello-service 8081 Point de terminaison GET /api/hello
 
 
 
 
  (port  ) — appelle hello-service en utilisant RestTemplate et est protégé par   avec un repli. client-service 8080 Resilience4j @CircuitBreaker Point de terminaison GET /api/get-message
 Exécutez les deux ( ) hello-service et client-service Testez ensuite GET http://localhost:8080/api/get-message
 Schéma d'architecture Il s'agit d'un flux petit et ciblé, adapté au dessin d'un diagramme. Fichiers et code : Explication classe par classe hello-service HelloServiceApplication.java 
 
 
 
 Classe de démarrage standard  . @SpringBootApplication HelloController.java

@RestController
public class HelloController {

    private static int counter = 0;

    @GetMapping("/api/hello")
    public String sayHello() {
        counter++;
        // Simuler une panne intermittente : tomber en panne à chaque 3ème requête
        if (counter % 3 == 0) {
            throw new RuntimeException("Échec simulé de Hello-Service !");
        }
        return "Bonjour de Hello-Service ! (count=" + counter + ")";
    }
}
  Ce contrôleur lance intentionnellement une RuntimeException lors d'appels périodiques pour simuler des pannes transitoires que l'on pourrait rencontrer dans des systèmes réels (panne de base de données, mauvaises données, timeouts). Explication : client-service ClientServiceApplication.java 
 
 Classe principale standard de Spring Boot. Aucune configuration spéciale requise. AppConfig.java
@Configuration
public class AppConfig {
    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}
  Fournit un seul bean RestTemplate. Assurez-vous que RestTemplate est un bean Spring afin que les proxys AOP/résilience puissent fonctionner correctement. Explication : HelloClientService.java
@Service
public class HelloClientService {

    private final RestTemplate restTemplate;

    @Value("${hello.service.url}")
    private String helloServiceUrl;

    public HelloClientService(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    @CircuitBreaker(name = "helloService", fallbackMethod = "fallbackHello")
    public String getHelloMessage() {
        System.out.println("Appel du service hello : " + helloServiceUrl);
        return restTemplate.getForObject(helloServiceUrl, String.class);
    }

    public String fallbackHello(Throwable t) {
        System.out.println("Repli déclenché : " + t);
        return "Le service Hello est actuellement indisponible. Veuillez réessayer plus tard.";
    }
}
 Explication (éléments cruciaux) 
 
 
 
 
 
 @CircuitBreaker(name = "helloService", fallbackMethod = "fallbackHello") encapsule l'appel getHelloMessage() dans un disjoncteur. Le nom est lié aux propriétés de configuration. 
 
 
 
 fallbackHello(Throwable t) est appelé lorsque l'appel échoue conformément aux règles du disjoncteur. Le repli doit :     o    Être dans la même classe

    o    Avoir le même type de retour

    o   Accepter les paramètres de la méthode d'origine (aucun ici) et un paramètre Throwable final (ou Exception/Throwable compatible avec les exceptions levées)
 
 
 Important : La méthode doit être publique et la classe doit être un bean Spring (@Service) pour que l'AOP basé sur les proxys fonctionne. ClientController.java
@RestController
public class ClientController {

    private final HelloClientService helloClientService;

    public ClientController(HelloClientService helloClientService) {
        this.helloClientService = helloClientService;
    }

    @GetMapping("/api/get-message")
    public String getMessage() {
        return helloClientService.getHelloMessage();
    }
}
  Un contrôleur simple qui délègue à  . Cela garantit que l'appel passe par le proxy où le disjoncteur est appliqué. Explication : HelloClientService Configuration utilisée (client-service application.properties) Configuration clé utilisée dans la démo server.port=8080
spring.application.name=client-service

hello.service.url=http://localhost:8081/api/hello

resilience4j.circuitbreaker.instances.helloService.registerHealthIndicator=true
resilience4j.circuitbreaker.instances.helloService.slidingWindowSize=5
resilience4j.circuitbreaker.instances.helloService.minimumNumberOfCalls=2
resilience4j.circuitbreaker.instances.helloService.failureRateThreshold=50
resilience4j.circuitbreaker.instances.helloService.waitDurationInOpenState=10s

logging.level.io.github.resilience4j.circuitbreaker=DEBUG
 Signification des propriétés importantes 
 
 
 
 
 
  nombre d'appels que le disjoncteur surveille pour le pourcentage d'échecs. slidingWindowSize :  nombre minimum d'appels avant que le taux d'échec ne soit évalué. minimumNumberOfCalls :  pourcentage d'échecs (par exemple, 50) pour ouvrir le circuit. failureRateThreshold :  durée pendant laquelle le circuit reste ouvert avant de passer à demi-ouvert. waitDurationInOpenState :  expose l'état du disjoncteur via l'actuateur. registerHealthIndicator : Exécution étape par étape et sorties attendues Démarrage des services 
 
 Démarrer  hello-service Visiter : http://localhost:8081/api/hello
  → "Bonjour de Hello-Service !" (ou lève une panne simulée) Retourne 
 
 Démarrer  client-service Visiter : http://localhost:8080/api/get-message
 Scénarios de test et sorties Scénario A — Hello-Service sain Faire une requête GET http://localhost:8080/api/get-message
 Journaux du client Appel du service hello : http://localhost:8081/api/hello
2025-11-13T11:58:23.366+05:30 DEBUG 32692 --- [client-service] [nio-8080-exec-8] i.g.r.c.i.CircuitBreakerStateMachine : CircuitBreaker 'helloService' succeeded:
2025-11-13T11:58:23.366+05:30 DEBUG 32692 --- [client-service] [nio-8080-exec-8] i.g.r.c.i.CircuitBreakerStateMachine : Event SUCCESS published: 2025-11-13T11:58:23.366634+05:30[Asia/Calcutta]: CircuitBreaker 'helloService' recorded a successful call. Elapsed time: 15 ms
 Réponse Bonjour de Hello-Service ! (count=4)
 Scénario B — Pannes intermittentes de Hello-Service Si vous appelez à plusieurs reprises et que hello-service lève une   pour certaines requêtes : RuntimeException ● Appels réussis : le client renvoie le message de bienvenue. ●  Lorsqu'un appel en aval renvoie un HTTP 500/exception :             o    Resilience4j enregistre l'échec.

            o    Si le taux d'échec dépasse le seuil (par exemple, 50 % sur la fenêtre glissante), le circuit devient **OUVERT**.

            o    Tant qu'il est OUVERT, les appels sont court-circuités ; **fallbackHello() est immédiatement exécuté — pas d'appel réseau. \n                        
 Réponse du client pendant le repli actif Réponse du client pendant l'activité Réponse Le service Hello est actuellement indisponible. Veuillez réessayer plus tard.
 Séquence d'exemple de journaux du client Appel du service hello : http://localhost:8081/api/hello
2025-11-13T12:00:55.842+05:30 DEBUG 32692 --- [client-service] [nio-8080-exec-1] i.g.r.c.i.CircuitBreakerStateMachine : CircuitBreaker 'helloService' recorded an exception as failure:
 Scénario C — Récupération Après    waitDurationInOpenState (10s) : 
 
 
 
 Le circuit passe à   : quelques appels de test sont autorisés. HALF_OPEN Si les appels de test réussissent, le disjoncteur se   et le trafic normal reprend. FERME Si les tests échouent, le disjoncteur repasse à  . OPEN Cas d'utilisation réels 
 
 
 
 
  Un service de paiement appelant une API bancaire externe : si l'API de la banque devient lente/échoue, le disjoncteur renvoie un message convivial pour l'utilisateur et évite les tempêtes de nouvelles tentatives. Intégration de paiement -  APIs avec un nombre limité d'appels par seconde — lorsque les limites sont atteintes, le circuit s'ouvre pour éviter de dépasser les quotas ; le repli renvoie des données mises en cache. APIs tierces limitées par débit -  Le service A appelle B, qui appelle C. Si C est instable, les disjoncteurs ouverts protègent B et A, empêchant un ralentissement à l'échelle du système. Chaînes de microservices au sein d'une entreprise -  Lorsqu'un service de fonctionnalité non critique échoue, renvoie un résultat plus simple pour maintenir la fonctionnalité principale disponible (par exemple, renvoyer la liste des produits sans recommandations). Interrupteurs de fonctionnalités et dégradation progressive - Avantages et valeur commerciale 
 
 
 
 
 
 
  — empêche une mauvaise dépendance de se propager. Isolation des pannes  — échoue rapidement au lieu d'attendre les timeouts. Réponse plus rapide aux pannes  — offre des réponses de repli au lieu de pannes complètes. Dégradation gracieuse  — évite de gaspiller du CPU, des threads et du réseau. Protection des ressources  — revient automatiquement à la normale lorsque la dépendance est saine. Récupération automatique  — les états et les métriques du disjoncteur peuvent être exposés via l'Actuateur et surveillés. Observabilité Exemples de journaux que vous verrez (réalistes) Appel du service hello : http://localhost:8081/api/hello
2025-11-13T12:00:55.842+05:30 DEBUG 32692 --- [client-service] [nio-8080-exec-1] i.g.r.c.i.CircuitBreakerStateMachine : CircuitBreaker 'helloService' recorded an exception as failure
2025-11-13T12:00:55.847+05:30 DEBUG 32692 --- [client-service] [nio-8080-exec-1] i.g.r.c.i.CircuitBreakerStateMachine : Event ERROR published: 2025-11-13T12:00:55.847908200+05:30[Asia/Calcutta]: CircuitBreaker 'helloService' recorded an error: 'org.springframework.web.client.HttpServerErrorException$InternalServerError: 500 : "{"timestamp":"2025-11-13T06:30:55.842+00:00","status":500,"error":"Internal Server Error","path":"/api/hello"}"'. Elapsed time: 8 ms
Fallback triggered: org.springframework.web.client.HttpServerErrorException$InternalServerError: 500 : "{"timestamp":"2025-11-13T06:30:55.842+00:00","status":500,"error":"Internal Server Error","path":"/api/hello"}"


Read My Stories

Cet audio est produit dans la langue originale de l'histoire !

Comment créer des API résilientes avec Resilience4j Circuit Breaker dans Spring Boot

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Télégramme : le pont de Crypto Island vers le continent

Croissance des crypto-monnaies : créer des profils d'utilisateurs efficaces

Nomades numériques, écoutez : ce que vous devez savoir sur le nouveau visa DTV de la Thaïlande

Appuyez pour gagner : Telegram pourrait intégrer les 10 prochains milliards d'utilisateurs de crypto avant Solana

Télégramme : le pont de Crypto Island vers le continent

Croissance des crypto-monnaies : créer des profils d'utilisateurs efficaces

Nomades numériques, écoutez : ce que vous devez savoir sur le nouveau visa DTV de la Thaïlande

Appuyez pour gagner : Telegram pourrait intégrer les 10 prochains milliards d'utilisateurs de crypto avant Solana

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps