Service Discovery in a Microservices Environment: 5 Key Strategies
Soon, all complex applications will be architected as a group of independent microservices, not as a great monolith of code. A central challenge in microservices architectures is service discovery: how to ensure services can find and communicate with each other in a seamless manner, allowing for easy maintenance and further expansion of the application.
In this page you will learn about 5 key strategies for implementing service delivery:
- Service Discovery with Registry-Aware Clients
- Client Side Service Discovery via Configuration Management
- Server-Based Service Discovery via Load Balancing
- Service-Based Service Discovery via DNS-SD
- Service-Based Service Discovery via NS1’s Next-Gen DNS Platform
The Challenge of Service Discovery in a Microservices Architecture
In a microservices architecture, applications are built up of self-sufficient units, which can be deployed and updated independently, and communicate with each other via REST APIs.
One of the challenges in a microservices application is how services discover and connect to each other. With services scaling up and down their location is dynamic. Fixed IP addresses don't work so a more dynamic approach, usually involving a service registry is needed.
Microservices vs. Monolithic Applications
A monolithic application is a traditional software architecture, in which the application is a single unit, with interfaces to external systems like databases and web services. Service discovery is less complex because fewer components need to talk to each other - the application components are self contained.
However, monolithic applications are more difficult to maintain and add features and functions. A change in one component requires the entire application to be recompiled and tested. There are also scalability issues. An increase in demand for one function of the application (e.g. the user interface) means the entire application needs to be replicated and run on additional servers. A modular approach, in which each function is a separate microservice, is more flexible, maintainable and scalable.
How Service Discovery Works
Service discovery is a method for application components to locate each other. Service discovery in a microservices environment is a challenge because service instances are constantly being created and destroyed. The location and availability of those services needs constant updating.
Service Registry
A key component of service discovery in a microservices architecture is a service registry. The service registry is a database of available service instances. It contains the currently-available instances of each service and their connection details. Services query the service registry to retrieve the details for the required microservice, and then connect to it. The registry maintains a heartbeat mechanism to see if services are still up and if not, removes them from the registry.
Microservice Registration Patterns
There are two primary microservice registration patterns:
Self-registration: A service instance registers itself with the service registry and makes itself available for discovery. On shutdown it unregisters itself.
Third-party registration: A 3rd party is responsible for identifying that a service has started, registering the service, and unregistering the service when it shuts down or crashes.
Client Side vs. Server Side Service Discovery
There are two primary strategies for discovery of services via a service registry:
Client side discovery: The client contacts a service registry, receives details for available services, and contacts one of them using a load balancing algorithm.
Server side discovery: The client contacts a load balancer, making a request that indicates which type of service it needs. The load balancer consults the service registry, selects the optimal service (for example, the least loaded one) and routes the request to it. An example of a server-side discovery mechanism is AWS Elastic Load Balancing (ELB).
Four Strategies for Service Discovery in a Microservices Environment
Strategy #1
Service Discovery with Registry-Aware Client
In this strategy the client is pre-built with the capability to contact the service registry and retrieve information about service instances. When the client requires a microservice, it finds a suitable service in the registry and connects to it directly. The assumption is that the registry tracks availability of services using a heartbeat mechanism.
Strategy #2
Client Side Service Discovery via Configuration Management
A most sophisticated form of client side service discovery is via configuration management tools, like Puppet or Chef. A configuration management tool can act as a service registry—services can use it to update their configuration when they start. However to make this strategy effective, services need to be registered in the configuration management tool very quickly and changes must be propagated immediately to prevent stale configuration.
Pros/cons: This removes the drawbacks of client side service discovery because there is central control over the load balancing. However still tightly coupled with client and requires full control over client environment.
Strategy #3
Server-Based Service Discovery via Load Balancing
Load balancing is commonly used as a service discovery mechanism; it provides health checks and can automatically register/unregister services when they fail. The load balancer works in tandem with the service registry.
DNS provides an easy way to connect microservices to the load balancer. You can configure a hostname for each microservice, register it on a DNS server and associate the hostname with the load balancer’s DNS name using a CNAME entry.
Pros | Cons |
|
|
Strategy #4
Server Side Service Discovery with DNS-SD
Service discovery can be achieved end-to-end using DNS infrastructure, removing the need to set up a load balancer or dedicated service registry.
The DNS Service Discovery (DNS-SD, RFC 6763) specification uses three DNS record types to define the location, status, type and capabilities for services:
PTR maps service types to named service instances
SRV provides location and port for service instances
TXT provides additional metadata about service instances
Here is a code example provided by Jan Algermissen, illustrating the process for basic usage of DNS-SD:
A service needs to access a service running the Atom Publishing Protocol. The domain setup for the microservices app is example.org. The service performs a DNS record lookup for Atom services at example.org, using PTR records, as follows:
DNS-based load balancing is highly useful because it leverages existing DNS infrastructure, without having to set up new service discovery mechanisms, ensure they are reliable, and so on.
Pros | Cons |
|
|
Strategy #5
Service Discovery with NS1’s Next-Gen DNS Platform
NS1 is a DNS platform that meets the needs of modern service discovery. It guarantees fast DNS response and is able to propagate DNS SD changes in seconds across the enterprise, or around the globe.
NS1 solves the challenges of other service discovery approaches:
Does not require tight coupling with clients
Relies on existing DNS infrastructure, does not require load balancers
Highly available and fault tolerant
Fast and able to deal with rapid changes to services and serve them globally
NS1 Next-Gen DNS Features
In addition to seamlessly supporting service discovery, NS1 provides the world’s most advanced DNS traffic management system.
Start Now
Get a free trial of NS1 to see how to setup a fast, failsafe service discovery system using existing DNS infrastructure.
Sign Up
Magnetic’s performance is now beating even the largest Internet advertising giants. We’ve decreased latency by 70 percent – and have the same number of servers. They’re just now deployed in a far more cost-effective, flexible and resilient infrastructure that isn’t locked into a single cloud provider.
James Marcus, Vice President of Technical Operations Magnetic
NS1’s customer support is excellent. When we had questions, we fired off an email to the support team and they were right back with the answers we needed. It helped us complete the migration quite quickly.
Simon Hildrew, Lead Software Developer Guardian News & Media
