Spring Boot-உடன் microservice-களை எவ்வாறு உருவாக்குவது: config, discovery, resilience?

Question

IT Interview Practice · Accepted Answer

Spring Boot மற்றும் Spring Cloud உங்களுக்கு microservice-களுக்கான building block-களை வழங்குகின்றன. ஒவ்வொரு 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-ஐ மாற்றுகிறீர்கள். Service-கள் startup-இல் அதை pull செய்கின்றன (மேலும் `/actuator/refresh` வழியாக refresh செய்கின்றன). - **Service discovery** (Eureka, Consul, அல்லது Kubernetes DNS), Service A-ஐ hard-coded host-க்குப் பதிலாக *பெயரால்* Service B-ஐக் கண்டறிய அனுமதிக்கிறது, எனவே instance-கள் சுதந்திரமாக scale ஆகி நகரலாம். - **API Gateway** (Spring Cloud Gateway), routing, auth, மற்றும் rate limiting-க்கான ஒற்றை நுழைவுப் புள்ளி. ## Resilience — junior-கள் தவிர்க்கும் பகுதி ஒரு distributed system-இல் ஒவ்வொரு network call-ம் இறுதியில் *தோல்வியடையும்*. ஒரு மெதுவான service ஒரு outage-ஆகப் பரவுவதைத் தடுக்க 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 ஆகத் திறக்கிறது, எனவே ஒரு இறந்த dependency-க்காகக் காத்திருக்கும் thread-கள் குவிவதற்குப் பதிலாக call-கள் விரைவாகத் தோல்வியடைகின்றன. ## இது ஏன் முக்கியம் Senior interview-கள் distributed-systems முதிர்ச்சியை ஆராய்கின்றன. Discovery மற்றும் config-ஐப் பெயரிடுவது அடிப்படை; வேறுபடுத்தும் அம்சம் **failure** பற்றிப் பேசுவது: circuit breaker-கள், timeout-கள், idempotency, மற்றும் observability (Micrometer/Zipkin-உடன் distributed tracing). வலிமையான candidate-கள் எதிர்ப்பையும் தெரிவிக்கிறார்கள் — microservice-கள் operational cost-ஐச் சேர்க்கின்றன, மேலும் scale கோரும் வரை ஒரு monolith பெரும்பாலும் சரியான தேர்வு என்பதைக் குறிப்பிடுகிறார்கள்.

நகரும் பாகங்கள்

Resilience — junior-கள் தவிர்க்கும் பகுதி

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்