Service Discovery Patterns in Microservice Architecture
This group of templates describes methods that client applications can use to locate the services they need. This is especially important in microservices applications, as they run in virtualized and containerized environments where the number of service instances and their location change dynamically.
The critical component of microservice discovery is the Service Registry, a database containing information about the location of service instances. When instances start and stop, the information in the registry is updated. But you can interact with the service registry in two ways, which formed the basis of the templates described below.
Client-Side Service Discovery Pattern
The first way to discover services is on the client-side. In this case, the services and their clients interact directly with the registry. The sequence of steps is as follows:
- The service instance calls the registry API to register its network location. It can also provide a Health Check URL that will be used to renew its registration in the registry.
- The client independently consults the service registry to get a list of service instances. The client can cache service instances to improve performance.
- The client uses a load balancing algorithm, round-robin or random, to select a specific service instance and request it.
A key advantage of client-side service discovery is its independence from the deployment platform being used. For example, if some of your services are deployed on K8s, the rest are running in a legacy environment. Application-level discovery will be the best option since a Kubernetes-based server solution will not be compatible with all services.
The disadvantages of this approach include the need to use different client libraries for each programming language and sometimes the framework. In addition, your team bears the additional burden of setting up and maintaining the service registry.
Server-Side Service Discovery Pattern
The second way to discover services is on the server-side. In this case, the deployment infrastructure is responsible for registration, service discovery, and request routing. The sequence of steps is as follows:
The registrar, which is usually part of the deployment platform, registers all service instances in the service registry. A DNS name and virtual IP address (VIP) are stored for each instance.
Instead of accessing the registry directly, the client queries the service’s DNS name. The request goes to a router that is part of the deployment platform.
The router consults the service registry to obtain the network location of instances of the desired service. The router uses load balancing to select a specific service instance and send a request to it.
All modern deployment platforms, including Docker, Kubernetes, and others, tend to have built-in registry and service discovery mechanisms.
The main advantage of the pattern is that the platform itself deals with all aspects of service discovery. No additional client-side or service-side code is required. This ensures independence from the programming languages and frameworks used in the application.
The disadvantage of the pattern is that it cannot be applied to services deployed outside the leading platform that implements the discovery mechanisms. Despite this limitation, it is recommended that you use server-side service discovery wherever practicable.
Also Read: Data Management Patterns In Microservice Architecture
