开发者学堂课程【Dubbo + ZooKeeper 的服务发现最佳实践：Dubbo + ZooKeeper 的服务发现最佳实践】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1012/detail/15069
Dubbo + ZooKeeper 的服务发现最佳实践
内容介绍：
一、MSE- ZooKeeper 介绍
二、ZooKeeper 最佳实践场景
三、微服务动手实践
四、ZooKeeper 后续预告
本课程带来 MSE- ZooKeeper 的一个介绍。介绍 MC 跟主题课的一个关系，以及近期发布上线主题专业版的一个特性的介绍。
然后，再介绍一下 ZooKeeper 的最佳实践的场景，其中包括微服务领域。大数据领域，以及在自研的分布式系统里面，ZooKeeper 可以做些什么事情？
接下来再聊一聊 ZooKeeper 是怎么在微服务体系中注册中心的。通过一个具体的一个动作实践，然后更直观的展示 Dubbo 与 ZooKeeper 是怎末协作的，这样也能够让大家更熟悉的去使用 MSE- ZooKeepe.
一、MSE- ZooKeeper 介绍
第一节 MSE- ZooKeeper 的一个介绍，主要分下面三个模块。第一个，就是 MSE与 ZooKeeper 的一个关系。接下来，就是 MSE- ZooKeeper 的一个整体的演进历程。最后分享一下。ZooKeeper 专业板的一个特性。
1. MSE 与 ZooKeeper 的关系
大家可能会疑问，MSE 与 ZooKeeper 的一个关系。
MSE 的定位是做成一个平台。微服务生态的所有的服务都能够在这个平台上面被集成，然后目前 mse 提供四个大的模块。
第一个，就是我们的一个注册配置中心。
第二个是原生网关
第三个是分布式事物 -seata 。
第四个是微服务治理。
主要这四大块。ZooKeeper 它是属于注册配置中心里面的，它 nacos 是一样的，是为微服务体系里面提供一个注册配置中心的一个功能。但是主课本，它还有另外一个场景，就是做分布式协调的。
它在大数据领域也会有广泛的应用，然后接下来会详细介绍的。然后目前，这些服务在 MSE 里面都是一个独立托管的。
它目的就是为了能够给大家提供一个高性能，高可用，并且是高集成，一个非常安全的服务。
2. MSE- ZooKeeper 历程演进
接下来让介绍一下 MSE- ZooKeeper 演进历程。
现在的 MSE- ZooKeeper 它其实是依托于阿里巴巴集团以前内部一款叫 taokeeper的分布式的一个协调协调组件，它诞生于阿里巴巴2008年的时候，整个阿里内部再做一个服务化的改造，各种各样的一个分支中间键，比如说 h chef，然后conficserver。Pddl 等都是在那个时候诞生的。
在2019年的时候，整个阿里云集团实施了一个全站上云的一个战役，然后所有的产品，都需要升级到一个公有云的一个架构。MSE- ZooKeeper 就是在那个时间点诞生的。
它正式的工作时间是2019年九月份。上线的时候也兼容的开元组织的一个组织的一个版本。
总的来说，MSE- ZooKeeper 经历了三个阶段，
（1）、1.0版本
第一个阶段，就是从08年开始的1.0版本。它主要是支持集团内分布式协调需求的一些应用，那时候所有的业务，都是混着用的，有1000多个应用，最终大概，就是手动应用有大概有150多个工厂的集群。然后随着时间的一个推移，业务都在做一些微服务的一个拆分，然后整体整个共享集训的容量就爆炸式的增长。这样带来的一个问题就是，所有的业务进行了一个混布，爆炸半径是非常大的，整体的稳定性是存在很大的一个风险，一些日常的 zk 的运维，例如机器置换等等。牵一发而动全身，如果在置换过程中出现问题，那就是影响整个阿里所有的业务。
（2）、2.0版本
然后在2.0的演进中，，针对这个问题做的一些改进，那时候刚好是拢聚化兴起的时候。，当时内部讨论过一些拢聚化的一些改造方案对性能的一些影响，以及运维上面能够能带来的一些效率，最终结论，其实就是说。能够满足当时的一些诉求，然后就做了一个大的改造。当时对整体上升的业务进行了一个拆分，然后整体的一个共享集群的一个数据的一个迁移，按照最小运用单元去运维一个集群。然后把爆炸半径就说到最小。这样终于可以睡一个安稳的觉了。拆分完了之后。有个问题，就是 ZooKeeper 的集训数量以前是100多个，然后拆完了之后，整体的运维规模的数量就上来了。就是依托 prometheus 的功能化运维能力，都得到一个很好的一个解决！这样能效一下就上来了。所以说现在，就是整个2.0的版本里面集群其实都是独享模式的，整个资源都是互相隔离的！这时候给用户的 SLA 也都能得到提升能达到99.5%。，
（3）、3.0版本
ZooKeeper3.0，其实重点做的是一个专业版的一个升级，然后，这个版本的特点，它其实就是为了打造相比于自建，会更加突出的一些优势，主要在高可用、免运维、可观测性和性能方面做了很多优化的改造。
例如，提升了 prometheus 一个内部的一个云产品，然后。就是大大增强ZooKeeper 的一个可观测性。同时在部署形态上面，也进行了多 ag 的一个强制平均的打散。
支持动态配置，支持平滑扩缩容。这种我们对用户提供的 jdk，也能跟也更上升了一步，能够达到99.95%！然后具体后面专业版的一个具体的优势，下个章节会分享详细的介绍一下。然后 MSE- ZooKeeper 的一个演进历程主要就是这三个阶段，每一次的升级都是一个自我的一个提升，升华。
3. MSE- ZooKeeper 专业版优势1-（稳定高可用）
然后接下来我给大家介绍一下 MSE- ZooKeeper 的一个专业版，专业版近期已经开始在上线了，现在杭州已经可以用，可以购买了，然后在这个月底推出所有任选大概有23个。假如果有需求，就去支持一下。然后，这个章节介绍一下 MSE- ZooKeeper的专业版的相对于自建的 ZooKeeper 的优势，可以做一个对比。
第一个优势就是比自建的 ZooKeeper 更稳定更高可用，可以看一下下面这个 MSE的一个架构图！
（1）、多 AZ 部署
第一个其实 MSE- ZooKeeper 它是多 az 部署的，也都知道 ZooKeeper 只有过半的节点才能选出组，一个五节点的 ZooKeeper 集群部署在三个可用区的时候，它应该是二二一分布。
那这样任意一个可用区出现了一个故障，如果它整体还是可用的。然后阿里云之间不同的区可能会担心存在的延迟，它的延迟其实是目前是非常低的，小于三毫秒的，所以说这是对 ZooKeeper 本身其实是不会有太大的影响。
（2）、主备高可用，负载均衡，自动摘除故障节点
第二点，就是提供给用户的一个访问的接入点。是提供的一个 single tunnel slb，这个 slb 它其实是一个主被可用的，它会自动对用户的请求做一个负载均衡加。业务测的一些群的压力给平均的分散到后端的节点，然后当节点出现故障的时候，它会自动的去做一个心跳检测，会自动摘除，然后保证用户机器的请求能达到一个正常的节点上面。
（3）、Livesness 探测自动恢复故障节点
第三点就是依托于 k8s 的 Livesnes 的能力，当后端的节点出现故障的时候。这个故障的节点会自动的进行一个恢复，然后及时的保障的服务一个可持续性。
（4）、ZooKeeper 快照备份容灾
第四点。就是对 ZooKeeper 的一个快照提供了一个备份，在集群出现一些非域区的情况下，都就能够快速的恢复重建集中的数据，然后整体保证集的数据的一个安全。
（5）、CoreDns 容灾
第五点就是在 ZooKeeper 内部的集中的运营解析，其实是通过 CoreDns 去作的，那为了保证它的一个高可用，安装 node local dns 开启了一个容灾模式，在CoreDns 不可用的情况下，可以使用 note 的一个本地缓存。然后尽可能的保证域名解析的服务不中断。这是一个架构产品，对整体一个 mse 高可用的一个保障。
在整个研发过程中，也有一套完备的一个稳定性体系。从研发的阶段到最后变更的上线，都有一些对应的一些规范制度，例如，会有变更三板斧，在变更的时候必须要满足可观测，可规格，回归做的情况下才能够上线，否则就会进行打回。
在线上运行的时候，有一系列的一些巡检的组件在线上跑着。例如说检查配置的一致性。检查那个节点的健康状态，检查各种各一些配置之类的。如果巡检发现的问题，立马就会有报警，然后都会进来自己的去解决。
mse 也把故障演练也做到了一个常态化，针对常见的一些故障场景，比如说网络中断，宕机，ecs 宕机等等，都在定期的跑着，保证线上的一个稳定。
在线上应急这一块，也注重做到了一个主动的探测，就是说能够及时发现线上的问题。安排二十四小时人员。有一套一五十的一个应急流程，就是说要求在一分钟内必须发现有些难问题，同时五分钟能够进行一个响应，最终十分钟进行揭露处理。做作的这些都是为了一个保证 mse 的稳定高可用，目前能够达到99.95%这样的一个 sla。mse 现在线上最大规模的一个集群支持着40万的场链接现在线上最大规模的一个集群
4. MSE- ZooKeeper 专业版优势-2（易运维，控制台功能丰富）
从专业版相比于自建，第二个优势就是免运维。同时 mse 的控台提供了许多丰富功能！
来看一下，如果是自建 ZooKeeper 需要做哪些事情？第一步，需要把一些基础设施都给购买齐全！比如说一些 ecs ，slb，当然还要做一些复杂的一些网络规划。当这些基础做完了之后，接下来就要安装 ZooKeeper。按照足够把大家熟悉，应该也是知道它要配置需要非常多的一些参数，要对这些参数要有足够的熟悉，否则出现问题不知道怎么做了。
不同的参数对集群运行时的性能，它也是有一定的影响的，这时候就需要有一些足够专业的知识才能升任这个事情。ZooKeeper 在扩缩容的时候，也是非常的复杂。要提前去规划买 ID 的分配，新扩容器，它必须是买 ID 必须是是真的，否则新的机器就没有办法加入去做一个数据同步。买 id 大的才会主动去联系的去同步集群。新缺点要加入那个老集群。也只有严格的一个其中顺序的。短新加入的机器数数必须小于原集群的一半，否则就会出现 mast 选择新节点上面，这样就会导致。据的一个丢失。如
果要加入节点非常多，那就要按照这个规则要重复多次，少一个步骤都很容易导致集群的选组失败，数据丢失，造成一个线上的生产故障。同时要在做服务端配置变更的时候修改完配置之后，其实每一台机器都得重启当。当出现线上问题的时候，例如出现了 ZooKeeper 的节点的 jvm gc 或者网络闪断了客户端连接连不上。然后这时候要去排查问题，这时候一要需要熟悉 ZooKeeper 操作系统的运营运运维知识。这个成本还是非常大的，一般的公司都应该会很少去配备专门的 ZooKeeper 运维的工作人员。对于公司来讲，其实这是一个一比不小的开支。
在开元的 ZooKeeper 是没有一个图形化管理工具的，要查看数据，必须通过黑屏的下面去执行zk client.sh 这个脚本或者说自己写代码去查询。操作也是非常的复杂和繁琐。而这些的问题话都是自己带来的。
相比于 mac 托管的 ZooKeeper，这些问题我们都把它解决了，把它做成的产品化的功能。无需再烦恼这些，这时候要如果要一个创建一个 ZooKeeper 集群只要一键购买，基本上三分钟左右就可以开箱机用了，但如果出现容量问题的时候，也提供一件平滑扩容的能力，同时还提供的重置数据的能力，服务端的能力也提供了一个打电话的一个设置。在可观测这块，我们也提供了一些常用的核心，默认的一些指标，大盘与之相配套的就是报警。所以说如果相比于之前去使用 mse 托管的图片，相对来说是非常省心的，无论对于研发。给你们两次非常省心的，对于公司老板来讲。就是基本上就是说省很多成本的。毕竟一个专业的运维公司。目前现在也是非常难招的。
5. MSE- ZooKeeper 专业版优势-3（可观测性增强）
然后接下来介绍一下 MSE- ZooKeeper 专业版的一个第三个优势，就是可观测性的一个增强。这次专业版和普通民事进行了一个集成，并且是免费开启给大家使用的，这次默认提供了20多个常用的 ZooKeeper 业务监控指标。
同时有四个核心的一个资源监控指标。然后与之相配到就是警规则的基本上就能满足大家日常的运维需求的，当然，如果你还需要，可以随时找到我们提需求，随时给安排上。另外，这次专业版，也把 ZooKeeper 类似的70多个 metrics 指标，已经通过 open ipad 形式已经开放出去。然后对于你们来讲，基本上都可以利用这些数据，绘制自己的一些大盘，就根据自己业务，自己关注哪些数据，可以就用这些数据去绘制大盘，是非常的方便的。
6. MSE- ZooKeeper 专业版优势-4（性能提升）
然后最后一个优势，第四个优势就是在性能， ZooKeeper 专业版也做了一些事情，相比于之前提升了不少的。
（1）、高性能 essd 云盘
第一个都知道 ZooKeeper 显性能它和磁盘的性能有很大的关系。它必须要把数据写到磁盘里面，就是写入成功之后才算写成功。那为了提成显性能采用了艾琳的essd，ple 的高性能云盘。最大的 lops 能够达到五万，最大的吞吐量能达到 350M每秒。数据可靠性达到了九个九。整一波操作下来整体的tbs有做过性能预测，大概基本上能提升大约20%。
（2）、集成高性能 jdk
第二个，就是集成的阿里的高性能 jdk。然后同时它里面有很多复杂的一些参数，进行参数的调优，开启了一些协程优化，然后热加载机制等等，并对自由批判的内部的一些读写任务队列，做了一个有锁粒度的优化。在高并发场景下，性能能相比开源能够提升大概100左右的。
（3）、jvm 的参数调优
第三个，就是都知道 ZooKeeper，其实是一个时间敏感型的一个应用它的时间和次数，实际是会影响作品的一个存储量的一个处理的，因此针对这种情况也做，对这些物品参数也做了一些调优。相对的一些设置可以根据不同的大小进行动态配置。总之，也做一些资源碎片的一些体现了一个回收，避免它出现过 gc，整体优化下来相比默认参数，能够大约节省五倍的时间。同时，也就是最大可能的避免了一个fullgc。
然后 ZooKeeper 的专业版的优势介绍完了。
二、ZooKeeper 最佳实践场景
接下来介绍一下 ZooKeeper 的一个最佳实践场景。把它归类为三类。分别是在微服务领域里面，它代表做产品是 Dubbo，Spring Cloud。在第二个是大数据领域代表的集成作品是 Flink ，Hbase ，Hadoop。那剩下就是统类为自研的一些分布式系统，包括阿里它内部的自研分布式系统像 Schedulex，精卫等等。
它都跟 ZooKeeper 做了一些集成。详细的介绍一下 ZooKeeper 在这三个场景里面是如何工作的，起了一些什么作用？
1.微服务领域
ZooKeeper 在微服务场景里面，它主要的作用就是用作微服务场景里的注册中心的功能利用了 ZooKeeper 的注册订阅模型。同时它足够的临时节点的一个特性。
（1）、注册
在 provide 启动之后，它会向 ZooKeeper 创建一个临时节点。然后在这个节点里面存入自己的一些基本的服务信息，例如应用的名字，然后IP，端口还有一些常用的参数，比如说超速参数。自由参数等等。
（2）、订阅
然后 consumer 在消费 provide 的时候。它会通过 ZooKeeper 先拿到 provide 的信息，然后拿到它的地址列表，它会监听服务名下面所有的子节点，当有新的provide上线的时候，所有的地址也都会聚合到这个服务下面。然后 ZooKeeper 会主动通知到订阅的这个服务的 consumer 去更新地址列表。
（3）、下线
provide 做得到 ZooKeeper 上面的那个临时节点，它的生命周期和 provide 跟ZooKeeper之间出现了一个长链接的，它的那个生命周期跟这个长链接生命周期其实保持一致的，除非是 provide 主动下线。比如说 provide 要么是宕机，要么主动下线了，那这个临时点就会被删除。当订阅的这个服务的这些 consumer 它会通过jk里面的 watch 机制去监听下面所有的子节点。当 Provide 变化，比如说下线，上线之后，然后jk就会主动去把它通知到 consumer 侧，然后 consume 侧如果发现它是有 provide 下线就会把它摘除。
（4）、注意
在这里有两个注意的点，就是说注册到 ZooKeeper 的服务数据，不要太长，如果是provide 和 consumer 数目非常多的情况下，并且如果伴随着很频繁的上线下线，这样非常容易导致 ZooKeeper 的一个 full GC，这种情况在日常工作中很常见。Dubbo框架其实是有这个问题的。后面会详细的讲解。
现在第二个点，就是 provide 它一般正常它正常下线，可能中断网络或者说正常的调用下线接口，但是当出现一些非正常的情况下，比如说网线突然被踢掉，这时候，就是 provide 注册在 ZooKeeper 上面的临时节点，它其实感知不到这是网络的变化的，它存在的生命周期取决于什么？
它会有一个心跳去探测那个就是申请的健康状态。它的生命周期取决于session time out 设置的时间，session time out 如果长的话，这个临时节点它留的时间也就越长，这个长短可以根据自己的业务可以进行一个设置，如果是非常敏感，那可能就时间设短一点。这个是在微服务场景下面的一个应用，做出的中心。
