Spring Cloud Basics
Spring Cloud, Spring Boot ke UPAR TOOLS ka SET hai, MICROSERVICES architectures banaने ke liye. SERVICE DISCOVERY (Eureka) — HAR microservice STARTUP par khud REGISTER karti hai, aur DUSRI services usse NAAM SE dhoondती hain (hardcoded IP/port ke bajaye) — cloud environments mein, jaha IPs CONSTANTLY CHANGE hoti hain, ye ESSENTIAL hai.
API GATEWAY (Spring Cloud Gateway) EK SINGLE ENTRY POINT hai — CLIENT sirf Gateway se baat karta hai, jo request ko SAHI internal service tak ROUTE karta hai. Cross-cutting concerns (RATE LIMITING, AUTHENTICATION) YAHIN CENTRALIZE ho sakte hain, HAR individual service mein DUPLICATE karne ke bajaye.
// Eureka Server (registry):
@SpringBootApplication
@EnableEurekaServer
public class DiscoveryServerApplication { }
// Individual microservice — khud REGISTER karti hai:
@SpringBootApplication
@EnableDiscoveryClient
public class OrderServiceApplication { }
// Ek service, DUSRI ko NAAM se call karti hai (IP nahi):
@Service
public class OrderService {
private final WebClient.Builder webClientBuilder;
public Inventory checkInventory(Long productId) {
return webClientBuilder.build()
.get()
.uri("http://inventory-service/api/inventory/" + productId) // service NAME, IP nahi
.retrieve()
.bodyToMono(Inventory.class)
.block();
}
}- Service Discovery (Eureka) = services khud register hoti hain, naam se dhoondi jaati hain
- API Gateway = single entry point, cross-cutting concerns centralize
- Sirf ACTUAL microservices architecture mein zaroori — monolith mein NAHI
Microservices environment mein, services EK-DUSRE ko DIRECTLY hardcoded IP/PORT se call NAHI karte (IPs change hoti rehti hain, especially cloud/container environments mein). Eureka ek SERVICE REGISTRY hai — HAR service startup par apna naam REGISTER karti hai, aur DUSRI services usse NAAM SE dhoondhती hain, IP-agnostic.
API Gateway (jaise Spring Cloud Gateway) ek SINGLE ENTRY POINT hai poore microservices system ke liye — client SIRF Gateway se baat karta hai, Gateway REQUEST ko SAHI internal service tak ROUTE karta hai. Cross-cutting concerns (rate limiting, authentication) YAHAN CENTRALIZE ho sakte hain.
- Client → API Gateway → correct internal microservice
- Cross-cutting concerns (auth, rate-limiting) Gateway par centralize
- Internal service URLs client se HIDDEN rehte hain