Come si costruiscono microservizi con Spring Boot: config, discovery, resilienza?

Question

IT Interview Practice · Accepted Answer

Spring Boot insieme a Spring Cloud ti dà i mattoni per i microservizi. I tre problemi che ogni sistema distribuito deve risolvere sono la **configurazione centralizzata**, la **service discovery** e la **resilienza** contro i fallimenti parziali. ## Le parti in gioco ```text ┌── Config Server (git-backed properties) │ Client ──▶ API Gateway ──▶ Service A ──▶ Service B │ │ │ └──▶ Discovery (Eureka / K8s DNS) ◀── register + look up ``` - Il **Config Server** serve le properties di ciascun servizio da un repository git centrale, così cambi la configurazione senza ridistribuire. I servizi la recuperano all'avvio (e la aggiornano tramite `/actuator/refresh`). - La **service discovery** (Eureka, Consul o Kubernetes DNS) permette al Service A di trovare il Service B per *nome* invece che tramite un host hard-coded, così le istanze possono scalare e spostarsi liberamente. - L'**API Gateway** (Spring Cloud Gateway) è il punto d'ingresso unico per il routing, l'autenticazione e il rate limiting. ## Resilienza — la parte che i junior saltano In un sistema distribuito ogni chiamata di rete *prima o poi* fallirà. Usa Resilience4j per impedire che un servizio lento provochi un'interruzione a cascata: ```java @CircuitBreaker(name = "inventory", fallbackMethod = "cachedStock") @Retry(name = "inventory") // retry transient blips @TimeLimiter(name = "inventory") // cap the wait public CompletableFuture stock(String sku) { return inventoryClient.get(sku); // remote call } // Called when the circuit is open or the call fails — degrade gracefully. public CompletableFuture cachedStock(String sku, Throwable ex) { return CompletableFuture.completedFuture(Stock.unknown(sku)); } ``` Il **circuit breaker** scatta in posizione aperta dopo ripetuti fallimenti, così le chiamate falliscono rapidamente invece di accumularsi in thread in attesa di una dipendenza morta. ## Perché è importante I colloqui senior sondano la maturità sui sistemi distribuiti. Nominare discovery e config è il minimo indispensabile; il fattore distintivo è parlare di **fallimento**: circuit breaker, timeout, idempotenza e osservabilità (distributed tracing con Micrometer/Zipkin). I candidati forti fanno anche resistenza — notando che i microservizi aggiungono costo operativo e che un monolite è spesso la scelta giusta finché la scala non impone il contrario.

Le parti in gioco

Resilienza — la parte che i junior saltano

Perché è importante

Domande correlate