Comment construire des microservices avec Spring Boot : config, discovery, resilience ?

Question

IT Interview Practice · Accepted Answer

Spring Boot associé à Spring Cloud vous donne les briques de base des microservices. Les trois problèmes que tout système distribué doit résoudre sont la **configuration centralisée**, la **service discovery** et la **résilience** face aux défaillances partielles. ## Les pièces mobiles ```text ┌── Config Server (git-backed properties) │ Client ──▶ API Gateway ──▶ Service A ──▶ Service B │ │ │ └──▶ Discovery (Eureka / K8s DNS) ◀── register + look up ``` - Le **Config Server** sert les properties de chaque service depuis un dépôt git central, si bien que vous changez la config sans redéployer. Les services la récupèrent au démarrage (et se rafraîchissent via `/actuator/refresh`). - La **service discovery** (Eureka, Consul ou le DNS de Kubernetes) permet au Service A de trouver le Service B par son *nom* au lieu d'un hôte codé en dur, de sorte que les instances peuvent monter en charge et se déplacer librement. - L'**API Gateway** (Spring Cloud Gateway) est le point d'entrée unique pour le routage, l'auth et le rate limiting. ## Résilience — la partie que les juniors sautent Dans un système distribué, chaque appel réseau *finira* par échouer. Utilisez Resilience4j pour empêcher qu'un service lent ne se propage en panne : ```java @CircuitBreaker(name = "inventory", fallbackMethod = "cachedStock") @Retry(name = "inventory") // réessaie les à-coups transitoires @TimeLimiter(name = "inventory") // plafonne l'attente public CompletableFuture stock(String sku) { return inventoryClient.get(sku); // appel distant } // Appelée quand le circuit est ouvert ou que l'appel échoue — dégrade en douceur. public CompletableFuture cachedStock(String sku, Throwable ex) { return CompletableFuture.completedFuture(Stock.unknown(sku)); } ``` Le **circuit breaker** s'ouvre après des échecs répétés, de sorte que les appels échouent rapidement au lieu d'empiler des threads en attente d'une dépendance morte. ## Pourquoi c'est important Les entretiens seniors sondent la maturité en systèmes distribués. Nommer la discovery et la config est le minimum ; le facteur différenciant est de parler de la **défaillance** : circuit breakers, timeouts, idempotence et observabilité (tracing distribué avec Micrometer/Zipkin). Les bons candidats savent aussi nuancer — en notant que les microservices ajoutent un coût opérationnel et qu'un monolithe est souvent le bon choix jusqu'à ce que l'échelle l'exige.

Les pièces mobiles

Résilience — la partie que les juniors sautent

Pourquoi c'est important

Questions connexes