तुम्ही Spring Boot सह microservices कसे बांधता: config, discovery, resilience?

Question

IT Interview Practice · Accepted Answer

Spring Boot अधिक Spring Cloud तुम्हाला microservices साठीचे building blocks देते. प्रत्येक distributed system ला सोडवाव्या लागणाऱ्या तीन समस्या म्हणजे **centralized configuration**, **service discovery**, आणि partial failure विरुद्ध **resilience**. ## हलणारे भाग ```text ┌── Config Server (git-backed properties) │ Client ──▶ API Gateway ──▶ Service A ──▶ Service B │ │ │ └──▶ Discovery (Eureka / K8s DNS) ◀── register + look up ``` - **Config Server** प्रत्येक service चे properties एका मध्यवर्ती git repo मधून serve करतो, त्यामुळे तुम्ही पुन्हा deploy न करता config बदलता. Services ते startup च्या वेळी pull करतात (आणि `/actuator/refresh` द्वारे refresh करतात). - **Service discovery** (Eureka, Consul, किंवा Kubernetes DNS) मुळे Service A हे Service B ला hard-coded host ऐवजी *नावाने* शोधू शकते, त्यामुळे instances मुक्तपणे scale आणि move होऊ शकतात. - **API Gateway** (Spring Cloud Gateway) हे routing, auth, आणि rate limiting साठीचे एकमेव प्रवेशद्वार आहे. ## Resilience — juniors वगळतात तो भाग Distributed system मध्ये प्रत्येक network call कधीतरी *अपयशी होणारच*. एक slow service outage मध्ये cascade होण्यापासून थांबवण्यासाठी Resilience4j वापरा: ```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)); } ``` **Circuit breaker** वारंवार अपयशांनंतर open होतो (trips), त्यामुळे calls मृत dependency ची वाट पाहत threads साचण्याऐवजी लवकर fail होतात. ## हे का महत्त्वाचे आहे Senior interviews distributed-systems परिपक्वता तपासतात. discovery आणि config सांगणे ही किमान अपेक्षा आहे; वेगळेपणा **failure** बद्दल बोलण्यात आहे: circuit breakers, timeouts, idempotency, आणि observability (Micrometer/Zipkin सह distributed tracing). भक्कम उमेदवार प्रतिवाद सुद्धा करतात — नमूद करतात की microservices operational खर्च वाढवतात आणि scale ची मागणी होईपर्यंत monolith हाच बहुधा योग्य पर्याय असतो.

हलणारे भाग

Resilience — juniors वगळतात तो भाग

हे का महत्त्वाचे आहे

संबंधित प्रश्न