तपाईं Spring Boot सँग microservices कसरी बनाउनुहुन्छ: config, discovery, resilience?

Question

IT Interview Practice · Accepted Answer

Spring Boot सँगै Spring Cloud ले तपाईंलाई microservices का लागि building block हरू दिन्छ। हरेक distributed system ले समाधान गर्नैपर्ने तीन समस्या हुन् **centralized configuration**, **service discovery**, र आंशिक 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 बदल्नुहुन्छ। Service हरूले यसलाई startup मा pull गर्छन् (र `/actuator/refresh` मार्फत refresh गर्छन्)। - **Service discovery** (Eureka, Consul, वा Kubernetes DNS) ले Service A लाई hard-coded host को सट्टा *नाम* द्वारा Service B फेला पार्न दिन्छ, त्यसैले instance हरू स्वतन्त्र रूपमा scale र move हुन सक्छन्। - **API Gateway** (Spring Cloud Gateway) routing, auth, र rate limiting का लागि एकल प्रवेश बिन्दु हो। ## Resilience — junior हरूले छाड्ने भाग 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** बारम्बार failure पछि खुला हुन्छ, त्यसैले call हरू मृत dependency मा पर्खिने thread हरू थुप्रिनुको सट्टा छिटो fail हुन्छन्। ## यो किन महत्त्वपूर्ण छ Senior interview हरूले distributed-systems परिपक्वता जाँच्छन्। discovery र config नाम लिनु आधारभूत हो; भिन्नता ल्याउने कुरा **failure** को बारेमा कुरा गर्नु हो: circuit breaker, timeout, idempotency, र observability (Micrometer/Zipkin सँग distributed tracing)। बलियो candidate हरूले push back पनि गर्छन् — microservices ले operational लागत थप्छ र scale ले नमागुन्जेल प्रायः monolith नै सही छनोट हो भन्ने उल्लेख गर्दै।

चलायमान भागहरू

Resilience — junior हरूले छाड्ने भाग

यो किन महत्त्वपूर्ण छ

सम्बन्धित प्रश्नहरू