ZooKeeper 在阿里巴巴的服务形态演进

Apache ZooKeeper 在阿里巴巴经历了开源自用、深度优化、反哺社区、开发企业版服务云上客户的演进过程，为了厘清本文脉络，我们对演进过程中提到的关键名词做以下定义。

• Apache ZooKeeper：提供分布式协调服务如分布式锁、分布式队列等，还可用于注册配置中心的能力。
• TaoKeepeer：基于 ZooKeeper 做了深度改造，于2008年服务于淘宝。
• MSE：阿里云的一个面向业界主流开源微服务生态的一站式微服务平台。
• ZooKeeper 企业服务：MSE 的子产品，提供开源增强的云上服务，分为基础版和专业版两种。

ZooKeeper 在阿里巴巴的服务形态演进历程

早在 2008 年，阿里巴巴基于 ZooKeeper 的开源实现和淘宝的电商业务，设计 Taokeeper 这款分布式协调软件，彼时恰逢淘宝启动服务化改造，那时候，也诞生了各类分布式中间件，例如
HSF/ConfigServer/VIPServer 等。

10 年后的 2019 年，阿里巴巴实施全站上云战役，所有的产品都需要升级到公有云架构，MSE 就是在那个时候诞生的，上线后便兼容了主流的 ZooKeeper 版本。

整个过程经历了以下 3 个阶段：

第一个阶段：08 年的 1.0 版本，主要支持集团有分布式协调需求的应用，那时候所有的业务都是混着用，有 1000 多个应用，最终大概手动运维着 150+个共享集群。随着时间的推移，业务都在做微服务拆分，共享集群的容量爆炸式增长，这样带来的问题就是：业务混部，爆炸半径大，稳定性存在着很大的风险；日常的运维，例如机器置换等，牵一发而动全身，如果配置出问题，影响所有业务。

第二个阶段：为了解决阶段一的问题，我们将 ZooKeeper 演进到 2.0 版本。那时候正直容器化刚刚兴起，在仔细研究过容器化的改造方案后，我们在性能和运维能够同时满足要求的情况下，进行了大量的改造，业务进行拆分、集群迁移、按最小稳定单元去运维一个集群，这样我们终于可以睡个安稳觉了，拆分完后，依托于 K8s 的规模化运维能力，这些问题都得到了很好的解决，由此实现了独享模式集群、资源隔离，SLA 得到了提升，能到达 99.9%。

第三个阶段：上云提供公共云服务，也就演进到了 3.0。这个版本重点打造了开源增强，例如，基于 Dragonwell 进行构建、JVM 参数调优、集成了 Prometheus、部署形态多 AZ 强制平均打散、支持动态配置 、平滑扩缩容等改造，在性能、免运维、可观测、高可用和安全等方面做了诸多提升，SLA 能够到达 99.95%。

ZooKeeper 在技术场景上的最佳实践

接下来，给大家介绍下 ZooKeeper 的最佳实践场景，归为了 3 类，分别是：

• 微服务领域，代表的集成产品是 Dubbo/SpringCloud
• 大数据领域，代表的集成产品是 Flink/Hbase/Hadoop/Kafka
• 自研的分布式系统，包括大家自己公司内部的分布式系统，对分布式协调有需求，如分布式锁

微服务领域-注册中心

ZooKeeper 在微服务场景里面，主要是用作注册中心，利用了 ZooKeeper 的注册/订阅模式，可以看下 Dubbo 在 ZooKeeper 里面的数据结构：

在 Provider 启动时，会向 ZooKeeper 固定路径 providers 下面创建一个临时节点， 在这个节点里面存入本机的服务信息，例如，应用名，IP 和端口等，Consumer 启动的时候 ，监听对应服务下 Providers 的所有子节点，ZooKeeper 会把所有子节点信息主动通知到 Consumer，Consumer 此时就拿到所有 Provider 的地址列表信息了，Provider 注册到 ZooKeeper 上面的临时节点，它的生命周期和 Provider 与ZooKeeper 之间建立的长链接时一致的，除非 Provider 主动下线，当 Provider 宕机或者主动下线，这个临时节点就会被删除，那么订阅这个服务的 Consumer 们&#x