Si ndërton microservices me Spring Boot: config, discovery, resilience?

Question

IT Interview Practice · Accepted Answer

Spring Boot plus Spring Cloud ju jep blloqet ndërtuese për microservices. Tri problemet që çdo sistem i shpërndarë duhet të zgjidhë janë **konfigurimi i centralizuar**, **service discovery**, dhe **resilience** kundrejt dështimit të pjesshëm. ## Pjesët lëvizëse ```text ┌── Config Server (properties të mbështetura në git) │ Client ──▶ API Gateway ──▶ Service A ──▶ Service B │ │ │ └──▶ Discovery (Eureka / K8s DNS) ◀── regjistro + kërko ``` - **Config Server** shërben properties-in e çdo shërbimi nga një repo git qendror, kështu që ndryshoni config-un pa bërë redeploy. Shërbimet e tërheqin në nisje (dhe e freskojnë përmes `/actuator/refresh`). - **Service discovery** (Eureka, Consul, ose Kubernetes DNS) lejon Service A të gjejë Service B me *emër* në vend të një host-i hard-coded, kështu që instancat mund të shkallëzohen dhe të lëvizin lirisht. - **API Gateway** (Spring Cloud Gateway) është pika e vetme e hyrjes për routing, auth, dhe rate limiting. ## Resilience — pjesa që junior-ët e anashkalojnë Në një sistem të shpërndarë çdo thirrje rrjeti *do* të dështojë herët a vonë. Përdor Resilience4j për të ndaluar një shërbim të ngadaltë të kaskadojë në një ndërprerje: ```java @CircuitBreaker(name = "inventory", fallbackMethod = "cachedStock") @Retry(name = "inventory") // ritenta dridhjet kalimtare @TimeLimiter(name = "inventory") // kufizo pritjen public CompletableFuture stock(String sku) { return inventoryClient.get(sku); // thirrje remote } // Thirret kur qarku është i hapur ose thirrja dështon — degrado me hijeshi. public CompletableFuture cachedStock(String sku, Throwable ex) { return CompletableFuture.completedFuture(Stock.unknown(sku)); } ``` **Circuit breaker**-i hapet pas dështimeve të përsëritura, kështu që thirrjet dështojnë shpejt në vend që të grumbullohen thread-e që presin një varësi të vdekur. ## Pse ka rëndësi Intervistat senior hetojnë pjekurinë në sisteme të shpërndara. Emërtimi i discovery dhe config është minimumi; dallimi është të flasësh për **dështimin**: circuit breakers, timeouts, idempotency, dhe observability (distributed tracing me Micrometer/Zipkin). Kandidatët e fortë gjithashtu kundërshtojnë — duke vënë në dukje se microservices shtojnë kosto operacionale dhe një monolit është shpesh zgjedhja e duhur derisa shkalla të kërkojë ndryshe.

Pjesët lëvizëse

Resilience — pjesa që junior-ët e anashkalojnë

Pse ka rëndësi

Pyetje të ngjashme