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