Through this article we’re going to discuss, one of the most vital components of a microservice architecture, which are Service Discovery and Service Registry.
Let’s starts with an Introduction
In a traditional monolithic architecture, as the complexity of building an application can increase over time. Using auto-scaling feature cannot be a breeze because this type of architecture requires to be scaled as a whole unit which may lead to higher hardware usage.
On the other hand, this type of architecture, application consists of a bunch of services that are linked as a one-unit code base. The network location of all the services are manually added in a configuration file. Therefore, as the application grows and services are constantly updated it’s going to be a hard work for developers to update this file.
For these two reasons, many companies are moving towards microservices architecture in a cloud-based environment to enable their development teams to co-ordinate with each other easily and efficiently.
What is a Service Discovery?
An application that relies on a cloud microservice architecture can include a bunch of microservices that all need to communicate securely with each other. However. due to auto-scaling and failure, the number of microservice instances may vary; hence it’s going to be difficult to manage API calls between instances of these microservices.
The main challenge here is, how does a microservice knows the network location of an instance of another microservice?
That’s where Service Discovery find it’s role. This component keeps tracking all available microservices and registers them, so they can call each other.
Note: the microservice needs to be up and running in order to be registered in a Service Registry.
The following diagram shows the structure of this pattern.
Why using a Service Discovery?
Let’s imagine this scenario, where a microservice B invokes a REST API in a microservice A, in a cloud-based application, due to auto-scaling feature, with cloud, you can request for more resources when the load increases (scale Out) and send them back to the cloud when the load goes down (scale In). thereby, whenever a new instance of microservice A is launched, it registers itself in a Service Registry. Then, when microservice B wants to call an instance of microservice A, first it asks the Service Registry for the available instances of microservice A.
In the case of the diagram above, the scenario looks like this:
microservice Bmakes a request to the Service Registry.- Service Registry obtains all information about the exact location of the instance of
microservice A(hostname + port number) and sends back a response tomicroservice B. microservice Bsends a second request to the instance ofmicroservice Aitself.
Architecture of Service Discovery
We find three main components of the Service Discovery:
- Service Registry : a database that stores each service name and its address location.
- Service or Service Provider or Register Agent : represents each service that registers itself when it enters the system and deregisters when it leaves the system or in case of a failure.
- Service Consumer or Service Discovery Client : asks the address of the needed service to the Service Registry.
Types of Service Discovery Patterns
Client-Side Service Discovery
In the Client-Side Service Discovery, the client is responsible for all the work, which means; the client sends a lookup request to the Service Discovery to identify the location of the microservice it needs, then it makes a second request to the actual microservice itself.
The following diagram shows the structure of this pattern;
The network location of a new microservice instance is registered in a Service Registry when it starts up and unregistered when it ends.
Server-Side Service Discovery
In the Server-Side Service Discovery, the client makes a request call to the Load Balancer (for example API Gateway), then it forwards the request to the Service Discovery to obtain all information about the network location of the needed microservice instance. Then the Service Discovery sends back a response to the Load Balancer which then sends the request to the proper microservice instance.
In order to improve availability of the microservice application, Load Balancer comes to the picture, its role is routing the incoming requests to the proper running microservice instances.
The following diagram shows the structure of this pattern;
The Server-Side Service Discovery Pattern scenario boils down like the following:
- Client makes a request to the Load Balancer server.
- Load Balancer sends a request to the Service Discovery to obtain the information about exact location of needed instance microservice.
What is a Service Registry?
Service Registry is a centralized service of the Service Discovery, it provides a database that contains a list of all available microservice or microservices instances. Each microservice/microservice instance with its own network location.
The Service Registry expects a regular heartbeat message from each service instance. If an instance fails to send the heartbeat, the Service Registry will remove the instance from its registry.
When a team of developers are building a cloud based microservice application (online course application), they may auto-scaling the microservice instances. Hence, the Service Registry ensure availability and constantly stay up to date to these changes.
Types of Service Registry Patterns
Self-Registration Pattern
Services own the responsibility of registering itself on startup and unregister on shut down, the drawback of this pattern is that microservices or microservices instances are linked with the Service Registry.
Third-Party Registration
Contrasted with Self Registration Pattern, another component known as the Service Registrar manages all available microservices or microservice instances. When it notices a new microservice instance it registers this instance with the Service Registry, this component also deregisters the ended microservice instance from the Service Registry.
The third party registration pattern has multiple benefits and drawbacks. A major benefit is that services are not linked directly to the Service Registry. You don’t need to implement Service Registration logic for each programming language and framework used by your developers. Instead, service instance registration is handled in a centralized dedicated service.