原文
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. 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, 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.
译文
Eureka是一种服务发现工具。该体系结构主要是客户端/服务器,每个数据中心有一组Eureka服务器,通常每个可用区域一个。通常,Eureka的客户使用嵌入式SDK来注册和发现服务。对于非本地集成的客户端,使用Ribbon等边车通过Eureka透明地发现服务。
Eureka使用尽力而为的复制提供弱一致的服务视图。当客户端向服务器注册时,该服务器将尝试复制到其他服务器但不提供保证。服务注册的生存时间很短(TTL),要求客户端对服务器进行心跳检测。不健康的服务或节点将停止心跳,导致它们超时并从注册表中删除。发现请求可以路由到任何服务,由于尽力复制,这些服务可以提供过时或丢失的数据。这种简化的模型可以实现轻松的集群管理和高可扩展性。
Consul提供了一系列超级功能,包括更丰富的健康检查,键/值存储和多数据中心感知。Consul需要每个数据中心中的一组服务器,以及每个客户端上的代理,类似于使用像Ribbon这样的边车。Consul代理允许大多数应用程序不知道Consul,通过配置文件执行服务注册以及通过DNS或负载平衡器sidecars进行发现。
Consul提供强大的一致性保证,因为服务器使用Raft协议复制状态 。Consul支持丰富的运行状况检查,包括TCP,HTTP,Nagios / Sensu兼容脚本或基于Ture的Eureka。客户端节点参与基于八卦的健康检查,该检查分发健康检查的工作,而不像集中式心跳,这成为可扩展性挑战。发现请求被路由到当选的领事领导者,这使他们默认情况下非常一致。允许过时读取的客户端允许任何服务器处理其请求,从而允许像Eureka一样的线性可伸缩性。
Consul的强烈一致性意味着它可以用作领导者选举和集群协调的锁定服务。Eureka不提供类似的保证,并且通常需要为需要执行协调或具有更强一致性需求的服务运行ZooKeeper。
Consul提供了支持面向服务的体系结构所需的功能工具包。这包括服务发现,还包括丰富的运行状况检查,锁定,键/值,多数据中心联合,事件系统和ACL。Consul和consul-template和envconsul等工具生态系统都试图最大限度地减少集成所需的应用程序更改,以避免需要通过SDK进行本机集成。Eureka是更大的Netflix OSS套件的一部分,该套件期望应用程序相对同质且紧密集成。因此,Eureka只解决了有限的一部分问题,期望其他工具如ZooKeeper可以同时使用。
网友评论