As we know, in the microservices architecture, various protocols may be used for connecting services to each other. But how do these services find each other?

And also, one service may have multiple instances. So, what happens if we run multiple instances? Let's look at the following diagram:

As you can see, there are two services running in this microservices-based application—Account Service and Customer Service. Account Service requests Customer Service to fetch records of a customer in JSON format. And both services have their own DB access—Account DB and Customer DB, respectively. Also, Customer Service has multiple running instances due to high availability and throughput, and to make it resilient. But how will Account Service call Customer Service? Which instance should be called? 

To answer these questions, Service Discovery comes into the picture and solves these cloud-native problems. Let's look at the diagram with Discovery Service:

As you can see, the discovery server has been used to register the microservices and consulted to use microservices. Let's see the workflow:

1. Account Service registers itself with Eureka Discovery Server
2. Customer Service also registers itself with Eureka Discovery Server
3. Account Service consults with Discover Server to find Customer Service
4. Account Service knows about the Customer Service's instance to be called

As you have seen, Discovery Service solves the cloud-native problems of the microservices-based architecture. Spring Cloud supports several implementations of Service Discovery, such as Netflix Eureka and Hashicorp Consul, Spring Cloud makes it easy to utilize either of those servers while hiding their internal complexity. But, in this chapter, we will discuss the Netflix Eureka Service Discovery and its implementation.