CONSUL VS. ZOOKEEPER, DOOZERD, ETCD


ZooKeeper、doozerd和etcd有着相似的架构,这三个都有Server节点,并且需要一个法定的多数(通常是简单多数)节点才能进行运转。他们是强一致性的,并且开放多种基本操作,使用这些操作编写成Client库,集成到应用中来构建复杂的分布式系统。

Consul也需要Server节点。在每个数据中心,Consul都需要一个法定的数目的Server节点来控制和提供强一致性。然而,Consul原生支持多数据中心,并且有一个用于连接Server和Client节点的功能丰富的流言系统。

这些系统在提供键值存储方面都有大致相同的语义:读是强一致的,并且在面对网络分区时可用性要为保证一致性做出牺牲。然而当这些系统被应用于一些高级场景时,其和Consul的差异将变的更为明显。

这些系统提供的语义对于服务发现是很有吸引力的,但是很重要的需要强调的是这些功能必须自己构建。ZooKeeper以及其它的软件仅仅提供了一个原始的键值存储功能,需要应用开发者构建他们自己的系统来提供服务发现。和它们比起来,Consul专门提供了一个框架用于服务发现,消除了空头支票和开发计划。Client简单地注册服务,然后使用DNS或者HTTP接口进行服务发现。其它的系统则需要一个自己定制的解决方案。

一个值得信赖的服务发现框架必须包含健康检查,以及可能的故障检测。对于节点A上的Foo Service,如果节点已经挂了或者服务已经崩溃了,那么知道这个服务的存在没有什么用处。朴素的(简单的)系统一般可以使用心跳、周期性的更新和TTLs等方案来实现此功能。这些方案需要工作在线性增长的节点,并要求一组固定数量的Server。另外,故障检测窗口至少要像TTL一样长。

ZooKeeper的临时节点,作为键值条目存在,当客户端连接断开时条目被删除。这比一个心跳系统更为精密,但是也会带来扩展性问题,并增加客户端的复杂性。所有的客户端必须保持到ZooKeeper Server的活动连接,并进行keep-alives。另外,这将导致“胖客户端”,程序难以编写并经常导致调试风险。

Consul使用一个非常不同的架构来进行健康检查。除了Server节点,Consul Client运行在集群的每一个节点。这些Client是流言池的一部分,流言池提供一些功能,包括分布式的健康检查。流言协议实现了一个高效的故障检测,可以扩展到一个任意数量的集群,而不集中工作在一个选定的Server组。Client也可以在本地运行一套丰富的的健康检查,反之ZooKeeper临时节点是一个非常原始的活跃度检查。使用Consul,Client可以检查一个Web服务是否返回200状态码,内存使用是否危急,是否有足够的磁盘空间,等等。Consul客户端开放一个简单的HTTP接口,并且避免像ZooKeeper一样将系统的复杂性暴露给客户端。

Consul提供了优秀的服务发现、健康检查、键值存储和多数据中心支持。其它系统为了提供比简单的键值存储更多的功能,需要在其上增加另外的工具或库。在Client节点,Consul仅需要一个瘦客户端提供一个简单的API。此外,通过配置文件和DNS接口可以实现一个完整的服务发现方案,可以完全避免使用API,从而不用进行任何开发工作。