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 们，会经过 Watch 监听到事情，更新一下地址列表，把它摘除调。

在这儿有 2 个留意的点：

• 注册到 ZooKeeper 的服务数据，不要太多，在 Provider 或许 Consumer 十分多的状况下，频繁上下线的时分，十分简略导致 ZooKeeper FullGC。

• Provider 在非正常下线时，暂时节点的生命周期取决于 SessionTimeOut 的时刻，这个能够依据事务自行设置，防止过长或许过短影响事务调用。

大数据范畴-HA 高可用

在大数据范畴，Flink/Hadoop/Hbase/Kafka 等体系都默许的把 ZooKeeper 当作散布式和谐的组件，在这儿边，ZooKeeper 运用自己的特性，协助它们处理了十分多的散布式问题，其间最主要的便是运用 ZooKeeper 做了 HA（Highly Available）计划，进步集群可用性，一般有两个或两个以上的节点，且分为活动节（Active）点及备用节点（standby）。

下方图例中有 2 个 Server，组成 HA 模式，在 Server 发动的时分，往 ZooKeeper 写入一个约定好的途径下暂时节点，因为 ZooKeeper 只答应 1 个写成功，谁先写成功，谁就作为 Active， 而且由 ZooKeeper 告诉到集群中其他节点，其他节点则状况改成 standby 状况。

当 Active 节点宕机的时分，ZooKeeper 将节点状况告诉下去，其他的 standby 节点马上往该节点里边写数据，写成功了，就顶替成为 Active。

整个流程大约便是这样，这儿要留意一个点，便是在网络异常状况下，主备节点切换不那么实时，可能会呈现脑裂，也便是存在 2 个主节点的状况，这种状况的话，能够客户端在切换的时分，能够尝试等一等，状况安稳之后，再切换。

自研体系的散布式和谐场景

在自研散布式体系的时分，必然会遇到许多散布式和谐的问题，ZooKeeper 就像一个全能的工具箱。

针对不同的场景，依据 ZooKeeper 的特性，都能组合成一个处理计划；在写散布式体系的时分，经常需求用到的有这几个功用：

• Master 的选举

咱们的体系需求选举出来 1 个 Maseter 来履行使命；例如 ScheduleX 便是运用 ZooKeeper 做到这个的，Schedulex 的 Worker 节点有十分多，一些使命对错幂等的，只能由一个进程履行，这时分就需求从许多的 Worker 中选一个 master 来，完成的方法主要有 2 种：

• 抢占主节点的方法：约定一个固定的途径，谁往里边写暂时节点数据写成功了，就算当 master，当 Master 宕机后，暂时节点会过期开释，ZooKeeper 告诉到其他节点，其他节点再持续往里边写数据抢占。

• 最小节点方法：运用的是 ZooKeeper 的暂时有序节点完成的，如图所示：要进行选主的时分，每台 Server 往目录下面写一个暂时有序节点，约定好，序号最小的节点作为 master 即可。

• 散布式锁

在散布式环境中，程序都散布独立的节点中，散布式锁是操控散布式体系之间同步拜访同享资源的一种方法，下面介绍下 Zookeeper 如何完成散布式锁，散布式锁主要有 2 种类型：

1、排他锁（Exclusive Locks）：称为独占锁，获取到这个锁后，其他的进程都不答应读写

完成的原理也很简略，运用 ZooKeeper 一个详细途径下只能创立一个节点的特性，约定谁创立成功了，就抢到了锁，一起其他节点要监听这个变化，暂时节点删除了，能够被告诉到去抢（Create）,这个和 Master 选举里边抢占 Master 节点，是相同的做法：

2、同享锁（Shared Locks）：又称为读锁，多个进程能够一起获取这把锁，进行读操作，可是假如要写操作，有必要没有读操作了，且自己是第一个获取到写操作类型锁的

完成的方法如图示；读的时分，创立一个 R 的暂时次序节点，假如比他小的节点里边没有 W 节点，那么写入成功，能够读，假如要写，则判断一切 R 的节点中，自己是否最小的即可。

• 散布式行列

散布式行列最常见的 FIFO（First Input First Output ）先入先出行列模型，先进入行列的恳求操作先完成后，才会开始处理后面的恳求：

Zookeeper 完成 FIFO 行列，和同享锁完成类似，类似于一个全写的同享锁模型：

1、获取/Queue 节点下的一切子节点，获取行列中的一切元素

2、确认自己的节点序号在一切子节点中的次序

3、假如自己的序号不是最小，那么就需求等待，一起向比自己序号小的最终一个节点注册 Watcher 监听

4、接收到 Watcher 告诉后，重复第一个进程

• 装备中心

运用 ZooKeeper 作为装备中心，运用的也是 ZooKeeper 的注册/订阅模式，这儿有个留意点，ZooKeeper 不适用于存储太大的数据，一般不超越 1M，不然简略呈现功用问题。

MSE 供给的 ZooKeeper 企业服务

MSE 和 ZooKeeper 的联络

微服务引擎（Micro Service Engine，简称 MSE）是一个面向业界干流开源微服务生态的一站式微服务渠道，微服务生态的一切服务都能够在这个渠道上面被集成，它供给的引擎都是独立托管的，目的便是为了给咱们供给高功用、高可用、高集成、安全的服务，现在，MSE 供给了如下模块：

• 注册装备中心-(ZooKeeper/Nacos/Eureka）
• 云原生网关-(Envoy)
• 散布式事务-(Seata)
• 微服务治理（Dubbo/Spring Cloud/Sentinel/OpenSergo）

ZooKeeper 和 Nacos 相同，供给注册装备中心功用，可是 ZooKeeper 还供给了散布式和谐的才干，运用在大数据范畴。

MSE 供给的 ZooKeeper 企业服务分为根底版和专业版两种，前者适用于开发测验环境和简略的出产环境，后者在功用、可观测、高可用便利做了许多进步，接下来，咱们将介绍专业版，比较自建的优势。

比自建的 ZooKeeper 更安稳和高可用

MSE 的产品架构图

• ZooKeeper 是多 AZ 布置的：咱们知道 ZooKeeper 只有过半的节点才干选出主来，当一个 5 节点的 ZooKeeper 集群，布置在 3 个可用区的时分，它应该要 2/2/1 的散布，这样的话，恣意一个可用区呈现毛病，ZooKeeper 全体还是可用的，阿里云 AZ 之间的延时，现在是低于 3ms 的，十分短是可控的。

• 高可用负载均衡：用户节点拜访 ZooKeeper 的 endpoint，是 MSE 供给的一个 SingleTunnelSLB，这个 SLB 是一个主备高可用的，它会自动对用户恳求做负载均衡，将恳求压力分散到后端节点，当后端节点毛病时，会自动摘除，确保恳求到正常的节点上面。

• 节点毛病自愈：依托于 K8s 的 Liveness 才干，在节点呈现毛病的时分，会自动恢复毛病节点，及时的保障服务的可持续性。

• 数据安全：专业版 ZooKeeper 供给了快照的备份才干，在集群呈现非预期的状况下 ，能够快速重建恢复集群中的数据，保障数据的安全。

上面介绍的是架构规划上面，对高可用的一个保障。

在研制进程，咱们有一套完备的安稳性保障体系：从研制阶段，到最终的改变上线，都有对应的标准准则，例如改变三板斧，在改变时，必需求满意可观测/可回滚/可灰度的状况下才干上线，不然会被打回；在运行时，咱们有一系列的巡检组建，装备一致性检查，后面也会不断的完善，巡检出问题，立马需求处理。

MSE 也把毛病演练做到了常态化，针对常见的毛病场景，例如网络中止，CoreDNS 宕机、ECS 宕机等，都定时在跑着；在线上预警这块，咱们也做到了自动探测，及时发现，安排值班人员 24 小时处理，咱们有一套 1/5/10 的应急流程，要求在 1 分钟内发现问题，5 分钟处理，10 分钟恢复。

以上的这些，最终都是为了保障 MSE 的安稳高可用，MSE 线上最大规划的一个集群，支撑着 40w+的长链接，安稳运行了 3 年的时刻，没有呈现过毛病，SLA 到达 99.95%。

免运维，供给了丰厚的操控台功用

假如是自建 ZooKeeper 的话，需求做哪些事：

• 搭建根底设施：把一些根底的设施给预备彻底，例如 ECS/SLB 等，再做网络规划。

• 装置 ZooKeeper：装置进程中，要装备许多参数，并对这些参数满意的了解，不然出问题就抓瞎了，不同的参数，对集群运行时的功用也是有必定影响的，这都需求要有满意的专业知识，才干胜任。

• 扩缩容：规划 MyId 的分配，新扩容机器需求自增，不然新机器将无法参加旧集群同步数据，因为只有 MyId 大的才会去自动连小的去同步集群数据；新节点参加集群，也是有严格的发动次序的，新参加的机器数，有必要小于原集群的一半，不然会呈现 master 选在新节点上面，导致数据丢失；在参加节点特别多的时分，需求按这个规矩重复多次，少一个进程，都很简略导致集群选主失利，数据丢失，形成线上出产毛病。

• 服务端装备改变：zoo.cfg 中的装备项，更新之后，需求把集群中每台机器手动重启，才干触发收效。

• 数据管理：开源的 ZooKeeper 没有图形化管理工具，要查看数据，得经过 zkClient 或许写代码查询，操作十分的复杂和繁琐，这些都是自建带来的问题。

• 线上毛病处理：例如 ZooKeeper GC 了，或许网络闪断了，这时分就需求了解 ZK/JVM/操作体系的专业运维人员处理了。

而 MSE 供给的 ZooKeeper 企业服务，则将以上问题经过产品化的方法处理了：

需求一个 ZooKeeper 集群的时分，一键购买，3 分钟开箱即用，呈现容量问题时，一键滑润扩缩容，还供给了重置数据、参数白屏化设置等功用，在可观测这块，也供给了常用的中心默许目标大盘，与之相配套的便是报警了。运用 ZooKeeper 企业服务，省心、省力，进步企业 IT ROI。

可观测性增强

ZooKeeper 专业版的第三个优势，可观测性的增强：

• 丰厚的监控大盘：这次专业版和普罗米修斯进行了深度集成，而且给咱们免费开启运用，供给了 20 多个 Zookeeper 常用的监控目标，4 个中心资源监控目标

• 支撑中心告警规矩：基本能满意咱们日常的运维需求了，当然，假如你还需求的话，能够随时找咱们，给你安排上

• 敞开丰厚 Metrics 标准目标：这次专业版把 ZooKeeper 内置的 70 多个 Metrics 目标，都经过 API 的形式敞开出去了，对应你们来讲，就能够运用这些数据，自己去制作监控大盘了，十分的便利

功用进步

写入功用优化进步 20%，数据可靠性达 99.9999999%（即 9 个 9）。

ZooKeeper 的写入功用， 和磁盘功用有很大的联络，必需求把数据写入到磁盘的事务日志成功后，才算写成功，为了进步写功用，咱们采用了阿里云 ESSD 高功用云盘，最大 IOPS 能够到达 5W，最大吞吐量 350M/S，数据的可靠性 99.9999999%（即 9 个 9），整个写入 TPS 功用能够进步约 20%。

依据Dragonwell 进行构建，读取功用进步 1 倍

咱们集成了阿里高功用 JDK，开启了里边的协程优化才干，并对 ZooKeeper 的读写使命行列做了锁力度的优化，在高并发处理的场景下，读功用比较开源能够进步 1 倍左右的功用。\

GC 时刻下降 80%，大幅削减 Full GC 的状况

ZooKeeper 是时延灵敏型的运用，GC 的时刻和次数，会影响 ZooKeeper 的处理吞吐量，因而咱们针对这种状况，做了 JVM 参数的调优，堆的设置依据不同的装备动态设置，一起提早做了资源碎片的收回，防止呈现 FullGC，全体优化下来，GC 时刻下降 80%，一起尽可能的防止了 FullGC。

依据 MSE，构建 Dubbo+Zookeeper 微服务

操作之前，需求购买一个 ZooKeeper，能够挑选按量付费，不需求是能够开释，假如长期运用，能够挑选包年包月：

在挑选网络拜访方法的时分，以下几种状况：

1、假如你仅仅运用 VPC 网络运用，你就挑选专有网络，选上交换机和专业网络，其他不用动（这儿留意：不要去挑选公网带宽）

2、假如你仅仅要公网拜访，挑选公网网络，再选上对应的带宽即可；

3、假如需求公网，一起也需求 VPC 网络拜访，那么你挑选专有网络，一起在公网带宽处，挑选你需求的公网带宽，这样就会创立 2 个接入点了；

购买之后，大约 5 分钟左右，ZooKeeper 集群就创立成功了，咱们记住拜访方法， 等会 Dubbo 装备文件里边需求装备这个地址：

环境预备好了，就预备 Provider/Consumer 的装备了。欲了解详细的操作进程，可观看直播视频进行了解：yqh.aliyun.com/live/detail…

写在最终

MSE 供给的 ZooKeeper 企业服务，旨在为用户供给更可靠的、成本更低、功率更高的，彻底兼容开源的散布式和谐服务。供给后付费和包年包月两类付费模式，支撑杭州，上海，北京，深圳等海内外 23 个 region，满意 95%地域用户。假如你有其他新开服需求，能够联络咱们。

现在购买 MSE 专业版 ZooKeeper，立享 9 折优惠，新老同享。

也可钉钉搜索群号 34754806 可参加用户群沟通、答疑。

点击此处，前往 MSE 官网进行抢购吧！