1 概念

優(yōu)雅停機是什么？網(wǎng)上說的優(yōu)雅下線、無損下線，都是一個意思。

優(yōu)雅停機，通常是指在設備、系統(tǒng)或應用程序中止運作前，先執(zhí)行一定的流程或動作，以確保數(shù)據(jù)的安全、預防錯誤并保證系統(tǒng)的整體穩(wěn)定。

一般來說，優(yōu)雅停機可以參考以下步驟以實現(xiàn)：

備份數(shù)據(jù) ：立即將內(nèi)存中的所有未保存的修改、緩存等數(shù)據(jù)保存到數(shù)據(jù)庫或磁盤中。

停止接收新的請求

處理未完成的請求

通知其他依賴組件

等待所有要素安全退出后，關(guān)閉系統(tǒng)

在具體實施時，不同的設備、不同的系統(tǒng)、不同的應用，所需要的優(yōu)雅停機步驟也不盡相同，甚至需要根據(jù)不同的場景來選擇不同的方法。

例如，在某些情況下，你可能需要讓用戶知道，系統(tǒng)即將關(guān)閉，并告訴他們應當保存所有的工作并退出系統(tǒng)；而在另一些情況下，你可能需要設計一種策略，能夠讓系統(tǒng)在無用戶介入的情況下，自動保存所有的狀態(tài)，并在下次啟動時恢復之。

但是，無論在哪種情況下，優(yōu)雅停機的目標都是保護數(shù)據(jù)，避免錯誤，并盡量減少到訪用戶或使用者的不便。

上面的步驟，其實還缺了不少基礎(chǔ)的內(nèi)容，比如，停止請求外，還要停止接收定時任務、停止接收mq消息，等待他們的完成，這2項都是我們微服務中必不可缺的能力。

因此，我希望通過本文，能夠更清晰，更詳細的講解，在我已知的真實業(yè)務場景下，如何做優(yōu)雅停機。

文中，很多內(nèi)容不會講得太詳細，需要大家有一定的搜索能力或者經(jīng)驗！

2 用案例說話

隨著微服務的興起，運維方式由docker -> k8s 變化，優(yōu)雅停機涉及到的點就越來越多！下面，我們用一個案例，說明優(yōu)雅停機中的問題和問題解決方案。

案例前：k8s 停機流程

當程序員執(zhí)行 kubectl delete pod 命令時，兩個過程開始：

網(wǎng)絡規(guī)則即將生效：

Kube-apiserver 收到 pod 刪除請求，并將 pod 的狀態(tài)更新為 Extinating at Etcd;

終結(jié)點控制器從終結(jié)點對象中刪除 Pod 的 IP;

Kuber-proxy 根據(jù) Endpoint 對象的更改更新 iptables 的規(guī)則，并且不再將流量路由到已刪除的 pod。

刪除容器：

Kube-apiserver 收到 pod 刪除請求，并將 pod 的狀態(tài)更新為 Extinating at Etcd;

Kubelet 清理節(jié)點處的容器相關(guān)資源，如存儲、網(wǎng)絡;

添加 Prestop hook 鉤子，等待流量不再發(fā)給pod;

Kubelet 將SIGTERM發(fā)送到容器;

如果容器在默認的 30 秒內(nèi)沒有退出，Kubelet 將發(fā)送 SIGKILL 并強制其退出。

k8s + springboot + nacos 案例

PreStopHook 做了2件事情：

nacos反注冊

休眠35秒

通過信號量關(guān)閉springboot程序;

其中，k8s的 terminationGracePeriodSeconds（寬限期）設置為35s。

問題

springBoot程序關(guān)閉時間只有2s, 那么該程序就無法處理完一些線程任務、異步消息、定時任務等。為什么呢？

寬限期設置了35s，PreStop休眠了35s + 一個請求的時間，超過了寬限期，那么 kubelet 就會給與 pod 增加一次性2s的寬限時間。Pod 的生命周期，2s不管程序是否正常結(jié)束，都會被Kill -9。

為什么反注冊之后需要休眠35s？

這里涉及到nacos服務發(fā)現(xiàn)原理，nacos服務變更響應時間：實時；ribbon 默認緩存刷新時間30s；因此，一開始是設置30s的，發(fā)現(xiàn)還有feign請求失敗的情況，所以設置成了35s以解決這個問題！

nacos服務變更響應時間真的是實時嗎？

其實并不一定，nacos服務發(fā)現(xiàn)是通過http和udp實現(xiàn)的，udp是實時的，http最大等待時間是10s，但是，udp端口生產(chǎn)環(huán)境可能沒有開放！所以，案例中的nacos服務發(fā)現(xiàn)僅通過http定時輪詢實現(xiàn)。

案例優(yōu)化

上面的案例可以優(yōu)化的點

nacos 反注冊后休眠35s，是否可以減少；

terminationGracePeriodSeconds 設置多少合理？

優(yōu)化點1

反注冊后休眠的35s時候受到nacos服務發(fā)現(xiàn) + ribbon 緩存刷新時間影響，正常應該是 服務發(fā)現(xiàn)時間 + 緩存刷新時間 40s才能在極端情況下保證服務停機時，不會再有feign 請求進入。

如果想要縮短這個時間

啟用udp，這個需要和運維同學商量，否則10s等待少不了；

監(jiān)聽nacos服務變更通知，發(fā)現(xiàn)服務下線后，及時刷新ribbon緩存；

/**
*訂閱nacos實例變更通知
*手動刷新ribbon服務實例緩存
*nacosclient1.4.6【1.4.1有重大缺陷，要注意】
*/
@Component
@Slf4j
publicclassNacosInstancesChangeEventListenerextendsSubscriber{

@Resource
privateSpringClientFactoryspringClientFactory;

@PostConstruct
publicvoidregisterToNotifyCenter(){
NotifyCenter.registerSubscriber(this);
}
@Override
publicvoidonEvent(InstancesChangeEventevent){
Stringservice=event.getServiceName();
//service:DEFAULT_GROUP@@demoribbonService:demo
StringribbonService=service.substring(service.indexOf("@@")+2);
log.info("####接收到微服務nacos實例變更事件:{}ribbonServiceName:{}",event.getServiceName(),ribbonService);
ILoadBalancerloadBalancer=springClientFactory.getLoadBalancer(ribbonService);
if(loadBalancer!=null){
((ZoneAwareLoadBalancer)loadBalancer).updateListOfServers();
log.info("刷新 ribbon 服務實例：{}緩存成功",ribbonService);
}
}

@Override
publicClasssubscribeType(){
returnInstancesChangeEvent.class;
}


/**
*nacos1.4.4~1.4.6需要加這個方法的實現(xiàn)，2.1.2以后版本修復了該問題
*多注冊中心時，變更事件沒有隔離，因此需要實現(xiàn)該方法來判斷事件是否需要處理
*@seeISSUE#8428-NacosInstancesChangeEventScope
***/
@Override
publicbooleanscopeMatches(InstancesChangeEventevent){
returntrue;
}

}

優(yōu)化點2

terminationGracePeriodSeconds 的值應該略大于 PreStop耗時 + springBoot 停機時間，springBoot 停機時間是由程序業(yè)務決定的（mq消息、定時任務、線程池任務、以及備份數(shù)據(jù)），網(wǎng)上的推薦做法是啟用springBoot的優(yōu)雅停機功能，并實現(xiàn)自定義的關(guān)閉邏輯。

springBoot優(yōu)雅停機的默認緩沖時間是30s，因此，terminationGracePeriodSeconds的時間個人建議10 + 30s即可。

經(jīng)過優(yōu)化后

使用 actuator shutdown 方案

有些網(wǎng)貼推薦使用 actuator shutdown 進行優(yōu)雅停機，那么看下其流程圖：

其實，真正的情況并非如上圖所示，因為調(diào)用shutdown后，springBoot就會進入優(yōu)雅停機流程，但是這個流程沒有結(jié)束，然后就會被kill -15 中斷，如果線程池沒有做好配置，線程池任務沒有結(jié)束，服務就會關(guān)閉。

//沒有設置下面參數(shù)，在kill-15時，線程池沒有執(zhí)行結(jié)束，會被強制關(guān)閉
threadPoolTaskExecutor.setWaitForTasksToCompleteOnShutdown(true);
threadPoolTaskExecutor.setAwaitTerminationSeconds(30);

3 再次優(yōu)化

mq 和 定時任務

上面的方案中，提到nacos反注冊時，其他服務監(jiān)聽反注冊事件，進行ribbon緩存刷新，那么，反注冊的服務（停機服務）自身，是否可以也監(jiān)聽該事件呢？答案是可以的。

停機的服務監(jiān)聽nacos反注冊事件，判斷是自己反注冊了，表示準備關(guān)機，那么就可以停止對mq消息的監(jiān)聽，停止定時任務，這樣就比在優(yōu)雅停機時，進行mq 和 定時任務的停止更完美。

流量控制

如果沒有使用k8s進行pod節(jié)點的流量控制，那么大概率會使用 springCloud gateway作為服務網(wǎng)關(guān)，因此，gateway 服務也應該監(jiān)聽nacos的反注冊事件，從而及時刷新ribbon的緩存，關(guān)閉停機服務的流量。

4 小結(jié)

經(jīng)過大量的資料參考、學習，最終得到的一份自己認為合格的優(yōu)雅停機方案，里面可能有較多的不專業(yè)表述，敬請諒解和指正，謝謝。

在本文的最后，還要說下，優(yōu)雅停機最大的挑戰(zhàn)并不是來源于這個優(yōu)雅停機流程，機械化的流程前人都幫忙躺過了，剩下的是業(yè)務服務自身的邏輯：

有沒有包含超過30s的業(yè)務邏輯，如執(zhí)行超過30s的請求，定時任務、線程池任務或mq消息；

服務關(guān)閉時，如何保存未完成的任務、數(shù)據(jù)，實現(xiàn)自定義的關(guān)閉邏輯；

接口邏輯是否做了冪等；

審核編輯：劉清