△Hollis, 一个对Coding有着独特追求的人△
来源 l Hollis(ID:hollischuang)
最近无论是校招还是社招,都进行的如火如荼,我也承担了很多的面试工作,在一次面试过程中,和候选人聊了一些关于Dubbo的知识。
Dubbo是一个比较著名的RPC框架,很多人对于他的一些网络通信、通信协议、动态代理等等都有一定的了解,这位候选人也一样。
但是,我接下来问了他一个问题:你们在使用Dubbo的时候,应用如果重启,怎么保证一个请求不会被中断处理的呢?
他没怎么说的上来,我以为他不理解我的问题,我接着问他:我就是想问下Dubbo是如何做优雅上下线的你知道吗?
关于"优雅上下线"这个词,我没找到官方的解释,我尝试解释一下这是什么。
首先,上线、下线大家一定都很清楚,比如我们一次应用发布过程中,就需要先将应用服务停掉,然后再把服务启动起来。这个过程就包含了一次下线和一次上线。
1、服务停止时,没有关闭对应的监控,导致应用停止后发生大量报警。
2、应用停止时,没有通知外部调用方,很多请求还会过来,导致很多调用失败。
3、应用停止时,有线程正在执行中,执行了一半,JVM进程就被干掉了。
4、应用启动时,服务还没准备好,就开始对外提供服务,导致很多失败调用。
5、应用启动时,没有检查应用的健康状态,就开始对外提供服务,导致很多失败调用。
以上,都是我们认为的不优雅的情况,那么,反过来,优雅上下线就是一种避免上述情况发生的手段。
一个应用的优雅上下线涉及到的内容其实有很多,从底层的操作系统、容器层面,到编程语言、框架层面,再到应用架构层面,涉及到的知识很广泛。
其实,优雅上下线中,最重要的还是优雅下线。因为如果下线过程不优雅的话,就会发生很多调用失败了、服务找不到等问题。所以很多时候,大家也会提优雅停机这样的概念。
本文后面介绍的优雅上下线也重点关注优雅停机的过程。
关于操作系统,我之前有一篇文章专门介绍过这个话题,可能大家没有注意到,那时候介绍的主题是。
我们知道,
kill -9
之所以不建议使用,是因为 kill -9
特别强硬,系统会发出SIGKILL信号,他要求接收到该信号的程序应该立即结束运行,不能被阻塞或者忽略。
这个过程显然是不优雅的,因为应用立刻停止的话,就没办法做收尾动作。而更优雅的方式是
kill -15
。
当使用
kill -15
时,系统会发送一个SIGTERM的信号给对应的程序。当程序接收到该信号后,具体要如何处理是自己可以决定的。
kill -15
会通知到应用程序,这就是操作系统对于优雅上下线的最基本的支持。
以前,在操作系统之上就是应用程序了,但是,自从容器化技术推出之后,在操作系统和应用程序之间,多了一个容器层,而Docker、k8s等容器其实也是支持优雅上下线的。
如Docker中同样提供了两个命令,
docker stop
和
docker kill
docker stop
就像 kill -15
一样
,他会向容器内的进程发送SIGTERM信号,在10S之后(可通过参数指定)再发送SIGKILL信号。
而 docker kill
就像 kill -9
,直接发送SIGKILL信号。
在操作系统、容器等对优雅上下线有了基本的支持之后,在接收到
docker stop
、
kill -15
等命令后,会通知应用进程进行进程关闭。
而Java应用在运行时就是一个独立运行的进程,这个进程是如何关闭的呢?
Java程序的终止运行是基于JVM的关闭实现的,JVM关闭方式分为正常关闭、强制关闭和异常关闭3种。
这其中,正常关闭就是支持优雅上下线的。正常关闭过程中,JVM可以做一些清理动作,比如删除临时文件。
当然,开发者也是可以自定义做一些额外的事情的,比如通知应用框架优雅上下线操作。
而这种机制是通过JDK中提供的shutdown hook实现的。JDK提供了Java.Runtime.addShutdownHook(Thread hook)方法,可以注册一个JVM关闭的钩子。
package com.hollis; public class ShutdownHookTest { public static void main (String[] args) { boolean flag = true ; Runtime.getRuntime().addShutdownHook(new Thread(() -> { System.out.println("hook execute..." ); })); while (flag) { // app is runing } System.out.println("main thread execute end..." ); } }
执行命令:
jps 6520 ShutdownHookTest 6521 Jps kill 6520
控制台输出内容:
hook execute... Process finished with exit code 143 (interrupted by signal 15 : SIGTERM)
可以看到,当我们使用kill(默认kill -15)关闭进程的时候,程序会先执行我注册的shutdownHook,然后再退出,并且会给出一个提示:
interrupted by signal 15: SIGTERM
有了JVM提供的shutdown hook之后,很多框架都可以通过这个机制来做优雅下线的支持。
比如Spring,他就会向JVM注册一个shutdown hook,在接收到关闭通知的时候,进行bean的销毁,容器的销毁处理等操作。
同时,作为一个成熟的框架,Spring也提供了事件机制,可以借助这个机制实现更多的优雅上下线功能。
ApplicationListener是Spring事件机制的一部分,与抽象类ApplicationEvent类配合来完成ApplicationContext的事件机制。
开发者可以实现ApplicationListener接口,监听到 Spring 容器的关闭事件(ContextClosedEvent),来做一些特殊的处理:
@Component public class MyListener implements ApplicationListener <ContextClosedEvent > { @Override public void onApplicationEvent (ContextClosedEvent event) { // 做容器关闭之前的清理工作 } }
因为Spring中提供了ApplicationListener接口,帮助我们来监听容器关闭事件,那么,很多web容器、框架等就可以借助这个机制来做自己的优雅上下线操作。
这里简答说一下Dubbo的,在Dubbo的官网中,有关于优雅停机的介绍:
应用在停机时,接收到关闭通知时,会先把自己标记为不接受(发起)新请求,然后再等待10s(默认是10秒)的时候,等执行中的线程执行完。
那么,之所以他能做这些事,是因为从操作系统、到JVM、到Spring等都对优雅停机做了很好的支持。
关于Dubbo各个版本中具体是如何借助JVM的shutdown hook机制、或者说Spring的事件机制的优雅停机,我的一位同事的一篇文章介绍的很清晰,大家可以看下:
https://www.cnkirito.moe/dubbo-gracefully-shutdown/
在从Dubbo 2.5 到 Dubbo 2.7介绍了历史版本中,Dubbo为了解决优雅上下线问题所遇到的问题和方案。
目前,Dubbo中实现方式如下,同样是用到了Spring的事件机制:
public class SpringExtensionFactory implements ExtensionFactory { public static void addApplicationContext (ApplicationContext context) { CONTEXTS.add(context); if (context instanceof ConfigurableApplicationContext) { ((ConfigurableApplicationContext) context).registerShutdownHook(); DubboShutdownHook.getDubboShutdownHook().unregister(); } BeanFactoryUtils.addApplicationListener(context, SHUTDOWN_HOOK_LISTENER); } }
本文从操作系统开始,分别介绍了Linux、Docker、JVM、Spring、Dubbo等对优雅停机的支持。
可以看到,一个简单的优雅停机功能,上下游需要这么多底层基础设施和上层应用的支持。
相信通过学习本文,你一定对优雅上下线有了更多的了解。
除此之外,我还希望你,通过本文以后,遇到一些实际问题的时候,可以想到文中提到的shutdown hook机制、Spring的event机制。很多时候,这些机制都能帮助我们解决很多问题。
我在工作中,就有很多次使用过这样的机制的实例,后面有机会给大家介绍几个实例。
好了,本文的全部内容就是这么多啦,如果对你有帮助,记得一键三连哦~
参考 :
https://zhuanlan.zhihu.com/p/29093407
https://www.cnkirito.moe/dubbo-gracefully-shutdown/
直面Java第343期:为什么TOMCAT要破坏双亲委派
深入并发第013期:拓展synchronized——锁优化