nacos迁移及踩坑历程

背景：将内部使用的nacos迁移到新的服务器nacos；新版本：2.2.0

开发环境：nacos  1.1.0

       因为开发环境都是组内成员使用，所以采用冷迁移的方式（简单来说就是不考虑任何服务宕机问题直接硬迁）：

       直接将服务注册地址更改为新的服务地址，不考虑别人使用情况，内部成员一起硬迁，避免因迁移问题导致其他使用成员服务异常。（这里就涉及测试和生产如何解决问题）

测试环境：1.1.0

发版工具：坎特

     模拟生产迁移，因为测试环境无论是对接还是测试老师都在使用，不能因为个人原因影响测试进度或对接进度。

     1.保证原有服务的可用，采用热启动（双注册双发现）的方式，下载polaris代理包放到指定路径，供坎特发版引入实现双注册（原nacos及新nacos）。这时候是不是就考虑请求是打在原nacos上还是新的nacos，可以通过测试进行验证，当然是原nacos，因为代码中指向的节点还都是原来的nacos，那如果下线的话，只能下掉原nacos服务，新的nacos是下不了的；这时候还要考虑如果将代码中某个服务的配置信息更改为新nacos节点会出现什么情况？答案是：服务不可用，它是找不到其他服务的，并且原有依赖它的服务也会因为找不到这个服务而不可用。

     2.保证所有服务都迁移完成（这一点非常重要否则到了生产直接GG，我们都是excel表进行统计多人同时操作再三确认），为什么要等到所有服务都注册进来呢？就是为了新nacos（集群）各服务之间是通的，完成以后修改代码配置新的nacos信息及相关配置信息（这里面也是非常关键包括坎特发版中的配置信息：命名空间、服务名等），这样就可以直接一个服务一个服务的迁移到新的nacos（双注册双发现）。

常见问题：

       1.根据需要升级spring-cloud-alibaba-XXX服务发现版本升级为2.1.4，否则注册不上。版本匹配问题。为了提高集群的稳定性及降低cpu的使用率，将spring-cloud-alibaba-XXX升级到2.2.9，因为之前版本对应nacos-client版本为1.4.1，而现在对应的版本号为2.1.0。nacos服务端与nacos客户端对应关系，spring-cloud-alibaba-XXX与nacos-client对应关系，都影响nacos使用性能。

       2.生产发版工具是坎特及jekins，由于生产环境nacos版本是1.1.0版本，在测试环境无法测出问题导致生产无法注册问题，坎特和jekins发版首先进行的是下线操作，之前版本发版超过就会自动上线状态，但是新的nacos会对下线操作emtadata缓存。默认60秒，导致还是下线操作，这个问题有很多解决方案？比如：修改默认值（由于用的腾讯云的所以不支持修改），运维掉api进行上线操作（都不想因为你的任务，别人去负责）、延长发版时间等，所以我们自己写了一个新的nacos客户端包，监听服务是否上线，如果没有上线则调用api上线操作。每一个服务都要引入这个服务注册依赖，去掉之前的。
       3.之前提到的polaris因为默认注册到public命名空间还要对其进行修改。
       4.整个流程，从头到尾不知道反复测试大概一个月的时间，因为还有其他开发任务，只能业余时间处理，在加上反复踩坑，尤其是测试完成灰度验证失败的时候是最绝望的，还要排查还要重新测试，重新走一遍。
       5.最重要的是一定要保证服务可用，并且每走一步都要进行验证是否与自己想的一样，否则一步错，步步错。