立在以后的路口，回望历史时间的迷失，经常会很有趣，由于大家会不经意间地盛行玩命的想法，例如假如当初某件事提早发生了，而此外一件事又并没有产生会如何？一如当初的奥匈帝国帝位继承者斐迪南大公夫妻要是没有被塞尔维亚族热血男儿普林西普枪击会如何，又倘若当初的丘小编并没有通过牛家村会如何？

2008 年末，淘宝网打开一个叫做“五彩石”的内部结构构建新项目，这一新项目之后变成了淘宝卖家服务化、面对分布式系统走自研之途，摆脱了互联网技术分布式数据库管理体系之始，而淘宝卖家服务注册中心 ConfigServer 于同一年问世。

2008 年前后左右，Yahoo 这一以前的互联网大佬逐渐慢慢在公共场合宣传教育自身的互联网大数据分布式系统融洽商品 ZooKeeper，这一商品参照了 Google 发布的有关 Chubby 及其 Paxos 的毕业论文。

2010 年11月，ZooKeeper 从 Apache Hadoop 的单项工程发展趋势为 Apache 的顶尖新项目，宣布宣告 ZooKeeper 变成一个工业生产级的完善稳定性的商品。

2011 年，阿里巴巴开源系统 Dubbo，为了更好地更强开源系统，必须脱离与阿里巴巴内部结构体系的关联，Dubbo 适用了开源系统的 ZooKeeper 做为其注册中心，之后在中国，在业内诸位的勤奋实践活动下，Dubbo ZooKeeper 的非常典型的服务创新计划方案造就了 ZooKeeper 做为注册中心的名声。

2015 年双 11，ConfigServer 服务项目内部结构近 8 个年过去，阿里巴巴内部结构“服务项目经营规模”超上百万 ，及其推动“千里”的 IDC 容灾技术性发展战略等，一同促进阿里巴巴内部结构打开了 ConfigServer 2.0 到 ConfigServer 3.0 的构架更新之途。

时长迈向 2018 年，立在 10 年的时长街口上，有几个想要在追求日月牙异的时尚技术性定义的情况下，略微慢一下步伐，细心凝望一下服务发现这一行业，有几个想起过或是思索过一个问题：

服务发现，ZooKeeper 真的是最好的选择么？

而回望历史时间，大家也偶有迷思，在服务发现这一情景下，假如当初 ZooKeeper 的兴起之日比大家 HSF 的注册中心 ConfigServer 早一点会如何？

大家是否会迈向先应用 ZooKeeper 随后玩命更新改造与修复 ZooKeeper 以融入阿里巴巴的服务创新情景与需求量的弯道？

可是，立在今日和先前的肩头上，大家从没如今日那样坚持的认知能力到，在服务发现行业，ZooKeeper 压根就不可以算得上最好的挑选，一如这么多年一直与大家同行业的 Eureka 及其这篇文章 《Eureka! Why You Shouldn’t Use ZooKeeper for Service Discovery》那坚定不移的论述一样，为何不应该用 ZooKeeper 做服务发现！

吾道不孤矣。

注册中心需求分析及关键设计方案考虑

下面，使我们重归对服务发现的需求分析，融合阿里巴巴在关键情景上的实践活动，来一一剖析，一起讨论为什么说 ZooKeeper 并非最好的注册中心解决方法。

注册中心是 CP 或是 AP 系统软件?

CAP 和 BASE 基础理论坚信大家都已经广为人知，其已然变成具体指导分布式架构及移动互联网运用搭建的关键标准之一，在这里不会再赘述其基础理论，大家直接进入对注册中心的信息一致性和易用性要求的剖析:

• 数据信息一致性需求分析

注册中心最实质的作用可以当做是一个 Query 函数公式 Si = F(service-name)，以 service-name 为查看主要参数，service-name 相匹配的服務的可以用的 endpoints (ip:port)目录为传参.

注: 后文将 service 缩写为 svc。

先一起来看看关键数据信息 endpoints (ip:port) 不一致性产生的危害，即 CAP 中的 C 不符合产生的不良影响 :

如上图所述所显示，假如一个 svcB 布署了 10 个连接点 (团本 /Replica），假如针对同一个服务项目名 svcB, 调用者 svcA 的 2 个连接点的 2 次查看回到了不一致的数据信息，例如: S1 = { ip1,ip2,ip3…,ip9 }, S2 = { ip2,ip3,….ip10 }, 那麼此次不一致造成的不良影响是啥？相信你一定已经看出来，svcB 的每个连接点总流量会出现一点不平衡。

ip1 和 ip10 相对性其他 8 个连接点{ip2…ip9}，要求总流量小了一点，但很显著，在分布式架构中，即使是对等布署的服务项目，由于要求达到的时长，硬件配置的情况，电脑操作系统的生产调度，vm虚拟机的 GC 等，一切一个时间点，这种对等布署的连接点情况也难以完全一致，而总流量不一致的情形下，只需注册中心在 SLA 服务承诺的時间内（例如 1s 内）将数据信息收敛性到一致情况（即达到最后一致），总流量将迅速趋向统计学意义上的一致，因此注册中心以最后一致的设计模型在实践中彻底可以接纳。

• 系统分区忍受及易用性需求分析

下面让我们看一下互联网系统分区（Network Partition）状况下注册中心不能用对服务项目启用出现的危害，即 CAP 中的 A 不符合时提供的危害。

考虑到一个非常典型的 ZooKeeper 三主机房容灾 5 连接点布署构造 (即 2-2-1 结构)，如下图:

当主机房 3 发生互联网系统分区 (Network Partitioned) 的情况下，即主机房 3 在互联网上上了荒岛，我们知道尽管总体 ZooKeeper 服务项目是可以用的，可是连接点 ZK5 是不能写的，由于联络不了 Leader。

换句话说，此刻主机房 3 的业务系统 svcB 是不能新布署，重启，扩充或是缩容的，可是立在互联网和服务项目启用的角度观察，主机房 3 的 svcA 尽管没法启用主机房 1 和机房 2 的 svcB, 可是与主机房 3 的 svcB 中间的互联网本来是 OK 的啊，为什么禁止我启用本主机房的服务项目？

如今由于注册中心本身为了更好地保脑裂 (P) 下的信息一致性（C）而放弃了易用性，造成了同主机房的业务中间发生了没法启用，这也是肯定不允许的！可以说在日常生活中，注册中心不可以由于自己的任何原因毁坏服务项目中间自身的可连通性，这也是注册中心设计方案应当遵循的法则！ 后边在注册中心手机客户端灾容上大家还会探讨。

与此同时大家再考虑一下这样的事情下的数据信息不一致性，假如主机房 1，2，3 中间都变成荒岛，那麼假如每一个数据中心的 svcA 都只取得本主机房的 svcB 的 ip 目录，也即在各主机房 svcB 的 ip 目录数据信息彻底不一致，危害是啥？

实际上没啥大危害，仅仅这样的事情下，统统变成了同主机房启用，我们在设计方案注册中心的情况下，有时乃至会积极运用这类注册中心的统计数据可以不一致性，来协助运用积极保证同主机房启用，进而改善服务启用链接 RT 的实际效果！

根据以上大家的论述能够看见，在 CAP 的衡量中，注册中心的易用性比数据信息强一致性更珍贵，因此总体设计更应当偏重 AP，并非 CP，数据信息不一致在可接收范畴，而 P 下放弃 A 却彻底违背了注册中心不可以由于自己的任何原因毁坏服务项目自身的可连通性的标准。

服务项目经营规模、容积、服务项目中国联通性

你所属企业的“微服务架构”经营规模有多大？上百微服务架构？布署了上一百多个连接点？那麼 3 年之后呢？互联网技术是造成惊喜的地区，或许你的“服务项目”一夜之间就众所周知，总流量增长，经营规模增涨！

当数据中心服务经营规模超出一定总数 (服务项目经营规模 =F{服务项目 pub 数, 服务 sub 数})，做为注册中心的 ZooKeeper 迅速便会像下面的图的毛驴一样承受不住

实际上当 ZooKeeper 用对的地方时，即用在细粒度分布式锁，分布式系统融洽情景下，ZooKeeper 能适用的 tps 和支撑点的线程数是充足用的，由于这种情景针对 ZooKeeper 的可扩展性和容积需求并不是很明显。

但在服务发现和健康监测情景下，伴随着服务项目经营规模的扩大，不论是运用经常公布时的服务项目申请注册产生的写要求，或是刷ms级的服务项目身心健康情况产生的写要求，或是恨不得全部大数据中心的设备或是器皿皆与注册中心有长连接产生的联接工作压力上，ZooKeeper 迅速便会心有余而力不足，而 ZooKeeper 的写并并不是可拓展的，不能根据加连接点处理水准可扩展性问题。

要想在 ZooKeeper 基本上咬着牙处理服务项目经营规模的提高问题，一个操作中可以考量的办法是想办法整理业务流程，竖直区划业务流程域，将其区划到好几个 ZooKeeper 注册中心，可是做为给予通用性服务项目的服务平台组织组，因自身带来的服务项目能力不足要业务流程依照技术性的方向标相互配合区划整治业务流程，确实行得通么？

并且这又违背了由于注册中心本身的缘故（能力不足）毁坏了贴心服务的可连通性，举个简便的事例，1 个检索业务流程，1 个地形图业务流程，1 个大文化娱乐业务流程，1 个手机游戏业务流程，她们中间的业务就应当老死不相往来么？或许今天毫无疑问的，那麼明日呢，1 年之后呢，10 年后呢？有谁知道以后会要连通好多个业务流程域去干什么奇怪的工作自主创新？注册中心做为基础服务，没法意料将来的情况下自然不可以防碍业务流程服务项目对将来原有中国联通性的要求。

注册中心必须长久储存和事务管理日志么？

必须，也不用。

我们知道 ZooKeeper 的 ZAB 协议书对每一个写要求，会在每一个 ZooKeeper 连接点上维持写一个事务管理日志，与此同时再再加上按时的将运行内存数据信息镜像文件（Snapshot）到硬盘来确保数据的一致性和持续性，及其服务器宕机以后的统计数据可修复，这也是很好的特点，可是我们要问，在服务发现情景中，其最主要的数据信息 – 即时的身心健康的服務的详细地址目录确实必须数据信息分布式锁么？

针对这一份数据信息，回答是否认的。

如上图所述所显示，假如 svcB 经历了申请注册服务 (ip1) 到扩充到 2 个连接点（ip1，ip2）到因服务器宕机缩容 (ip1 宕机），这一环节中，造成了 3 次对于 ZooKeeper 的写实际操作。

可是具体分析，根据事务管理日志，分布式锁持续纪录这一转变全过程实际上实际意义并不大，由于在服务发觉中，服务调用发起方更关心的是其要调用的服务的即时的详细地址目录和即时身心健康情况，每一次进行调用时，并不关注要调用的服务的历史时间服务详细地址目录、以往的身心健康情况。

可是为什么又说必须呢，由于一个完全的生产制造可以用的注册中心，除开服务的即时详细地址目录及其即时的身心健康情况以外，还会继续储存一些服务的元数据信息，例如服务的版本号，分类，所属的大数据中心，权重值，身份验证策略信息，service label 等元信息内容，这种信息必须分布式锁储存，而且注册中心应当给予对这种元数据的查找的工作能力。

Service Health Check

应用 ZooKeeper 做为服务注册中心时，服务的健康检测常运用 ZooKeeper 的 Session 活性 Track 体制 及其融合 Ephemeral ZNode 的体制，简易来讲，便是将服务的健康监测关联在了 ZooKeeper 针对 Session 的健康监测上，换句话说关联在 TCP 长连接活性检测上。

这在许多情况下也会导致致命性的问题，ZK 与服务服务提供者设备中间的 TCP 长连接活性检测正常的的情况下，该服务便是身心健康的么？回答或许是否认的！注册中心应当给予更丰富的健康监测计划方案，服务的身体健康程度的逻辑性应当对外开放给服务给予方自身界定，而不是一刀切搞变成 TCP 活性检验！

健康检测的一大基本上设计原理便是尽量真正的意见反馈服务自身的真正身心健康情况，不然一个不敢被服务调用者坚信的身心健康情况判断结论还比不上并没有健康检测。

注册中心的容灾考虑到

上文提到，在日常生活中，注册中心不可以由于自己的任何原因毁坏服务中间自身的可连通性，那麼在易用性上，一个本质上的问题，假如注册中心（Registry）自身彻底服务器宕机了，svcA 调用 svcB 链接应当遭到危害么？

是的，不应该遭受危害。

服务调用（要求回应流）链接应该是弱依靠注册中心，务必仅在服务公布，设备左右线，服务扩缩容等必需时才依靠注册中心。

这必须注册中心细心的设计方案自身带来的手机客户端，客户端中应当有对于注册中心服务彻底不能用时做容灾的方式，例如设计方案手机客户端缓存文件体制（大家称作 client snapshot）便是切实可行的方式。此外，注册中心的 health check 体制也需要细心设计方案便于在这样的事情不可能发生例如推空等情形的发生。

ZooKeeper 的原生态手机客户端并并没有这个工作能力，因此运用 ZooKeeper 完成注册中心的情况下大家一定要问一下自己，假如把 ZooKeeper 全部连接点全灭掉，你生产制造上的全部服务调用链接能不会受到其他危害么？并且应当按时就这一点做常见故障演习。

你有没有 ZooKeeper 的医生可借助？

ZooKeeper 看起来非常简单的一个商品，但在生产制造上规模性应用而且用好，并非那麼理所应当的事儿。假如你决策在制造中引进 ZooKeeper，你最好搞好随时随地向 ZooKeeper 技术专家寻求帮助的心里预估，最经典的体现是在2个层面:

• 无法把握的 Client/Session 有限状态机

ZooKeeper 的原生态手机客户端肯定不能叫作实用，Curator 会好一点，但实际上也好的比较有限，要彻底了解 ZooKeeper 手机客户端与 Server 中间的互动协议书也并不容易，彻底了解并把握 ZooKeeper Client/Session 的有限状态机（下面的图）也并非那麼简洁明了:

但根据 ZooKeeper 的服务发觉计划方案则是依靠 ZooKeeper 给予的长连接 /Session 管理方法，Ephemeral ZNode，Event&Notification, ping 体制上，因此得用好 ZooKeeper 做服务发觉，刚好要掌握这种 ZooKeeper 关键的制度基本原理，这有时会使你深陷狂躁，我只是需要个服务发觉罢了，如何要了解这么多？而假如这种你都了解了而且不踩坑，祝贺你了，你已经变成 ZooKeeper 的技术专家了。

• 承受不住的错误处理

我们在阿里内部结构运用连接 ZooKeeper 时，有一个《ZooKeeper 应用接入必知必会》的 WIKI，在其中有关错误处理有如下所示的阐述:

假如说要挑选出运用开发人员在应用 ZooKeeper 的历程中，最必须认识明白的事儿？那麼依据大家以前的适用工作经验，一定是错误处理。

当全部一切（宿主机，硬盘，互联网这些）都很好运的常规作业的情况下，运用与 ZooKeeper 很有可能也会运作的非常好，但遗憾的是，大家一天到晚会应对各种各样出现意外，并且这遵循墨菲定律，意想不到的坏事儿一直在你最担忧的过程中产生。

因此尽量认真掌握 ZooKeeper 在一些情景下能发生的异常情况和不正确，保证您恰当的了解了这种出现异常和不正确，及其了解您的运用如何正确的解决这种状况。

ConnectionLossException 和 Disconnected 事情

简易而言，这也是个可以在同一个 ZooKeeper Session 修复的出现异常 (Recoverable), 可是运用开发人员必须承担将运用修复到恰当的情况。

产生这一出现异常的因素有很多，例如运用设备与 ZooKeeper 连接点中间互联网闪断，ZooKeeper 连接点服务器宕机，服务端 Full GC 时长较长，乃至你的使用过程 Hang 死，运用过程 Full GC 时长较长以后修复都是有很有可能。

要了解这一出现异常，必须掌握分布式服务中的一个非常典型的问题，如下图：

在一个经典的手机客户端要求、服务端回应中，当他们中间的长连接闪断的情况下，手机客户端认知到这一闪断事情的情况下，会处于一个非常无奈的处境，那便是没法明确该情况出现时周边的那一个要求究竟处于哪些情况，Server 端究竟接到这一要求了么？已经解决了么？由于没法明确这一点，因此当手机客户端再次联接上 Server 以后，这一要求是不是应当再试（Retry）就也需要打一个疑问。

因此在解决联接断掉事情中，运用开发人员务必清晰处在闪断周边的那一个要求是啥（这经常无法分辨），该要求是不是幂等的，针对业务流程要求在 Server 端服务解决上针对”仅解决一次” “较多解决一次” “至少解决一次”词义要有挑选和预估。

举例说明，假如运用在接到 ConnectionLossException 时，以前的要求是 Create 实际操作，那麼使用的 catch 到这一出现异常，运用一个有可能的修复逻辑性便是，分辨以前要求建立的连接点的是不是已经具有了，假如存有就千万别建立了，不然就建立。

再例如，假如运用应用了 exists Watch 去监视一个不会有的连接点的建立的事情，那麼在 ConnectionLossException 的期内，有可能碰到的情形是，在这个闪断期内，其他的手机客户端过程很有可能已经建立了连接点，而且又已经删除了，那麼针对现阶段运用而言，就 miss 了一次关注的连接点的建立事情，这类 miss 对使用的不良影响是啥？是可以忍耐的或是无法接纳？必须运用开发人员自身依据业务流程词义去分析和解决。

SessionExpiredException 和 SessionExpired 事情

Session 请求超时是一个不能修复的出现异常，这也是指运用 Catch 到这一出现异常的情况下，运用不太可能在同一个 Session 中修复运用情况，务必要再次创建新 Session，老 Session 关系的临时性连接点也很有可能已经无效，有着的锁很有可能已经无效。…

大家阿里的小伙伴们在自主试着应用 ZooKeeper 做服务发觉的历程中，以前在人们的内部网技术交流上汇总过一篇自身踩坑的心得分享

在本文中合理的提及:

… 在编写代码全过程中发觉许多很有可能具有的圈套，毛估估，第一次应用 zk 来完成群集管理方法的人应当有 80% 以上会掉坑，有一些坑较为隐敝，在网络问题或是出现异常的情景时才会发生，很有可能较长一段时间才会泄露出去 …

向左走，向右走

阿里是否彻底没应用 ZooKeeper？并并不是！

了解阿里技术性系统的都了解，实际上阿里维护保养了现阶段中国乃至世界最大经营规模的 ZooKeeper 群集，总体经营规模有近千台的 ZooKeeper 服务连接点。

与此同时阿里分布式数据库内部结构也维护保养了一个面对大规模生产的、高可用性、更易监控器和运营的 ZooKeeper 的编码支系 TaoKeeper，假如以大家近 10 年在每个工作线和生产制造上应用 ZooKeeper 的实践活动，给 ZooKeeper 用一个语句点评得话，那麼大家觉得 ZooKeeper 应该是 “The King Of Coordination for Big Data”！

在细粒度分布式锁，分布式系统选主，主备高可用性转换等不用高 TPS 适用的场景下有不可替代的功效，而这种要求通常多聚集在大数据、线下每日任务等相应的业务范围，由于大数据行业，注重切分数据，而且绝大多数时长分每日任务多进程 / 进程并行计算这种数据，可是老是有一些点上必须将这类目标和过程统一融洽，此刻便是 ZooKeeper 充分发挥关键作用的立足之地。

可是在交易场景交易链接上，在主业务流程数据信息存储，规模性服务发现、大规模健康监测等领域有自然的薄弱点，应当尽力防止在这种场景下引进 ZooKeeper，在阿里巴巴集团的生产实践中，运用对 ZooKeeper 申请办理采用的那时候要实现严苛的场景、容积、SLA 要求的评定。

因此可以应用 ZooKeeper，可是大数据请往左边，而交易则往右边，分布式系统融洽往左边，服务发现往右边。

写在最终

谢谢你细心的阅读文章到这儿，至此，我敢确信已经了解，大家写这篇文章并非彻底否定 ZooKeeper，而仅仅依据大家阿里近 10 年以来在规模性服务创新上的生产实践，对我们在服务发现和注册中心设计方案及应用上的成功经验开展一个汇总，期待对业内就怎样更快的应用 ZooKeeper，怎样更快的设计方案自身的服务项目注册中心有一定的启迪和协助。

最终，这山望着那山高，衷心祝福你的注册中心立即就出现在罗马帝国。