Service Registry is collective information of services along with related details including, the location of service and number of instances. Since service registry is the database of services available, it must be highly available. There are two stages of interaction with Service Registry-
- Registration — whenever a new service or service instance scales in/out, it needs to register/de-register itself with Service Registry.
- Discovery — whenever client needs to interact with service, client would lookup for service details or discover service on Service Registry.
Registration
In Microservices world, services go up/down with developers constantly deploying changes or the service instances scale up/down based on requirement. While this happens, it is important to constantly keep up-to date details of services. And this is where registration comes into play. There are two flavours of service registration:
1. Self-registration
The services own the responsibility of registering itself with Service Registry on startup and de-register on shutdown. This enables services to be self-aware of their state. Also, has a drawback of services being tightly coupled with Service Registry. Also, services having the overhead of maintaining the framework specific implementation of registration and de-registration.
An example implementation of self-registration is using Netflix’s Eureka client to register services itself with Eureka Service Registry (which we’ll discuss in a while). The spring cloud client example can register using configuration as:
eureka.client.service-url.default-zone=http://localhost:5001/eureka
Note, Eureka Service Registry is available at port 5001 and the client service is registering on start-up. Complete implementation available on GitHub.
2. Third-party Registration
As opposed to self-registration, Thrid-party registration allows delegation of service registration/de-registration task to Third-party registrar (service manager) component. On service instance start-up, service manager is responsible for registering the service with Service Registry. Similarly, it de-registers on service shutdown. With this option, service resilience can be better handled as service manager can handle these requests more elegantly than self-registration where a service can abruptly go down with Service Registry not being aware. Service manger being one of the important components of microservices architecture, it needs to be highly available.
There are various third party tools available for this purpose. Some of them include:
* Istio, side car application for Kubernetes
* Prana, side car application for Eureka implementation services
* Apache ZooKeeper
* AWS Auto-scaling with Elastic Load Balancers manages scaling of EC2 instances
Discovery
Service discovery is the counter aspect of service registration. For the client to make calls to service instances, it first needs to locate the available service and its details and then proceed with actual call. There are two implementations for service discovery:
1. Client-side Service Discovery
In this pattern, the client needs to handle the overhead of implementation required to identify the service instance and its details. This is usually called the discovery service (Service Registry). Then make the actual service call with request load balancing as well. So, there are steps involved before making the actual call itself - first call to discovery service and second call to the service. With this approach, each client needs to be additionally aware of discovery service and also have client-side load balancing implemented.
Example implementation of client-side service discovery pattern is with Eureka Server with class annotated as @EnableEurekaServer. Sample implementation available in Github. The client-side load balancing can be achieved using Ribbon load balancer. As mentioned in self-registration pattern, client-side discovery tightly couples services with Service Registry for registration and discovery which needs to be considered while architecting microservices.
2. Server-side Service Discovery
Server-side service discovery often implemented using API gateway. API gateway handles the discovery of service instances and routing client requests to these instances accordingly. This leaves the client side implementation light with client always directing the service requests to API gateway. No need to know where the actual services are located and its details. This also moves the load balancing overhead to server-side. Gateways can implement caching allowing service discovery with low latency.
Few of the common implementation strategies for this type of discovery service is using - AWS load balancers where EC2 instances register with ELB. And EC2 instances’ auto-scaling allows tracking the available instances based on scaling rules set-up. Clustering with Kubernetes also allows server-side service discovery.
References: Ribbon load balancer documentation - https://cloud.spring.io/spring-cloud-netflix/multi/multi_spring-cloud-ribbon.html
