*作者：十眠*

“從一次常見的釋出說起，在雲上某個系統應用釋出時，重啟階段會導致較大數量的 OpenAPI、上游業務的請求響應時間明顯增加甚至超時失敗。隨著業務的發展，使用者數和呼叫數越來越多，該系統又一直保持一週釋出二次的高效迭代頻率，釋出期間對業務的影響越來越無法接受，微服務下線的治理也就越來越緊迫。”

雲原生架構的發展給我們微服務系統帶來了自動的彈性伸縮、滾動升級、分批發布等原生能力，讓我們享受到了資源、成本、穩定性的最優解，但是在應用的縮容、釋出等過程中，由於例項下線處理得不夠優雅，將會導致短暫的服務不可用，短時間內業務監控會出現大量 io 異常報錯；如果業務沒做好事務，那麼還會引起資料不一致的問題，那麼需要緊急手動訂正錯誤資料；甚至每次釋出，都需要發告示停機發布，我們的使用者會出現一段時間服務不可用。

## 微服務下線有損問題分析

減少不必要的 API 報錯，是最好的使用者體驗，也是最好的微服務開發體驗。如何解決這個在微服務領域內讓人頭疼的問題呢？在這之前我們先來了解一下為什麼我們的微服務在下線的過程中會有可能出現流量損失。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f420353783da4be5981eca2c459c35a8~tplv-k3u1fbpfcp-zoom-1.image "1.png")

如上圖所示，是一個微服務節點下線的正常流程

1.  下線前，消費者根據負載均衡規則呼叫服務提供者，業務正常。
1.  服務提供者節點 A 準備下線，先對其中的一個節點進行操作，首先是觸發停止 Java 程式訊號。
1.  節點停止過程中，服務提供者節點會向註冊中心傳送服務節點登出的動作。
1.  服務註冊中心接收到服務提供者節點列表變更的訊號後會，通知消費者服務提供者列表中的節點已下線。
1.  服務消費者收到新的服務提供者節點列表後，會重新整理客戶端的地址列表快取，然後基於新的地址列表重新計算路由與負載均衡。
1.  最終，服務消費者不再呼叫已經下線的節點

微服務下線的流程雖然比較複雜，但整個流程還是非常符合邏輯的，微服務架構是透過服務註冊與發現實現的節點感知，自然也是透過這條路子實現節點下線變化的感知，整個流程沒有什麼問題。

參考我們這邊給出的一些簡單的實踐資料，我想你的看法可能就會變得不同。從第 2 步到第 6 步的過程中，Eureka 在最差的情況下需要耗時 2 分鐘，即使是 Nacos 在最差的情況下需要耗時 50 秒；在第 3 步中，Dubbo 3.0 之前的所有版本都是使用的是服務級別的註冊與發現模型，意味著當業務量過大時，會引起註冊中心壓力大，假設每次註冊/登出動作需要花費 20～30ms，五六百個服務則需要註冊/登出花費掉近 15s 的時間；在第 5 步中， Spring Cloud 使用的 Ribbon 負載均衡預設的地址快取重新整理時間是 30 秒一次，那麼意味著及時客戶端實時地從註冊中心獲取到下線節點的訊號，依舊會有一段時間客戶端會將請求負載均衡至老的節點中。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/abb363020e2e4a9a8da966ce11f2cd30~tplv-k3u1fbpfcp-zoom-1.image "2.png")

如上圖所示，只有到客戶端感知到服務端下線並且使用最新的地址列表進行路由與負載均衡時，請求才不會被負載均衡至下線的節點上。那麼在節點開始下線的開始到請求不再被打到下線的節點上的這段時間內，業務請求都有可能出現問題，這段時間我們可以稱之為服務呼叫報錯期。

在微服務架構下，面對每秒上萬次請求的流量洪峰，即使服務呼叫報錯期只有短短几秒，對於企業來說都是非常痛的影響。在一些更極端的情況下，服務呼叫報錯期可能會惡化到數分鐘，導致許多企業不敢釋出，最後不得不每次發版都安排在凌晨兩三點。對於研發來說每次發版都是心驚膽顫，苦不堪言。

## 無損下線技術

透過對微服務下線的流程分析，我們理解了解決微服務下線問題的關鍵就是：保證每一次微服務下線過程中，儘可能縮短服務呼叫報錯期，同時確保待下線節點處理完任何發往該節點的請求之後再下線。

那麼如何縮短服務呼叫報錯期呢？我們想到了一些策略：

1.  將步驟 3 即節點向註冊中心執行服務下線的過程提前到步驟 2 之前，即讓服務登出的通知行為在應用下線前執行，考慮到 K8s 提供了 Prestop 介面，那麼我們就可以將該流程抽象出來，放到 K8s 的 Prestop 中進行觸發。 
1.  如果註冊中心能力不行，那麼我們是否有可能服務端在下線之前繞過註冊中心直接告知客戶端當前服務端節點下線的訊號，該動作也可以放在 K8s 的 Prestop 介面中觸發。 
1.  客戶端在收到服務端通知後，是否可以主動重新整理客戶端的地址列表快取。

如何儘可能得保證服務端節點在處理完任何發往該節點的請求之後再下線？站在服務端視角考慮，在告知了客戶端下線的訊號後，是否可以提供一種等待機制，保證所有的在途請求以及服務端正在處理的請求被處理完成之後再進行下線流程。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/19d814deee664a94bb4775552fabf5cd~tplv-k3u1fbpfcp-zoom-1.image "3.png")

如上圖所示，我們透過以上這些策略可以確保服務消費者端儘可能早實時地感知到服務提供者節點下線的行為，同時服務提供者會確保所有在途請求以及處理中的請求處理完成之後，再進行服務下線。這些想法看起來沒什麼問題，接下來看一下我們是如何在 Spring Cloud 跟 Dubbo 服務框架中實現的。

首先我們需要在服務提供者程式中內建一個 HttpServer 向外暴露 /offline 介面，用於接受主動登出的通知。我們可以在 K8s 的 Prestop 中配置 curl http://localhost:20001/offline 觸發主動登出介面。該介面收到 offline 命令後，透過觸發呼叫註冊中心中下線例項的介面或者透過呼叫微服務程式中的 ServiceRegistration.stop 介面執行服務登出動作，使得我們在停止微服務之前完成向註冊中心進行節點地址的下線動作。

我們在 Prestop 介面中還要實現一個能力就是主動通知的能力。在 Dubbo 框架中是比較好實現的，因為 Dubbo 本身就是長連線的模型，我們可以發現 Dubbo 在服務提供者中維護了與所有服務消費者連線的 Channel 集合，在收到 offline 命令後，向所有維護中的 Channel 傳送一個 ReadOnly 訊號，標記該 Channel 為只讀狀態，Dubbo 的消費者收到 ReadOnly 訊號後，將不再往該服務提供者傳送請求，從而實現主動通知的效果。對於 Spring Cloud 框架而言實現思路也是類似的，由於 Spring Cloud 呼叫的請求是沒有 Channel 的模型，因此我們在收到 offline 命令後，我們在請求的 Response Header 中帶上 ReadOnly 標籤，服務消費者收到 ReadOnly 標籤後，會主動重新整理負載均衡 Ribbon 快取，保證不再有新的請求訪問下線過程中的服務提供者。

我們服務提供者端需要等待所有在途請求處理完成之後，再進行應用停止流程。由於業務的不確定性，請求處理時長是不確定的，那麼服務提供者端需要等待多久才可以等到所有在途請求處理完成呢？為了解決這個問題，我們設計了一種自適應等待的策略。我們讓應用在下線前會有一段自適應等待的時期，我們對所有進入服務提供者以及呼叫完成的流量進行統計與計算。在這個過程中應用會一直等待，直到應用處理完成所有流向當前應用的流量之後再進行停機下線流程。

透過服務提前登出、主動通知以及自適應等待這三種策略，我們實現了微服務無損下線的能力。從而避免微服務節點下線過程中存在較長的服務報錯期，解決了釋出過程中業務流量損失的問題。

## 大規模下無損下線實踐

到目前為止，以上的一系列解決思路與策略都看起來非常的完美，但是當我們面對雲上客戶時，特別是在面對大規模的微服務場景下，無損下線方案在落地的過程中依舊碰到了許多問題。雲上某客戶生產環境的 Spring Cloud 應用在接入我們的方案之後，釋出的過程中依舊出現了大量的錯誤ErrorCode: ServiceUnavailable。我們跟客戶一起分析排查之後，我們定位到問題的根因是有些 Consumer 沒能及時收到 Provider 的下線通知，即使服務端節點已經下線了，依舊有流量訪問下線的服務端節點。在大規模之下，註冊中心的通知及時性是不能保證的，我們還意識到 “在收到 offline 命令後，我們可以在收到請求的返回值中帶上 ReadOnly 標籤” 這個方式的及時性也不能保證，特別是在QPS不大、RT較長、應用的節點數量過多的情況下，有許多 Consumer 是沒能收到 Provider 下線通知的。我們排查了各個 Consumer 節點收到 ReadOnly 標籤的日誌，發現確實有不少 Consumer 沒有日誌記錄，證明了我們的懷疑。

### 主動通知

為了解決大規模實踐中的問題，我們必須有一種更加實時可靠的主動通知方案。考慮到 Spring Cloud 呼叫的請求是沒有 Channel 的模型，那麼我們就需要在 Spring Cloud 服務提供者端維護最近一段時間內呼叫過該例項的服務消費者地址列表。在收到 offline 命令後，服務提供者將會遍歷快取在記憶體中的服務消費者地址列表，並對每一個 Consumer 發起一次 GoAway 的 Http 呼叫。當然我們需要在服務消費者對外暴露的 HttpServer 中增加接收 GoAway 通知的介面。當服務消費者收到呼叫後，服務消費者會主動重新整理當前節點的負載均衡 Ribbon 快取，並且在流量路由的過程中隔離掉髮送 GoAway 請求的 Provider 節點，這樣當前服務消費者就不會再向對應的 Provider 節點發起請求。當 Provider 對每一個 Consumer 節點進行 GoAway 呼叫後，則表示該服務提供者已經將“下線中”的訊號通知至所有活躍的消費者，透過這個方式我們實現了大規模下相對可靠的主動通知的能力。

### 可觀測性建設

無損下線的流程非常複雜，同時還涉及到多個節點之間的通知機制，特別是在大規模之下，下線流程的完整性以及可靠性的確認變得非常複雜與繁瑣。我們需要一種完善的可觀測能力，幫助我們觀測下線的流程有無任何問題。當出現問題的時候，需要可觀測能力幫助我們快速定位問題以及根因。

**如何判斷我們每次釋出應用的無損下線是否生效？**

最直觀的方式那就是看業務的流量，我們需要站在 Provider 視角上看業務流量是否在 Provider 下線前停止，並且在這個過程中業務流量沒有損失。想到這一塊，那我們就應該提供 Provider 節點的流量情況，並且需要關聯無損下線的事件。這樣就可以直觀地看到先是觸發了無損下線，在沒有業務流量之後再停止應用的完整無損下線流程。

-   **Metrics 流量檢視**

我們藉助可觀測 Metrics 能力，對於每個 Pod 的業務流量進行統計與展示，同時在流量執行的過程中關聯無損下線事件，這樣就可以直觀地看到到微服務節點下線過程有無問題，一目瞭然。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/93a8be92442244d7abddaa5414dd6cd5~tplv-k3u1fbpfcp-zoom-1.image "4.png")

**如何判斷無損下線的流程執行符合我們的預期？**

按照我們主動通知的邏輯，我們微服務節點下線過程中，需要對每一個 Consumer 節點進行 GoAway 呼叫。設想一下，在大規模場景下，假設當前應用有 5 個消費者應用，且每個應用有 50 個節點，那麼我們如何確保 GoAway 通知到了這 250 個 Consumer 中的每一個 Consumer ？無損下線流程本身就非常複雜，特別在大規模場景下，無損下線可觀測問題的複雜度急劇上升。我們想到可以藉助 Tracing 能力提升無損下線的可觀測能力。

-   **依賴 Tracing 的無損下線可觀測新思路**

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d3a1a31a537146a38a0e1f57ee00e29c~tplv-k3u1fbpfcp-zoom-1.image "5.png")

如上圖該場景，我們對 108 節點進行縮容操作，我們就可以得到一條 Tracing 鏈路，其中包含主動通知、服務登出、應用停止等幾個步驟，並且我們可以在每個步驟中看到所需的資訊。

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e455c058574e499d8f9041724dda8566~tplv-k3u1fbpfcp-zoom-1.image "6.png")

在主動通知環節我們可以看到當前 Provider 節點對哪些 Consumer 進行 GoAway 請求的呼叫，如下圖所示我們將主動通知 10.0.0.90、10.0.0.176 兩個 Consumer 節點。

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/89254318f5eb497cb2c7e74592522c10~tplv-k3u1fbpfcp-zoom-1.image "7.png")

當 Consumer 收到 GoAway 呼叫後，會進行負載均衡列表的重新整理以及路由的隔離，我們將在負載均衡地址列表中顯示最新抓到的當前 Consumer 對於當前服務快取的最新地址列表，我們可以在下圖中看到，地址列表中只剩下 10.0.0.204 這個服務提供者節點的呼叫地址。

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a8f58b328093405399dc4178986ba1a3~tplv-k3u1fbpfcp-zoom-1.image "8.png")

我們也可以看到 Spring Cloud 向 Nacos（註冊中心）執行服務下線的呼叫結果，登出成功。

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b77f2e60122f4089a1d13ff219e10dd5~tplv-k3u1fbpfcp-zoom-1.image "9.png")

我們發現透過將無損下線的 workflow 抽象成 Tracing 結構的策略，可以幫助我們降低大規模場景、複雜鏈路下無損下線問題的排查成本，幫助我們更好地解決大規模下微服務下線時流量無損的問題。

## 總結

軟體迭代過程中，除了風險控制，在微服務領域還有一個常見的問題就是應用上下線過程中的流量治理，目的也比較明確，確保應用在釋出、擴縮容、重啟等場景時，不會損失任何業務流量損失。無損下線技術正是在這樣的背景下應運而生的，他解決了變更過程中的業務流量損失問題，也是流量治理體系中非常重要的一個環節。無損下線功能有效地保證我們業務流量的平滑，提升了微服務開發的幸福度。

MSE 無損下線功能也隨著客戶場景的豐富在不斷演進與完善。值得一提的是，我們在實踐微服務治理的過程中開源了 OpenSergo 這個專案，旨在推動微服務治理從生產實踐走向標準。歡迎感興趣的同學們一起參與討論與共建，一起來定義微服務治理的未來。

如何聯絡我們，歡迎加入 OpenSergo 釘釘交流群：34826335

大規模 Spring Cloud 微服務無損上下線探索與實踐

相關文章