The Path to Microservices: Service Discovery

We have talked about several topics about microservices. In this post, we are going to discuss Service Discovery in a microservices architecture. This is important for a microservices architecture. Without this, your client does not know how to talk to your microservices. So, let’s jump into the topic.

Why do we need service discovery in microservices architecture?

Imagine a client is sending a request to your microservices. Now, you have a few services in the backend and each service has several replicas. How do you reach the right service? Given that the network locations are dynamically assigned to different services and the services are created dynamically due to auto-scaling or failure.

In this context, the client is not able to connect to the right network location because the client does not know the correct location. To resolve this problem, service discovery comes into play.

What is service discovery?

Basically, there are two types of service discovery:

1. Server-side service discovery

2. Client-side service discovery

Today, we are going to talk about server-side service discovery.

When using server-side service discovery, the services register their network locations to a Service Registry. The service registry is responsible to store the network locations of all service instances and must be highly available. Otherwise, the client does not know how to talk to the correct service if the service registry goes down.

After storing the network locations in the service registry, we need a Load Balancer to help the client to get the available instance and forward the request to the correct destination. That said, the client will talk to the load balancer only and the load balancer will help to conduct the remaining work including query service network location and forward requests to the destination.

From here, you can see how important a service registry is. The services will register themselves to the registry and the load balance will query the network locations from the registry as well. So, we need to make sure the registry is highly available. Otherwise, it will become a single point of failure. Since the service instances are created dynamically depending on auto-scaling or container failure, so the network location is assigned dynamically too. That’s the reason why we need a service registry to store this information and the network locations will be updated depending on the situation in the service cluster.