Cum construiești microservicii cu Spring Boot: config, discovery, reziliență?

Question

IT Interview Practice · Accepted Answer

Spring Boot împreună cu Spring Cloud îți oferă componentele de bază pentru microservicii. Cele trei probleme pe care orice sistem distribuit trebuie să le rezolve sunt **configurarea centralizată**, **service discovery** și **reziliența** în fața eșecului parțial. ## Piesele mobile ```text ┌── Config Server (proprietăți susținute de git) │ Client ──▶ API Gateway ──▶ Service A ──▶ Service B │ │ │ └──▶ Discovery (Eureka / K8s DNS) ◀── înregistrare + căutare ``` - **Config Server** servește proprietățile fiecărui serviciu dintr-un repo git central, așa că schimbi configurarea fără redeploy. Serviciile o preiau la pornire (și se reîmprospătează prin `/actuator/refresh`). - **Service discovery** (Eureka, Consul sau Kubernetes DNS) permite Serviciului A să găsească Serviciul B după *nume* în loc de un host hard-codat, așa că instanțele pot scala și se pot muta liber. - **API Gateway** (Spring Cloud Gateway) este punctul unic de intrare pentru rutare, autentificare și rate limiting. ## Reziliență — partea pe care juniorii o sar Într-un sistem distribuit, fiecare apel de rețea *va* eșua în cele din urmă. Folosește Resilience4j ca să oprești un serviciu lent să se propage într-o pană: ```java @CircuitBreaker(name = "inventory", fallbackMethod = "cachedStock") @Retry(name = "inventory") // reîncearcă întreruperile tranzitorii @TimeLimiter(name = "inventory") // limitează așteptarea public CompletableFuture stock(String sku) { return inventoryClient.get(sku); // apel remote } // Apelată când circuitul este deschis sau apelul eșuează — degradează grațios. public CompletableFuture cachedStock(String sku, Throwable ex) { return CompletableFuture.completedFuture(Stock.unknown(sku)); } ``` **Circuit breaker-ul** se deschide după eșecuri repetate, așa că apelurile eșuează rapid în loc să acumuleze thread-uri care așteaptă după o dependență moartă. ## De ce contează Interviurile pentru seniori sondează maturitatea în sisteme distribuite. Numirea lui discovery și config este minimul necesar; diferențiatorul este să vorbești despre **eșec**: circuit breakere, timeout-uri, idempotență și observabilitate (distributed tracing cu Micrometer/Zipkin). Candidații puternici și contrazic — remarcând că microserviciile adaugă cost operațional și că un monolit este adesea alegerea corectă până când scara o cere altfel.

Piesele mobile

Reziliență — partea pe care juniorii o sar

De ce contează

Întrebări conexe