“0代码”实现滚动升级不断服

升级不断服存在的问题

要实现升级不断服，通常需要解决如下问题：

1. 停止服务的时候，可能引起业务中断。在停止服务的过程中，可能服务正在处理请求，新的请求可能持续的发送到该服务。

2. 在微服务架构下，一般都会通过注册中心进行服务发现，客户端会缓存实例地址。停止服务的时候，使用者可能无法及时感知实例下线，并继续使用错误的实例进行访问，导致失败。

3. 新服务启动起来后，会存在灰度状态，出现多个版本并存，如果新服务新增加了接口，新升级的服务需要正确的将流量发送到包含新接口的服务。

4. 成本：实现升级不断服，可以先准备大量的备份机器，将新服务启动起来。然后对用户的请求进行引流，待老服务没有流量后，停止老服务。这需要运维人员准备额外的集群资源并开发强大的运维监控系统来完成。

使用CSE框架，可以以极低的成本，不借助运维工具，就能够轻松的实现升级不断服

 

使用CSE进行滚动升级的实践和评估

在讨论不断服的时候，需要先设计一个测试评估模型。为了简单，采用下面测试场景来进行评估。调用者通过网关来访问应用实例1和应用实例2，现在要对应用实例进行升级。升级的过程中，调用者会启动N个线程，以Mtps的流量来请求。我们可以以整个升级过程出现的失败次数来评估系统对于不断服升级的支持好坏。为了节省资源，我们采用先停止1.0版本的实例1，然后部署2.0版本的实例1；再停止1.0版本的实例2，最后部署2.0版本的实例2。另外，我们还需要构造服务端处理时延T&#