Background:
Microservices is a newer architectural pattern for Enterprise Web Service development. One of the biggest challenges with this type of architecture is how to manage the discovery of the web services. Based on this challenge, there are several different open source options. In this article, I will share my experiences gained with two different solutions. Each of these solutions has been rolled into the Spring Cloud project making them potential candidates for the application space being targeted.
Assumptions:
These were evaluated based on a set of assumptions that may or may not be typical.
- Spring Boot with Spring Cloud.
- Application connects through ZUUL Proxy to service endpoints.
- ZUUL used for both Server and Client load balancing
- Ribbon used for Client load balancing and retry
Eureka
- Eureka Server can be deployed or self launched as a Runnable JAR. Eureka Client is connected through Spring Boot and is part of the application.
- Use Zuul for edge connections such as external devices or JavaScript clients.
Consul.io
- The Consul application is an application that is launched from the command line.
- Control-C is used to terminate the Server instance gracefully.
- Consul expects 3-5 instances of the Server to be run per Datacenter.
- A Datacenter is connected internally with a join command specifying the Consul Server nodes.
- To connect the Datacenters, one of the Consul Server instance need to join -wan with the other WAN servers.
- The Datacenter to Datacenter communication is limited to Consul Server communication between Centers.
- The Consul.io documentation doesn’t always use an industry consistent terminology. However, careful reading resolves these issues.
- The Spring Cloud project first created different release pipelines for Eureka and Consul.io on June 26th, 2015. Prior to that, the Netflix OSS additions appeared to be the primary service discovery approach.
- In general, using Ribbon within Spring Cloud provides server side load balancing via a round-robin mechanism. Ribbon is supported with or without either Eureka or Consul.io.
- A simple Netflix Eureka environment was easier to set up in a local environment. However, I’ve not set either up in a Docker container deployed to AWS. It is difficult to compare this aspect without actually setting up a Docker container in AWS with multiple Data Centers and Data Zone.
General
Figure 1 - Sample Consul.io configuration
Figure 2 - Sample Eureka Configuration
Capabilities
|
Measure |
Eureka |
Consul.io |
|
Spring Cloud integration |
Yes - Angel SR3 |
Yes – Brixton |
|
Management in Container |
I believe so. There are Docker targets. However, based on documentation, I’m not clear on configuration of peers. |
Yes. The API implies Docker support. |
|
Health monitoring of Endpoints |
Yes. Removal of failed after 90 minutes (configurable) |
Yes. Removal after 72 hours. (Fixed) |
|
Multiple Datacenter |
Possible |
Yes per application documentation. |
|
DNS support |
No. Would require another package. |
Yes. Built in. |
|
HTTPS |
Possible but not used in Netflix |
Yes. Keygen and other configuration done via Consul CLI |
|
Endpoint Update method |
Delta content with occasional full content |
Always full content |
|
Recommended Number per datacenter |
2 or more instances of Server connected as Peers |
3-5 instances per Datacenter with ability to connect Datacenters. |
|
Circuit Breaker |
Supported with Hystrix and code modification |
Not available |
|
Health Check data collection |
Hystrix with HystrixDashboard. Aggregation via Turbine. |
Built in to the Consul.io web access page. |
|
Polyglot support |
Requires addition of Sidecar. |
Built in support. |
Results
In looking at Micro-service architectures, one of the biggest challenges is managing Service Discovery and providing a reliable architecture. Along those lines, two different Service Discovery options are easily integrated into an application using Spring Cloud: Eureka and Consul.io.
Eureka comes from the Netflix OSS and was added to one of the Spring Cloud release pipelines.
Consul.io comes from HashiCorp and is maintained by both HashiCorp and the open source community. Consul.io was also added to a Spring Cloud release pipeline.
There are other Service Discovery utilities. However, these are the only ones evaluated for this purpose.
Recommendation
When comparing Eureka and Consul.io, they have a slightly different focus. For example, the Eureka is presented as a service discovery for backend services. This is slightly different from Consul.io that can act as service discovery and also as DNS for end points.
Both are capable as a service discovery tool and both integrate with Spring Cloud and the RestTemplate injection.
Based on the research done and my past usage of Eureka, I feel Consul.io is a more capable library for use within a Docker Container in an AWS environment. The Eureka system is also very capable and would be a viable production alternative.
I feel Consul.io does better in the following area:
- The focus on scriptable configuration allows for better container management.
Eureka requires either external Configuration Server or multiple configuration files. - The options for securing communications is more advanced.
Eureka requires creating application with security settings desired. Default will allow HTTP only. Registration of end points assumes http but can be forced to https with code. - Support for non-REST endpoints via DNS. This would allow database and other resource connections.
Eureka presumably would do this through ZUUL and/or Sidecar.