技术分享——zookeeper到nacos的迁移实践
写在前⾯：2020年⾯试必备的Java后端进阶⾯试题总结了⼀份复习指南在Github上，内容详细，图⽂并茂，有需要学习的朋友可以Star⼀下！
技术选型
公司的RPC框架是 dubbo ，配合使⽤的服务发现组件⼀直是 zookeeper ，长久以来也没什么⼤问题。⾄于为什么要考虑换掉zookeeper，并不是因为它的性能瓶颈，⽽是考虑往 云原⽣ ⽅向演进。
云原⽣计算基⾦会（CNCF）对云原⽣的定义是：
云原⽣技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运⾏可弹性扩展的应⽤。云原⽣的代表技术包括容器、服务⽹格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的⾃动化⼿段，云原⽣技术使⼯程师能够轻松的对系统作出频繁和可预测的重⼤变更。
想要落地云原⽣，关键步骤就是 mesh化 ，当前主要讨论 service mesh （服务⽹格），⼀句话形象描述service mesh
service mesh是微服务时代的TCP协议
服务⽹格相对于当前的微服务最明显的优势是下沉基础设置，让服务治理和业务开发分离。
举个简单的例⼦，如果在微服务架构中想要做好服务治理，不得不引⼊⼤量的第三⽅组件，如限流、熔断，监控，服务发现，负载均衡、链路追踪等等⼀系列组件，⽽这些组件⼤概率需要以jar包的形式被业务代码依赖，甚⾄不同的开发语⾔还得维护不同的组件，业务和基础设施耦合让服务治理变得异常困难。
service mesh处理服务间的通信，通常由⼀系列⽹格代理组成，对应⽤程序透明。服务治理中的⼀切（包括但不限于上述的限流、熔断、监控、服务发现等）都可以下沉到⽹格代理中。
说了这么多，跟替换zookeeper有什么关系呢？
dubbo的设计中有三⼤组件：服务提供者（provider），服务消费者（consumer），注册中⼼（registry）。
provider启动后往registry注册它提供的ip、端⼝、服务名、⽅法名等信息，consumer发起调⽤时通过服务名、⽅法名从registry查到对应的ip和端⼝发起远程调⽤。
⽽在云原⽣体系下的服务注册与发现机制与dubbo的服务注册发现机制有很⼤区别，云原⽣是基于容器编排，主流的 k8s 服务注册发现是基于 DNS ，也就是通过⼀个域名查到⼀个对应的ip。
这样⼀来，如果要迁移dubbo服务到云原⽣体系中就很艰难，有没有⼀款兼容两种服务注册发现的组件？经过调研nacos就是。
⾸先nacos和zookeeper⼀样，提供了传统微服务的注册与发现⽅式，其次nacos还提供了基于coreDNS的插件DNS-F（DNS
filter），DNS-F作为⼀个代理拦截主机上的DNS请求，如果该服务在nacos上能到则直接返回注册的ip，否则继续查DNS。
完成后，我们的service mesh架构⼤致如下
⽹格内外的访问策略如下：
⽹格外dubbo -> ⽹格内dubbo：注册中⼼
⽹格外dubbo -> ⽹格外dubbo：注册中⼼微服务注册中心有哪些
⽹格内dubbo -> ⽹格外dubbo：域名 => dns-f => 注册中⼼
⽹格内dubbo -> ⽹格内dubbo：域名 => dns-f => dns
异构语⾔（PHP、Node）可通过服务名直接发起调⽤，由DNS-F拦截，解析为正确IP地址，且负载均衡策略可调整
同时nacosAP模式的⾼可⽤与写的可扩展性、可对接CMDB等等特性也是选择的考虑因素之⼀。
迁移⽅案
如果要从zookeeper平滑地迁移到nacos上，可选的⽅案有两个：
改造dubbo应⽤，将服务注册改为双注册（同时注册到zookeeper与nacos），等所有应⽤改造完成后再统⼀切换到nacos
使⽤迁移⼯具，将zookeeper上注册的服务统⼀迁移到nacos，这时再慢慢修改应⽤，不必等完全迁移完即可享受nacos带来的新特性
⽅案1实现上来说简单，但改造成本较⼤，⼀些⽼旧⽆⼈维护的服务迁移起来困难，甚⾄公司层⾯还有PHP，node等服务也依赖了zookeeper，不可能⼀次性迁移完成。
⽅案2需要⼀款强⼤的迁移⼯具，增加了技术的复杂度，好在nacos提供了 nacosSync 。
当然，我们选择了⽅案2，同时做了⼀点点优化。为了降低迁移风险，基于dubbo优秀的扩展性，定制了⼀套 态注册中⼼ ，动态注册中⼼在服务启动时从配置中⼼读取配置，选择是往zookeeper还是nacos注册（或者都注册），服务消费时是选择nacos还是zookeeper，消费只能指定⼀个注册中⼼。
默认情况下会往两个注册中⼼同时注册，消费zookeeper，引⼊jar包后业务⽅⽆感知，切换时只需要变更配置，下次发布即可改变注册和消费的注册中⼼，⽀持针对单个应⽤进⾏配置，便于灰度。
迁移⼯具优化
nacosSync的原理很简单，如果是zookeeper同步数据到nacos，启动时nacosSync作为⼀个zookeeper客户端，将zookeeper上的所有服务拉下来，解析为nacos的服务格式，注册到nacos上，同时监听每个服务节点，有变化时对nacos数据进⾏更新。
单向同步策略
nacosSync可实现从zookeeper到nacos的双向同步功能，但我们觉得双向同步有风险，毕竟nacos是个新东西，稳定性不敢保证，如果nacos中的数据有误，同步到zookeeper上就会带来⽣产上的故障。于是采取了⽐较保守的zookeeper到nacos的单向同步策略。
⾼可⽤
作为需要长期在线的迁移⼯具，需要保证它本⾝的稳定性和⾼可⽤，试想如果如果迁移⼯具宕机，导致所有的服务都将从nacos上掉线，这将是⼀个毁灭性的打击。nacosSync将数据存储下沉到数据库，组件本⾝是⽆状态的，可部署多台，防⽌单点故障。但也带来另外的问题，部署N台对nacos服务端的
压⼒为N倍，因为⼀个服务会被注册N次，修改后也会被更新N次，这块的优化后⾯会说。
全量同步⽀持
nacosSync不⽀持全量的同步，只能单个服务单个服务的配置，对于有3k+服务来说，不可能⼀个服务⼀个服务地⼿动配置。于是开发⼀个全量的配置，这个倒是不难，但很有⽤。
zookeeper事件乱序处理
nacosSync在监听zookeeper的节点后，当zookeeper节点发⽣变更，nacosSync将变更后的数据同步到nacos。
但在测试过程中我们发现⼀个问题，dubbo服务下线后，如果是没有优雅地下线（如进程被kill -9），会在⼏秒⾄⼏分钟内（取决于配置）被zookeeper踢掉节点，如果这时服务重新注册，可能会存在节点remove事件较新节点add事件后到达，这会导致⼀个很重要的问题，新注册上来的服务，被旧的remove事件下线。
解决⽅案也⽐较简单，dubbo注册节点的信息中存有毫秒级的 timestamp 信息，每次处理事件时将⽐较timestamp，如果⼤于等于当前值，则认为此次事件有效，否则认为此次事件是旧事件，丢弃不处理。
通过这样的逻辑判断后就再也没有出现此类问题。
主动⼼跳检测
由于nacosSync部署两台，万⼀某服务下线时，其中⼀台nacosSync发⽣了未知异常，会导致该服务不可⽤，但⼀直在nacos上存在，这时发起调⽤将会报错。
为了避免这种情况，在nacosSync中新增了对机器端⼝的检测，每隔⼀段时间对所有机器进⾏建连接，如果失败，再去看zookeeper中该节点是否存在，不存在再剔除该机器。
为什么不能在⼼跳检测失败后直接剔除？因为有时候服务器会拒绝连接或者超时，但这时服务还在线，
所以还是以zookeeper中为准。⾄于为什么不直接扫描zookeeper，也是出于对zookeeper性能的担⼼，万⼀扫挂了zookeeper，可是个⼤故障。
nacos优化
迁移⼯具优化的差不多了，就开始将所有线上服务同步到nacos中。
起初我们搭建了包含3个节点的nacos集，结果由于服务数量太多，导致nacos机器的cpu长期处于⾮常⾼的值，超过50%。这⾥给出⼀组数据作为参考：
服务数：3k+
服务实例数：30k+
nacosSync节点数：2
nacos节点数：3（50%~80%cpu利⽤率）
监控完善
如何优化？⾸先出性能瓶颈，nacos原⽣基于spring-boot做了监控，但是很鸡肋，没有想要的数据，
于是从客户端和服务端两个维度对监控做了完善，这⾥列出我认为⽐较重要的⼏个监控指标
nacos服务端：cpu占⽐，服务数，实例数，接受请求数量（区分api），请求响应时间（区分api），⼼跳处理速度，推送耗时（原⽣），推送量（原⽣）
nacos客户端：请求量（区分api），请求耗时（区分api），⼼跳发送速度
⼼跳优化
在上述监控完善之后，⼀眼就能看出瓶颈，⼼跳请求实在是太多了，99%的请求都是⼼跳请求。
这与nacos和dubbo的设计有关，dubbo注册是服务维度，⼀个ip注册了很多服务实例，⽽nacos的⼼跳以实例为纬度，⽽且默认的是⼀个实例5秒⼀个⼼跳。
接近40k的实例，每5秒就有40k的⼼跳请求，换算成qps就是8k/s，⽽且使⽤了两台nacosSync，也就是双倍的⼼跳请求16k/s，⽽且是http请求，节点内部还有数据同步的任务，cpu不⾼才怪。
于是我们想了⼀系列办法来优化：
调整⼼跳间隔
⼼跳时间调整为默认的两倍，即10秒，同时也调整了节点⽆⼼跳下线时间（30s调整为60s）牺牲了实例下线检测的实时性。
扩容
将nacos服务端从3台扩容到5台，效果有，但不明显。
减少⼼跳
由于我们是需要逐步迁移服务，迁移后的服务，如果服务本⾝发送⼼跳，2台nacosSync也发送⼼跳，迁移后的服务就有三倍的⼼跳请求了，同时这样也导致了服务下线后万⼀有⼀⽅未剔除，服务仍在线的风险。
于是在前⽂提到的动态注册中⼼中对往nacos上注册的服务，增加了⼀条元数据信息 withNacos=true ，再修改nacosSync的逻辑，忽略zookeeper同步过来的带withNacos=true的服务。这样只要迁移过的服务只会由服务本⾝发送⼼跳，减少⼼跳请求。
合并⼼跳
nacosSync中注册了⼤量的服务，通过前⾯的计算得知每秒约发送8k左右⼼跳，这部分⼼跳如果可以合并，将⼤量减少⼼跳的⽹络消耗，服务端批处理也能加快速度。
在实现合并⼼跳前需要理解nacos AP模式下的distro协议，这部分可以参考 《nacos的⼀致性协议distro介绍 》
简单概括⼀下单条⼼跳的处理路径：
客户端随机⼀台nacos节点对某⼀个服务实例发⽣⼼跳，由于每个nacos服务端节点只负责部分服务，当它收到请求后判断是否为⾃⼰负责的服务，如果是则处理，如果不是则转交给负责的节点。
单条⼼跳路由⽐较好处理，如果合并服务发送⼼跳，就需要在服务端将收到的请求按负责的节点进⾏分类，分类完只处理属于⾃⼰的服务，对于不是⾃⼰的服务则批量转交给其他节点。需要注意处理来⾃客户端还是服务端的请求。
客户端是将需要⼼跳的对象缓冲到队列中，每秒钟从队列中读取出⼀批进⾏批量发送，需要注意算好这个缓冲的⼤⼩设置，如果太⼩，可能会丢失⼼跳，太⼤就太消耗内存。
合并后的效果⽴竿见影，不仅服务端的cpu由50%+下降到10%以内，nacosSync的cpu消耗也下降了⼀半。
只保存了这张图，当时cpu还在20%左右是因为有个bug，解决后cpu就到10%以内了。
长连接
到这⾥其实⼼跳问题只解决了⼀半，因为在nacosSync中有⼤量服务时，批量⼼跳才效果⽐较明显。如果是迁移后的服务，单机只有10个实例，⼀秒内也攒不了⼏个⼼跳请求，所以效果肯定⼤打折扣。于是分析了可能是http请求的建⽴连接，以及每个请求都要⾛很长的web filter⽐较消耗性能，于是想看看修改为长连接之后的效果。
为了快速验证猜想，只修改⼼跳接⼝，这个接⼝量最⼤，搞定它能解决80%的问题。
长连接使⽤什么来实现，当初考虑的有netty和grpc两个⽅案。为了快速验证，锁定了 grpc ，同时上⽂中提到的DNS-F其实也是⼀个nacos的客户端，它是go语⾔实现，刚好原⽣⽀持grpc，所以毫不犹豫就⽤grpc实现了⼀版。
使⽤配置来选择使⽤原⽣⼼跳、批量⼼跳、grpc⼼跳。
实现长连接中遇到了⼀个问题是distro协议中将⼼跳转发给负责的节点，原⽣是内部中转，如果长连接也这样实现就⽐较复杂，需要维持集内部的长连接。考虑逻辑写进客户端，和redis⼀样，当不是⾃⼰负责的服务时，将请求 redirect 给负责的节点，客户端重新发起请求。
初始时客户端随机挑⼀个节点发送，如果收到redirect，则缓存住该服务的⽬标节点，下次遇到redirect或者报错时再清空缓存，这样就能保证选择节点的正确性，只要服务端节点没有变化，客户端就能⼀次命中节点，简单⾼效，同时这个逻辑也不是很复杂，在DNS-F中实现也⽐较简单。
最后的测量结果是，如果nacosSync全量使⽤grpc⼼跳，会⽐批量⼼跳cpu稍微⾼⼀点，没有很多。这可是单个⼼跳发送，能这样已经很不错了，这样就说明就算服务全部迁移，也可以接近批量发送的效率。
关键接⼝长连接

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。