What is Service Discovery in Microservices?
Hello everyone. In this article, let's go through Service Discovery in Microservices architecture.
Monolithic Architecture
Before the advent of Microservices architecture, Monolithic architecture was predominant across the web. As seen from the picture above, lets us assume that this is the Monolith application that runs on a physical server on-premise. It has 3 servers and all of them have static IPs and the requests are routed to them using a load balancer. The IP of these 3 servers is stored in a config file usually and is read by the load balancer. In this case, there is no need for a Service Registry as the IP addresses of these 3 APP servers are fixed and won't change.
Microservices Architecture
In the case of a micro-service architecture that is deployed in the cloud, there will be a lot of microservice components for different services. Every microservice can scale differently based on the demands.
The Order service might have 4 or 5 instances and Billing Service might have 2 or 3 instances running. With each instance having a dynamic network address because of multiple factors like Autoscaling, Upgrade, Failure, Deployments, etc, it is extremely difficult to locate these services and communicate with them.
This problem leads to the solution in the form of a design pattern called Service Discovery.
What is Service Discovery
Service Discovery is a design pattern by which the Client or the API Gateways discover the network info (IP address and port) of the Server through an important component called Service Registry or Discovery Server.
The Service Registry keeps track of the entire individual microservices in the architecture and stores the IP address / Port of those in its database. Every time a service scales up or down, it will send a heartbeat to the discovery service and it will update its database accordingly. The discovery server / Registry also groups the instances of each service accordingly.
There are two types of Service Discovery as follows
- Client-Side service discovery
In the Client-side service discovery pattern, the client is responsible for discovering the network address of the service instances and the load balance of the requests to the instances of the same service.
The client will query the Service Registry to get the list of available instances for the particular service and then use an efficient load balancing algorithm to select one of the instances and send a request to it.
Netflix OSS is an example of Client Side Service Discovery. Eureka Server is the Service Registry and Netflix Ribbon is a client-side load balancer. The ribbon is a client-side load balancer that gives you a lot of control over the behavior of HTTP and TCP clients. Eg: When microservice A talks to microservice B using Feign Client, service A contacts Eureka to get the information about all the instances of Service B. Then the Ribbon load balancer on Service A will find the best instance of Service B to send the request.
Advantages:
- This pattern is quite simple and straightforward to implement as the client only needs to communicate with the Service Registry
- The client can have its own Load Balancings algorithms like Round Robin or Consistent Hashing etc
Drawback:
- The Service Discovery logic is tightly coupled with the client and hence it is difficult if we have different types of clients and frameworks
2. Server-side service discovery
This is the most widely used pattern for Service Discovery. Here the client makes calls to the Load Balancer which then queries the Service Registry to discover the instances and query one of them.
The load balancing logic now stays inside the Load Balancer component and this is common to any client or framework that requests it. Load Balancer component is the only change when compared to the Client Side Service Discovery
The AWS Elastic Load Balancer (ELB) is an example of a server-side discovery pattern. The EC2 servers or ECS containers will register their network information to the ELB which acts as both the Router and the Service Registry. When a request reaches ELB, it can route to the specific instances after picking the best match through the algorithm.
Advantages:
- The discovery information is abstracted de-couple from the clients
- Implementation is quite simple for the client side as it just needs to call the load balancer DNS
Drawbacks:
- For a non-cloud environment, the Router or Load Balancer is an extra physical component to be maintained in terms of configuration, replication, availability, etc.
- More network hops are required than when using the Client Side Discovery Pattern
Common Service Registry / Discovery Frameworks
The most widely used Service Discovery frameworks are
- Netflix OSS — This is widely used for Spring framework applications that are deployed in the cloud. Eureka is the Service Registry (Discovery Server) and all other microservices components are the clients of Eureka.
- etcd — This is a highly available, distributed, consistent, key‑value store that is used for shared configuration and service discovery which is used by Kubernetes and Cloud Foundry.
- consul — Hashicorp consul is the one-stop solution for microservices (self) registration, discovery, health checks, key-value store, and load balancing. It is one of the most powerful frameworks
Moreover, every cloud provider has its own service discovery as well. I will leave it to you to explore in-depth Service Discovery.
In this article, we saw what is the need for Service Discovery in the modern microservices architecture and also the various types of such patterns.
Please follow me for more content. Happy learning and stay tuned!!!
If you like to get more updates from me, please follow me on Medium and subscribe to the email alerts. If you are considering buying a medium membership, please buy through my referral linkIf you wanted to learn more about microservices, please go through my article
