Service registry

The service registry acts as a database of microservices. It must have a dedicated static IP address or a fixed DNS name that must be accessible from all the clients, as shown in the following diagram. Since all the clients depend on a service registry to look up the target services, it also becomes a single point of failure for the entire microservices architecture. Therefore, the implementation of the service registry must be extremely lightweight and should support high availability by default. Some common tools that can be used as a service registry are Apache Zookeeper (http://zookeeper.apache.org/), etcd (https://github.com/coreos/etcd), and consul (https://www.consul.io/):

To keep the registry up to date, microservices should either implement the startup/shutdown event to register/deregister with the service registry themselves or there should be an external service configured to keep track of services and keep the registry up to date. Some orchestration tools, such as Kubernetes (https://kubernetes.io/), support service registry out of the box and maintain the registry for the entire infrastructure.