关于java:别再用-kill-9-了这才是微服务上下线的正确姿势

对于微服务来说,服务的优雅高低线是必要的。

就上线来说,如果组件或者容器没有启动胜利,就不应该对外裸露服务,对于下线来说,如果机器曾经停机了,就应该保障服务已下线,如此可防止上游流量进入不衰弱的机器。

优雅下线

根底下线(Spring/SpringBoot/内置容器)

首先JVM自身是反对通过shutdownHook的形式优雅停机的。

Runtime.getRuntime().addShutdownHook(new Thread() {
    @Override
    public void run() {
        close();
    }
});

此形式反对在以下几种场景优雅停机:

1.程序失常退出
2.应用System.exit()
3.终端应用Ctrl+C
4.应用Kill pid干掉过程

那么如果你偏偏要kill -9 程序必定是手足无措的。

而在Springboot中,其实曾经帮你实现好了一个shutdownHook,反对响应Ctrl+c或者kill -15 TERM信号。

轻易启动一个利用,而后Ctrl+c一下,察看日志就可知, 它在 AnnotationConfigEmbeddedWebApplicationContext 这个类中打印出了疑似Closing…的日志,真正的实现逻辑在其父类 AbstractApplicationContext 中(这个其实是spring中的类,意味着什么呢,在spring中就反对了对优雅停机的扩大)。

public void registerShutdownHook() {
    if (this.shutdownHook == null) {
        this.shutdownHook = new Thread() {
            public void run() {
                synchronized(AbstractApplicationContext.this.startupShutdownMonitor) {
                    AbstractApplicationContext.this.doClose();
                }
            }
        };
        Runtime.getRuntime().addShutdownHook(this.shutdownHook);
    }
 
}
 
public void destroy() {
    this.close();
}
 
public void close() {
    Object var1 = this.startupShutdownMonitor;
    synchronized(this.startupShutdownMonitor) {
        this.doClose();
        if (this.shutdownHook != null) {
            try {
                Runtime.getRuntime().removeShutdownHook(this.shutdownHook);
            } catch (IllegalStateException var4) {
                ;
            }
        }
 
    }
}
 
protected void doClose() {
    if (this.active.get() && this.closed.compareAndSet(false, true)) {
        if (this.logger.isInfoEnabled()) {
            this.logger.info("Closing " + this);
        }
 
        LiveBeansView.unregisterApplicationContext(this);
 
        try {
            this.publishEvent((ApplicationEvent)(new ContextClosedEvent(this)));
        } catch (Throwable var3) {
            this.logger.warn("Exception thrown from ApplicationListener handling ContextClosedEvent", var3);
        }
 
        if (this.lifecycleProcessor != null) {
            try {
                this.lifecycleProcessor.onClose();
            } catch (Throwable var2) {
                this.logger.warn("Exception thrown from LifecycleProcessor on context close", var2);
            }
        }
 
        this.destroyBeans();
        this.closeBeanFactory();
        this.onClose();
        this.active.set(false);
    }
 
}

咱们能对它做些什么呢,其实很显著,在doClose办法中它公布了一个ContextClosedEvent的办法,不就是给咱们扩大用的么。

于是咱们能够写个监听器监听ContextClosedEvent,在产生事件的时候做下线逻辑,对微服务来说即是从注册核心中登记掉服务。

@Component
public class GracefulShutdownListener implements ApplicationListener<ContextClosedEvent> {
    
    @Override
    public void onApplicationEvent(ContextClosedEvent contextClosedEvent){
       //登记逻辑
       zookeeperRegistry.unregister(mCurrentServiceURL);
       ...
    }
}

可能会有疑难的是,微服务中一般来说,登记服务往往是优雅下线的第一步,接着才会执行停机操作,那么这个时候流量进来怎么办呢?

集体会倡议是,在登记服务之后就可开启申请挡板回绝流量了,通过微服务框架自身的故障转移性能去解决被回绝的流量即可。

Docker中的下线

好有人说了,我用docker部署服务,支不反对优雅下线。

那来看看docker的一些进行命令都会干些啥:

一般来说,正常人可能会用docker stop或者docker kill 命令去敞开容器(当然如果上一步注册了USR2自定义信息,可能会通过docker exec kill -12去敞开)。

对于docker stop来说,它会发一个SIGTERM(kill -15 term信息)给容器的PID1过程,并且默认会期待10s,再发送一个SIGKILL(kill -9 信息)给PID1。

那么很显著,docker stop容许程序有个默认10s的反应时间去做一下优雅停机的操作,程序只有能对kill -15 信号做些反馈就好了,如上一步形容。那么这是比拟良好的形式。

当然如果shutdownHook办法执行了个50s,那必定不优雅了。能够通过docker stop -t 加上等待时间。

外置容器的shutdown脚本(Jetty)

如果非要用外置容器形式部署(集体认为浪费资源并晋升复杂度)。那么能不能优雅停机呢。

能够当然也是能够的,这里有两种形式:

首先RPC框架自身提供优雅高低线接口,以供调用来完结整个利用的生命周期,并且提供扩大点供开发者自定义服务下线本身的停机逻辑。同时调用该接口的操作会封装成一个preStop操作固化在jetty或者其余容器的shutdown脚本中,保障在容器进行之前先调用下线接口完结掉整个利用的生命周期。shutdown脚本中执行类发动下线服务 -> 敞开端口 -> 查看下线服务直至实现 -> 敞开容器的流程。

而更简略的另一种办法是间接在脚本中退出kill -15命令。

优雅上线

优雅上线相对来说可能会更加艰难一些,因为没有什么默认的实现形式,然而总之呢,一个准则就是确保端口存在之后才上线服务。

springboot内置容器优雅上线

这个就很简略了,并且业界在利用层面的优雅上线均是在内置容器的前提下实现的,并且还能够配合一些列健康检查做文章。

参看sofa-boot的健康检查的源码,它会在程序启动的时候先对springboot的组件做一些健康检查,而后再对它本人搞得sofa的一些中间件做健康检查,整个健康检查的流程结束之后(sofaboot 目前是没法对本身利用层面做健康检查的,它有写相干接口,然而写死了port is ready…)才会裸露服务或者说优雅上线,那么它健康检查的机会是什么时候呢:

@Override
public void onApplicationEvent(ContextRefreshedEvent event) {
    healthCheckerProcessor.init();
    healthIndicatorProcessor.init();
    afterHealthCheckCallbackProcessor.init();
    publishBeforeHealthCheckEvent();
    readinessHealthCheck();
}

能够看到它是监听了ContextRefreshedEvent这个事件。在内置容器模式中,内置容器模式的start办法是在refreshContext办法中,办法执行实现之后公布一个ContextRefreshedEvent事件,也就是说在监听到这个事件的时候,内置容器必然是启动胜利了的。

但ContextRefreshedEvent这个事件,在一些特定场景中因为种种原因,ContextRefreshedEvent会被监听到屡次,没有方法保障以后是最初一次event,从而正确执行优雅上线逻辑。

在springboot中还有一个更加靠后的事件,叫做ApplicationReadyEvent,它的公布藏在了afterRefresh还要前面的那一句listeners.finished(context, null)中,完完全全能够保障内置容器 端口曾经存在了,所以咱们能够监听这个事件去做优雅上线的逻辑,甚至能够把中间件相干的健康检查集成在这里。

@Component
public class GracefulStartupListener implements ApplicationListener<ApplicationReadyEvent> {    
    @Override
    public void onApplicationEvent(ApplicationReadyEvent applicationReadyEvent){
       //注册逻辑 优雅上线
       apiRegister.register(urls);
       ...
    }
}

外置容器(Jetty)优雅上线

目前大多数利用的部署模式不论是jetty部署模式还是docker部署模式(同样应用jetty镜像),实质上用的都是外置容器。那么这个状况就比拟艰难了,至多在利用层面无奈察看到内部容器的运行状态,并且容器自身没有提供什么hook给你实现。

那么和优雅上线一样,须要RPC框架提供优雅上线接口来初始化整个利用的生命周期,并且提供扩大点给开发者供执行自定义的上线逻辑(上报版本探测信息等)。同样将调用这个接口封装成一个postStart操作,固化在jetty等外置容器的startup脚本中,保障利用在容器启动之后在上线。容器执行相似启动容器 -> 健康检查 -> 上线服务逻辑 -> 衰弱上线服务直至实现 的流程。

作者:fredalxin
地址:https://fredal.xin/graceful-s…

【腾讯云】云产品限时秒杀,爆款1核2G云服务器,首年50元

阿里云限时活动-2核2G-5M带宽-60G SSD-1000G月流量 ,特惠价99元/年(原价1234.2元/年,可以直接买3年),速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

You may also like...

发表评论

邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据