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 ను ఒక central git repo నుండి serve చేస్తుంది, కాబట్టి మీరు redeploy చేయకుండా config ను మార్చుతారు. Services దాన్ని startup వద్ద pull చేస్తాయి (మరియు `/actuator/refresh` ద్వారా refresh చేస్తాయి). - **Service discovery** (Eureka, Consul, లేదా Kubernetes DNS) Service A కు Service B ను hard-coded host కు బదులుగా *name* ద్వారా కనుగొనడానికి అనుమతిస్తుంది, కాబట్టి instances స్వేచ్ఛగా scale మరియు move కాగలవు. - **API Gateway** (Spring Cloud Gateway) అనేది routing, auth, మరియు rate limiting కోసం ఒకే entry point. ## Resilience — juniors దాటవేసే భాగం distributed system లో ప్రతి network call *చివరికి* fail అవుతుంది. ఒక నెమ్మదైన 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** పునరావృత failures తర్వాత open గా trip అవుతుంది, కాబట్టి calls ఒక dead dependency కోసం వేచి ఉన్న threads ను పోగుచేయడానికి బదులుగా వేగంగా fail అవుతాయి. ## ఇది ఎందుకు ముఖ్యం Senior interviews distributed-systems పరిపక్వతను పరిశీలిస్తాయి. discovery మరియు config ను పేర్కొనడం కనీస అవసరం; తేడా చూపేది **failure** గురించి మాట్లాడటం: circuit breakers, timeouts, idempotency, మరియు observability (Micrometer/Zipkin తో distributed tracing). బలమైన అభ్యర్థులు వెనక్కి కూడా నెట్టుతారు — microservices operational cost ను జోడిస్తాయని మరియు scale డిమాండ్ చేసే వరకు monolith తరచుగా సరైన ఎంపిక అని గమనిస్తారు.

కదిలే భాగాలు

Resilience — juniors దాటవేసే భాగం

ఇది ఎందుకు ముఖ్యం

సంబంధిత ప్రశ్నలు