Consul与其它软件(ZooKeeper、Eureka)的对比[译]

原文链接：https://www.consul.io/intro/vs/index.html

---

---

Consul vs. 其它软件

Consul能解决的问题是多种多样的，但是每个独立的特性都已经被很多不同的系统解决了。尽管没有一个单独的系统能够同时提供Consul的所有特性，但有其它可用的选项能够解决其中的一些问题。

在这部分中，我们把Consul与其它一些选项做对比。在大部分情况下，Consul不会与任何其它系统互斥。

Consul vs. ZooKeeper, doozerd, etcd

ZooKeeper、doozerd以及etcd的结构很相似。它们都有服务节点，需要有足够数目的节点才能运行(通常是简单多数)。它们是强一致性的，并且提供了丰富的原语，可以通过应用中的客户端库去构建复杂的分布式系统。

Consul同样使用拥有一个单独数据中心的服务器节点。在每个数据中心中，Consul服务器需要有足够数量的节点才能运行和提供强一致性。不过，Consul对多个数据中心以及能连接服务器节点和客户端的包含更多功能的Gossip系统，提供原生支持。

所有这些系统在提供键值存储时都有大致相同的语义：读是强一致性的，在面对网络分区时，可用性为一致性做出了牺牲。然而，当这些系统用于高级案例中，这些差异变得更加显著。

这些系统提供的语义对构建服务发现系统来说是有吸引力的，但是强调这些功能必须被构建是很重要的。ZooKeeper等提供的仅是一个原始的键值存储而且要求应用开发者们构建他们自己的系统以提供服务发现功能。相反的，Consul提供完整的服务发现框架，并且消除了歧义和开发成本。客户端仅仅需要注册服务，就能通过DNS或者HTTP接口使用服务发现功能。其它系统需要自己的解决方案。

一个吸引人的服务发现框架必须包含健康检查和故障可能性。知道节点A提供Foo服务在节点已经故障或者服务崩溃了的情况下是不管用的。简单的系统利用带周期性更新和TTL（存活时间）的心跳机制。这些体系要求节点数量与工作成线性关系，并且强烈要求设置固定数量的服务器。此外，故障探测窗口至少需要与TTL一样长。

ZooKeeper提供临时节点，即键值对，当客户端断开时，这些键值对会被删除。这比心跳系统更高级，但仍然存在固有的扩展性问题，而且增加了客户端的复杂性。所有的客户端必须维系与ZooKeeper服务器的活跃连接并保持存活(keep-alive)。另外，这通常需要胖客户端，胖客户端难以实现而且经常导致调试困难。

Consul用一种很不同的架构来完成健康检查。Consul客户端在集群的每个节点上运行，而不仅仅是有服务器节点。这些客户端是Gossip池的一部分，用来服务一些功能，包含分布式的健康检查。Gossip协议实现了有效的故障检测，它不需要将工作集中在任何选定的服务器组上，就能调整集群容量至任意大小。客户端同样可以本地运行更丰富的健康检查集合，然而ZooKeeper的临时节点是非常原始的存活检查。通过使用Consul，客户端能够检查web服务器是否返回200状态码、内存利用率是否过高、是否有充足的磁盘空间等。Consul客户端提供了简单的HTTP接口，避免了将系统的复杂性暴露给客户端，这类似于ZooKeeper。

Consul为服务发现、健康检查、键值存储和多数据中心，提供了一流的支持。为了支持除简单的键值存储外更多特性，其它的系统都要求在顶部搭建额外的工具和库。通过使用客户端节点，Consul提供了仅需要瘦客户端就能使用的简单的API。此外，可以通过使用配置文件和DNS接口，而不需要任何开发，就能完整地实现服务发现，从而能够完全避免API。

Consul vs. Eureka

Eureka是一个服务发现工具。它的结构主要是C/S架构，每个数据中心包含一组Eureka服务器，通常每个可用区域包含一个Eureka服务器。典型地，Eureka客户端使用嵌入式SDK来完成注册和发现其它服务。对于不是本地集成的那些客户端，会使用类似Ribbon的边车(sidecar)，通过Eureka显式地发现服务。

Eureka通过尽力复制，提供服务的弱一致性视图。当一个客户端注册到一个服务器上时，该服务器将尝试将信息复制到其它服务器上，但是不提供任何保障。服务注册的存活时间短，这要求客户端与服务器保持心跳。不健康的服务或者节点将停止心跳，导致它们超时从而从注册中心移除。发现请求可以被路由到任意服务上，由于尽力复制，这使得该服务可以提供脏的或丢失的数据。这个精简的模型使得集群管理简单，同时保证了高扩展性。

Consul提供了许多功能，包括更丰富的健康检查、键值存储和多数据中心感知。Consul要求在每个数据中心中有一组服务器，在每个客户端上包含一个代理，这类似于使用如Ribbon的边车。Consul代理允许大部分应用不感知Consul，它们通过配置文件完成服务注册，通过DNS或者负载均衡边车完成服务发现。

Consul保障强一致性，因为服务器使用Raft协议复制状态。Consul支持更丰富的健康检查，包括TCP、HTTP、兼容Nagios/Sensu脚本，或者像Euraka一样的TTL。客户端节点参与到基于Gossip的健康检查，该检查分散了健康检查的工作，不像集中式心跳机制，会带来扩展性的挑战。发现请求被路由到被选举为Consul领导的节点上，这允许它们在默认情况下保持高度一致。允许脏读的客户端允许任一服务器去处理它们的请求，这可以像Eureka一样实现线性扩展。

Consul强一致性的本质意味着它能够在选举领导和协调集群时锁住服务。Eureka不提供类似的保障，并且通常要求那些需要完成协调工作或者有强一致性需求的服务运行ZooKeeper。

Consul提供了一套工具去支持面向服务的体系结构所需要的特性，包括含丰富健康检查的服务发现、锁、键值存储、多数据中心联合、事件系统和访问控制列表(ACL)。Consul、类似consul-template工具的生态系统和envconsul都尝试在集成时将应用程序需要修改的部分最小化，避免需要通过SDK做本地集成。Eureka是Netflix开源软件大家族中的一部分，它希望应用能够相对同质并且紧密集成。因此，Eureka仅仅解决了部分问题，需要与类似ZooKeeper的其它工具同时使用。