Introduction
What is it?
Service Registration: Process of registering a service location in a central registry
Service Discovery: Process of client applications to query the central registry to find a service
What is it used for?
Locating services in:
- Distributed environments
- Service oriented architectures
Different Aspects of Services Discovery
Monitoring: Checking if a registered service is alive and kicking (heartbeat)
Load Balancing: Distribute load to different instances of the service
Versioning: Allow registration of the same service with different versions
Migration: Services will coexist with different versions to ease migration efforts
Availability: Resilient services to compensate lost nodes
Intershop Cloud & Service Discovery
We do not need Service Discovery!
- Application Servers know each other via multicast
- Web Adapter knows about Application Servers via ConfigurationServlet
- Application Server knows about Solr via Managed Service configuration
- Services plugged-in into Managed Service Framework and configured via same
So why do we implement a Service Discovery then?
- Services in the cloud have dynamic IP’s, are spread over different regions
- Configuration on the fly is a problem as of now in Intershop
- Real Time Monitoring needs to know about all running services
- Strategic importance for discovering Microservices
- Version Management
- Load Balancing
- Security
- Clustering
Which tools did we consider?
- Open Source
- Java project from Netflix
- REST based service primarily for AWS
- Point-to-Point Client/Server communication
- Key/Value Store for Metadata
- Health check included
- Netflix is using Eureka
- Eureka is integrated into Spring
- Newest version Eureka 1.4.7
- Open Source
- Go project by HashiCorp
- Based on Gossip protocol Serf
- Communication relies on TCP and UDP unicast
- Key/Value Store for Metadata
- Health check included
- BOL.com is using Consul
- Newest version Consul 0.6.4
- Open Source
- Java project maintained by Apache
- Subproject of Apache Hadoop, now it’s own top-level project
- Data is stored in a hierarchical name space
- Atomic messaging system between server to keep them in sync
- Quorum is used to distribute and retrieve information
- Apache Solr, Apache HBase, Apache Hadoop are using ZooKeeper
- Netflix was using ZooKeeper up until they decided to write their own tool
- Newest version ZooKeeper 3.4.8
And now a short detour into theoretical computer science – the CAP theorem:
Eric Brewer, University of California, Berkley:
- Consistency: All nodes see the same data any time
- Availability: All requests receiving a response
- Partition Tolerance: System is continuing to operate despite arbitrary partitioning due to network failures
A distributed system can satisfy any two for instance Availability and Partition Tolerance (AP) or Consistency and Partition Tolerance (CP) of these guarantees at the same time but not all three!
Decision Matrix
| Eureka | Consul | ZooKeeper | |
| Classification CAP | AP | CP | CP |
| Java Client Lib exists? | Yes | Yes | Yes |
| OS Support | Windows, Linux | Windows, Linux | Windows, Linux |
| Cloud Support |    |
|
|
| Maturity | ++ | + | +++ |
| Community | +++ | + | +++ |
| Discovery | Client-side | Client-side | Client-side |
| Deployment Tool | Netflix Asgard | Atlas | – |
| Dynamic Routing/Load Balancing | Netflix Ribbon | – | – |
| Circuit Breaker | Netflix Hystrix | – | – |
| Monitoring | Netflix Hystrix, Netflix Turbine | – | – |
| Edge Server | Netflix Zuul | – | – |
| Client Development Tool | Netflix Feign | – | – |
And the Winner is … Eureka
Why did we choose Eureka?
- Uses AP over CP
- Strong Tooling around Service Discovery
Why did we rule out Consul?
- Not mature enough
- Uses CP over AP
Why did we rule out ZooKeeper?
- Uses CP over AP
Cool thing you might say.
But when is it available?
Our Service Registration & Service Discovery (SRD) will be available with Intershop Commerce Management 7.7.0.0. For those who don’t wanna use Eureka it is possible of course to do their own implementation with any other SRD out there which works similar to the one we investigated.
For instance in a Hackathon, which takes place every 6 months, we demonstrated within 3 days of work a prototype which used Consul instead of Eureka.