前言
在生产环境中，随着云原生架构的发展，自动的弹性伸缩、滚动升级、分批发布等云原生能力让用户享受到了资源、成本、稳定性的最优解。但是在应用的缩容、发布等过程中，由于实例下线处理得不够优雅，将会导致短暂的服务不可用，短时间内业务监控会出现大量 io 异常报错；如果业务没做好事务，那么还会引起数据不一致的问题，那么需要紧急手动订正错误数据；甚至每次发布，您需要发告示停机发布，否则您的用户会出现一段时间服务不可用。没处理好服务实例下线，无论发生上述哪种情况，都会对您业务的连续性造成困扰。
对于任何一个线上应用，如何在服务更新部署过程中保证业务无感知是开发者必须要解决的问题，即从应用停止到重启恢复服务这个阶段不能影响正常的业务请求，这使得无损下线成为应用生命周期中必不可少的一个环节。
同时在多次 Dubbo Meetup 中，平滑上下线一直都是位居微服务开发痛点前 Top 3。
下面我们来了解一下 Spring Boot 2.3 中提供的新特性 Graceful Shutdown，来分析一下它对我们生产稳定性带来什么样的帮助。
Spring Boot graceful shutdown
Graceful shutdown
Graceful shutdown is supported with all four embedded web servers (Jetty, Reactor Netty, Tomcat, and Undertow) and with both reactive and Servlet-based web applications. When enabled using server.shutdown=graceful, upon shutdown, the web server will no longer permit new requests and will wait for a grace period for active requests to complete. The grace period can be configured using spring.lifecycle.timeout-per-shutdown-phase. Please see the reference documentation for further details.
Spring Boot 2.3.0.RELEASE引入了Graceful Shutdown的功能。其中应用在等待下线期间对待新请求的方式，取决于我们所使用的 Server 类型。根据官方文档Tomcat、Jetty 和 Reactor Netty将会在网络层面停止接收新的请求。Undertow 会继续接收新的请求，但立即会以 HTTP 503（服务不可用）来响应。
配置与使用
在Spring Boot 2.3.0中，优雅停机的使用非常简单，可以通过在应用程序配置文件中设置两个属性来进行。
1、 server.shutdown 属性可以支持的值有两种
- immediate 这是默认值，配置后服务器立即关闭，无优雅停机逻辑。
- graceful 开启优雅停机功能，并遵守 spring.lifecycle.timeout-per-shutdown-phase 属性中给出的超时来作为服务端等待的最大时间。
2、spring.lifecycle.timeout-per-shutdown-phase 服务端等待最大超时时间，采用java.time.Duration格式的值，默认30s。
例如：Properties 文件
1、#To enable graceful shutdown
2、server.shutdown=graceful
3、#To configure the timeout period
4、spring.lifecycle.timeout-per-shutdown-phase=20s
当我们使用了如上配置开启了优雅停机功能，当我们通过SIGTERM信号关闭 Spring Boot 应用时
1、 此时如果应用中没有正在进行的请求，应用程序将会直接关闭，而无需等待超时时间结束后才关闭。
2、此时如果应用中有正在处理的请求，则应用程序将等待超时时间结束后才会关闭。如果应用在超时时间之后仍然有未处理完的请求，应用程序将抛出异常并继续强制关闭。
源码实现分析
我们以 Tomcat 为例看一下是SpringBoot 2.3如何实现graceful shutdown的
这里注意下，Tomcat 9.0.33或更高版本，才具备graceful shutdown功能。
我们看一下 SpringBoot 的 TomcatWebServer 的实现，先看其中构造函数
1、org.springframework.boot.web.embedded.tomcat.TomcatWebServer
2、public TomcatWebServer(Tomcat tomcat, boolean autoStart, Shutdown shutdown) {
3、 Assert.notNull(tomcat, "Tomcat Server must not be null");
4、 this.tomcat = tomcat;
5、 this.autoStart = autoStart;
6、 this.gracefulShutdown = (shutdown == Shutdown.GRACEFUL) ? new GracefulShutdown(tomcat) : null;
7、 initialize();
8、}
可以看到当我们配置 server.shutdown=graceful 时，其中 gracefulShutdown 成员就不为null，而是被置为 GracefulShutdown 实例。
当我们关闭SpringBoot的应用容器时，会触发其生命周期的 stop 方法，我们看到其中会执行webServer的shutDownGracefully方法
因为我们配置 了server.shutdown=graceful ，所以 gracefulShutdown 成员并不为null，而是会触发 gracefulShutdown 的 shutDownGracefully 方法
我们看一下shutDownGracefully 方法是如何做到graceful shutdown的
来看一下doShutdown的逻辑
org.springframework.boot.web.embedded.tomcat.GracefulShutdown#doShutdown
private void doShutdown(GracefulShutdownCallback callback) {
List<Connector> connectors = getConnectors();
connectors.forEach(this::close);
try {
for (Container host : this.tomcat.getEngine().findChildren()) {
for (Container context : host.findChildren()) {
while (isActive(context)) {
if (this.aborted) {
logger.info("Graceful shutdown aborted with one or more requests still active");
callback.shutdownComplete(GracefulShutdownResult.REQUESTS_ACTIVE);
return;
}
Thread.sleep(50);
}
}
}
}
catch (InterruptedException ex) {
Thread.currentThread().interrupt();
}
logger.info("Graceful shutdown complete");
callback.shutdownComplete(GracefulShutdownResult.IDLE);
}
先是关闭掉所有的连接，在网络层停止接受请求，然后再等待所有请求处理完毕。
其中关于 spring.lifecycle.timeout-per-shutdown-phase 配置，是通过等待配置的时间后，再执行TomcatWebServer的stop方法，将其aborted成员置为true，实现如果应用在宽限期之后仍然有待处理的请求，应用程序将抛出异常并继续强制关闭，而不是一直等待下去。
@Override
public void stop() throws WebServerException {
this.aborted = true;
}
void abort() {
this.aborted = true;
}
在微服务场景下问题似乎依旧存在...
总结一下一个 Spring Cloud 应用正常分批发布的流程
1、服务发布前，消费者根据负载均衡规则调用服务提供者，业务正常。
2、服务提供者 B 需要发布新版本，先对其中的一个节点进行操作，先是正常停止 Java 进程。
3、服务停止过程中，首先去注册中心注销服务，然后等待服务端线程处理完成，再停止服务。
4、注册中心则将通知消费者，其中的一个服务提供者节点已下线。这个过程包含推送和轮询两种方式，推送可以认为是准实时的，轮询的耗时由服务消费者轮询间隔决定，最差的情况下需要 1 分钟。
5、服务消费者刷新服务列表，感知到服务提供者已经下线了一个节点，但是这个过程中Spring Cloud 的负载均衡组件 Ribbon 默认的刷新时间是 30 秒 ，最差情况下需要耗时 30 秒。
6、服务消费者不再调用已经下线的节点
我们看到，当一个Spring Cloud服务端通过SpringBoot提供的graceful shutdown下线时，它会拒绝客户端新的请求，并且等待已经在处理的线程处理完成后，或者在配置的应用最长等待时间到了之后进行下线。
但是在服务端重启开始拒绝客户端新的请求的时刻开始，即执行了Connectors.stop开始，到客户端感知到服务端该实例下线这段时间内，客户端向该实例发起的所有请求都会被拒绝，从而引起服务调用异常。
如果客户端考虑增加重试能力，这一定程度上可以缓解发布过程中服务调用报错的问题，但是无法根本上保证下线过程的无损，如果服务调用报错期过程，或者分批发布时候同一批次下线的节点数过多，无法保证仅仅增加多次重试就能够调用到未下线的节点上。这不能根本解决问题！同时需要考虑配置重试带来的业务上存在不幂等的风险。
EDAS 3.0 无损下线
EDAS 3.0 通过Java Agent技术无侵入增强您的应用，使其具备无损下线能力。
• 您无需修改一行代码与配置，天然具备无侵入特点
• 同时支持 ECS 、K8s 场景
• 全面兼容开源，支持开源Dubbo、Spring Cloud 以及开源微服务网关
EDAS的应用如何做到无损下线？
如图看到，我们通过3个步骤的增强，主动注销、服务提供者通知下线信息、服务消费者调其他服务提供者。
可以看到，真正做到无损下线能力是需要客户端增强一起联动的
- 主动注销
我们在应用服务下线前，主动通知注册中心注销该实例 - 通知下线信息
我们会在服务端实例下线前主动通知客户端，该服务节点下线的信息 - 调用其他提供者
我们在客户端增强其负载均衡能力，在服务端下线后，客户端主动调用其他服务提供者节点
同时我们提供应用等待的逻辑，使要下线的服务端等待已经收到的请求处理完成再关闭 Spring 容器。
完整的解决方案
EDAS 3.0无损下线不仅仅支持 Spring Cloud 与 Dubbo 服务，我们还打通了消息、网关等微服务组件，让您的应用在EDAS中做到全链路的下线无损。
EDAS 3.0支持端到端的无损下线
- 云上客户存在多种微服务网关，支持主流开源微服务网关（Spring Cloud Gateway、Zuul等）的无损下线
- 有些用户的流量是通过 Ingress、SLB、Nginx 等方式打到服务端的场景
- MQ消息等异步订阅关系的微服务场景
- K8s 使用 Service 服务发现的微服务场景
为了做到全链路的无损下线，EDAS 3.0 通过无侵入的方式涵盖多种场景的完整解决方案，确保您的发布平滑无损。
即使面对白天大流量的场景，发布依旧风轻云淡。
作者信息：
泮圣伟（花名：十眠）阿里云智能开发工程师，负责 Dubbo / Spring Cloud 商业化产品开发相关工作，目前主要关注云原生、微服务等技术方向。
本文为阿里云原创内容，未经允许不得转载。
