A Guide to Service Discovery in a Microservices Architecture

Quick Summary (TL;DR)

In a microservices architecture, service instances are ephemeral… Service discovery is the mechanism that enables a service to find the current location of another service without hardcoding its address. This is achieved using a central service registry. When a service instance starts up, it registers its location with the registry. When another service wants to communicate with it, it queries the registry to get the up-to-date location.

Key Takeaways

• Services are Ephemeral: In a modern, containerized environment, service instances are constantly being created, destroyed, and moved. Hardcoding IP addresses is not a viable option.
• The Service Registry is the Source of Truth: The service registry is a highly available database that contains the real-time network locations of all running service instances. It is the central source of truth for service addresses.
• Client-Side vs. Server-Side Discovery: In client-side discovery, the client service is responsible for querying the service registry to get the address of a downstream service and then making the request. In server-side discovery, the client makes a request to a router or load balancer, which then queries the registry and forwards the request to an available service instance.

The Solution

How does Service A find Service B in a dynamic, distributed environment? The answer is a service registry. This pattern completely decouples services from their physical locations. Instead of knowing where a service is, a client only needs to know the service’s logical name and where the service registry is. This allows for a much more resilient and scalable system. As you add more instances of a service to handle increased load, they simply register themselves, …and the load balancer automatically starts routing traffic to them. If an instance dies, it is automatically removed from the registry.

Discovery Patterns

1. Client-Side Discovery

• How it Works:
  1. Service B starts up and registers itself with the service registry.
  2. Service A needs to call Service B, so it queries the service registry for all available instances of “Service B.”
  3. The registry returns a list of IP addresses and ports.
  4. Service A then uses a client-side load balancing algorithm (e.g., round-robin) to choose one of the instances and makes a direct request to it.
• Pros: Simple, with fewer moving parts.
• Cons: The logic for querying the registry and load balancing must be implemented in a library within every client service.

2. Server-Side Discovery

• How it Works:
  1. Service B starts up and registers itself with the service registry.
  2. Service A makes a request to a central router or load balancer, using a logical name for Service B (e.g., http://service-b/).
  3. The router queries the service registry to get the actual address of a healthy instance of Service B.
  4. The router then forwards the request to that instance.
• Pros: Abstracts the discovery logic away from the clients. The clients are simpler as they don’t need to know about the service registry.
• Cons: The router becomes a highly critical piece of infrastructure that must be managed and scaled.

Service Discovery in Kubernetes

Kubernetes has a powerful, built-in implementation of server-side service discovery. When you create a Kubernetes Service object, it automatically gets a stable, internal DNS name. Kubernetes keeps track of the Pods associated with that service and will automatically load balance requests sent to the service’s DNS name to one of the healthy Pods. This means that within a Kubernetes cluster, a service can simply make a request to http://order-service/ without needing to know anything about where the order service is running.

Common Questions

Q: What is a health check? For service discovery to work, the registry must know if a service instance is healthy enough to receive traffic. Service instances are typically configured to periodically send a “heartbeat” to the registry. If the registry doesn’t receive a heartbeat for a certain period, it assumes the instance is unhealthy and removes it from the pool of available services.

Q: What tools are used for service discovery? Outside of Kubernetes, popular tools include HashiCorp Consul and Apache Zookeeper. These are dedicated, highly-available systems that provide both a service registry and health checking capabilities. Most cloud providers also offer their own service discovery solutions.

Tools & Resources

• Kubernetes Services Documentation: The official documentation explaining how the built-in service discovery works in Kubernetes.
• HashiCorp Consul: A popular, open-source tool for service discovery, configuration, and segmentation in distributed systems.
• NGINX as a Service Discovery Router: An article explaining how a reverse proxy like NGINX can be used to implement server-side discovery.

Related Topics

Microservices Architecture & Communication

• An Introduction to Microservices Architecture
• Microservices Communication Patterns

Infrastructure & Containerization

• Kubernetes Cluster Management and Deployment
• Docker and Containerization Fundamentals
• Cloud Native Development Patterns

Service Discovery & Load Balancing

• Choosing the Right Load Balancer: A Practical Guide
• Consul Service Discovery and Configuration
• NGINX Reverse Proxy and Load Balancing
• DNS and Service Discovery Patterns

API Gateway & Routing

• API Gateway Patterns and Implementation

Need Help With Implementation?

Implementing a robust service discovery mechanism is essential for any non-trivial microservices architecture. Built By Dakic provides expert consulting on cloud-native and microservices architectures, helping you design and build resilient, scalable, and observable systems using tools like Kubernetes and Consul. Get in touch for a free consultation.