共计 6815 个字符，预计需要花费 18 分钟才能阅读完成。
作者：草谷
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 的配置了。欲了解具体的操作步骤，可观看直播视频进行理解：https://yqh.aliyun.com/live/d…
写在最初
MSE 提供的 ZooKeeper 企业服务，旨在为用户提供更牢靠的、老本更低、效率更高的，齐全兼容开源的分布式协调服务。提供后付费和包年包月两类付费模式，反对杭州，上海，北京，深圳等海内外 23 个 region，满足 95% 地区用户。如果你有其余新开服须要，能够分割咱们。
当初购买 MSE 专业版 ZooKeeper，立享 9 折优惠，新老同享。
也可钉钉搜寻群号 34754806 可退出用户群交换、答疑。
点击此处，返回 MSE 官网进行抢购吧！
