服务优雅下线

分手后的思念是犯贱 2024-05-23 20:35 27阅读 0赞

## 服务优雅下线 ##

### 问题背景描述 ###

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

### 优雅下线要解决的问题 ###

#### **处理完已经接受的请求** ####

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

#### **不再接收新的请求** ####

*  目前部署架构和发布方式，发布采用滚动发布的方式，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 finished
        
        Process 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 shutdown
        
        Process 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()
        	 */
        	@Override
        	public void registerShutdownHook() {
        		if (this.shutdownHook == null) {
        			// No shutdown hook registered yet.
        			this.shutdownHook = new Thread() {
        				@Override
        				public 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 实现：
 *      @Bean
            public 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;
        
                @Override
                public void customize(Connector connector) {
                    this.connector = connector;
                }
        
                @Override
                public 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、服务消费者不再调用已经下线的节点
 *  ![在这里插入图片描述][76c9940ae8974512ac061a6b8b599256.png]
 *  我们看到，当一个Spring Cloud服务端通过SpringBoot提供的graceful shutdown下线时，它会拒绝客户端新的请求，并且等待已经在处理的线程处理完成后，或者在配置的应用最长等待时间到了之后进行下线。
 *  但是在服务端重启开始拒绝客户端新的请求的时刻开始，即执行了Connectors.stop开始，到客户端感知到服务端该实例下线这段时间内，客户端向该实例发起的所有请求都会被拒绝，从而引起服务调用异常。
 *  ![在这里插入图片描述][67a37f1e2adb49e687ffcc987c056510.png]
 *  如果客户端考虑增加重试能力，这一定程度上可以缓解发布过程中服务调用报错的问题，但是无法根本上保证下线过程的无损，如果服务调用报错期过程，或者分批发布时候同一批次下线的节点数过多，无法保证仅仅增加多次重试就能够调用到未下线的节点上。这不能根本解决问题！  
    同时需要考虑配置重试带来的业务上存在不幂等的风险。

### [长连接][Link 1]服务的重启 ###

*  我们很多时候都需要安全的将服务停止，也就是把没有处理完的工作继续处理完成。比如停止一些依赖的服务，输出一些日志，发一些信号给其他的应用系统等，这个在保证系统的高可用中是非常有必要的。
 *  长连接服务，管理了大量的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，协程在处理请求的过程中，如果收到了迁移信号，则会判断是否将现有的客户端连接发给新进程，如果连接里还有可读的数据，则需要迁移。  
        到此整个迁移流程就完毕了。

[e6b98ecd696748f195e08c3870cab376.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/22401860cb844fe2a413fe42d74132f2.png
[Jetty]: https://so.csdn.net/so/search?q=Jetty&spm=1001.2101.3001.7020
[76c9940ae8974512ac061a6b8b599256.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/9672bb50cf3b44129d0db298bc3191c9.png
[67a37f1e2adb49e687ffcc987c056510.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/f388e46d441a4a15b532040bdb93ca9f.png
[Link 1]: https://so.csdn.net/so/search?q=%E9%95%BF%E8%BF%9E%E6%8E%A5&spm=1001.2101.3001.7020