Dubbo優雅停機

對於任何乙個線上應用，如何在服務更新部署過程中保證客戶端無感知是開發者必須要解決的問題，即從應用停止到重啟恢復服務這個階段不能影響正常的業務請求。理想條件下，在沒有請求的時候再進行更新是最安全可靠的，然而網際網路應用必須要保證可用性，因此在技術層面上優化應用更新流程來保證服務在更新時無損是必要的。

傳統的解決方式是通過將應用更新流程劃分為手工摘流量、停應用、更新重啟三個步驟，由人工操作實現客戶端無對更新感知。這種方式簡單而有效，但是限制較多：不僅需要使用借助閘道器的支援來摘流量，還需要在停應用前人工判斷來保證在途請求已經處理完畢。這種需要人工介入的方式運維複雜度較高，只能適用規模較小的應用，無法在大規模系統上使用。

因此，如果在容器/框架級別提供某種自動化機制，來自動進行摘流量並確保處理完已到達的請求，不僅能保證業務不受更新影響，還可以極大地提公升更新應用時的運維效率。

這個機制也就是優雅停機，目前tomcat/undertow/dubbo等容器/框架都有提供相關實現。下面給出正式一些的定義：優雅停機是指在停止應用時，執行的一系列保證應用正常關閉的操作。這些操作往往包括等待已有請求執行完成、關閉執行緒、關閉連線和釋放資源等，優雅停機可以避免非正常關閉程式可能造成資料異常或丟失，應用異常等問題。優雅停機本質上是jvm即將關閉前執行的一些額外的處理**。

在dubbo中，優雅停機是預設開啟的，停機等待時間為10000毫秒。可以通過配置dubbo.service.shutdown.wait來修改等待時間。

例如將等待時間設定為20秒可通過增加以下配置實現：

dubbo.service.shutdown.wait=20000

當使用org.apache.dubbo.container.main這種容器方式來使用 dubbo 時，也可以通過配置dubbo.shutdown.hook為true來開啟優雅停機。

基於shutdownhook方式的優雅停機無法確保所有關閉流程一定執行完，所以 dubbo 推出了多段關閉的方式來保證服務完全無損。

多段關閉即將停止應用分為多個步驟，通過運維自動化指令碼或手工操作的方式來保證指令碼每一階段都能執行完畢。

qos可通過 telnet 或 http 方式使用，具體方式請見dubbo-qos命令使用說明。

provider在接收到停機指令後

consumer在接收到停機指令後

當使用容器方式執行 dubbo 時，在容器準備退出前，可進行一系列的資源釋放和清理工。

在載入類org.apache.dubbo.config.abstractconfig時，通過org.apache.dubbo.config.dubboshutdownhook向jvm註冊 shutdownhook。

/**

* register the shutdownhook
*/public
void
register()
}

/**

* destroy all the resources, including registries and protocols.
*/public
void
dodestroy()
// destroy all the registries
abstractregistryfactory.
destroyall()
;// destroy all the protocols
destroyprotocols()
;}

執行所有protocol的destroy()，主要包括：

執行完畢，關閉jvm。

dubbo如何做到服務的無損發布？

dubbo優雅停機

Dubbo 優雅停機

對於任何乙個線上應用，如何在服務更新部署過程中保證客戶端無感知是開發者必須要解決的問題，即從應用停止到重啟恢復服務這個階段不能影響正常的業務請求。理想條件下，在沒有請求的時候再進行更新是最安全可靠的，然而網際網路應用必須要保證可用性，因此在技術層面上優化應用更新流程來保證服務在更新時無損是必要的。傳...

Dubbo應用優雅停機實踐

網上相關的帖子很多，主要方法也都是加鉤子hook，這裡我對優雅停機進行了實踐 目前不管是dubbox apache的dubbo alibaba的dubbo都沒有實現真正意義上的優雅停機 截止20191231 標紅是重點，目前jar中自帶的hook並不能滿足先從註冊中心移除 再銷毀容器的順序，且啟用h...

dubbo學習四 優雅停機

目錄 1 dubbo優雅停機概述 2 dubbo優雅停機實現 2.1 abstractregistryfactory.destroyall 2.1.1 registry.destroy zookeeperregistry 2.1.2 registry.destroy failbackregistry...