透露了部分細節(jié)，主要講述了微服務的過載控制。

基于這篇論文，本文核心要點有二。其一，解析微信的后端; 第二，解析微信五年生產化運行過程中，得到實踐檢驗的過載控制系統(tǒng)DAGOR的設計思路。這套系統(tǒng)在設計上專門考慮到微服務架構的特殊性，如果你希望為自己的微服務制定策略，那么本文無疑是一份極好的上手指南。

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

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

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

圖：微信的微服務架構

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

基于大規(guī)模微服務平臺的過載控制挑戰(zhàn)

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

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

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

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

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

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

•由于微信的服務DAG（有向無環(huán)圖）極其復雜且不斷發(fā)展，因此用于實現(xiàn)高效跨服務協(xié)調的維護成本與系統(tǒng)開銷都將超出可承受范圍。

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

“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…”（后續(xù)過載會對過載控制機制的有效性提出挑戰(zhàn)。直觀來講，在服務過載時執(zhí)行隨機減裁操作可以將系統(tǒng)的實際吞吐量維持在飽和狀態(tài)。而后續(xù)過載則可能大大降低超出預期的系統(tǒng)吞吐量……）

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

DAGOR概述

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

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

過載檢測

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

“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毫秒。這種基于經驗的配置方式已經在微信業(yè)務系統(tǒng)中應用了超過五年之久，其有效性通過系統(tǒng)對微信業(yè)務活動支持的穩(wěn)健性表現(xiàn)得到了證實。）

接納控制

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

“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.”（微信的運營日志顯示，每當與微信支付與即時消息體驗相關的服務發(fā)生不可用問題時，用戶對微信支付服務的投訴是針對即時消息收發(fā)服務的100倍。）

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

圖：用于存儲微信入口服務內操作執(zhí)行業(yè)務優(yōu)先級的哈希表

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

微信對此拿出了一種良好的解決方案。其增加了基于用戶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.”（用戶優(yōu)先級由入口服務通過以用戶ID為參數(shù)的哈希函數(shù)動態(tài)生成。每項入口服務每小時變更一次其哈希函數(shù)，因此來自同一用戶的請求很可能在一小時之內被分配予相同的用戶優(yōu)先級，但在數(shù)小時內被分配予不同的用戶優(yōu)先級。）

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

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

圖：復合接納級別

“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.”（由于每項業(yè)務優(yōu)先級的接納級別都包含128種用戶優(yōu)先級，因此其得出的復合接納級別數(shù)量將達到數(shù)萬種。對復合接納級別的調整，能夠細化至用戶優(yōu)先級粒度。）

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

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

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

因此，DAGOR的端到端過載控制系統(tǒng)將如下所示：

圖：DAGOR過載控制工作流

實驗

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

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

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

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

圖：過載控制的公平性

構建處有系統(tǒng)中的三項經驗

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

•超大規(guī)模微服務架構下的過載控制必須在每項服務中實現(xiàn)分散與自治。

•過載控制應當考慮到各種反饋機制（例如DAGOR的協(xié)調接納控制），而非僅僅依賴于開環(huán)啟發(fā)式機制。

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

【注】論文“Overload Control for Scaling WeChat Microservices（超大規(guī)模微信微服務中的過載控制）”下載方式：關注科技行者微信公眾號（ID：techwalker）回復“微信”，即可獲取。