Due to the dynamic nature of microservice applications, it is difficult to call services with fixed IP addresses. This is the context in which the concept of service discovery emerged. Service discovery helps clients understand the location of service instances. In this case, the service discovery component acts as a service registry.
The service registry is a centralized server/database that contains the locations of service instances. In a microservices setup, services periodically update their location in the service registry. The service consumer can then connect to the service registry and obtain the location of these services. Netflix Eureka [1] is a popular “application-level” open source service registry.
In service discovery, there are two modes.
1. Client-side service discovery 2. Server-side service discovery
Client service discovery
This involves multiple steps.
Figure 01 - Client Service Discovery
1. Add the location of the service provider instance to the service registry (self-registration mode). 2. When a service consumer wants to request a specific service, the service discovery mechanism queries the service registry to obtain a list of available service provider instance locations. 3. After getting the location list from the service registry, send it back to the service consumer. 4. Finally, the service consumer will route the service request to one of the service provider instances.
Self-registration mode
In self-registration mode, the service instance registers itself with the service registry when it starts (see Figure 01 - Step 01). This happens on the service registry and is unregistered on shutdown.
A service instance may call the service registry's registration API to register its network location. In addition, the service registry also calls the health check API of the service provider instance.
Mode 2: Server-side service discovery mode
Unlike client-side service discovery mode, in server-side service discovery mode, the service client makes a request for a DNS name, which resolves to a platform request router that queries the service registry and load-balances the request.
The main advantage of this model is that, unlike the client-side discovery model, all aspects of service discovery are completely handled by the deployment platform. This is a major advantage and a hassle-free approach for any developer. Deployment platforms such as Kubernetes have built-in service registries and service discovery mechanisms to override the server-side discovery model.
The only limitation of this approach is that you are slightly coupled to the deployment platform used for the service registry. For example, if you use Kubernetes as your deployment platform, you are essentially coupling to Kubernetes for service discovery. This won't be a problem if your other service components are also running on Kubernetes. However, with most deployments today taking place in cloud-native Kubernetes containerized environments, this is not a major limitation.
Figure 02 - Server-side service discovery pattern
This involves multiple steps.
1. The service instance is registered with the service registry through registrar (third-party registration mode). 2. The service client obtains the service network location from the Router, and makes the Router query request from the service registry. 3.The Router then load balances requests from available service provider instances.
Third-party registration model
In the third-party registration mode (see Figure 02 - Step 02), unlike the self-registration of the service registry, a third party called the registrar is responsible for the registration.
Reference link
[1] Netflix Eureka: https://github.com/spring-cloud/spring-cloud-netflix