Let's say you’re writing some code that invokes a service that has a REST API. In order to make a request, your code needs to know the network location (IP address and port) of a service instance. In a traditional application, the network locations of service instances are usually static.
For example, your code could read the network locations from a configuration file that’s occasionally updated. But in a modern, cloud-based microservices application, it’s usually not that simple. It is much more dynamic.
Service instances have dynamically assigned network locations. Moreover, the set of service instances changes dynamically because of autoscaling, failures, and upgrades.Consequently, your client code must use service discovery.
What is Service Discovery?
From the above image you can see, you can’t statically configure a client with the IP addresses of the services. Instead, an application must use a dynamic service discovery mechanism.
Service discovery is conceptually quite simple: its key component is a service registry, which is a database of the network locations of an application’s service instances.
The service discovery mechanism updates the service registry when service instances start and stop. When a client invokes a service, the service discovery mechanism queries the service registry to obtain a list of available service instances and routes the request to one of them.
In this article, I will mention about 4 service discovery patterns that you should consider for your microservices.
- 1. Self Registration Pattern
- 2. Client Side Discovery Pattern
- 3. Server Side Discovery Pattern
- 4. 3rd Party Registration Pattern
The services and their clients interact directly with the service registry:
1. Self Registration Pattern
The first pattern is the Self Registration pattern. A service instance invokes the service registry’s registration API to register its network location. It may also supply a health check URL.
The health check URL is an API end-point that the service registry invokes periodically to verify that the service instance is healthy and available to handle requests.
A service registry may require a service instance to periodically invoke a “heartbeat” API in order to prevent its registration from expiring.
A service instance registers itself with the service registry. Find out more details here.
2. Client Side Discovery Pattern
The second pattern is the Client-side discovery pattern. When a service client wants to invoke a service, it queries the service registry to obtain a list of the service’s instances.
To improve performance, a client might cache the service instances. The service client then uses a load-balancing algorithm, such as a round-robin or random, to select a ser-
vice instance. It then makes a request to a select service instance.
Find out more details here
The deployment infrastructure handles service discovery:
3. Server Side Discovery Pattern
In this pattern, Instead of a client querying the service registry, it makes a request to a DNS name, which resolves to a request router that queries the service registry and load-balances requests.
A client makes a request to a router, which is responsible for service discovery. Find out more details here.
4. 3rd Party Registration Pattern
In this pattern, Instead of a service registering itself with the service registry, a third party called the registrar, which is typically part of the deployment platform, handles the registration.
Service instances are automatically registered with the service registry by a third party.
Find out more details here.
Advantages of platform-provided service discovery:
The key benefit of platform-provided service discovery is that all aspects of service discovery are entirely handled by the deployment platform. Neither the services nor the
clients contain any service discovery code. Consequently, the service discovery mechanism is readily available to all services and clients regardless of which language or framework they’re written in.
Disadvantages of platform-provided service discovery:
One drawback of platform-provided service discovery is that it only supports the discovery of services that have been deployed using the platform. For example, Kubernetes-based discovery only works for services running on Kubernetes.
Thank you for reading
Hope you find these resources useful. If you like what you read and want to see more about system design, microservices, and other technology-related stuff... You can follow me on
- Twitter - Follow @vishnuchi
- Subscribe to my weekly newsletter here.
Top comments (0)