|
| 1 | +# Server-Side Service Discovery Pattern |
| 2 | + |
| 3 | +## Intent |
| 4 | + |
| 5 | +The Server-Side Service Discovery pattern is a microservice architecture pattern that provides a centralized mechanism for services to register themselves and for consumers to discover available services dynamically. This pattern enhances system scalability and flexibility by decoupling service consumers from the physical locations of service providers. |
| 6 | + |
| 7 | +## Explanation |
| 8 | + |
| 9 | +Real-world example |
| 10 | + |
| 11 | +> Consider a large e-commerce platform with multiple microservices like Product Service, Order Service, Payment Service, and Inventory Service. Instead of hardcoding the network locations of each service, they register themselves with a central Service Registry (like Netflix Eureka). When the Order Service needs to check product availability, it queries the Service Registry to discover available instances of the Product Service. The registry returns healthy instances, and a load balancer distributes the request among them. This approach allows services to scale up/down dynamically, fail gracefully, and be discovered automatically without manual configuration. |
| 12 | +
|
| 13 | +In plain words |
| 14 | + |
| 15 | +> Server-Side Service Discovery provides a centralized registry where services register themselves and consumers can discover and communicate with available services dynamically. |
| 16 | +
|
| 17 | +Wikipedia says |
| 18 | + |
| 19 | +> Service discovery is the automatic detection of devices and services offered by these devices on a computer network. In the context of microservices, service discovery refers to the mechanism by which services find and communicate with each other. |
| 20 | +
|
| 21 | +## Programmatic Example |
| 22 | + |
| 23 | +This implementation demonstrates the Server-Side Service Discovery pattern using Spring Cloud Netflix Eureka. The example includes: |
| 24 | + |
| 25 | +### 1. Service Registry (Eureka Server) |
| 26 | + |
| 27 | +```java |
| 28 | +@SpringBootApplication |
| 29 | +@EnableEurekaServer |
| 30 | +public class ServiceRegistryApp { |
| 31 | + public static void main(String[] args) { |
| 32 | + SpringApplication.run(ServiceRegistryApp.class, args); |
| 33 | + } |
| 34 | +} |
| 35 | +``` |
| 36 | + |
| 37 | +### 2. Service Providers (Product Service & Order Service) |
| 38 | + |
| 39 | +```java |
| 40 | +@SpringBootApplication |
| 41 | +@EnableEurekaClient |
| 42 | +public class ProductServiceApp { |
| 43 | + public static void main(String[] args) { |
| 44 | + SpringApplication.run(ProductServiceApp.class, args); |
| 45 | + } |
| 46 | +} |
| 47 | +``` |
| 48 | + |
| 49 | +### 3. Service Consumer with Load Balancing |
| 50 | + |
| 51 | +```java |
| 52 | +@Configuration |
| 53 | +public class ServiceConsumerConfig { |
| 54 | + @Bean |
| 55 | + @LoadBalanced |
| 56 | + public RestTemplate restTemplate() { |
| 57 | + return new RestTemplate(); |
| 58 | + } |
| 59 | +} |
| 60 | + |
| 61 | +@Service |
| 62 | +public class ServiceDiscoveryService { |
| 63 | + private final RestTemplate restTemplate; |
| 64 | + private final EurekaClient eurekaClient; |
| 65 | + |
| 66 | + public String callService(String serviceName, String endpoint) { |
| 67 | + try { |
| 68 | + String serviceUrl = "http://" + serviceName + endpoint; |
| 69 | + return restTemplate.getForObject(serviceUrl, String.class); |
| 70 | + } catch (Exception e) { |
| 71 | + return "Error calling service: " + e.getMessage(); |
| 72 | + } |
| 73 | + } |
| 74 | +} |
| 75 | +``` |
| 76 | + |
| 77 | +## Key Components |
| 78 | + |
| 79 | +### Service Registry |
| 80 | +- **Purpose**: Central repository for service instance information |
| 81 | +- **Implementation**: Netflix Eureka Server |
| 82 | +- **Features**: Service registration, health monitoring, instance management |
| 83 | + |
| 84 | +### Service Provider |
| 85 | +- **Purpose**: Services that register themselves with the registry |
| 86 | +- **Examples**: Product Service, Order Service |
| 87 | +- **Features**: Auto-registration, health checks, graceful shutdown |
| 88 | + |
| 89 | +### Service Consumer |
| 90 | +- **Purpose**: Applications that discover and consume services |
| 91 | +- **Features**: Service discovery, load balancing, fault tolerance |
| 92 | +- **Implementation**: Uses Eureka Client and Spring Cloud LoadBalancer |
| 93 | + |
| 94 | +### Load Balancer |
| 95 | +- **Purpose**: Distributes requests among available service instances |
| 96 | +- **Implementation**: Spring Cloud LoadBalancer |
| 97 | +- **Strategies**: Round-robin, random, weighted |
| 98 | + |
| 99 | +## Running the Example |
| 100 | + |
| 101 | +### Prerequisites |
| 102 | +- Java 21+ |
| 103 | +- Maven 3.8+ |
| 104 | + |
| 105 | +### Step 1: Start the Service Registry |
| 106 | +```bash |
| 107 | +cd service-registry |
| 108 | +mvn spring-boot:run |
| 109 | +``` |
| 110 | +The Eureka dashboard will be available at: http://localhost:8761 |
| 111 | + |
| 112 | +### Step 2: Start Service Providers |
| 113 | +```bash |
| 114 | +# Terminal 1 - Product Service |
| 115 | +cd product-service |
| 116 | +mvn spring-boot:run -Dspring-boot.run.arguments="--server.port=8081 --spring.application.name=product-service" |
| 117 | + |
| 118 | +# Terminal 2 - Order Service |
| 119 | +cd order-service |
| 120 | +mvn spring-boot:run -Dspring-boot.run.arguments="--server.port=8082 --spring.application.name=order-service" |
| 121 | +``` |
| 122 | + |
| 123 | +### Step 3: Start Service Consumer |
| 124 | +```bash |
| 125 | +cd service-consumer |
| 126 | +mvn spring-boot:run -Dspring-boot.run.arguments="--server.port=8080 --spring.application.name=service-consumer" |
| 127 | +``` |
| 128 | + |
| 129 | +### Step 4: Test the Pattern |
| 130 | +```bash |
| 131 | +# Discover all services |
| 132 | +curl http://localhost:8080/api/services |
| 133 | + |
| 134 | +# Get products through service discovery |
| 135 | +curl http://localhost:8080/api/products |
| 136 | + |
| 137 | +# Get orders through service discovery |
| 138 | +curl http://localhost:8080/api/orders |
| 139 | + |
| 140 | +# Check service health |
| 141 | +curl http://localhost:8080/api/services/product-service/health |
| 142 | +``` |
| 143 | + |
| 144 | +## Pattern Benefits |
| 145 | + |
| 146 | +1. **Dynamic Service Discovery**: Services can be discovered at runtime without hardcoded configurations |
| 147 | +2. **Load Balancing**: Automatic distribution of requests across available instances |
| 148 | +3. **Fault Tolerance**: Failed instances are automatically removed from the registry |
| 149 | +4. **Scalability**: New service instances are automatically discovered and included |
| 150 | +5. **Health Monitoring**: Only healthy services participate in request handling |
| 151 | +6. **Decoupling**: Services are decoupled from physical network locations |
| 152 | + |
| 153 | +## Pattern Drawbacks |
| 154 | + |
| 155 | +1. **Single Point of Failure**: Service registry becomes critical infrastructure |
| 156 | +2. **Network Overhead**: Additional network calls for service discovery |
| 157 | +3. **Complexity**: Adds operational complexity to the system |
| 158 | +4. **Consistency**: Potential delays in service registry updates |
| 159 | +5. **Network Partitions**: Service registry unavailability affects all services |
| 160 | + |
| 161 | +## Related Patterns |
| 162 | + |
| 163 | +- **Client-Side Service Discovery**: Service consumers are responsible for discovering services |
| 164 | +- **Circuit Breaker**: Provides fault tolerance when calling discovered services |
| 165 | +- **API Gateway**: Often combined with service discovery for external access |
| 166 | +- **Health Check**: Essential for maintaining accurate service registry information |
| 167 | + |
| 168 | +## Credits |
| 169 | + |
| 170 | +- [Microservices Patterns by Chris Richardson](https://microservices.io/patterns/service-registry.html) |
| 171 | +- [Spring Cloud Netflix Documentation](https://spring.io/projects/spring-cloud-netflix) |
| 172 | +- [Building Microservices by Sam Newman](https://samnewman.io/books/building_microservices/) |
0 commit comments