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 करता है, इसलिए आप redeploy किए बिना 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 आखिरकार *विफल होगी ही*। एक धीमी 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 हो जाता है (trip), इसलिए calls किसी मृत dependency की प्रतीक्षा में threads को ढेर करने के बजाय fail-fast हो जाती हैं। ## यह क्यों महत्वपूर्ण है Senior interviews distributed-systems परिपक्वता जाँचते हैं। Discovery और config नाम लेना बुनियादी बात है; अंतर पैदा करने वाली बात **failure** के बारे में बात करना है: circuit breakers, timeouts, idempotency, और observability (Micrometer/Zipkin के साथ distributed tracing)। मज़बूत उम्मीदवार पीछे भी धकेलते हैं — यह टिप्पणी करते हुए कि microservices परिचालन लागत जोड़ते हैं और जब तक scale की माँग न हो, एक monolith अक्सर सही विकल्प होता है।

चलने वाले पुर्ज़े

Resilience — वह भाग जिसे juniors छोड़ देते हैं

यह क्यों महत्वपूर्ण है

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