微服務架構之優雅停機

1、介紹

1、介紹

微服務架構中的應用優雅停機主要是指應用實例有計劃而平滑（即不產生需要處理的事故）的退出。應用服務器的停機主要分為兩類：主動停機和被動停機，而其中主動停機和大部分的被動停機都是可以實現優雅停機。如果應用不做優雅停機，則會帶來以下情況：

數據丟失：內存的中數據尚未持久化至磁盤

文件損壞：正在操作寫的文件因沒有更新完成，導致文件損壞

請求丟失：排隊中等待處理的請求丟失

響應丟失：成功的交易還沒來得及做出響應

交易中斷：正在處理至中間狀態的交易被強制中斷

服務未下線：上游服務依然還會繼續往下游服務發送消費請求

而我們微服務的優雅升級的目標就是避免以上幾種情況，從而避免人工干預的工作量和提升微服務架構的服務高可靠。

2、使用場景

優雅停機可以解決以下場景：

KILL PID

應用意外自動退出

使用腳本命令的方式停止應用

優雅停機解決不了以下場景：

突然斷電

機器物理破壞

KILL-9 PID?或?taskkill /f /pid

3、ShutdownHook

Java的優雅停機通常通過注冊JDK的ShutdownHook（鉤子）來實現，當系統接收到退出指令后，首先標記系統處于退出狀態，不再接收新的消息，然后將積壓的消息處理完，最后調用資源回收接口將資源銷毀，最后各線程退出執行。簡單的使用demo案例如下（簡單版）：

超時控制

通常優雅退出需要有超時控制機制，如果到達超時時間仍然沒有完成退出前的資源回收等操作，則由停機腳本直接調用KILL -9 PID的方式進行強制退出，不然可能會等待很長時間。

4、微服務優雅停機

微服務的優雅停機沒有統一的解決方案，只要抓住核心思想進行設計即可：

引流 → 擋板 → 等待停機

但在微服務架構中，我們可以遵守以下建議規則來設計微服務的優雅停機機制：

所有微服務應用都應該支持優雅停機

優先注銷注冊中心注冊的服務實例

待停機的服務應用的接入點標記拒絕服務

上游服務支持故障轉移因優雅停機而拒絕的服務

根據具體業務也提供適當的停機接口

微服務應用的優雅停機根據其使用者角色的不同，而主要分為兩種類型：

微服務業務應用優雅停機設計：

微服務網關應用優雅停機設計：

5、使用案例

其余各層設備的優雅停機都可從以上兩種類型進行衍生出解決方案，如：

整個后端架構升級，則可從DNS或Nginx直接切換

Nginx層升級，則可以從DNS直接切換

在業界開源的產品中，很多產品都使用了JDK鉤子的方式來實現優雅停機，如以下產品：

Netty

DUBBO

本文轉載自公眾號【java學習之道】。

微服務 注冊

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。