服务优雅下线

问题背景描述

• 运维同事反馈上线滚动发布，旧实例接收的请求发生业务中断，没有处理完成， 为保证服务质量，期望发布时旧实例将已有请求处理完成再回收。
• 先说可能会带来的影响：
• 业务处理中断
  • 导致数据不完整，属于致命危害。
  • 举例：文件写入中断，文件数据不完整；支付完成，本地业务处理失败。
  • 应用是可以通过一些手段保证业务流程，比如业务补偿、幂等设计、状态机严格控制，这要求编程时考虑因素更大，即使能做到这些，也会带来维护成本，出现问题需要排查，甚至人工补偿，保证数据完整性。
• 已下线的服务继续提供服务
  • 微服务一般都由注册中心提供的服务自动发现机制，在一定时间范围内，即使服务下线，注册中心和服务有心跳时间窗口，比如eureka默认是30S，这个时间窗口内，注册中心不会下线服务，导致上游调用该服务大量报错，引发告警甚至熔断，业务请求大量失败。
  • 服务不存在绝对的优雅下线，一方面有断电、拔电源等外在因素；还有kill -15后应用本身不能在正常下线窗口时间范围内处理完成业务，触发 kill -9，发生业务中断。
    但我们可以在可以控制的范围内，做到优雅下线。
  • 

优雅下线要解决的问题

处理完已经接受的请求

• 正常执行完成后台业务逻辑
• 调用方接收正常处理完成的信号

不再接收新的请求

• 目前部署架构和发布方式，发布采用滚动发布的方式，k8s已经实现了停机时将服务从注册列表自动移除的机制。

• k8s对pod是有一个terminationGracePeriodSeconds的配置项（默认是30秒），当采用RollingUpdate方式更新应用时，一个新pod起来并经过healthcheck后，会通知k8s终止一个pod。Pod被设置为Terminating状态，并从k8s的service/endpoint列表中删除，Pod停止获得新流量。K8S向Pod中的容器发送SIGTERM（kill 15）信号，通知应用进程。

• 这给应用层面省去了不少麻烦，不然得下线时挂钩子（shutdownHook）将服务主动从注册列表移除，还没那么简单，容器重启服务时，如果发布前后ip无变化，还得对外暴露接口，配置执行脚本将服务加入注册列表，需要一整套方案去保证。

• DiscoveryManager.getInstance().shutdownComponent();
  

• 测试代码：

• @GetMapping("/test")public String test1(@RequestParam int s) throws InterruptedException {System.out.println(Thread.currentThread().getName() + " start");TimeUnit.SECONDS.sleep(s);System.out.println(Thread.currentThread().getName() + " finished");return "m1";}

• Jetty 停机日志：可以看到系统会处理完成请求，但是客户端接收不到响应！

• qtp1648582256-24 start
  2022-04-18 17:21:54.040  INFO 28284 --- [      Thread-13] ConfigServletWebServerApplicationContext : Closing org.springframework.boot.web.servlet.context.AnnotationConfigServletWebServerApplicationContext@647e447: startup date [Mon Apr 18 17:21:38 CST 2022]; root of context hierarchy
  2022-04-18 17:21:54.041  INFO 28284 --- [      Thread-13] o.s.j.e.a.AnnotationMBeanExporter        : Unregistering JMX-exposed beans on shutdown
  2022-04-18 17:21:54.050  INFO 28284 --- [      Thread-13] o.e.jetty.server.AbstractConnector       : Stopped ServerConnector@2caf6912{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
  2022-04-18 17:21:54.050  INFO 28284 --- [      Thread-13] org.eclipse.jetty.server.session         : Stopped scavenging
  2022-04-18 17:21:54.053  INFO 28284 --- [      Thread-13] o.e.j.s.h.ContextHandler.application     : Destroying Spring FrameworkServlet 'dispatcherServlet'
  2022-04-18 17:21:54.054  INFO 28284 --- [      Thread-13] o.e.jetty.server.handler.ContextHandler  : Stopped o.s.b.w.e.j.JettyEmbeddedWebAppContext@5910de75{/,[file:///private/var/folders/fd/ts66c75s6pl47q8cy2q5szy80000gn/T/jetty-docbase.7513543250728756019.8080/],UNAVAILABLE}
  qtp1648582256-24 finishedProcess finished with exit code 130 (interrupted by signal 2: SIGINT)

• jetty客户端响应

• org.apache.http.NoHttpResponseException: localhost:8080 failed to respond
  

• tomcat 停机日志：可以看到系统收到指令，业务中断

• http-nio-8080-exec-2 start
  2022-04-18 17:37:19.863  INFO 28365 --- [       Thread-6] ConfigServletWebServerApplicationContext : Closing org.springframework.boot.web.servlet.context.AnnotationConfigServletWebServerApplicationContext@6580cfdd: startup date [Mon Apr 18 17:36:33 CST 2022]; root of context hierarchy
  2022-04-18 17:37:19.865  INFO 28365 --- [       Thread-6] o.s.j.e.a.AnnotationMBeanExporter        : Unregistering JMX-exposed beans on shutdownProcess finished with exit code 130 (interrupted by signal 2: SIGINT)

• 客户端响应

• org.apache.http.NoHttpResponseException: localhost:8080 failed to respond。
  

Springboot对优雅关闭的支持

• 根据关闭打印日志可以看到，关闭相关类AnnotationConfigEmbeddedWebApplicationContext，
  父类AbstractApplicationContext提供了对优雅下线的扩展支持，Springboot 在关闭时，如果有请求没有响应完，
  在不同的容器会出现不同的结果，实际上具体关闭处理是交给具体容器自己实现的。

• 贴一下关键源码：

• /*** Register a shutdown hook with the JVM runtime, closing this context* on JVM shutdown unless it has already been closed at that time.* <p>Delegates to {@code doClose()} for the actual closing procedure.* @see Runtime#addShutdownHook* @see #close()* @see #doClose()*/@Overridepublic void registerShutdownHook() {if (this.shutdownHook == null) {// No shutdown hook registered yet.this.shutdownHook = new Thread() {@Overridepublic void run() {synchronized (startupShutdownMonitor) {doClose();}}};Runtime.getRuntime().addShutdownHook(this.shutdownHook);}}/*** Actually performs context closing: publishes a ContextClosedEvent and* destroys the singletons in the bean factory of this application context.* <p>Called by both {@code close()} and a JVM shutdown hook, if any.* @see org.springframework.context.event.ContextClosedEvent* @see #destroyBeans()* @see #close()* @see #registerShutdownHook()*/protected void doClose() {if (this.active.get() && this.closed.compareAndSet(false, true)) {if (logger.isInfoEnabled()) {logger.info("Closing " + this);}LiveBeansView.unregisterApplicationContext(this);try {// Publish shutdown event.publishEvent(new ContextClosedEvent(this));}catch (Throwable ex) {logger.warn("Exception thrown from ApplicationListener handling ContextClosedEvent", ex);}// Stop all Lifecycle beans, to avoid delays during individual destruction.try {getLifecycleProcessor().onClose();}catch (Throwable ex) {logger.warn("Exception thrown from LifecycleProcessor on context close", ex);}// Destroy all cached singletons in the context's BeanFactory.destroyBeans();// Close the state of this context itself.closeBeanFactory();// Let subclasses do some final clean-up if they wish...onClose();this.active.set(false);}}

为什么tomcat默认不会优雅关闭？

• tomcat 未对服务关闭事件做特殊处理，业务处理中断，调用方报错。

jetty的优雅关闭有什么问题？

• 接收到的请求能继续处理，调用方会报错，原因是Jetty中Server.stop()方法先关闭connections，然后处理队列中未完成的request，request完成后，由于connection已经关闭了，响应不能写回去了。

Springboot内嵌容器优雅停机的处理方案

Spring Boot 2.3 及以上版本，开箱即用

• ## 开启优雅停机, 如果不配置是默认IMMEDIATE, 立即停机
  server.shutdown=graceful
  ## 优雅停机宽限期时间
  spring.lifecycle.timeout-per-shutdown-phase=30s

Spring Boot 2.3 以下版本

• 相当于手动实现高版本功能，完美一点，可以做开关和关闭时间可配置化。

• (1) Jetty 实现：

• 先看一下jetty核心类org.eclipse.jetty.server.Server两个关键的方法

• /*** Set a graceful stop time.* The {@link StatisticsHandler} must be configured so that open connections can* be tracked for a graceful shutdown.* @see org.eclipse.jetty.util.component.ContainerLifeCycle#setStopTimeout(long)*/
  @Override
  public void setStopTimeout(long stopTimeout)
  {super.setStopTimeout(stopTimeout);
  }/** Set stop server at shutdown behaviour.* @param stop If true, this server instance will be explicitly stopped when the* JVM is shutdown. Otherwise the JVM is stopped with the server running.* @see Runtime#addShutdownHook(Thread)* @see ShutdownThread*/
  public void setStopAtShutdown(boolean stop)
  

• 解决方法：Jetty 是用 StatisticsHandler 做请求数量监控，关闭应用时，请求数量从N变为O的过程其实就是优雅关闭。

• @Bean
  public EmbeddedServletContainerFactory jettyEmbeddedServletContainerFactory() {JettyEmbeddedServletContainerFactory factory = new JettyEmbeddedServletContainerFactory();factory.addServerCustomizers(server -> {server.setStopAtShutdown(false);StatisticsHandler statisticsHandler = new StatisticsHandler();statisticsHandler.setHandler(server.getHandler());server.setHandler(statisticsHandler);server.setStopTimeout(30000); // 为了简单，写死30s});return factory;
  }
  

• (2) Tomcat 实现：

•   @Beanpublic EmbeddedServletContainerCustomizer tomcatCustomizer() {return container -> {if (container instanceof TomcatEmbeddedServletContainerFactory) {((TomcatEmbeddedServletContainerFactory) container).addConnectorCustomizers(new GracefulShutdown());}};}private static class GracefulShutdown implements TomcatConnectorCustomizer,ApplicationListener<ContextClosedEvent> {private static final Logger log = LoggerFactory.getLogger(GracefulShutdown.class);private volatile Connector connector;@Overridepublic void customize(Connector connector) {this.connector = connector;}@Overridepublic void onApplicationEvent(ContextClosedEvent event) {this.connector.pause();Executor executor = this.connector.getProtocolHandler().getExecutor();if (executor instanceof ThreadPoolExecutor) {try {ThreadPoolExecutor threadPoolExecutor = (ThreadPoolExecutor) executor;threadPoolExecutor.shutdown();if (!threadPoolExecutor.awaitTermination(30, TimeUnit.SECONDS)) {log.warn("Force shutdown ...");}} catch (InterruptedException ex) {Thread.currentThread().interrupt();}}}}
  

开发需要注意的事项

• 评估每个服务停机处理完请求需要的下线时间

• 保证应用在下线指定时间内的请求都能正常处理并且响应调用方

• 手动对自定义线程资源优雅下线

• 业务处理线程资源释放示例：

• @Bean
  public ExecutorService bizExecutorService() {ExecutorService executorService = Executors.newFixedThreadPool(10);// shutdownAndAwaitTermination  可以参考guava线程池优雅关闭Runtime.getRuntime().addShutdownHook(new Thread(() -> shutdownAndAwaitTermination(executorService, 10l, TimeUnit.SECONDS)));return executorService;
  }
  

• 对生产发布因未在指定时间内完成的业务请求进行监控，并优化性能

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。
• 当我们使用了如上配置开启了优雅停机功能，当我们通过SIGTERM信号关闭 Spring Boot 应用时
• 1、 此时如果应用中没有正在进行的请求，应用程序将会直接关闭，而无需等待超时时间结束后才关闭。
• 2、此时如果应用中有正在处理的请求，则应用程序将等待超时时间结束后才会关闭。如果应用在超时时间之后仍然有未处理完的请求，应用程序将抛出异常并继续强制关闭。

graceful shutdown源码实现分析

• 我们以 Tomcat 为例看一下是SpringBoot 2.3如何实现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 Cloud 应用正常分批发布的流程

  • 1、服务发布前，消费者根据负载均衡规则调用服务提供者，业务正常。
  • 2、服务提供者 B 需要发布新版本，先对其中的一个节点进行操作，先是正常停止 Java 进程。
  • 3、服务停止过程中，首先去注册中心注销服务，然后等待服务端线程处理完成，再停止服务。
  • 4、注册中心则将通知消费者，其中的一个服务提供者节点已下线。这个过程包含推送和轮询两种方式，推送可以认为是准实时的，轮询的耗时由服务消费者轮询间隔决定，最差的情况下需要 1 分钟。
  • 5、服务消费者刷新服务列表，感知到服务提供者已经下线了一个节点，但是这个过程中Spring Cloud 的负载均衡组件 Ribbon 默认的刷新时间是 30 秒 ，最差情况下需要耗时 30 秒。
  • 6、服务消费者不再调用已经下线的节点

• 

• 我们看到，当一个Spring Cloud服务端通过SpringBoot提供的graceful shutdown下线时，它会拒绝客户端新的请求，并且等待已经在处理的线程处理完成后，或者在配置的应用最长等待时间到了之后进行下线。

• 但是在服务端重启开始拒绝客户端新的请求的时刻开始，即执行了Connectors.stop开始，到客户端感知到服务端该实例下线这段时间内，客户端向该实例发起的所有请求都会被拒绝，从而引起服务调用异常。

• 

• 如果客户端考虑增加重试能力，这一定程度上可以缓解发布过程中服务调用报错的问题，但是无法根本上保证下线过程的无损，如果服务调用报错期过程，或者分批发布时候同一批次下线的节点数过多，无法保证仅仅增加多次重试就能够调用到未下线的节点上。这不能根本解决问题！
  同时需要考虑配置重试带来的业务上存在不幂等的风险。

长连接服务的重启

• 我们很多时候都需要安全的将服务停止，也就是把没有处理完的工作继续处理完成。比如停止一些依赖的服务，输出一些日志，发一些信号给其他的应用系统等，这个在保证系统的高可用中是非常有必要的。
• 长连接服务，管理了大量的TCP 连接FD，绝不能直接暴力关闭，否则OOM。必须要保证已有的任务全都处理完，并且在关闭的过程中不会有新的请求连接进来。

优雅关闭

• 服务的优雅关闭通常都是利用 JDK 里面提供的 Runtime.addShutDownHook(Thread hook)方法，JVM 提供一种 ShutdownHook（钩子）机制，当 JVM 接受到系统的关闭通知之后，会调用 ShutdownHook 内的方法，用以完成清理操作，从而平滑的退出应用。
• 像Spring 、Dubbo 等都是基于这个实现的优雅关闭，而Netty 自身提供了优雅退出的方式，那就是 EventExecutorGroup 的 shutdownGracefully() 方法。

长连接的平滑重启

• 长连接相关的事情，最大的感触就是发版太痛苦，一个个踢掉连接然后发版，导致发版时长过长，操作繁琐。所以在想能不能实现优雅重启, 发版时客户端无感知。
• 实现思路：
• 主要思路就是要解决新老进程切换过程中listener文件描述符和现有连接描述符的迁移，之前有一篇文章讲了如何通过unixSocket来传递文件描述符，这里也会用到这个技术， 具体的迁移流程如下：
  • 1、老进程在启动时，启动tcp listen监听，就是开启对外服务的端口，如果有请求过来，开启一个协程处理这个请求。
  • 2、老进程启动一个unix Socket监听，通过switch.sock和新进程进行通信，一旦由请求过来，就把自己的listener文件描述符发给新进程，然后通过发送信号触发迁移流程，同时等待一段时间关闭自己的listener，进程退出。
  • 3、新进程在启动前，会尝试连接旧进程的switch.sock，如果通信成功，就知道它需要开始接收旧的listener 和 connection了，此时会分别启动listen.sock监听和conn.sock监听，来获取旧进程的listener信息和conn信息。如果收到了listener信息，则会用这个listener启动服务。
  • 4、接步骤1，协程在处理请求的过程中，如果收到了迁移信号，则会判断是否将现有的客户端连接发给新进程，如果连接里还有可读的数据，则需要迁移。
    到此整个迁移流程就完毕了。