Introduction
In a typical monolithic layered architecture, a presentation or a controller layer communicates with the service layer through a function call. The request URL has a fixed endpoint address which is used to invoke different services or service functions. With microservices, you are dealing with plethora of services with dynamic endpoint address and number of service instances.
Microservices based applications are typically deployed in a server environment like a container or virualized host that are assigned dynamic IP address. The service instances itself could change dynamically based on the load balancer configuration. With these dynamic characteristics of microservices, it becomes imperative to find a pattern where services can be looked up in a location independent way without really worrying about its actual endpoint address. The solution is to apply a Service Discovery pattern while devising a microservices based architecture.
Service Discovery pattern can be applied using one of the different variations. These variations are also called patterns in itself. Some of these patterns are as follows:
Server-Side Service Discovery
This pattern enables client application to discover services via a router or a load balancer. The endpoint address of the router is well known. The router in turn looks up the service registry to make a request to appropriate service instance. The lookup logic is built into the router.
Pros
- It makes the client application lighter as it doen not have to deal with the lookup procedure and simply makes a request for services to the router.
Cons
- Router or load balancer is another component that needs to be installed and configured in your deployment environment. Moreover, the router node itself may have to be placed under the realm of high availablity and fault tolerant setup.
- It adds an overhead on one extra network hop to discover services.
Example
AWS Elastic Load Balance (ELB)
Client-Side Service Discovery
This pattern enables client application to discover services by looking up or querying Service Registry. The service instances and its endpoints are registered with the registry which is a repository or database of services.
Pros
- Unlike Server-Side Service Discovery pattern, client application does not have to route through a router or a load balancer and therefore can avoid that extra hop.
Cons
- You have to build and maintain a service registry repository that can be an extra overhead of maintaining service instances.
- Lookup procedure is client driven. Depending on the programming language used, you have to devise service discovery logic. So it needs that extra effort to build the lookup component for every type of client application.
Example
Netflix Eureka (service registry) and Netflix Ribbon (client)
Service Registry
Service discovery happens on service registry and therefore it is necessary to implement a registry or repository containing service instances along with its endpoint address. The registry component itself can be deployed on a separate node. You can use either client side or server side lookup mechanism to query the service registry for the appropriate service.
Pros
- Provides a separate infrastructure for the client to discover services in a location independent manner.
Cons
- Service registry is a separate component and needs to be maintained and configured on a dedicated node. The registry node itself has to be placed under the realm of high availability and fault tolerant setup. One cannot afford to lose service instances due to the failure of registry node.
Example
Netflix Eureka, Apache Zookeeper, Consul, Etcd
Self Registration
The pattern suggests registration of service instances on service registry startup so that they are ready for lookup and similarly allow for deregistration of service upon registry shutdown.
Pros
- Service knows its changing state like Available, Starting, Started, Shutdown. A more exhaustive lifecycle events can be implemented.
Cons
- Service registration obviously does not happen automatically. It requires an extra overhead of writing an appropriate registration logic in the service component.
- Service may become worthless if its running but unable to service request from the client. Such a service may not be able to de-register itself.
Example
Netflix Eureka, Apache Zookeeper
Third Party Registration
Unlike self registration, here services are registered and unregistered by a third party registrar component. A third party registrar registers the service instance when it is started and unregisters the instance when it is shutdown or destroyed.
Pros
- No extra overhead of writing a registration logic in the service component as it is now handled by third party registrar.
- Effective service monitoring is possible with respect to its health-check and appropriate events can be handled based on the health-check parameters.
Cons
- Service health check may or may not be possible depending on third party registrar used. Some registrar may be ill-equipped to understand the worthiness of service. This is to say whether service once registered is able to service the request or not.
- Service registration is tightly coupled with the third party registrar component and therefore it becomes another entity in the deployment environment. A dedicated node acting as a registrar needs to be installed and configured and also bring under the purview of high availability setup to avoid failure scenario.
Example
Netflix Prana, AWS Autoscaling, Registrator
| Reference: | Microservices Series: A Quick Look At Service Discovery Patterns from our JCG partner Rajeev Hathi at the TECH ORGAN blog. |
What sites must l keep visiting to understand what is behind coding well, particularly how to build fantastic apps.
Thanks!