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 们&