雲棲號資訊:【點擊查看更多行業資訊】
在這裏您可以找到不同行業的第一手的上雲資訊,還在等什麼,快來!
對於微服務來說,服務的優雅上下線是必要的。就上線來說,如果組件或者容器沒有啓動成功,就不應該對外暴露服務,對於下線來說,如果機器已經停機了,就應該保證服務已下線,如此可避免上游流量進入不健康的機器。
優雅下線
基礎下線(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程序肯定是不知所措的。
而在Spring Boot中,其實已經幫你實現好了一個shutdownHook,支持響應Ctrl+c或者kill -15 TERM信號。
隨便啓動一個應用,然後Ctrl+c一下,觀察日誌就可知, 它在AnnotationConfigEmbeddedWebApplicationContext這個類中打印出了疑似Closing...的日誌,真正的實現邏輯在其父類
AbstractApplicationContext中(這個其實是Spring中的類,意味着什麼呢,在Spring中就支持了對優雅停機的擴展)。
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中的下線
好有人說了,我用Socker部署服務,支不支持優雅下線。
那來看看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命令。
優雅上線
優雅上線相對來說可能會更加困難一些,因爲沒有什麼默認的實現方式,但是總之呢,一個原則就是確保端口存在之後才上線服務。
Spring Boot內置容器優雅上線
這個就很簡單了,並且業界在應用層面的優雅上線均是在內置容器的前提下實現的,並且還可以配合一些列健康檢查做文章。
參看sofa-boot的健康檢查的源碼,它會在程序啓動的時候先對Spring Boot的組件做一些健康檢查,然後再對它自己搞得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,從而正確執行優雅上線邏輯。
在Spring Boot中還有一個更加靠後的事件,叫做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腳本中,保證應用在容器啓動之後在上線。容器執行類似啓動容器 -> 健康檢查 -> 上線服務邏輯 -> 健康上線服務直至完成 的流程。
【雲棲號在線課堂】每天都有產品技術專家分享!
課程地址:https://yqh.aliyun.com/live立即加入社羣,與專家面對面,及時瞭解課程最新動態!
【雲棲號在線課堂 社羣】https://c.tb.cn/F3.Z8gvnK
原文發佈時間:2020-07-02
本文作者: fredalxin
本文來自:“dockone”,瞭解相關信息可以關注“dockone”