Introduction
Microservices are rapidly getting adopted by organizations. Building smaller services instead of large monolithic applications/large services has a lot of advantages. The more minor fine-grained services look appealing for various reasons, including scalability, understandability, faster deployments, independent teams, etc. But smaller services do have their problems, and there is skepticism about the implementation and architecture of Microservices. Various challenges need to be addressed before implementing microservices. One of the key challenges that need to be addressed is how service clients discover the microservice. I will not cover all the microservice challenges, however, I will focus on the part of microservice and a solution to address the problem.
Need for Microservice Discovery
Typically, Microservices are exposed using HTTP endpoints and communicate with each other using API, usually using REST protocols. One of the basic requirements of any distributed environment is identifying the location of the calling service. Traditionally, in SOA architecture, the service is deployed on a server with a static IP address/Hostname and ports. One of the common approaches is that the IP address/Hostname is placed in properties files that the clients read to discover the service’s location. In the microservice world, the same is possible but not practical since microservices are usually deployed in containers. These containers are managed by container management tools like Kubernetes which are dynamically scaled up and scaled-down based on the load requirements. Services are deployed on cloud environments where URLs are assigned dynamically and even change dynamically over a period of time.
Since placing the IP address/Hostname and ports in a properties file does not work, there needs to be a way to dynamically discover the address of microservices. The solution is to have an additional layer of abstraction that lets you discover the hostname dynamically through the broker which is called a discovery server. This broker acts as a middle man between the service and service clients. The consumer does not need to know the hostname and port of the service before calling, but it only requires the service’s logical name configured to look up the hostname from the discovery server. All services which expose their APIs, need to register them with the discovery server with their location mapped to their logical name which must be unique. The discovery server holds the map of all the services along with their IP Address/Hostname and port. The service client will look up the required service from the discovery server with the logical name which returns the location of the service. This allows the service client to directly connect the required service with the discovered hostname and port.
Netflix Eureka
Eureka is one of the many open-source libraries from Netflix. Netflix is one of the pioneers in building microservices and creating libraries for them to use on internal projects. Since these libraries are useful and address the common problems in the microservices architecture, Netflix made these libraries open-source projects and available for others to use. The Spring community found the Eureka library useful and integrated into its Spring Cloud framework.
Netflix Eureka Architecture
Eureka Architecture consists of three components:
- Eureka Server
- Eureka Client
- Dashboard
The Eureka Server is a microservice that lets all other microservices register their service which is identified by a unique logical name. The Eureka Server maintains the mapping of logical names to hostnames and maintains the periodical heartbeats with registered clients to ensure the connected services are alive. It registers itself with the location information during the startup.
The Eureka Clients are microservices that look up the unique logical name to discover the address of the calling microservice. Using this returned URL, the Client service calls the required microservice directly.
Eureka also provides the optional dashboard UI which helps in health monitoring, troubleshooting and diagnosis registered services.
The following are the steps involved in service clients calling the actual services:
- Microservice register the location with the Eureka Server
- The service client looks up the Eureka server with calling service logical name
- The Eureka server returns the URL of required service
- The service client now directly calls the service
Advantages
The following are some of the advantages of the Netflix Eureka server:
- Simple to configure and setup
- Java-based implementation that nicely integrates with Spring Cloud framework
- Provides support to built-in client-side load balancing
- Open source
- Provides web UI for monitoring the health of services
- Embedded client to discover the service instead of relying on external tools
Disadvantages
However, the Eureka server comes with some disadvantages:
- The additional layer for abstraction can be a single point of failure
- There is an additional round trip with the Eureka server before making the call to a service
- There needs to be client-side logic to discover the service
Conclusion
There is another approach for addressing the problem of discovery of service, which was not discussed here. The approach is to have the server discover and call the service instead of returning the location of a service. This approach is called server side discovery, even though it is not really discovering the service, rather, it delegates to the appropriate service. Our future blog will address the server side discovery issues, advantages, and disadvantages.