In this article. we will discuss Microservice Discovery Patterns and Registry in the Microservice architecture. We will see how to register and discover services.
In the series of Microservice architecture tutorial, we have discussed a lot of things like Software architecture patterns such as Microservice architecture pattern and Monolithic. We have saw differences between them as well. Also, we have seen how to decompose an application into microservice based architecture and how to grasp the benefits of the microservices architecture.
In microservices architectural patterns, we have also discussed different deployment patterns for an application based on the Microservice architecture.
Deployment patterns such as the following:
- Multiple instances of the Microservices per host &
- A single instance of the Microservices per host
- A single instance of the Microservices per VM
- A single instance of the Microservices per Container.
You can also read this article for the inter-service communication in the Microservice architectural patterns for either synchronous communication or asynchronous communication. In Inter-Service Communications, we have discussed how services communicate with each other and also describe different aspects of communication within a microservices architecture. Event-based and Message-driven inter-service communication is frequently used in asynchronous communication Microservice communication.
As you know, we require both the IP address and the port for any communication between services when using either the REST API or the Apache Thrift API. However, it is possible to change the IP address, so how can we ensure that service communication remains stable? In this article, we will explore the solution to this problem and discuss other issues related to service discovery.
The need for Service Discovery in a Microservices Architecture
In traditional or old-fashioned application architecture, IP addresses and ports are mainly static and fixed so that they can be easily managed for client applications. In a static, configuration-based application, each service is deployed at the same location and only rarely do we need to change the location of the services. However, in the case of cloud-based microservices applications, IP addresses and ports are very difficult, and sometimes even impossible, to manage.
In the microservice architecture, we cannot guarantee that there will be static configuration because microservices are independently deployable and individual teams work on individual microservices; each team can deploy and scale their microservices independently. More services and instances may also be added to the system to provide scalability to the distributed application. Because of this scaling, service locations can change frequently, so locations cannot be thought of as static. This means that a more dynamic configuration is needed for the microservice architecture.
Let’s assume, in a Microservices based application, we have many instances of the several services on the different server. Due to dynamically changes in the locations of these services, it is much more difficult to manage the service discovery in the client application as the following diagram:
In the preceding diagram, you can see that all service instances have dynamic IP addresses and ports. However, the service clients and the API Gateway, which we will discuss in the next chapter, need to be able to communicate with the services. The client code, or the API Gateway, therefore need a better mechanism to find services—one which doesn’t require the hardcoded location of a service.
In the following section, we’ll take a look at the service discovery patterns.
Microservice Discovery Patterns
In the Microservices architecture, service discovery is very important to implement. It helps client application to search for services without hardcode network location. We can implement this service discovery pattern in two ways such as client-side discovery and server-side discovery.
Let’s see these service discovery patterns in details in the following section.
The client-side discovery pattern
In Microservices based application, services need to communicate with one another for a complete business task. In Monolithic application, this communication between the services is very easy because all services typically are part of the same application. But in a distributed system, services are not part of the same application, these services run on the separate independent virtual machine or containers with well-known locations (hosts and ports) and these locations may be dynamically changed due to scaling up the application. So, in this case, service discovery helps you to overcome from hardcode network locations.
In client-side discovery, a client service finds the location of other service instances by querying a Service Registry. The client is also responsible for managing load balancing requests across services. The Service Registry is a database for microservice instances. On the client side, we have to use an algorithm to select one of the available instances using a few parameters.
The following diagram illustrates the client-side service discovery pattern:
As you can see, the client service itself registers with the registry server. Other microservices also register with the same registry server. All instances of services are registered with a specific location on the registry server. The client service uses the service name with which it is registered, and is removed from the Service Registry when the instance terminates. The service instance’s registration is typically refreshed periodically using a heartbeat mechanism.
Pros of the client-side discovery pattern
This service discovery pattern has various advantages and disadvantages. The advantages are as follows:
- This pattern is very simple and straightforward because there are no moving parts related to the distributed application, except the registry server
- You can apply more intelligence on the client side to make load balancing decisions
Cons of the client-side discovery pattern
The client-side discovery pattern also has the following disadvantages:
- This approach of the service discovery couples the client code with the registry server code.
- You have to implement discovery logic for each service because the services may use different programming language.
Example the client-side discovery pattern
Netflix OSS provides a client‑side discovery pattern called Netflix Eureka. Netflix Eureka is a Service Registry that provides a REST API to manage service instance registration and send queries to available instances.
The Netflix also provides another component called Netflix Ribbon, which is an IPC client that works with Eureka to load balance requests across available service instances.
First, let’s have a look at another approach: the server-side service discovery pattern.
The server-side service discovery pattern
In the server-side discovery pattern, the client isn’t aware of the Service Registry. The client service requests a service using a load balancer, which then queries the Service Registry.
The AWS Elastic Load Balancer (ELB) is one example of server-side discovery. It is commonly used as a load balancer for external traffic from the internet. It manages the load between a set of registered Amazon Elastic Compute Cloud (EC2) instances or Amazon EC2 Container Service (ECS) containers. Other examples include HTTP servers and load balancers such as NGINX Plus.
In the server-side service discovery pattern, the client doesn’t need to worry about managing the code or algorithm for load balancing and discovering services. Instead, we can use a separate load balancer server.
The following diagram illustrates server-side service discovery:
As you can see in the preceding diagram, this approach uses a Load Balancer server that is separate from the client service. The client service makes a request directly to the load balancer, which queries the Service Registry and then finds a service.
Pros of server-side service discovery
The server-side service discovery pattern has various advantages and disadvantages. Some of the advantages include the following:
- In this approach, the client service doesn’t require the complex logic of searching for services or load balancing traffic
- There is no need to implement discovery logic for each programming language and framework used by a service client
- Some cloud environments, such as AWS Elastic load balancer, provide this functionality for free
Cons of server-side service discovery
This approach also has the following disadvantages:
- The load balancer needs to be a highly available system, so you have to set it up and manage it carefully.
- Load balancer could be a single point of failure, so it needs to be replicated for availability and capacity.
- The load balancer server must support important protocols such as HTTP, gRPC, and Thrift.
- It has more network rounds than the client-side service discovery pattern.
Microservice Registry
The service registry is a database of the instances of the services. It stores its locations. The instances of the service are registered with the registry service on startup and deregistered automatically at the time of shutdown. Netflix provides a registry service server that is Eureka. Spring Boot provides integration with the Netflix API, so we can easily implement a microservice registry using Netflix’s Eureka server.
The client service, or external routers, make a query to find the available instances of a service. The registry server provides all of the available instances of the requested service. Take a look at the following diagram, which shows Service Registry and discovery with Eureka:
As you can see, all services register with the Eureka server to make themselves available. In the next article, we’ll look at how to register services with Eureka.
Conclusion
Service discovery and registry are key parts of a microservice-based application because locations of service instances are always changing. We can implement service discovery using two approaches: client-side service discovery and server-side service discovery.
References
- Books- Hands on Microservices by Dinesh Rajput
- Article: Microservices.io
