Service Registration

Also known as service announcements, this is simply the process where changes to a service status are written to a service registry. These changes are typically when a service is available to handle requests, or is no longer available to handle requests. When a new service instance has been scheduled on a node and is ready to receive requests, we need to enable consumers of the service know that it’s ready and where it is. Multiple instances of a service can be scheduled across the cluster, all listening on different IP addresses and ports. It’s part of a service announcement’s job to simply report to the service registry, “I’m an Order service ready to receive requests and I am listening on 10.0.0.4 at port 9001.” The service registry then maintains this information, and when the service is shut down the service needs to let the registry know that it’s going away. We can also configure a time-to-live (TTL) on the records and expect the service to routinely check back in, or we can perform health checks on the service to make sure it has not silently disappeared.

A lot of different ways exist to implement this seemingly simple task. Common approaches are to make this the job of the service orchestration tools, make it part of the service initialization, or include it as a node management sidecar process. Kubernetes, for example, will manage this information in a service registry store like etcd when scheduling pods to run on nodes. Projects like Airbnb Nerve or Glider Labs Registrator will automatically register and deregister services for Docker containers by inspecting containers on a node as they come online. Another approach would be to have the service register itself as part of the service startup, and to implement this in a framework.

Service Announcement Implementation Options:

• Orchestration tooling is responsible for maintaining this information. The orchestrator will maintain a list of scheduled and running service instances in the cluster as well as the health of each instance.

• The service itself implements announcements, and on service startup it will make a call to register itself. This can be a simple approach and it can be implemented in a shared library for each supported language.

• A sidecar service running on each node monitors services and performs the registration and deregistration. Externalizing registration to a sidecar process means the service implementation does not need to be concerned with the task of registration or deregistration.