Service Registry Pattern ¶

Services discovery in Monolithic/SOA/Microservices¶

Services typically need to call one another.

In a monolithic application, services invoke one another through language-level method or procedure calls.
In a traditional distributed system SOA deployment, services run at fixed, well known locations (hosts and ports) and so can easily call one another using HTTP/REST or some RPC mechanism.
However, a modern microservice-based application typically runs in a virtualized or containerized environments where the number of instances of a service and their locations changes dynamically.

Why we need it?¶

Each microservice has a unique name/URL that's used to resolve its location. Your microservice needs to be addressable wherever it's running. In the same way that DNS resolves a URL to a particular computer IP, your microservice needs to have a unique name so that its current location is discoverable.

Handling service failure

If a computer fails, the registry service must be able to indicate where the service is running now.

Caching/Storing the results

The registry is a database containing the network locations of service instances. A service registry needs to be highly available and up-to-date. Clients could cache network locations obtained from the service registry.

Types of service discovery¶

Client-side¶

When using client‑side discovery, the client is responsible for determining the network locations of available service instances and load balancing requests across them. The client queries a service registry, which is a database of available service instances. The client then uses a load‑balancing algorithm to select one of the available service instances and makes a request.

Note

The network location of a service instance is registered with the service registry when it starts up. It is removed from the service registry when the instance terminates. The service instance’s registration is typically refreshed periodically using a heartbeat mechanism.

Sever-side¶

When making a request to a service, the client makes a request via a router (a.k.a load balancer) that runs at a well known location. The router queries a service registry, which might be built into the router, and forwards the request to an available service instance.

Registry for AKS¶

Using service registy in AKS

In some microservice deployment environments (called clusters, to be covered in a later section), service discovery is built in. For example, an Azure Kubernetes Service (AKS) environment can handle service instance registration and deregistration. It also runs a proxy on each cluster host that plays the role of server-side discovery router.

servcie discovery example¶

ELB as Service registry and server-side discovery router

An AWS Elastic Load Balancer (ELB) is an example of a server-side discovery router. A client makes HTTP requests (or opens TCP connections) to the ELB, which load balances the traffic amongst a set of EC2 instances. An ELB can load balance either external traffic from the Internet or, when deployed in a VPC, load balance internal traffic.

An ELB also functions as a Service Registry. EC2 instances are registered with the ELB either explicitly via an API call or automatically as part of an auto-scaling group.