Service Discovery in a Microservices Architecture

What is service discovery?

In a microservices-based application, there are often many microservices communicating with each other to achieve some common outcome.

So, we inherently require some method by which a client can call any specific service at a given point of time.

For that to take place, we must have the URL (API endpoint) of that service configured somewhere (in some property file such as application.properties, appl.yml, or something like that).

But it' a very bad practice to keep URLs hard coded. We should not hard code the URL of any service in our application for multiple reasons:

• Cloud-based application URLs are dynamic so they need to be updated every now and then.

• Hard coded URLs need code change/code updates.

• The basic requirement of an application to be run on multiple environments (e.g. local, QA, production, etc. (RFS/UAT/PAT)).

• Load balancing. This implies that for similar kinds of service there are multiple URLs, so deciding which URL to hard code becomes a bottle neck.

And the list goes on!

...

Conclusion: we cannot keep URLs hard coded in our application.

This leads to a problem of being able to somehow 'discover' the updated and current URL of a service. This process is called "Service Discovery."

In other words, Service Discovery is the process used to get/deduce/trace/find/gather, i.e. 'DISCOVER,' the URL of a particular service. In a nutshell, Service Discovery, as the name suggests, means to discover (somehow) the endpoint for a particular service.

There are two types of service discovery:

1. Client-side service discovery

2. Server-side service discovery

Client-Side Service Discovery

Client ===> DISCOVERY SERVER ===> service 1

                                    service 2

                                    service 3

The client calls the discovery server to get the URL of, say, service 2. The discovery server fetchs the URL of service 2 and returns it to the client. Then the client makes the actual API call to service 2 with the aid of the URL it obtained via discovery server.

But there's an obvious disadvantage to this model: there's too much 'pinging' going on. And the client cannot actually make a call to the 'service 2' directly. It's calling the discovery server, then getting the URl and then making the actual API call to service 2.

This gives rise to server-side service discovery.

Server-Side Service Discovery

Here, there's no discovery server. Instead, there's some sort of directory server (containing the URLs of all the Services) between the client and the available services.

The client calls the directory, telling it to convert 'service 2' that I (the client) said "Hi."

In return, the directory server pings service 2 and relays the client's message to it.

So, this makes it possible for the client to avoid unnecessary pings to the discovery server, getting the URL and making the actual call to service 2.