方案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+服务来说，不可能一个服务一个服务地手动配置。于是开发一个全量的配置，这个倒是不难，但很有用。
===============================================================================
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中。
起初我们搭建了包含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稍微高一点，没有很多。这可是单个心跳发送，能这样已经很不错了，这样就说明就算服务全部迁移，也可以接近批量发送的效率。
=======================================================================
在尝到了长连接优化心跳的甜头后，针对几个重要的接口，如服务注册，服务拉取等都改为了长连接，而且针对DNS-F也适配了长连接，效果很好，达到我们对nacos性能的预期。
=====================================================================
nacos提供了优雅下线的接口，即下线某个服务，但是是针对实例纬度的，对于公司内部的发布系统不是很友好，发布系统不知道机器中有什么服务，于是需要提供一个ip纬度的下线接口，也可以理解为一个批量下线接口，实现时同批量心跳接口，也需要注意处理distro协议。
总结
就写到这了，也算是给这段时间的面试做一个总结，查漏补缺，祝自己好运吧，也希望正在求职或者打算跳槽的 程序员看到这个文章能有一点点帮助或收获，我就心满意足了。多思考，多问为什么。希望小伙伴们早点收到满意的offer! 越努力越幸运！
金九银十已经过了，就目前国内的面试模式来讲，在面试前积极的准备面试，复习整个 Java 知识体系将变得非常重要，可以很负责任的说一句，复习准备的是否充分，将直接影响你入职的成功率。但很多小伙伴却苦于没有合适的资料来回顾整个 Java 知识体系，或者有的小伙伴可能都不知道该从哪里开始复习。我偶然得到一份整理的资料，不论是从整个 Java 知识体系，还是从面试的角度来看，都是一份含技术量很高的资料。
伙伴们早点收到满意的offer! 越努力越幸运！**
金九银十已经过了，就目前国内的面试模式来讲，在面试前积极的准备面试，复习整个 Java 知识体系将变得非常重要，可以很负责任的说一句，复习准备的是否充分，将直接影响你入职的成功率。但很多小伙伴却苦于没有合适的资料来回顾整个 Java 知识体系，或者有的小伙伴可能都不知道该从哪里开始复习。我偶然得到一份整理的资料，不论是从整个 Java 知识体系，还是从面试的角度来看，都是一份含技术量很高的资料。
[外链图片转存中…(img-ueAevziS-1714713131706)]
665
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
