d81889bb41
Avoid HTTP redirects for internal site links by updating old URLs to point to the new location for the target content.
55 lines
3.4 KiB
Plaintext
55 lines
3.4 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: Consul vs. Eureka
|
|
description: >-
|
|
Eureka is a service discovery tool that provides a best effort registry and
|
|
discovery service. It uses central servers and clients which are typically
|
|
natively integrated with SDKs. Consul provides a super set of features, such
|
|
as health checking, key/value storage, ACLs, and multi-datacenter awareness.
|
|
---
|
|
|
|
# Consul vs. Eureka
|
|
|
|
Eureka is a service discovery tool. The architecture is primarily client/server,
|
|
with a set of Eureka servers per datacenter, usually one per availability zone.
|
|
Typically clients of Eureka use an embedded SDK to register and discover services.
|
|
For clients that are not natively integrated, a sidecar such as Ribbon is used
|
|
to transparently discover services via Eureka.
|
|
|
|
Eureka provides a weakly consistent view of services, using best effort replication.
|
|
When a client registers with a server, that server will make an attempt to replicate
|
|
to the other servers but provides no guarantee. Service registrations have a short
|
|
Time-To-Live (TTL), requiring clients to heartbeat with the servers. Unhealthy services
|
|
or nodes will stop heartbeating, causing them to timeout and be removed from the registry.
|
|
Discovery requests can route to any service, which can serve stale or missing data due to
|
|
the best effort replication. This simplified model allows for easy cluster administration
|
|
and high scalability.
|
|
|
|
Consul provides a super set of features, including richer health checking, key/value store,
|
|
and multi-datacenter awareness. Consul requires a set of servers in each datacenter, along
|
|
with an agent on each client, similar to using a sidecar like Ribbon. The Consul agent allows
|
|
most applications to be Consul unaware, performing the service registration via configuration
|
|
files and discovery via DNS or load balancer sidecars.
|
|
|
|
Consul provides a strong consistency guarantee, since servers replicate state using the
|
|
[Raft protocol](/docs/architecture/consensus). Consul supports a rich set of health checks
|
|
including TCP, HTTP, Nagios/Sensu compatible scripts, or TTL based like Eureka. Client nodes
|
|
participate in a [gossip based health check](/docs/architecture/gossip), which distributes
|
|
the work of health checking, unlike centralized heartbeating which becomes a scalability challenge.
|
|
Discovery requests are routed to the elected Consul leader which allows them to be strongly consistent
|
|
by default. Clients that allow for stale reads enable any server to process their request allowing
|
|
for linear scalability like Eureka.
|
|
|
|
The strongly consistent nature of Consul means it can be used as a locking service for leader
|
|
elections and cluster coordination. Eureka does not provide similar guarantees, and typically
|
|
requires running ZooKeeper for services that need to perform coordination or have stronger
|
|
consistency needs.
|
|
|
|
Consul provides a toolkit of features needed to support a service oriented architecture.
|
|
This includes service discovery, but also rich health checking, locking, Key/Value, multi-datacenter
|
|
federation, an event system, and ACLs. Both Consul and the ecosystem of tools like consul-template
|
|
and envconsul try to minimize application changes required to integration, to avoid needing
|
|
native integration via SDKs. Eureka is part of a larger Netflix OSS suite, which expects applications
|
|
to be relatively homogeneous and tightly integrated. As a result, Eureka only solves a limited
|
|
subset of problems, expecting other tools such as ZooKeeper to be used alongside.
|