微服务滚动发布 | 优雅且丝滑

业务背景

众所周知，在我们迭代业务需求和Fix Bug时往往需要重启我们的服务，在高并发场景下，如果还像N年前一样，通过上机操作敲Linux命令执行Kill操作，在分布式环境下显然会让你敲断手指，并且这种方式重启还会影响用户的操作，导致一些线上事故，所以，在微服务、分布式系统中，平滑滚动发布无疑是非常重要的(主打的就是一个丝滑)。

SpringCloud微服务架构导致发布的一些弊端

1.Nacos组件导致的一些弊端

众所周知，Nacos利用心跳机制每隔一段时间(可配置,defalut:30s)服务端与客户端都会互相发送心跳包，当服务端接收到的客户端心跳包有异常情况时，Nacos服务端会剔除客户端在服务端中的注册信息，意味着这个服务是不可用状态，这种方式其实是有弊端的，这其实也是心跳机制的弊端，比如我服务A重启了，Nacos服务端并没有马上感知服务A的异常情况，这个时候还认为其是可用状态，这个时候如果有流量打进来，通过负载均衡很明显会有流量进入到服务A，无法即时感知客户端异常，就是它的最大弊端。

2.SpringCloud Gateway组件导致的一些弊端

SpringCloud Gateway组件对比以前的Zuul网关，在性能和吞吐提升了很多，主要是因为它是基于Spring5.0+SpringBoot2.0+Spring Reactor,没错看到Reactor你就会想到性能强悍的Netty，SpringCloud Gateway正是用了这一高性能通信框架。

提到网关，第一我们要想到的就是负载均衡机制，之前面试过不少后端的兄弟，你们的系统怎么做的负载均衡，他们中多数人的回答是使用了Nginx的负载均衡机制，我...，咱不废话，接着说SpringCloud Gateway的负载均衡机制,当使用Ribbon作为负载中间件时会使用定时线程从Nacos注册中心拉取服务列表然后放到Gateway服务的本地缓存中，拉取时间默认也是30s，同样的也是无法及时感知Nacos注册中心的服务异常情况，所以其实很多人在使用SpringCloud Gateway中会经常出现一些500，503等问题，下面我将针对这些组件的弊端做一个完善解决方案。

针对Nacos与GateWay弊端的解决方案