为何不要把ZooKeeper用于服务发现

ZooKeeper是Apache基金会下的一个开源的、高可用的分布式应用协调服务。许多公司都把它用于服务发现。但在云环境中，面对设备及网络故障时的恢复能力是须要重点考虑的问题。所以，将应用部署在云上，就必需要预见到硬件故障、网络延迟以及网络分区等问题，进而构建出恢复能力强的系统。Peter Kelley是个性化教育初创公司Knewton的一名软件工程师。他认为，从根本上讲，把ZooKeeper用于服务发现是个错误的作法，理由以下：

在ZooKeeper中，网络分区中的客户端节点没法到达Quorum时，就会与ZooKeeper失去联系，从而也就没法使用其服务发现机制。所以，在用于服务发现时，ZooKeeper没法很好地处理网络分区问题。做为一个协调服务，这没问题。但对于服务发现来讲，信息中可能包含错误要好于没有信息。虽然能够经过客户端缓存和其它技术弥补这种缺陷，像Pinterest和Airbnb等公司所作的那样，但这并不能从根本上解决问题，若是Quorum彻底不可用，或者集群分区和客户端都刚好链接到了不属于这个Quorum但仍然健康的节点，那么客户端状态仍将丢失。

更重要地，上述作法的本质是试图用缓存提升一个一致性系统的可用性，即在一个CP系统之上构建AP系统，这根本就是错误的方法。服务发现系统从设计之初就应该针对可用性而设计。

抛开CAP理论不说，ZooKeeper的设置和维护很是困难，以至Knewton屡次由于错误的使用出现问题。一些看似很简单的事情，实际操做起来也很是容易出错，如在客户端重建Watcher，处理Session和异常。另外，ZooKeeper自己确实也存在一些问题，如ZOOKEEPER-1159、ZOOKEEPER-1576。

因为这些问题的存在，他们切换到了Eureka。这是一个由Netflix开发的、开源的服务发现解决方案，具备可用性高、恢复能力强的特色。相比之下，它有以下优势：

若是一个服务器出现问题，Eureka不须要任何类型的选举，客户端会自动切换并链接到一个新的Eureka服务器。当它恢复时，能够自动加入Eureka节点集群。并且，按照设计，它能够在零停机的状况下处理更普遍的网络分区问题。在出现网络分区的状况下，Eureka将继续接受新的注册并发布。这能够确保新增服务仍然能够供分区同侧的任意客户端使用。

Eureka有一个服务心跳的概念，能够阻止过时数据：若是一个服务长时间没有发送心跳，那么Eureka将从服务注册中将其删除。但在出现网络分区、Eureka在短期内丢失过多客户端时，它会停用这一机制，进入“自我保护模式”。网络恢复后，它又会自动退出该模式。这样，虽然它保留的数据中可能存在错误，却不会丢失任何有效数据。

Eureka在客户端会有缓存。即便全部Eureka服务器不可用，服务注册信息也不会丢失。缓存在这里是恰当的，由于它只在全部的Eureka服务器都没响应的状况下才会用到。

Eureka就是为服务发现而构建的。它提供了一个客户端库，该库提供了服务心跳、服务健康检查、自动发布及缓存刷新等功能。使用ZooKeeper，这些功能都须要本身实现。

管理简单，很容易添加和删除节点。它还提供了一个清晰简洁的网页，上面列出了全部的服务及其健康情况。

Eureka还提供了REST API，使用户能够将其集成到其它可能的用途和查询机制。

总之，云平台并不老是可靠，服务发现须要具有尽量高的可用性和恢复能力，而Eureka偏偏是针对这种状况而设计的。