Spring Boot plus Spring Cloud dają ci klocki do budowy mikroserwisów. Trzy problemy, które każdy system rozproszony musi rozwiązać, to scentralizowana konfiguracja, service discovery oraz odporność na częściowe awarie.
┌── Config Server (git-backed properties)
│
Client ──▶ API Gateway ──▶ Service A ──▶ Service B
│ │ │
└──▶ Discovery (Eureka / K8s DNS) ◀── register + look up
/actuator/refresh).W systemie rozproszonym każde wywołanie sieciowe w końcu zawiedzie. Użyj Resilience4j, aby jedna wolna usługa nie kaskadowała w awarię:
@CircuitBreaker(name = "inventory", fallbackMethod = "cachedStock")
@Retry(name = "inventory") // retry transient blips
@TimeLimiter(name = "inventory") // cap the wait
public CompletableFuture<Stock> stock(String sku) {
return inventoryClient.get(sku); // remote call
}
// Called when the circuit is open or the call fails — degrade gracefully.
public CompletableFuture<Stock> cachedStock(String sku, Throwable ex) {
return CompletableFuture.completedFuture(Stock.unknown(sku));
}
Circuit breaker otwiera się po powtarzających się awariach, więc wywołania zawodzą szybko, zamiast piętrzyć wątki czekające na martwą zależność.
Rozmowy na poziomie senior badają dojrzałość w systemach rozproszonych. Nazwanie discovery i konfiguracji to podstawa; wyróżnikiem jest mówienie o awarii: circuit breakery, timeouty, idempotencja i observability (rozproszony tracing z Micrometer/Zipkin). Mocni kandydaci również oponują — zauważając, że mikroserwisy dodają koszt operacyjny, a monolit jest często właściwym wyborem, dopóki skala nie wymusi czego innego.
Biblioteka pytań rekrutacyjnych IT ze szczegółowymi odpowiedziami — od Juniora do Seniora.
Wesprzyj