为什么不应该使用ZooKeeper做服务发现 |我的资源库露水湾

【编者的话】本文作者通过 ZooKeeper 与 Eureka 作为Service 发现服务（注：WebServices 体系中的 UDDI 就是个发现服务）的优劣对比，分享了 Knewton 在云计算平台部署服务的经验。本文虽然略显偏激，但是看得出 Knewton 在云平台方面是非常有经验的，这篇文章从实践角度出发分别从云平台特点、CAP 原理以及运维三个方面对比了 ZooKeeper 与 Eureka 两个系统作为发布服务的优劣，并提出了在云平台构建发现服务的方法论。

背景

很多公司选择使用ZooKeeper作为 Service 发现服务（Service Discovery），但是在构建Knewton（Knewton 是一个提供个性化教育平台的公司、学校和出版商可以通过 Knewton 平台为学生提供自适应的学习材料）平台时，我们发现这是个根本性的错误。在这边文章中，我们将用我们在实践中遇到的问题来说明，为什么使用 ZooKeeper 做 Service 发现服务是个错误。

请留意服务部署环境

让我们从头开始梳理。我们在部署服务的时候，应该首先考虑服务部署的平台（平台环境），然后才能考虑平台上跑的软件系统或者如何在选定的平台上自己构建一套系统。例如，对于云部署平台来说，平台在硬件层面的伸缩（注：作者应该指的是系统的冗余性设计，即系统遇到单点失效问题，能够快速切换到其他节点完成任务）与如何应对网络故障是首先要考虑的。当你的服务运行在大量服务器构建的集群之上时（注：原话为大量可替换设备），则肯定会出现单点故障的问题。对于 knewton 来说，我们虽然是部署在 AWS 上的，但是在过往的运维中，我们也遇到过形形色色的故障；所以，你应该把系统设计成“故障开放型”（expecting failure）的。其实有很多同样使用 AWS 的公司跟我们遇到了（同时有很多书是介绍这方面的）相似的问题。你必须能够提前预料到平台可能会出现的问题如：意外故障（注：原文为 box failure，只能意会到作者指的是意外弹出的错误提示框），高延迟与网络分割问题（注：原文为 network partitions。意思是当网络交换机出故障会导致不同子网间通讯中断）——同时我们要能构建足够弹性的系统来应对它们的发生。

永远不要期望你部署服务的平台跟其他人是一样的！当然，如果你在独自运维一个数据中心，你可能会花很多时间与钱来避免硬件故障与网络分割问题，这是另一种情况了；但是在云计算平台中，如 AWS，会产生不同的问题以及不同的解决方式。当你实际使用时你就会明白，但是，你最好提前应对它们（注：指的是上一节说的意外故障、高延迟与网络分割问题）的发生。

ZooKeeper 作为发现服务的问题

ZooKeeper（注：ZooKeeper 是著名 Hadoop 的一个子项目，旨在解决大规模分布式应用场景下，服务协调同步（Coordinate Service）的问题；它可以为同在一个分布式系统中的其他服务提供：统一命名服务、配置管理、分布式锁服务、集群管理等功能）是个伟大的开源项目，它很成熟，有相当大的社区来支持它的发展，而且在生产环境得到了广泛的使用；但是用它来做 Service 发现服务解决方案则是个错误。

在分布式系统领域有个著名的CAP 定理（C-数据一致性；A-服务可用性；P-服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个）；ZooKeeper 是个 CP 的，即任何时刻对 ZooKeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性；但是它不能保证每次服务请求的可用性（注：也就是在极端环境下，ZooKeeper 可能会丢弃一些请求，消费者程序需要重新请求才能获得结果）。但是别忘了，ZooKeeper 是分布式协调服务，它的职责是保证数据（注：配置数据，状态数据）在其管辖下的所有服务之间保持同步、一致；所以就不难理解为什么 ZooKeeper 被设计成 CP 而不是 AP 特性的了，如果是 AP 的，那么将会带来恐怖的后果（注：ZooKeeper 就像交叉路口的信号灯一样，你能想象在交通要道突然信号灯失灵的情况吗？）。而且，作为 ZooKeeper 的核心实现算法Zab，就是解决了分布式系统下数据如何在多个服务之间保持同步问题的。

作为一个分布式协同服务，ZooKeeper 非常好，但是对于 Service 发现服务来说就不合适了；因为对于 Service 发现服务来说就算是返回了包含不实的信息的结果也比什么都不返回要好；再者，对于 Service 发现服务而言，宁可返回某服务 5 分钟之前在哪几个服务器上可用的信息，也不能因为暂时的网络故障而找不到可用的服务器，而不返回任何结果。所以说，用 ZooKeeper 来做 Service 发现服务是肯定错误的，如果你这么用就惨了！

而且更何况，如果被用作 Service 发现服务，ZooKeeper 本身并没有正确的处理网络分割的问题；而在云端，网络分割问题跟其他类型的故障一样的确会发生；所以最好提前对这个问题做好 100%的准备。就像Jepsen在 ZooKeeper 网站上发布的博客中所说：在 ZooKeeper 中，如果在同一个网络分区（partition）的节点数（nodes）数达不到 ZooKeeper 选取 Leader 节点的“法定人数”时，它们就会从 ZooKeeper 中断开，当然同时也就不能提供 Service 发现服务了。

如果给 ZooKeeper 加上客户端缓存（注：给 ZooKeeper 节点配上本地缓存）或者其他类似技术的话可以缓解 ZooKeeper 因为网络故障造成节点同步信息错误的问题。Pinterest与Airbnb公司就使用了这个方法来防止 ZooKeeper 故障发生。这种方式可以从表面上解决这个问题，具体地说，当部分或者所有节点跟 ZooKeeper 断开的情况下，每个节点还可以从本地缓存中获取到数据；但是，即便如此，ZooKeeper 下所有节点不可能保证任何时候都能缓存所有的服务注册信息。如果 ZooKeeper 下所有节点都断开了，或者集群中出现了网络分割的故障（注：由于交换机故障导致交换机底下的子网间不能互访）；那么 ZooKeeper 会将它们都从自己管理范围中剔除出去，外界就不能访问到这些节点了，即便这些节点本身是“健康”的，可以正常提供服务的；所以导致到达这些节点的服务请求被丢失了。（注：这也是为什么 ZooKeeper 不满足 CAP 中 A 的原因）

更深层次的原因是，ZooKeeper 是按照 CP 原则构建的，也就是说它能保证每个节点的数据保持一致，而为 ZooKeeper 加上缓存的做法的目的是为了让 ZooKeeper 变得更加可靠（available）；但是，ZooKeeper 设计的本意是保持节点的数据一致，也就是 CP。所以，这样一来，你可能既得不到一个数据一致的（CP）也得不到一个高可用的（AP）的 Service 发现服务了；因为，这相当于你在一个已有的 CP 系统上强制栓了一个 AP 的系统，这在本质上就行不通的！一个 Service 发现服务应该从一开始就被设计成高可用的才行！

如果抛开 CAP 原理不管，正确的设置与维护 ZooKeeper 服务就非常的困难；错误会经常发生，导致很多工程被建立只是为了减轻维护 ZooKeeper 的难度。这些错误不仅存在与客户端而且还存在于 ZooKeeper 服务器本身。Knewton 平台很多故障就是由于 ZooKeeper 使用不当而导致的。那些看似简单的操作，如：正确的重建观察者（reestablishing watcher）、客户端 Session 与异常的处理与在 ZK 窗口中管理内存都是非常容易导致 ZooKeeper 出错的。同时，我们确实也遇到过 ZooKeeper 的一些经典 bug：ZooKeeper-1159 与ZooKeeper-1576；我们甚至在生产环境中遇到过 ZooKeeper 选举 Leader 节点失败的情况。这些问题之所以会出现，在于 ZooKeeper 需要管理与保障所管辖服务群的 Session 与网络连接资源（注：这些资源的管理在分布式系统环境下是极其困难的）；但是它不负责管理服务的发现，所以使用 ZooKeeper 当 Service 发现服务得不偿失。

做出正确的选择：Eureka 的成功

我们把 Service 发现服务从 ZooKeeper 切换到了 Eureka 平台，它是一个开源的服务发现解决方案，由 Netflix 公司开发。（注：Eureka 由两个组件组成：Eureka 服务器和 Eureka 客户端。Eureka 服务器用作服务注册服务器。Eureka 客户端是一个 java 客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。）Eureka 一开始就被设计成高可用与可伸缩的 Service 发现服务，这两个特点也是 Netflix 公司开发所有平台的两个特色。（他们都在讨论 Eureka）。自从切换工作开始到现在，我们实现了在生产环境中所有依赖于 Eureka 的产品没有下线维护的记录。我们也被告知过，在云平台做服务迁移注定要遇到失败；但是我们从这个例子中得到的经验是，一个优秀的 Service 发现服务在其中发挥了至关重要的作用！

首先，在 Eureka 平台中，如果某台服务器宕机，Eureka 不会有类似于 ZooKeeper 的选举 leader 的过程；客户端请求会自动切换到新的 Eureka 节点；当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中；而对于它来说，所有要做的无非是同步一些新的服务注册信息而已。所以，再也不用担心有“掉队”的服务器恢复以后，会从 Eureka 服务器集群中剔除出去的风险了。Eureka 甚至被设计用来应付范围更广的网络分割故障，并实现“0”宕机维护需求。当网络分割故障发生时，每个 Eureka 节点，会持续的对外提供服务（注：ZooKeeper 不会）：接收新的服务注册同时将它们提供给下游的服务发现请求。这样一来，就可以实现在同一个子网中（same side of partition），新发布的服务仍然可以被发现与访问。

但是，Eureka 做到的不止这些。正常配置下，Eureka 内置了心跳服务，用于淘汰一些“濒死”的服务器；如果在 Eureka 中注册的服务，它的“心跳”变得迟缓时，Eureka 会将其整个剔除出管理范围（这点有点像 ZooKeeper 的做法）。这是个很好的功能，但是当网络分割故障发生时，这也是非常危险的；因为，那些因为网络问题（注：心跳慢被剔除了）而被剔除出去的服务器本身是很”健康“的，只是因为网络分割故障把 Eureka 集群分割成了独立的子网而不能互访而已。

幸运的是，Netflix 考虑到了这个缺陷。如果 Eureka 服务节点在短时间里丢失了大量的心跳连接（注：可能发生了网络故障），那么这个 Eureka 节点会进入”自我保护模式“，同时保留那些“心跳死亡“的服务注册信息不过期。此时，这个 Eureka 节点对于新的服务还能提供注册服务，对于”死亡“的仍然保留，以防还有客户端向其发起请求。当网络故障恢复后，这个 Eureka 节点会退出”自我保护模式“。所以 Eureka 的哲学是，同时保留”好数据“与”坏数据“总比丢掉任何”好数据“要更好，所以这种模式在实践中非常有效。

最后，Eureka 还有客户端缓存功能（注：Eureka 分为客户端程序与服务器端程序两个部分，客户端程序负责向外提供注册与发现服务接口）。所以即便 Eureka 集群中所有节点都失效，或者发生网络分割故障导致客户端不能访问任何一台 Eureka 服务器；Eureka 服务的消费者仍然可以通过 Eureka 客户端缓存来获取现有的服务注册信息。甚至最极端的环境下，所有正常的 Eureka 节点都不对请求产生相应，也没有更好的服务器解决方案来解决这种问题时；得益于 Eureka 的客户端缓存技术，消费者服务仍然可以通过 Eureka 客户端查询与获取注册服务信息，这点很重要。

Eureka 的构架保证了它能够成为 Service 发现服务。它相对与 ZooKeeper 来说剔除了 Leader 节点的选取或者事务日志机制，这样做有利于减少使用者维护的难度也保证了 Eureka 的在运行时的健壮性。而且 Eureka 就是为发现服务所设计的，它有独立的客户端程序库，同时提供心跳服务、服务健康监测、自动发布服务与自动刷新缓存的功能。但是，如果使用 ZooKeeper 你必须自己来实现这些功能。Eureka 的所有库都是开源的，所有人都能看到与使用这些源代码，这比那些只有一两个人能看或者维护的客户端库要好。

维护 Eureka 服务器也非常的简单，比如，切换一个节点只需要在现有 EIP 下移除一个现有的节点然后添加一个新的就行。Eureka 提供了一个 web-based 的图形化的运维界面，在这个界面中可以查看 Eureka 所管理的注册服务的运行状态信息：是否健康，运行日志等。Eureka 甚至提供了 Restful-API 接口，方便第三方程序集成 Eureka 的功能。

结论

关于 Service 发现服务通过本文我们想说明两点：1、留意服务运行的硬件平台；2、时刻关注你要解决的问题，然后决定使用什么平台。Knewton 就是从这两个方面考虑使用 Eureka 替换 ZooKeeper 来作为 service 发现服务的。云部署平台是充满不可靠性的，Eureka 可以应对这些缺陷；同时 Service 发现服务必须同时具备高可靠性与高弹性，Eureke 就是我们想要的！