简介：本文将给大家介绍下 ZooKeeper 的最佳实际场景，归为了 3 类，别离是：微服务畛域，代表的集成产品是 Dubbo/SpringCloud；大数据畛域，代表的集成产品是 Flink/Hbase/Hadoop/Kafka；自研的分布式系统，包含大家本人公司外部的分布式系统，对分布式协调有需要，如分布式锁。
作者：草谷
Apache ZooKeeper 在阿里巴巴经验了开源自用、深度优化、反哺社区、开发企业版服务云上客户的演进过程，为了厘清本文脉络，咱们对演进过程中提到的要害名词做以下定义。
Apache ZooKeeper：提供分布式协调服务如分布式锁、分布式队列等，还可用于注册配置核心的能力。
TaoKeepeer：基于 ZooKeeper 做了深度革新，于 2008 年服务于淘宝。
MSE：阿里云的一个面向业界支流开源微服务生态的一站式微服务平台。
ZooKeeper 企业服务：MSE 的子产品，提供开源加强的云上服务，分为根底版和专业版两种。
ZooKeeper 在阿里巴巴的服务状态演进历程
早在 2008 年，阿里巴巴基于 ZooKeeper 的开源实现和淘宝的电商业务，设计 Taokeeper 这款分布式协调软件，彼时恰逢淘宝启动服务化革新，那时候，也诞生了各类分布式中间件，例如 HSF/ConfigServer/VIPServer 等。
10 年后的 2019 年，阿里巴巴施行全站上云战斗，所有的产品都须要降级到私有云架构，MSE 就是在那个时候诞生的，上线后便兼容了支流的 ZooKeeper 版本。
增加图片正文，不超过 140 字（可选）
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
整个过程经验了以下 3 个阶段：
第一个阶段：08 年的 1.0 版本，次要反对团体有分布式协调需要的利用，那时候所有的业务都是混着用，有 1000 多个利用，最终大略手动运维着 150+ 个共享集群。随着工夫的推移，业务都在做微服务拆分，共享集群的容量爆炸式增长，这样带来的问题就是：业务混部，爆炸半径大，稳定性存在着很大的危险；日常的运维，例如机器置换等，牵一发而动全身，如果配置出问题，影响所有业务。
第二个阶段：为了解决阶段一的问题，咱们将 ZooKeeper 演进到 2.0 版本。那时候耿直容器化刚刚衰亡，在认真钻研过容器化的革新计划后，咱们在性能和运维可能同时满足要求的状况下，进行了大量的革新，业务进行拆分、集群迁徙、按最小稳固单元去运维一个集群，这样咱们终于能够睡个安稳觉了，拆分完后，依靠于 K8s 的规模化运维能力，这些问题都失去了很好的解决，由此实现了独享模式集群、资源隔离，SLA 失去了晋升，能达到 99.9%。
第三个阶段：上云提供公共云服务，也就演进到了 3.0。这个版本重点打造了开源加强，例如，基于 Dragonwell 进行构建、JVM 参数调优、集成了 Prometheus、部署状态多 AZ 强制均匀打散、反对动静配置、平滑扩缩容等革新，在性能、免运维、可观测、高可用和平安等方面做了诸多晋升，SLA 可能达到 99.95%。
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
ZooKeeper 在技术场景上的最佳实际
接下来，给大家介绍下 ZooKeeper 的最佳实际场景，归为了 3 类，别离是：
微服务畛域，代表的集成产品是 Dubbo/SpringCloud
大数据畛域，代表的集成产品是 Flink/Hbase/Hadoop/Kafka
自研的分布式系统，包含大家本人公司外部的分布式系统，对分布式协调有需要，如分布式锁
微服务畛域 - 注册核心
ZooKeeper 在微服务场景外面，次要是用作注册核心，利用了 ZooKeeper 的注册 / 订阅模式，能够看下 Dubbo 在 ZooKeeper 外面的数据结构：
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
增加图片正文，不超过 140 字（可选）
在 Provider 启动时，会向 ZooKeeper 固定门路 providers 上面创立一个长期节点，在这个节点外面存入本机的服务信息，例如，利用名，IP 和端口等，Consumer 启动的时候，监听对应服务下 Providers 的所有子节点，ZooKeeper 会把所有子节点信息被动告诉到 Consumer，Consumer 此时就拿到所有 Provider 的地址列表信息了，Provider 注册到 ZooKeeper 下面的长期节点，它的生命周期和 Provider 与 ZooKeeper 之间建设的长链接时统一的，除非 Provider 被动下线，当 Provider 宕机或者被动下线，这个长期节点就会被删除，那么订阅这个服务的 Consumer 们，会通过 Watch 监听到事件，更新一下地址列表，把它摘除调。
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
在这里有 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 个主节点的状况，这种状况的话，能够客户端在切换的时候，能够尝试等一等，状态稳固之后，再切换。
增加图片正文，不超过 140 字（可选）
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
自研零碎的分布式协调场景
在自研分布式系统的时候，必然会遇到许多分布式协调的问题，ZooKeeper 就像一个万能的工具箱。
针对不同的场景，基于 ZooKeeper 的个性，都能组合成一个解决方案；在写分布式系统的时候，常常须要用到的有这几个性能：
Master 的选举
咱们的零碎须要选举进去 1 个 Maseter 来执行工作；例如 ScheduleX 就是利用 ZooKeeper 做到这个的，Schedulex 的 Worker 节点有十分多，一些工作是非幂等的，只能由一个过程执行，这时候就须要从泛滥的 Worker 当选一个 master 来，实现的形式次要有 2 种：
抢占主节点的形式：约定一个固定的门路，谁往里面写长期节点数据写胜利了，就算当 master，当 Master 宕机后，长期节点会过期开释，ZooKeeper 告诉到其余节点，其余节点再持续往里面写数据抢占。
最小节点形式：利用的是 ZooKeeper 的长期有序节点实现的，如图所示：要进行选主的时候，每台 Server 往目录上面写一个长期有序节点，约定好，序号最小的节点作为 master 即可。
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
分布式锁
在分布式环境中，程序都散布独立的节点中，分布式锁是管制分布式系统之间同步访问共享资源的一种形式，上面介绍下 Zookeeper 如何实现分布式锁，分布式锁次要有 2 种类型：
1、排他锁（Exclusive Locks）：称为独占锁，获取到这个锁后，其余的过程都不容许读写
实现的原理也很简略，利用 ZooKeeper 一个具体门路下只能创立一个节点的个性，约定谁创立胜利了，就抢到了锁，同时其余节点要监听这个变动，长期节点删除了，能够被告诉到去抢（Create）, 这个和 Master 选举外面抢占 Master 节点，是一样的做法：
编辑
增加图片正文，不超过 140 字（可选）
2、共享锁（Shared Locks）：又称为读锁，多个过程能够同时获取这把锁，进行读操作，然而如果要写操作，必须没有读操作了，且本人是第一个获取到写操作类型锁的
实现的形式如图示；读的时候，创立一个 R 的长期程序节点，如果比他小的节点外面没有 W 节点，那么写入胜利，能够读，如果要写，则判断所有 R 的节点中，本人是否最小的即可。
编辑
增加图片正文，不超过 140 字（可选）
增加图片正文，不超过 140 字（可选）
分布式队列
分布式队列最常见的 FIFO（First Input First Output）先入先出队列模型，先进入队列的申请操作先实现后，才会开始解决前面的申请：
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
Zookeeper 实现 FIFO 队列，和共享锁实现相似，相似于一个全写的共享锁模型：
1、获取 /Queue 节点下的所有子节点，获取队列中的所有元素
2、确定本人的节点序号在所有子节点中的程序
3、如果本人的序号不是最小，那么就须要期待，同时向比本人序号小的最初一个节点注册 Watcher 监听
4、接管到 Watcher 告诉后，反复第一个步骤
配置核心
应用 ZooKeeper 作为配置核心，利用的也是 ZooKeeper 的注册 / 订阅模式，这里有个留神点，ZooKeeper 不适用于存储太大的数据，个别不超过 1M，否则容易呈现性能问题。
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
MSE 提供的 ZooKeeper 企业服务
MSE 和 ZooKeeper 的关系
微服务引擎（Micro Service Engine，简称 MSE）是一个面向业界支流开源微服务生态的一站式微服务平台，微服务生态的所有服务都可能在这个平台下面被集成，它提供的引擎都是独立托管的，目标就是为了给大家提供高性能、高可用、高集成、平安的服务，目前，MSE 提供了如下模块：
注册配置核心 -(ZooKeeper/Nacos/Eureka）
云原生网关 -(Envoy)
分布式事务 -(Seata)
微服务治理（Dubbo/Spring Cloud/Sentinel/OpenSergo）
ZooKeeper 和 Nacos 一样，提供注册配置核心性能，然而 ZooKeeper 还提供了分布式协调的能力，利用在大数据畛域。
MSE 提供的 ZooKeeper 企业服务分为根底版和专业版两种，前者实用于开发测试环境和简略的生产环境，后者在性能、可观测、高可用不便做了诸多晋升，接下来，咱们将介绍专业版，相比自建的劣势。
增加图片正文，不超过 140 字（可选）
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
比自建的 ZooKeeper 更稳固和高可用
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
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 分钟复原。
增加图片正文，不超过 140 字（可选）
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
以上的这些，最终都是为了保障 MSE 的稳固高可用，MSE 线上最大规模的一个集群，反对着 40w+ 的长链接，稳固运行了 3 年的工夫，没有呈现过故障，SLA 达到 99.95%。
免运维，提供了丰盛的控制台性能
如果是自建 ZooKeeper 的话，须要做哪些事：
搭建基础设施：把一些根底的设施给筹备齐全，例如 ECS/SLB 等，再做网络布局。
装置 ZooKeeper：装置过程中，要配置很多参数，并对这些参数足够的相熟，否则出问题就抓瞎了，不同的参数，对集群运行时的性能也是有肯定影响的，这都须要要有足够的专业知识，能力胜任。
扩缩容：布局 MyId 的调配，新扩容机器须要自增，否则新机器将无奈退出旧集群同步数据，因为只有 MyId 大的才会去被动连小的去同步集群数据；新节点退出集群，也是有严格的启动程序的，新退出的机器数，必须小于原集群的一半，否则会呈现 master 选在新节点下面，导致数据失落；在退出节点特地多的时候，须要按这个规定反复屡次，少一个步骤，都很容易导致集群选主失败，数据失落，造成线上生产故障。
服务端配置变更：zoo.cfg 中的配置项，更新之后，须要把集群中每台机器手动重启，能力触发失效。
数据管理：开源的 ZooKeeper 没有图形化管理工具，要查看数据，得通过 zkClient 或者写代码查问，操作十分的简单和繁琐，这些都是自建带来的问题。
线上故障解决：例如 ZooKeeper GC 了，或者网络闪断了，这时候就须要相熟 ZK/JVM/ 操作系统的业余运维人员解决了。
而 MSE 提供的 ZooKeeper 企业服务，则将以上问题通过产品化的形式解决了：
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
增加图片正文，不超过 140 字（可选）
须要一个 ZooKeeper 集群的时候，一键购买，3 分钟开箱即用，呈现容量问题时，一键平滑扩缩容，还提供了重置数据、参数白屏化设置等性能，在可观测这块，也提供了罕用的外围默认指标大盘，与之相配套的就是报警了。应用 ZooKeeper 企业服务，省心、省力，进步企业 IT ROI。
可观测性加强
ZooKeeper 专业版的第三个劣势，可观测性的加强：
丰盛的监控大盘：这次专业版和普罗米修斯进行了深度集成，并且给大家收费开启应用，提供了 20 多个 Zookeeper 罕用的监控指标，4 个外围资源监控指标
反对外围告警规定：根本能满足大家日常的运维需要了，当然，如果你还需要的话，能够随时找咱们，给你安顿上
凋谢丰盛 Metrics 规范指标：这次专业版把 ZooKeeper 内置的 70 多个 Metrics 指标，都通过 API 的模式凋谢进来了，对应你们来讲，就可能利用这些数据，本人去绘制监控大盘了，十分的不便
增加图片正文，不超过 140 字（可选）
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
性能晋升
写入性能优化晋升 20%，数据可靠性达 99.9999999%（即 9 个 9）。
ZooKeeper 的写入性能，和磁盘性能有很大的关系，必须要把数据写入到磁盘的事务日志胜利后，才算写胜利，为了晋升写性能，咱们采纳了阿里云 ESSD 高性能云盘，最大 IOPS 可能达到 5W，最大吞吐量 350M/S，数据的可靠性 99.9999999%（即 9 个 9），整个写入 TPS 性能可能晋升约 20%。
基于 Dragonwell 进行构建，读取性能晋升 1 倍
咱们集成了阿里高性能 JDK，开启了外面的协程优化能力，并对 ZooKeeper 的读写工作队列做了锁力度的优化，在高并发解决的场景下，读性能相比开源可能晋升 1 倍左右的性能。
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
GC 工夫升高 80%，大幅缩小 Full GC 的状况
ZooKeeper 是时延敏感型的利用，GC 的工夫和次数，会影响 ZooKeeper 的解决吞吐量，因而咱们针对这种状况，做了 JVM 参数的调优，堆的设置依据不同的配置动静设置，同时提前做了资源碎片的回收，避免出现 FullGC，整体优化下来，GC 工夫升高 80%，同时尽可能的防止了 FullGC。
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
基于 MSE，构建 Dubbo+Zookeeper 微服务
操作之前，须要购买一个 ZooKeeper，能够抉择按量付费，不须要是能够开释，如果长期应用，能够抉择包年包月：
增加图片正文，不超过 140 字（可选）
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
在选择网络拜访形式的时候，以下几种状况：
1、如果你只是应用 VPC 网络应用，你就抉择专有网络，选上交换机和业余网络，其余不必动（这里留神：不要去抉择公网带宽）
增加图片正文，不超过 140 字（可选）
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
2、如果你只是要公网拜访，抉择公网网络，再选上对应的带宽即可；
增加图片正文，不超过 140 字（可选）
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
3、如果须要公网，同时也须要 VPC 网络拜访，那么你抉择专有网络，同时在公网带宽处，抉择你须要的公网带宽，这样就会创立 2 个接入点了；
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
购买之后，大略 5 分钟左右，ZooKeeper 集群就创立胜利了，大家记住拜访形式，等会 Dubbo 配置文件外面须要配置这个地址：
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
环境筹备好了，就筹备 Provider/Consumer 的配置了。欲了解具体的操作步骤，可观看直播视频进行理解：https://yqh.aliyun.com/live/d…
写在最初
MSE 提供的 ZooKeeper 企业服务，旨在为用户提供更牢靠的、老本更低、效率更高的，齐全兼容开源的分布式协调服务。提供后付费和包年包月两类付费模式，反对杭州，上海，北京，深圳等海内外 23 个 region，满足 95% 地区用户。如果你有其余新开服须要，能够分割咱们。
原文链接：http://click.aliyun.com/m/100…
本文为阿里云原创内容，未经容许不得转载。