An Introduction to Service Discovery

In a traditional application, the network location of service instances are usually quite static and can be loaded from a configuration file, that is from time to time manually updated by system administrators.

Unfortunately, this solution hardly works when it comes to modern microservice-based applications that run in virtualized or containerized environments, where the number of instances and their locations change dynamically.

This dynamic nature comes from the fact that the services lifespans are usually measured in seconds or minutes, due to them being scaled up and down, upgraded or simply failing.

Consequently, we must implement a mechanism that enables services to locate each other in order for them to communicate through their APIs and this mechanism is called Service Discovery.

Although there are many possible implementations, they usually include a central server that maintains a list of the services network’s locations called a Service Registry and clients that connect to this central server to update and resolve them.

The Service Registry

The service registry is a highly available database containing the network locations of the various service instances and is the main component of the service discovery mechanism, but unlike other services of the infrastructure, it needs to be deployed on a fixed and well known IP address so it can be easily accessed.

In short, it allows services to register and unregister themselves upon startup and shutdown by sending their network location and other information such as their name or their version number for example, in order to let other services know of their existence.

In addition to that, services can also periodically send a special type of message called a heartbeat, so that the service registry knows they are still available and ready to receive requests.

That being said, there are two ways to register a service.

Self-registration

The first one, which is by far the easiest, is called self-registration as it puts a service in charge of managing its own registration by directly connecting to the registry.

However this approach couples the service to the registry, as the registration code must be implemented in every service, in each programming language.

Third-party registration

The second method is the third-party registration where a component called a registrar tracks the changes of the services in the running environment and automatically registers or unregisters them according to their status.

It is quite great in the sense that there’s no need to implement a registration logic in each service anymore, but it introduces an additional component with high availability into the infrastructure that needs to be properly set up and managed.

Service discovery patterns

Client-side discovery

When using the client-side discovery pattern, the client is responsible for fetching the network locations of available service instances by querying the service registry.

It allows the client to make application-specific decisions by load-balancing requests across them, using algorithms like round-robin for example.

The main problem tho, is that there must one implementation of the querying logic per client and so potentially per language or framework. For example one implementation in JavaScript for your website and another one in Java for your Android app.

Server-side discovery

When using the server-side discovery pattern, the client sends its requests to a router that will be in charge of querying the registry service and re-routing that requests to the available instances, using its own load-balancing algorithm.

The advantage of this pattern is that the discovery logic is taken away from the client, but you have to keep in mind that it introduces a new sensitive component that needs to be carefully managed, as the load-balancer must be highly available, since without it, no requests will reach any of the services.