Microservices Architecture: What Is Service Discovery?

What You Will Learn

• What service discovery is.
• Why service discovery is important in a microservices architecture.
• How to implement service discovery.
• What Eureka is.

What Is Service Discovery?

When we talk about a microservices architecture, we refer to a system with a large number of small services, working with each other:

An important feature of such architectures is auto-scaling. The number of instances of a microservice varies based on the system load. Initially, you could have 5 instances of Microservice5, which go up later to 20, 100, or 1000!

Two important questions arise

• How does Microservice4 know how many instances of Microservice5 are present, at a given time?
• In addition, how does it distribute the load among all of them?

Hardcoding URLs Is Not an Option

One way to do this is to hard-code the URLs of Microservice5 instances, within Microservice4. That means every time the number of Microservice5 instances changes (with the addition of new one or the deletion of existing one), the configuration within Microservice4 needs to change. This is a big headache.

Using Service Discovery

Ideally, you want to change the number of instances of Microservice5 based on the load, and make Microservice4 dynamically aware of the instances.

That's where the concept of Service Discovery comes into the picture.

The component that provides this service is generally called a naming server.

All instances of all the microservices register themselves with the naming server. Whenever a microservice wants to talk to another microservices, it asks the naming server about the available instances.

In the example above, whenever a new instance of Microservice5 is launched, it registers with the naming server. When Microservice4 wants to talk to Microservice5, it asks the naming server: what are the available instances of Microservice5?

Another Example of Service Discovery

Using Service Discovery to identify microservice instances helps keep things dynamic.

Let's say there is a service for currency conversion:

The CurrencyConversionService (CCS) talks to the ForexService. At a certain point of time, these services have two instances each:

However, there could be a time where there are five instances of the ForexService (FS):

In that case, CurrencyConversionService needs to make sure that the load is evenly distributed across all the ForexService instances. It needs to answer two important questions:

• How does the CurrencyConversionService know how many instances of ForexService are active?
• How does the CurrencyConversionService distribute the load among those active instances?

When a CCS microservice instance is brought up, it registers with Eureka. The same thing happens with all instances of FS as well.

When a CCS instance needs to talk to an FS instance, it requests information from Eureka. Eureka would then return the URLS of the two FS instances active at that time. Here, the application makes use of a client-side load distribution framework called Ribbon. Ribbon ensures proper load distribution over the two FS instances, for events coming in from the CCS.

Summary

In this video, we talked about microservice service discovery. We saw that microservices need to be able to communicate with each other. The number of instances of a microservice changes over time, depending on the load. Service discovery enables us to dynamically adapt to new instances and distribute load among microservices.