Service Discovery Blog Banner
Posted on / in Digital Transformation

Service Discovery in Microservices

Microservice architectures are now driving the evolution of service discovery. The lifespan of service in a microservice architecture is measured in seconds and minutes. Addresses are constantly added and changed in microservices as ports are changed, new hosts, or service termination.

When dealing with microservices, a mechanism that allows one service to use another without knowing its exact location becomes necessary. Let’s look at the concept of Service Discovery in this article.

What is Service Discovery?
Service discovery is the process by which applications and microservices find each other on a network. It includes a central server that maintains a global view of addresses as well as clients that connect to the central server to update and retrieve addresses through the Implementations.

The Service Discovery mechanism assists us in determining the location of each instance. Its component functions as a registry, tracking the addresses of all instances. The network paths for the instances are assigned dynamically. As a result, if a client wants to request a service, it must do so through a Service Discovery mechanism.

Your code must be aware of the network location, IP address, and port of a service instance in order to make a request. The network locations of service instances in a traditional application running on physical hardware are relatively static.

Service Discovery is a technique of automatically finding devices and services on a network.

QBrainX assists organizations in reducing user configuration efforts by presenting them with compatible resources.

What is Service Registry?
A service registry is a database that tracks the availability of each microservice in an application. The service registry must be updated whenever a new service is added to the system and whenever a service is taken offline or becomes unavailable. This can be accomplished through self-registration or through third-party registration.

Why should you use Service Discovery?
The service registry is an important component of service discovery. A management API and a query API are provided by the service registry. The management API is used to register and deregister service instances with the service registry. System components use the query API to discover available service instances.

Client-side discovery and service-side discovery are the two main service-discovery patterns. Clients query the service registry, select an available instance, and make a request in systems that use client-side service discovery. Clients make requests through a router in server-side discovery systems, which queries the service registry and forwards the request to an available instance.

Service instances are registered with and deregistered from the service registry in two ways. The self-registration pattern allows service instances to register themselves with the service registry. The third-party registration pattern requires another system component to handle registration and deregistration on behalf of the service.

How does Service Discovery Function?
Service Discovery is divided into two parts. For starters, it provides a way for an instance to register and declare, Second, it makes it possible to locate the service once it has been registered.

Let’s use an example to clarify the concept: a Service Consumer and a Service Provider (a service exposing REST API). The Service Provider is required by the Service Consumer to read and write data.

The Service Discovery function is depicted in the diagram below:

Service Discovery Function

The process steps depicted in the above diagram:

  • The Service Provider’s location is transmitted to the Service Registry (a database containing the locations of all available service instances).
  • The Service Consumer requests the location of the Service Provider from the Service Discovery Server.
  • The Service Registry searches its internal database for the Service Provider’s location and returns it to the Service Consumer.
  • The Service Consumer now has the ability to make direct requests to the Service Provider.

Implementation of Service Discovery:
The Service Consumer is responsible for determining the network locations of available service instances and balancing requests between them when using Client-Side Discovery.

The client requests information from the Service Register then employs a load-balancing algorithm to select one of the available service instances and issue a request.

The diagram below depicts how client-side service discovery works:

Client-Side Service Discovery

Advantages and Disadvantages of Client-side Service Discovery Implementation:

Advantage: Eliminating an extra hop requires a dedicated load balancer.

Disadvantage: The load balancing logic must be implemented by the Service Consumer.

The Service Consumer and the Service Registry are inextricably linked in the client-side service discovery implementation. This means that logic for Client-Side Discovery must be implemented for each programming language and framework used by Service Consumers.

Server-Side Service Discovery Implementation:
The Server-Side Discovery model uses an intermediary that acts as a Load Balancer. Here, the client sends a request to a service through a load balancer, which serves as an orchestrator, and the load balancer searches the Service Registry for available service instances and routes each request to one of them.

The diagram below depicts how communication occurs in service-side service discovery:

Service-Side Service Discovery

Advantages and Disadvantages of using Service-Side Service Discovery:

Advantages: The main advantage of this method is the approach of using a Load balancer, which creates such a level of abstraction lightens the Service Consumer by removing the need to deal with the lookup procedure. Here, we don’t need to implement the discovery logic for each language and framework that the Service Consumer employs.

Disadvantages: The main disadvantage is that we must configure and manage the Load Balancer unless it is already included in the deployment environment.