點(diǎn)擊上方“碼農(nóng)突圍”，馬上關(guān)注
這里是碼農(nóng)充電第一站，回復(fù)“666”，獲取一份專屬大禮包
真愛(ài)，請(qǐng)?jiān)O(shè)置“星標(biāo)”或點(diǎn)個(gè)“在看

作者：fredalxin
地址：https://fredal.xin/graceful-soa-updown

對(duì)于微服務(wù)來(lái)說(shuō)，服務(wù)的優(yōu)雅上下線是必要的。

就上線來(lái)說(shuō)，如果組件或者容器沒(méi)有啟動(dòng)成功，就不應(yīng)該對(duì)外暴露服務(wù)，對(duì)于下線來(lái)說(shuō)，如果機(jī)器已經(jīng)停機(jī)了，就應(yīng)該保證服務(wù)已下線，如此可避免上游流量進(jìn)入不健康的機(jī)器。

優(yōu)雅下線

基礎(chǔ)下線（Spring/SpringBoot/內(nèi)置容器）

首先JVM本身是支持通過(guò)shutdownHook的方式優(yōu)雅停機(jī)的。

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

此方式支持在以下幾種場(chǎng)景優(yōu)雅停機(jī):

1. 程序正常退出

2. 使用System.exit()

3. 終端使用Ctrl+C

4. 使用Kill pid干掉進(jìn)程

那么如果你偏偏要kill -9 程序肯定是不知所措的。

而在Springboot中，其實(shí)已經(jīng)幫你實(shí)現(xiàn)好了一個(gè)shutdownHook，支持響應(yīng)Ctrl+c或者kill -15 TERM信號(hào)。

隨便啟動(dòng)一個(gè)應(yīng)用，然后Ctrl+c一下，觀察日志就可知， 它在 AnnotationConfigEmbeddedWebApplicationContext 這個(gè)類(lèi)中打印出了疑似Closing...的日志，真正的實(shí)現(xiàn)邏輯在其父類(lèi) AbstractApplicationContext 中(這個(gè)其實(shí)是spring中的類(lèi)，意味著什么呢，在spring中就支持了對(duì)優(yōu)雅停機(jī)的擴(kuò)展)。

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);
????}
?
}

我們能對(duì)它做些什么呢，其實(shí)很明顯，在doClose方法中它發(fā)布了一個(gè)ContextClosedEvent的方法，不就是給我們擴(kuò)展用的么。

于是我們可以寫(xiě)個(gè)監(jiān)聽(tīng)器監(jiān)聽(tīng)ContextClosedEvent，在發(fā)生事件的時(shí)候做下線邏輯，對(duì)微服務(wù)來(lái)說(shuō)即是從注冊(cè)中心中注銷(xiāo)掉服務(wù)。

@Component
public?class?GracefulShutdownListener?implements?ApplicationListener<ContextClosedEvent>?{
????
????@Override
????public?void?onApplicationEvent(ContextClosedEvent?contextClosedEvent){
???????//注銷(xiāo)邏輯
???????zookeeperRegistry.unregister(mCurrentServiceURL);
???????...
????}
}

可能會(huì)有疑問(wèn)的是，微服務(wù)中一般來(lái)說(shuō)，注銷(xiāo)服務(wù)往往是優(yōu)雅下線的第一步，接著才會(huì)執(zhí)行停機(jī)操作，那么這個(gè)時(shí)候流量進(jìn)來(lái)怎么辦呢？

個(gè)人會(huì)建議是，在注銷(xiāo)服務(wù)之后就可開(kāi)啟請(qǐng)求擋板拒絕流量了，通過(guò)微服務(wù)框架本身的故障轉(zhuǎn)移功能去處理被拒絕的流量即可。

Docker中的下線

好有人說(shuō)了，我用docker部署服務(wù)，支不支持優(yōu)雅下線。

那來(lái)看看docker的一些停止命令都會(huì)干些啥：

一般來(lái)說(shuō)，正常人可能會(huì)用docker stop或者docker kill 命令去關(guān)閉容器（當(dāng)然如果上一步注冊(cè)了USR2自定義信息，可能會(huì)通過(guò)docker exec kill -12去關(guān)閉）。

對(duì)于docker stop來(lái)說(shuō)，它會(huì)發(fā)一個(gè)SIGTERM(kill -15 term信息)給容器的PID1進(jìn)程，并且默認(rèn)會(huì)等待10s，再發(fā)送一個(gè)SIGKILL(kill -9 信息)給PID1。

那么很明顯，docker stop允許程序有個(gè)默認(rèn)10s的反應(yīng)時(shí)間去做一下優(yōu)雅停機(jī)的操作，程序只要能對(duì)kill -15 信號(hào)做些反應(yīng)就好了，如上一步描述。那么這是比較良好的方式。

當(dāng)然如果shutdownHook方法執(zhí)行了個(gè)50s，那肯定不優(yōu)雅了?？梢酝ㄟ^(guò)docker stop -t 加上等待時(shí)間。

外置容器的shutdown腳本（Jetty）

如果非要用外置容器方式部署（個(gè)人認(rèn)為浪費(fèi)資源并提升復(fù)雜度）。那么能不能優(yōu)雅停機(jī)呢。

可以當(dāng)然也是可以的，這里有兩種方式：

首先RPC框架本身提供優(yōu)雅上下線接口，以供調(diào)用來(lái)結(jié)束整個(gè)應(yīng)用的生命周期，并且提供擴(kuò)展點(diǎn)供開(kāi)發(fā)者自定義服務(wù)下線自身的停機(jī)邏輯。同時(shí)調(diào)用該接口的操作會(huì)封裝成一個(gè)preStop操作固化在jetty或者其他容器的shutdown腳本中，保證在容器停止之前先調(diào)用下線接口結(jié)束掉整個(gè)應(yīng)用的生命周期。shutdown腳本中執(zhí)行類(lèi)發(fā)起下線服務(wù) -> 關(guān)閉端口 -> 檢查下線服務(wù)直至完成 -> 關(guān)閉容器的流程。

而更簡(jiǎn)單的另一種方法是直接在腳本中加入kill -15命令。

優(yōu)雅上線

優(yōu)雅上線相對(duì)來(lái)說(shuō)可能會(huì)更加困難一些，因?yàn)闆](méi)有什么默認(rèn)的實(shí)現(xiàn)方式，但是總之呢，一個(gè)原則就是確保端口存在之后才上線服務(wù)。

springboot內(nèi)置容器優(yōu)雅上線

這個(gè)就很簡(jiǎn)單了，并且業(yè)界在應(yīng)用層面的優(yōu)雅上線均是在內(nèi)置容器的前提下實(shí)現(xiàn)的，并且還可以配合一些列健康檢查做文章。

參看sofa-boot的健康檢查的源碼，它會(huì)在程序啟動(dòng)的時(shí)候先對(duì)springboot的組件做一些健康檢查，然后再對(duì)它自己搞得sofa的一些中間件做健康檢查，整個(gè)健康檢查的流程完畢之后（sofaboot 目前是沒(méi)法對(duì)自身應(yīng)用層面做健康檢查的，它有寫(xiě)相關(guān)接口，但是寫(xiě)死了port is ready...）才會(huì)暴露服務(wù)或者說(shuō)優(yōu)雅上線，那么它健康檢查的時(shí)機(jī)是什么時(shí)候呢：

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

可以看到它是監(jiān)聽(tīng)了ContextRefreshedEvent這個(gè)事件。在內(nèi)置容器模式中，內(nèi)置容器模式的start方法是在refreshContext方法中，方法執(zhí)行完成之后發(fā)布一個(gè)ContextRefreshedEvent事件，也就是說(shuō)在監(jiān)聽(tīng)到這個(gè)事件的時(shí)候，內(nèi)置容器必然是啟動(dòng)成功了的。

但ContextRefreshedEvent這個(gè)事件，在一些特定場(chǎng)景中由于種種原因，ContextRefreshedEvent會(huì)被監(jiān)聽(tīng)到多次，沒(méi)有辦法保證當(dāng)前是最后一次event，從而正確執(zhí)行優(yōu)雅上線邏輯。

在springboot中還有一個(gè)更加靠后的事件，叫做ApplicationReadyEvent，它的發(fā)布藏在了afterRefresh還要后面的那一句listeners.finished(context, null)中，完完全全可以保證內(nèi)置容器 端口已經(jīng)存在了，所以我們可以監(jiān)聽(tīng)這個(gè)事件去做優(yōu)雅上線的邏輯，甚至可以把中間件相關(guān)的健康檢查集成在這里。

@Component
public?class?GracefulStartupListener?implements?ApplicationListener<ApplicationReadyEvent>?{????
????@Override
????public?void?onApplicationEvent(ApplicationReadyEvent?applicationReadyEvent){
???????//注冊(cè)邏輯?優(yōu)雅上線
???????apiRegister.register(urls);
???????...
????}
}

外置容器(Jetty)優(yōu)雅上線

目前大多數(shù)應(yīng)用的部署模式不管是jetty部署模式還是docker部署模式(同樣使用jetty鏡像)，本質(zhì)上用的都是外置容器。那么這個(gè)情況就比較困難了，至少在應(yīng)用層面無(wú)法觀察到外部容器的運(yùn)行狀態(tài)，并且容器本身沒(méi)有提供什么hook給你實(shí)現(xiàn)。

那么和優(yōu)雅上線一樣，需要RPC框架提供優(yōu)雅上線接口來(lái)初始化整個(gè)應(yīng)用的生命周期，并且提供擴(kuò)展點(diǎn)給開(kāi)發(fā)者供執(zhí)行自定義的上線邏輯(上報(bào)版本探測(cè)信息等)。同樣將調(diào)用這個(gè)接口封裝成一個(gè)postStart操作，固化在jetty等外置容器的startup腳本中，保證應(yīng)用在容器啟動(dòng)之后在上線。容器執(zhí)行類(lèi)似啟動(dòng)容器 -> 健康檢查 -> 上線服務(wù)邏輯 -> 健康上線服務(wù)直至完成 的流程。

-?END -
最近熱文
? ?瘋了！成千上萬(wàn)網(wǎng)友正自爆公司薪資待遇?。?！
? ?985大學(xué)最美小姐姐，堪稱今年最強(qiáng)博士后...
? ?0.2秒居然復(fù)制了100G文件？
? ?某科技公司領(lǐng)導(dǎo)稱80后該退出IT行業(yè)，網(wǎng)友炸了！