Spring Boot skupaj s Spring Cloud ti da gradnike za mikrostoritve. Trije problemi, ki jih mora rešiti vsak porazdeljen sistem, so centralizirana konfiguracija, service discovery in odpornost proti delnim odpovedim.
┌── Config Server (git-backed properties)
│
Client ──▶ API Gateway ──▶ Service A ──▶ Service B
│ │ │
└──▶ Discovery (Eureka / K8s DNS) ◀── register + look up
/actuator/refresh).V porazdeljenem sistemu bo vsak omrežni klic sčasoma odpovedal. Uporabi Resilience4j, da preprečiš, da bi ena počasna storitev povzročila kaskadni izpad:
@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 se po ponavljajočih se odpovedih odpre, tako da klici hitro odpovejo, namesto da bi se kopičile niti, ki čakajo na mrtvo odvisnost.
Senior razgovori preverjajo zrelost pri porazdeljenih sistemih. Poimenovanje discovery in konfiguracije je osnova; razlikovalec je govor o odpovedih: circuit breakerji, timeouti, idempotenca in opazljivost (porazdeljeno sledenje z Micrometer/Zipkin). Močni kandidati tudi ugovarjajo — z opažanjem, da mikrostoritve dodajo operativni strošek in da je monolit pogosto prava izbira, dokler obseg ne zahteva drugače.
Knjižnica IT vprašanj za razgovore s podrobnimi odgovori — od začetnika do izkušenega.
Doniraj