Service Discovery Pattern Architecture
In this tutorial, we are going to discuss about the Service Discovery Pattern Architecture. The Service Discovery pattern is an essential design pattern in microservices and distributed systems. It allows services to discover each other dynamically, facilitating communication and ensuring that services can scale, be moved, and remain available without manual intervention.
Service Discovery Pattern Architecture Components
- Service Registry: A central directory where all services register their network locations and other metadata.
- Service Providers: The services that register themselves with the service registry and advertise their availability.
- These services periodically send heartbeats to the registry to maintain their active status.
- Service Consumers: The clients or other services that need to discover and communicate with the service providers.
- They query the service registry to get the location of the service providers.
- Health Checks: Mechanisms to ensure that registered services are healthy and available. Unhealthy services are removed from the registry.
A High-Level Overview
At a high level, the Service Discovery pattern architecture comprises three major components: the Service Registry, the Client Service, and the Server Service.
The Service Registry is a key-value store that maintains a record of all active services and their locations. The Client Service is the service that needs to find and interact with other services. The Server Service is the service that the client needs to discover and interact with.
The Client Service
The Client Service is the consumer in this system. Its role is to find and communicate with other services to fulfill its operations. When the client service needs to make a request to another service, it follows these steps:
- Service Query: The client queries the Service Registry to find the location of the Server Service it wants to interact with. This query is typically based on the service name.
- Service Selection: If multiple instances of the Server Service are available, the client selects one. The selection strategy can vary based on the use case – it could be random selection, round-robin, or based on the server load, among others. This step is specific to the client-side discovery model.
- Request: The client then sends a request to the Server Service using the location details it obtained.
The Server Service
The Server Service, on the other hand, is the provider. Its role is to register itself with the Service Registry so other services can find it. Here’s what the Server Service typically does:
- Service Registration: When the server starts up, it registers itself with the Service Registry. It provides its name and location details.
- Heartbeat: To ensure the Service Registry has the current status of the service, the server periodically sends a heartbeat signal to the registry. If the Service Registry doesn’t receive this signal within a certain time frame, it assumes that the service has failed and removes it from the registry.
The Service Registry
The Service Registry, as we’ve discussed, plays a pivotal role in this system. It is responsible for keeping a track of all active services. The Service Registry:
- Registers and Deregisters Services: As we’ve discussed, it adds services to its store when they come online and removes them when they go offline.
- Handles Service Queries: When a client service sends a service query, the Service Registry looks up its store and returns the location details of the requested service.
- Monitors Services: In some implementations, the Service Registry also monitors the services to ensure their availability. It does this by pinging the services periodically or listening to their heartbeat signals.
Client-side vs. Server-side Discovery in Architecture
As we mentioned before, there are two main flavors of the Service Discovery pattern, which slightly alters this architecture: client-side discovery and server-side discovery.
In the Client-side Discovery, the Client Service directly queries the Service Registry and then communicates with the Server Service. In this approach, the Client Service needs to implement the logic for querying the Service Registry and selecting a suitable service from the returned list.
On the other hand, in the Server-side Discovery, there’s an intermediary, often a load balancer or a router, between the Client Service and the Server Service. The Client Service sends its requests to this intermediary, which queries the Service Registry, selects a suitable Server Service, and forwards the client’s request to it. This abstracts away the service discovery details from the Client Service but adds an extra hop in the request path.
The Inner Workings of the Service Discovery Pattern
Understanding the basic architecture of the Service Discovery pattern is the first step. However, a deeper look into its inner mechanics is needed to grasp the actual implementation and nuances of this pattern. The following sections will delve into these details and provide a more refined picture of the Service Discovery pattern.
Self-Registration vs Third-Party Registration
In terms of registration, there are two primary methodologies to consider: self-registration and third-party registration.
In the Self-Registration approach, services are responsible for registering and deregistering themselves with the Service Registry when they come online or go offline. The upside to this approach is the simplicity and the control it gives to the service. However, the downside is the added responsibility on the service to keep its status up-to-date.
On the other hand, Third-Party Registration leverages a service manager that handles the registration process. The service manager monitors the services and updates their status in the Service Registry accordingly. This approach takes the burden off the services but introduces another component in the system that needs to be managed.
The Role of Health Checks
Once a service is registered, how does the Service Registry know it’s still available? This is where health checks come in. Health checks are a way of monitoring the status of services. They can take two primary forms:
- Self-Reporting: In this approach, also known as the heartbeat model, services send a periodic signal to the Service Registry indicating they are still active. If the Service Registry doesn’t receive a signal from a service within a given timeframe, it assumes the service is offline and removes it from its records.
- Active Monitoring: Here, the Service Registry proactively checks the status of services by sending a ping or a similar request. If it doesn’t receive a response, it marks the service as offline.
That’s all about the Service Discovery Pattern Architecture. If you have any queries or feedback, please write us email at contact@waytoeasylearn.com. Enjoy learning, Enjoy Microservices..!!