dubbo提供者配置 zookeeper和dubbo原理 _zookeeper

站在未来的路口，回望历史的迷途，常常会很有意思，因为我们会不经意地兴起疯狂的念头，例如如果当年某事提前发生了，而另外一件事又没有发生会怎样？一如当年的奥匈帝国皇位继承人斐迪南大公夫妇如果没有被塞尔维亚族热血青年普林西普枪杀会怎样，又如若当年的丘老道没有经过牛家村会怎样？
2008 年底，淘宝开启一个叫做“五彩石”的内部重构项目，这个项目后来成为了淘宝服务化、面向分布式走自研之路，走出了互联网中间件体系之始，而淘宝服务注册中心 ConfigServer 于同年诞生。
2008 年前后， Yahoo 这个曾经的互联网巨头开始逐渐在公开场合宣讲自己的大数据分布式协调产品 ZooKeeper ，这个产品参考了 Google 发表的关于 Chubby 以及 Paxos 的论文。
2010 年11月， ZooKeeper 从 Apache Hadoop 的子项目发展为 Apache 的顶级项目，正式宣告 ZooKeeper 成为一个工业级的成熟稳定的产品。
2011 年，阿里巴巴开源 Dubbo ，为了更好开源，需要剥离与阿里内部系统的关系， Dubbo 支持了开源的 ZooKeeper 作为其注册中心，后来在国内，在业界诸君的努力实践下， DubboZooKeeper 的典型的服务化方案成就了 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 的各个节点流量会有一点不均衡。