基于nacos系统平滑上下线方案
所谓平滑上下线简单说就是系统发版升级过程对用户无感知，不至于等到夜深人静的时候偷偷去搞，某些请求时间可以长点，但不能失败。
一、系统架构介绍
Springboot2.1.5 +springcloudGreentich.SR1 +naocs2.1.4
二、备选方案
方案一
基于naocs提供的SDK接口进行服务的注销|注册
在对应服务中新增注销服务的接口代码如下：
系统升级步骤：
a、在系统升级前先调用注销接口将目标服务实例注销，服务实例列表中将会删除该实例
b、注销之后将这个实例服务进行打包部署
c、部署后，调用服务注册接口将该服务重新注册
d、重复a、b、c完成服务的平滑升级过程
缺点：
需要开发人员手动增加服务注销|注册的接口
存在时间窗口，服务实例状态变化感知不实时
方案二
基于nacos的console上下线功能
系统升级步骤：
a、在系统升级前先在nacos的console管理台将对应实例的服务下线
b、服务下线之后，请求不会再分发到这个实例上来，对服务进行打包部署
c、启动之后，服务上线完成服务的平滑升级过程
d、重复a、b、c完成服务的平滑升级过程
缺点：
服务实例依然存在，只是负载均衡器进行了过滤，通过实例IP还是可以访问得到
存在时间窗口，服务实例状态变化感知不实时
两者有个共同的缺点-存在时间窗口问题
这个是由于ribbon缓存机制造成的，它维护本地一份服务列表信息，需要本地轮询，或心跳机制服务端推送来更新服务列表
解决方案，将spring.cloud.nacos.discovery.watch-delay=xx参数设置到一个合适的大小，可以缩短这个窗口期
方案三
我们知道nacos实现了服务权重的功能，可以在控制台自由编辑，且实时生效，基于此诞生第三种方案
系统升级步骤
a、升级前先将目标服务的权重调节至0，这时流量将会被截断，请求不会分发到该实例上来
b、进行打包部署
c、部署后将该实例权重调节至合适值，完成系统平滑升级过程
d、重复a、b、c完成服务的平滑升级过程
优点：
没有前面两种方案的时间窗口问题
三、方案选择
综上所述，采用方案三实现系统平滑上下线能力
四、效果测试
有两个要求：
1）ServiceA下线一台实例后，gatewat网关的调用不能失败
2）ServiceB下线一台实例后，ServiceA的Feign调用不能失败
启动三个服务分别是
gateway 8001
demo-service1 8785 权重 1
demo-service2 8786 权重 1
测试连接http://网关IP:8001/unicorn-demo-service/demo/info
模拟服务升级的过程
1、首先将demo-service1的权重设置为0
此时再访问测试连接，发现不在接受请求，所有的请求处理都分发给了demo-service2
2、对服务进行升级，重新部署，并启动完成
3、将demo-service1的权重设置为1,此时再访问测试连接，发现该实例接受到请求，并且是升级之后的逻辑
4、重复1、2、3，对demo-service2做同样的处理，再次访问测试连接，发现两台实例均接受请求，并且达到升级后的效果
5、完成平滑升级
