Consul vs. ZooKeeper, doozerd, etcd

Consul vs. ZooKeeper, doozerd, etcd

ZooKeeper，doozerd和etcd在它们的架构中都很相似。 这三个服务器节点都需要法定数量的节点才能运行（通常是简单多数）。 它们非常一致，并且可以通过应用程序中的客户端库使用各种原语来构建复杂的分布式系统。

 

Consul还在单个数据中心内使用服务器节点。 在每个数据中心，Consul服务器都需要一个法定人数来运行并提供强大的一致性。 但是，Consul本身支持多个数据中心，以及一个功能更丰富的gossip系统，可以链接服务器节点和客户端。

 

在提供key/value存储时，所有这些系统都具有大致相同的语义：读取非常一致，并且在网络分区面前牺牲了可用性以保持一致性。 但是，当这些系统用于高级案例时，差异会变得更加明显。

 

这些系统提供的语义对构建服务发现系统很有吸引力，但重要的是要强调必须构建这些功能。 ZooKeeper等。 仅提供原始K / V存储，并要求应用程序开发人员构建自己的系统以提供服务发现。 相比之下，Consul为服务发现提供了一个固定的框架，并消除了猜测和开发工作。 客户端只需注册服务，然后使用DNS或HTTP接口执行发现。 其他系统需要自家的解决方案。

 

一个引人注目的服务发现框架必须包含健康检查和失败的可能性。 如果节点A失败或服务崩溃，则知道节点A提供Foo服务是没有用的。 朴素系统利用心跳，使用定期更新和TTL。 这些方案需要与节点数量成线性工作，并将需求放在固定数量的服务器上。 另外，故障检测窗口至少与TTL一样长。

 

ZooKeeper提供临时节点，这些节点是客户端断开连接时删除的K / V条目。 这些比心跳系统更复杂，但仍然存在固有的可扩展性问题，并增加了客户端的复杂性。 所有客户端必须保持与ZooKeeper服务器的活动连接并执行保持活动。 另外，这需要“厚客户端”，这些客户端难以编写并且经常导致调试挑战。

 

Consul使用一种非常不同的架构进行健康检查。 Consul客户端不是仅具有服务器节点，而是在集群中的每个节点上运行。 这些客户端是gossip池的一部分，它提供多种功能，包括分布式健康检查。 八卦协议实现了一种有效的故障检测器，可以扩展到任何大小的集群，而无需将工作集中在任何选定的服务器组上。 客户端还可以在本地运行更丰富的运行状况检查，而ZooKeeper临时节点则是对原始状态的非常原始的检查。 使用Consul，客户端可以检查Web服务器是否返回200状态代码，内存利用率并不重要，磁盘空间足够等等.Consul客户端公开了一个简单的HTTP接口，并避免将系统的复杂性暴露给客户端 与ZooKeeper一样。

 

Consul为服务发现，健康检查，K / V存储和多个数据中心提供一流的支持。 除了简单的K / V存储之外，所有其他系统都需要额外的工具和库来构建。 通过使用客户端节点，Consul提供了一个只需要瘦客户端的简单API。 此外，通过使用配置文件和DNS接口可以完全避免API，从而拥有完整的服务发现解决方案而根本没有开发。