Service registration and discovery

Why is service registration and discovery important? So far, we have been calling the service through its URL, which includes the IP address—for example, http://localhost:8080/prod—thus we expect the service to run at that address. Even though we might substitute the test and the production URLs, the step of calling the service at a particular IP address and port is still static.

However, in a cloud environment, things are quite dynamic. If the service goes down at a given IP, it can come up in a different IP address as it comes up on some container. Although we can mitigate that with virtual IPs and reverse proxies, it would be better to look up a service dynamically at the time of the service call and then call the service at the IP address. The lookup addresses can be cached in the client, so that the dynamic lookup need not be performed for each service call.

A registry (referred to as a service registry) helps in this case. When the service boots up, it registers itself in a registry. There is also a heartbeat between registry and service to ensure that the registry keeps only live services in its registry. If the heartbeat stops, the registry deregisters that instance of the service.

For this quick starter, we are going to use Spring Cloud Netflix, which nicely integrates with Spring Boot. We need three components now:

• Product service: We have already written this
• Service registry: We are going to use Eureka, which is part of Spring Cloud
• Service client: Instead of calling our service directly through a browser, we will write a simple client to our service