干掉 “ZooKeeper“，阿里为什么不用 ZK 做服务发现？

站在未来的路口，回望历史的迷途，常常会很有意思，因为我们会不经意地兴起疯狂的念头，例如如果当年某事提前发生了，而另外一件事又没有发生会怎样？一如当年的奥匈帝国皇位继承人斐迪南大公夫妇如果没有被塞尔维亚族热血青年普林西普枪杀会怎样，又如若当年的丘老道没有经过牛家村会怎样？

2007年底，淘宝开启一个叫做“五彩石”的内部重构项目，这个项目后来成为了淘宝服务化、面向分布式走自研之路，走出了互联网中间件体系之始，而淘宝服务注册中心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}，请求流量小了一点，但很明显，在分布式系统中