ਤੁਸੀਂ 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 ਦੀ ਥਾਂ *ਨਾਮ* ਦੁਆਰਾ ਲੱਭਣ ਦਿੰਦੀ ਹੈ, ਇਸ ਲਈ instances ਆਜ਼ਾਦੀ ਨਾਲ scale ਅਤੇ move ਕਰ ਸਕਦੇ ਹਨ। - **API Gateway** (Spring Cloud Gateway) routing, auth, ਅਤੇ rate limiting ਲਈ single 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** ਦੁਹਰਾਈਆਂ ਅਸਫ਼ਲਤਾਵਾਂ ਤੋਂ ਬਾਅਦ open trip ਕਰ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ calls ਇੱਕ ਮਰ ਚੁੱਕੀ dependency ਦੀ ਉਡੀਕ ਵਿੱਚ threads ਢੇਰ ਕਰਨ ਦੀ ਥਾਂ ਜਲਦੀ fail ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ## ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ Senior interviews distributed-systems maturity ਨੂੰ ਜਾਂਚਦੇ ਹਨ। Discovery ਅਤੇ config ਦਾ ਨਾਮ ਲੈਣਾ table stakes ਹੈ; ਫ਼ਰਕ ਪਾਉਣ ਵਾਲੀ ਗੱਲ **failure** ਬਾਰੇ ਗੱਲ ਕਰਨਾ ਹੈ: circuit breakers, timeouts, idempotency, ਅਤੇ observability (Micrometer/Zipkin ਨਾਲ distributed tracing)। ਮਜ਼ਬੂਤ candidates ਪਿੱਛੇ ਵੀ ਧੱਕਦੇ ਹਨ — ਇਹ ਨੋਟ ਕਰਦੇ ਹੋਏ ਕਿ microservices operational cost ਜੋੜਦੇ ਹਨ ਅਤੇ ਜਦੋਂ ਤੱਕ scale ਦੀ ਮੰਗ ਨਾ ਹੋਵੇ, ਅਕਸਰ ਇੱਕ monolith ਸਹੀ ਚੋਣ ਹੁੰਦੀ ਹੈ।

ਚੱਲਦੇ ਹਿੱਸੇ

Resilience — ਉਹ ਹਿੱਸਾ ਜੋ juniors ਛੱਡ ਦਿੰਦੇ ਹਨ

ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਸੰਬੰਧਿਤ ਸਵਾਲ