Problem
How do clients of a service (in the case of Client-side discovery) and/or routers (in the case of Server-side discovery) know about the available instances of a service?
Forces
- Each instance of service exposes a remote API such as HTTP/REST, or Thrift etc. at a particular location (host and port)
- The number of services instances and their locations changes dynamically. Virtual machines and containers are usually assigned a dynamic IP address. An EC2 Autoscaling Group, for example, adjusts the number of instances based on load.
Solution
Implement a service registry, which is a database of services, their instances, and health check API their locations.
Service instances are registered with the service registry on startup and deregistered on shutdown.
The client of the service and/or routers query the service registry to find the available instances of a service. A service registry might invoke a service instance’s to verify that it is able to handle requests.
The service registry is a key part of service discovery. It is a database containing the network locations of service instances.
A service registry needs to be highly available and up to date. Clients can cache network locations obtained from the service registry. However, that information eventually becomes out of date and clients become unable to discover service instances.
Consequently, a service registry consists of a cluster of servers that use a replication protocol to maintain consistency.
As mentioned earlier, Netflix Eureka is good example of a
service registry. It provides a REST API for registering and querying
service instances. A service instance registers its network location using
a POST request.
Every 30 seconds it must refresh its registration using a PUT request. A registration is removed by either using an
HTTP DELETE request or by the instance registration timing out. As you might
expect, a client can retrieve the registered service instances by using an
HTTP GET request.
Netflix achieves high availability by running one or more Eureka
servers in each Amazon EC2 availability zone. Each Eureka server runs on
an EC2 instance that has an Elastic IP address. DNS TEXT records are used to store the Eureka cluster configuration, which
is a map from availability zones to a list of the network locations of
Eureka servers.
When a Eureka server starts up, it queries DNS to retrieve the Eureka cluster configuration, locates its peers, and assigns itself an unused Elastic IP address.
Eureka clients – services and service clients – query DNS to discover the network locations of Eureka servers. Clients prefer to use a Eureka server in the same availability zone. However, if none is available, the client uses a Eureka server in another availability zone.
Other examples of service registries include:
- etcd – A highly available, distributed, consistent, key‑value store that is used for shared configuration and service discovery. Two notable projects that use etcd are Kubernetes and Cloud Foundry.
- consul – A tool for discovering and configuring services. It provides an API that allows clients to register and discover services. Consul can perform health checks to determine service availability.
- Apache Zookeeper – A widely used, high‑performance coordination service for distributed applications. Apache Zookeeper was originally a subproject of Hadoop but is now a top‑level project.
Also, as noted previously, some systems such as Kubernetes, Marathon, and AWS do not have an explicit service registry. Instead, the service registry is just a built‑in part of the infrastructure.
Now that we have looked at the concept of a service registry, let’s look at how service instances are registered with the service registry.
