Getting your Trinity Audio player ready...
|
As many of us already know that ‘Microservices’ are expanding their footprint in overall software implementations across the world and the challenges as a designer or architect are also growing in order as business expectations are growing much faster. As term refers ‘Microservices’ means set of services grouped by functionality. Based on the size of implementation typical number of services in an environment will range from few 10s to many hundreds (Sometimes few thousand). Keeping a track of all those of services and making sure of invoking right service(Correct URL) all the time for a given need becomes Hercules task as the size of the application grows. When we add versioning and auto scale dimensions on top of it complexity grows to next level. If there is a suboptimal design in this specific area, we will end up having maintenance nightmare, unhappy customer and sleepless nights for DevOps team. But don’t worry, over the years many of our peers solved this and during this process, many good tools were also evolved. The process of registering service and calling it uniquely correct all the time is called ‘Service Discovery’. In this blog, we cover details about service discovery and different ways of designing it.
The Problem Of Discovery:
Because of upgrades in service instances, failure of VMs and/or auto-scaling, services will be dynamically launched from the new network location or removed from existing network locations. Irrespective of changes to service instance location, the client ( be in the front end or backend ) should be able to call right service all the time and there should not be manual effort involved to maintain and run this.
Solution :
There are two main service discovery patterns that we generally use to solve this problem of discovery.
- Client-side discovery
- Server-side discovery
Client-side discovery :
If we are using the Client side discovery, it is Client’s responsibility to identify the all available service instances and load balance the requests among all available service instances. To achieve this, Client makes a query to Service Registry, which knows the all available services instances. The client uses a load balancing mechanism to find one of the available service instances and sends a request.
The following diagram shows the structure of client-side discovery implementation:
Newly created all the network locations of service instances can be registered with the service registry on service instances startup. The Service instance can be deregistered (deleted) from the service registry on the particular service instance termination. Generally, the service instance registration/deregistration will be typically refreshed for every 30 secs.
Netflix OSS supports the client side discovery pattern and Netflix Eureka is the service registry. Netflix Eureka also provides a RESTful API for managing the newly created service-instances registration and for sending the request to available instances. To work with Netflix Eureka service registry we can use Netflix Ribbon, it is an IPC client to load balance the client requests across the available service instances
Server-side discovery :
In this pattern, the Client sends a request to a service via a load balancer. The load balancer makes a query to the service registry and routes each client request to an available service instance. In case of client-side discovery, the newly created service instances can be registered/deregistered with the service registry.
The following diagram shows the structure of server-side discovery implementation:
AWS is offering one of the most popular server-side discovery routers i.e The AWS Elastic Load Balancer (ELB). Nowadays an ELB is commonly used to load balance the external traffic from the Internet. But, we can also use an ELB to load balance the traffic that is internal to a virtual private cloud (VPC). A client makes requests (HTTP or TCP) via the ELB using its DNS name. The ELB load balances the traffic among a set of registered Elastic Compute Cloud (EC2) instances or EC2 Container Service (ECS) containers. There isn’t a separate service registry. Instead, EC2 instances and ECS containers are registered with the ELB itself
As a part of this article, we briefly talked about service discovery and different implementations of service discovery in microservices architecture and what are the available tools in both implementations.
References :
https://spring.io/guides/gs/service-registration-and-discovery/
