微服務架構如何實現客戶端負載均衡？

考慮到微服務架構的特殊性，我以「微信」的技術架構舉例，回答題主問題。

微信開發者團隊最近一篇論文“Overload Control for Scaling WeChat Microservices（超大規模微信微服務中的過載控制）”透露了部分細節，主要講述了微服務的過載控制。

基于這篇論文，本文核心要點有二。其一，解析微信的后端; 第二，解析微信五年生產化運行過程中，得到實踐檢驗的過載控制系統DAGOR的設計思路。當然，如果你希望為自己的微服務制定策略，這是一份上手指南。

截至目前，微信后端共包含超過3000項移動服務，其中包括即時消息收發、社交網絡、移動支付以及第三方驗證等等。該平臺每天接收到的外部請求量在 10^10-10^11次之間，其中每一項請求都會觸發更多的內部微服務請求，這意味著微信后端整體每秒需要處理數億次請求。

微信的微服務系統能夠在微信業務系統中的2萬多臺設備上運行超過3000項服務。而隨著微信的廣泛普及，這一數字仍然不斷增加……伴隨著微信的不斷發展，微服務系統一直在快速迭代并進行服務更新。舉例來說，從2018年3月到5月，微信的微服務系統每天平均經歷近千次變化。

微信將其微服務分類為“入口跳轉”服務（用于接收外部請求的前端服務）、“共享跳轉”服務（中間層協調服務）以及“基本服務”（不向任何其它服務扇出，因此可充當請求接收方的服務）。

圖：微信的微服務架構

以普通的單日運行場景為例，微信的峰值請求率約為每日平均值的3倍。在一年中的某些特定時段（例如在中國的農歷新年期間），峰值工作負載甚至有可能增長至每日平均值的10倍。

基于大規模微服務平臺的過載控制挑戰

“Overload control… is essential for large-scale online applications that need to enforce 24×7 service availability despite any unpredictable load surge.”（過載控制……對于大規模在線應用程序而言至關重要，這些應用程序需要在遭遇不可預測的負載激增時實現24 x 7全天候服務可用性。）

傳統的過載控制機制專門面向具有少量服務組件、“入口”相對狹窄且依賴性較為普通的場景所設計。

“… modern online services are becoming increasingly complex in their architecture and dependencies, far beyond what traditional overload control was designed for…”（…現代在線服務在架構與依賴性方面則變得越來越復雜，這遠遠超出了傳統過載控制方案的設計目標。）

? 由于發送至微信后端的服務請求不存在單一入口點，因此在全球入口點（網關）進行集中式負載監控的傳統方案將不再適用。

? 特定請求中的服務調用圖可能取決于因請求而異的數據與服務參數，即使是相同類型的請求也可能存在這種差異。因此，當特定服務出現過載時，很難確定應該刪除哪些類型的請求以緩解過載情況。

? 過多的請求中止（特別是在調用圖中較深或請求流程內偏后的部分時）會浪費計算資源，并帶來影響用戶體驗的高延遲問題。

? 由于微信的服務DAG（有向無環圖）極其復雜且不斷發展，因此用于實現高效跨服務協調的維護成本與系統開銷都將超出可承受范圍。

由于某項服務可能會對其所依賴的服務發出多次請求，并且有可能向多項后端服務發出請求，因此我們必須高度關注過載控制。對于調用多項過載服務或多次調用單一過載服務的情況，作者在論文中專門創造了一個新的詞匯，即“后續過載”。

“Subsequent overload raises challenges for effective overload control. Intuitively, performing load shedding at random when a service becomes overloaded can sustain the system with a saturated throughput. However, subsequent overload may greatly degrade system throughput beyond that intended…”（后續過載會對過載控制機制的有效性提出挑戰。直觀來講，在服務過載時執行隨機減裁操作可以將系統的實際吞吐量維持在飽和狀態。而后續過載則可能大大降低超出預期的系統吞吐量……）

這里考慮一個簡單的場景，其中服務A對服務B進行了兩次調用。如果B開始對全部傳入請求中的半數加以拒絕，則服務A的調用成功率將下降至0.25。

DAGOR概述

微信采用的過載控制系統被稱為DAGOR，其旨在為所有服務提供過載控制功能，因此必須具有服務中立性。由于集中式全局協調將帶來高昂的實現成本，因此過載控制需要以單一機器的細粒度方式運行。然而，其中還包含有處理后續過載情況所必需的輕量級機器間協調協議。最后，當由于嚴重過載而導致的減載變得不可避免時，DASGOR應盡可能維持服務的請求成功率。換言之，其應盡量減少浪費在失敗服務任務上的計算資源（例如CPU與I/O等等）。

這里，我們有兩項基本任務需要解決：檢測過載情況，并在檢測到過載之后決定如何加以處理。

過載檢測

對于過載檢測，DAGOR著眼于待處理隊列中各請求的平均等待時間（或者說排隊時間）。排隊時間的最大優勢，在于能夠抵消呼叫圖中較低延遲的平均化影響（相較于請求處理時間等指標）。即使本地服務器本身沒有發生過載，請求處理時間也有可能增加。DAGOR可采用基于窗口的監控機制，其中的容器為1秒或者2000次請求，以先到者為準。微信顯然一直處在高效緊張地的運行狀態之中：

“For overload detection, given the default timeout of each service task being 500ms in WeChat, the threshold of the average request queuing time to indicate server overload is set to 20ms. Such empirical configurations have been applied in the WeChat business system for more than five years with its effectiveness proven by the system robustness with respect to WeChat business activities.”（對于過載檢測，假設微信中每個服務任務的默認超時為500毫秒，則表示服務器過載的平均請求排隊時間閾值將設置為20毫秒。這種基于經驗的配置方式已經在微信業務系統中應用了超過五年之久，其有效性通過系統對微信業務活動支持的穩健性表現得到了證實。）

接納控制

一旦檢測到過載狀況，我們就必須決定如何加以處理。或者更具體地講，我們需要考量放棄哪些請求。這時，我們首先需要明確一點，各項請求之間并不是平等的：

“The operation log of WeChat shows that when WeChat Pay and Instant Messaging experience a similar period of service unavailability, user complaints against the WeChat Pay service are 100x those against the Instant Messaging service.”（微信的運營日志顯示，每當與微信支付與即時消息體驗相關的服務發生不可用問題時，用戶對微信支付服務的投訴是針對即時消息收發服務的100倍。）

為了以服務中立性方式處理這個問題，每項請求在首次進入系統時都會被賦予一種業務優先級。這項優先級會隨著所有下游請求一同繼承。用戶請求的業務優先級由其請求的操作類型決定。雖然存在數百個入口點，但實際其中只有幾十個具有顯性優先級，其它所有入口點都默認屬于較低優先級。優先級設定保留在復制的哈希表當中。

圖：用于存儲微信入口服務內操作執行業務優先級的哈希表

當過載控制被設定為業務優先級n時，所有來自n+1等級的請求都將被放棄。這種方式對于混合型工作負載來說效果良好，但假定我們面對的是大量付款請求，而所有請求都具有相同的優先級（假定為p），那么一旦系統遭遇過載，我們就需要調整過載閾值以實現輕載，即將過載閾值變更為p-1。而一旦檢測到輕載，過載閾值將再次增加至p，這時我們將重新面對過載狀態。因此，要在大量具有相同優先級的請求引發超載時停止這種無意義的轉換，我們需要采用超越業務優先級的細粒度調整。

微信對此拿出了一種良好的解決方案。其增加了基于用戶ID的第二層接納控制機制。

“User priority is dynamically generated by the entry service through a hash function that takes the user ID as an argument. Each entry service changes its hash function every hour. As a consequence, requests from the same user are likely to be assigned to the same user priority within one hour, but different user priorities across hours.”（用戶優先級由入口服務通過以用戶ID為參數的哈希函數動態生成。每項入口服務每小時變更一次其哈希函數，因此來自同一用戶的請求很可能在一小時之內被分配予相同的用戶優先級，但在數小時內被分配予不同的用戶優先級。）

這就提供了公平性，同時亦能夠在相對較長的時間周期內為個人用戶提供一致的使用體驗。另外，其還有助于解決后續過載問題，因為來自被分配予高優先級用戶的請求更有可能在整體調用圖中得到及時處理。

將業務優先級與用戶優先級結合起來，即可為每個業務優先級提供配合128種用戶優先級的復合接納級別。

圖：復合接納級別

“With each admission level of business priority having 128 levels of user priority, the resulting number of compound admission levels is in the tens of thousands. Adjustment of the compound admission level is at the granule of user priority.”（由于每項業務優先級的接納級別都包含128種用戶優先級，因此其得出的復合接納級別數量將達到數萬種。對復合接納級別的調整，能夠細化至用戶優先級粒度。）

另外值得一談的是，為什么要采用用戶ID而非會話ID來解決上述問題：因為如果以會話ID為解決方案，用戶最終只會通過注銷并重新登錄的方式解決服務無影響問題，而由此帶來的重新登錄風暴將帶來新的過載沖擊！

DAGOR在每臺服務器上都維持著一套關于請求的直方圖，用于追蹤超過接納優先級的請求的大體分布情況。當在窗口期間檢測到過載時，DAGOR會移動至另一“桶”（范圍），這將使預期負載減少5%。而如果過載消失，其同樣會移動至新的“桶”（范圍），這將使預期負載增加1%.

服務器會在發送至上游服務器的每條響應消息中附帶其當前接納級別。通過這種方式，上游服務器將獲知下游服務的當前接納控制設置，甚至能夠在發送之前即對該請求執行本地接納控制操作。

因此，DAGOR的端到端過載控制系統將如下所示：

圖：DAGOR過載控制工作流

實驗

DAGOR設計有效性的最佳證明，在于其已經在微信的生產環境中擁有長達五年的良好運作記錄。不過這無法為學術論文提供必要的圖表，因此我們進行了一組模擬實驗。下圖突出顯示了基于排隊時間——而非響應時間——的過載控制成效。在后續過載的情況下，這種收益最為明顯（如圖（b）所示）。

與CoDel以及SEDA相比，在進行一次后續調用時，DAGOR憑借著后續過載機制使請求成功率提高了50%。后續請求數量越大，這種收益就越是明顯：

圖：不同工作負載類型下的過載控制

最后，在公平性方面，CoDel在高壓場景下更傾向于使用扇出量較小的服務，而DAGOR則在各類請求當中表現出大致相同的成功率水平。

圖：過載控制的公平性

構建處有系統中的三項經驗

即使你不打算完全按照微信的方式使用DAGOR，作者仍然總結出了三項寶貴的實踐經驗：

? 超大規模微服務架構下的過載控制必須在每項服務中實現分散與自治。

? 過載控制應當考慮到各種反饋機制（例如DAGOR的協調接納控制），而非僅僅依賴于開環啟發式機制。

? 應當通過對實際工作負載的處理行為進行分析，從而探索過載控制的設計思路。