Client Side Service Discovery in Microservices

Microservices are small, loosely coupled distributed services. Microservices architecture evolved as a solution to the scalability, independently deployable, and innovation challenges with Monolithic Architecture. It provides us to take a big application and break it into efficiently manageable small components with some specified responsibilities. It is considered the building block of modern applications. Before understanding What is Service Discovery let’s understand what is the need for Service Discovery in Microservices.

What’s Service Discovery in Microservices?

Suppose we have Service-A & Service-B and we have our Load Balancer placed inside a different server. Now let’s introduce our Discovery Service. Now what this discovery service will do now whenever Service-A and Service-B want to communicate with each other then whenever we are starting our Microservices we’ll be registering them with Discovery Service. And this discovery service right now will know what is the IP and port number of Service-A and what is the IP and port number of Service-B. All detailed information will be there with Discovery Service. Similarly, if we have many different instances of Service-B, all this Service-B which is running in different servers will be registering their information with Discovery Service. So it is one central location where we’ll be managing our host and the port number information inside this particular server. This is basically called registration because all the services whenever they are starting off they are registering themselves with the discovery service and now the discovery service is maintaining all their information inside a particular map or a list or a database. We called it a Service Registry.

So, Service Registry is a crucial part of service identification. It’s a database containing the network locations of service instances. A Service Registry must be highly available and up-to-date. Here, inside Service Registry we have 4 different instances of Service-B and they are running in some port number and some IP address. Similarly, for Service-A we have one different instance.

Now Service-A wants to connect to Service-B. Now the load balancer once get the request, it is gonna do a query with the discovery service that, hey, can you tell me what instances are there for Service-B? Now the load balancer finds out that there are this many instances available where Service-B has been deployed. Now Load Balancer is going to dispatch to one of the servers by looking into Service Registry. It can take all four instances of Service-B and whoever has less load then to balance the load, it can send the request to there.

Note: Don’t mix up load balancing and service discovery. The Load Balancer job is to do load balancing while the Service Discovery job is to do discovering service info. When we build Microservices and call other microservices, we need service discovery to find the hosts and IP info and if multiple hosts are available then the load balancer helps to pick one and make a call in a load-balanced way.

Types of Service Discovery

There are two types of Service Discovery

• Client-Side Service Discovery
• Server-Side Service Discovery

In this article, we are going to explain Client-Side Service Discovery.

Client Side Service Discovery in Microservices

Imagine you have a Service-A and Service-B and a Discovery Service. Now whenever Service-A and Service-B start off they register themselves inside the discovery service. Let’s say there are a few more instances of Service-B. All the information has been registered with the Service Discovery and it basically maintains everything inside a registry. The registry basically has the instance list like how many Service-B are available and how many Service-A are available and what are their instance details. Everything is maintained in the registry. 

Now let’s say Service-A wants to connect to Service-B then Servic-A is asking directly to the Discovery Service and the Discovery Service is providing the URLs or the port number of all instances of Servic-B. So when Service-A wants to call the Service-B then the Service-B is going to reply to them back with all the instances which are available. In the below image, you can see all these four instances which are available inside the discovery service, the discovery service given back to Service-A. Now Service-A is going to call Service-B. Service-A has 4 different instances of Service-B and it will call the one which can take the load. Right now whenever Service-A will call Service-B it knows which of the server can take the load. So Service-A only will do the load balancing and will pick up one of the servers and it is going to dispatch a request. Now let’s say if there is another request that comes it will not give to the same server the service area will dispatch the request to another instance.

Whatever the request is going to hit from Service-A to Service-B then the load will be distributed between all these instances because right now Service-A knows that Service-B has been deployed in four different instances and Service-A will call Service-B and it will do the load balance. One thing you can see over here is there is no load balancer the client is asking Service Discovery to get the details of Service-B and again the client is doing the load balancing and calling the Service-B instance by itself. This is what we call a client-side discovery.

Advantages and Disadvantages:

Assigning responsibility for client-side load balancing is both a disadvantage and an advantage. It’s an advantage because it saves an extra hop that we would’ve had with a dedicated load balancer. It’s a disadvantage because the Service Consumer must implement the load balancing logic.

Example:

• Netflix Eureka: Eureka is the Netflix Service Discovery Server and Client. The server can be configured and deployed to be highly available, with each server replicating the state of the registered services to the others.
• Zookeeper: Zookeeper is a distributed, open-source coordination service for distributed applications. It exposes a simple set of primitives to implement higher-level services for synchronization, configuration maintenance, and group and naming.
• Consul: Consul is a service networking solution to automate network configurations, discover services, and enable secure connectivity across any cloud or runtime.