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

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

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

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

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

圖：微信的微服務(wù)架構(gòu)

以普通的單日運(yùn)行場(chǎng)景為例，微信的峰值請(qǐng)求率約為每日平均值的3倍。在一年中的某些特定時(shí)段（例如在中國(guó)的農(nóng)歷新年期間），峰值工作負(fù)載甚至有可能增長(zhǎng)至每日平均值的10倍。

基于大規(guī)模微服務(wù)平臺(tái)的過(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ò)載控制……對(duì)于大規(guī)模在線應(yīng)用程序而言至關(guān)重要，這些應(yīng)用程序需要在遭遇不可預(yù)測(cè)的負(fù)載激增時(shí)實(shí)現(xiàn)24 x 7全天候服務(wù)可用性。）

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

“… modern online services are becoming increasingly complex in their architecture and dependencies, far beyond what traditional overload control was designed for…”（…現(xiàn)代在線服務(wù)在架構(gòu)與依賴性方面則變得越來(lái)越復(fù)雜，這遠(yuǎn)遠(yuǎn)超出了傳統(tǒng)過(guò)載控制方案的設(shè)計(jì)目標(biāo)。）

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

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

•過(guò)多的請(qǐng)求中止（特別是在調(diào)用圖中較深或請(qǐng)求流程內(nèi)偏后的部分時(shí)）會(huì)浪費(fèi)計(jì)算資源，并帶來(lái)影響用戶體驗(yàn)的高延遲問(wèn)題。

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

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

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

這里考慮一個(gè)簡(jiǎn)單的場(chǎng)景，其中服務(wù)A對(duì)服務(wù)B進(jìn)行了兩次調(diào)用。如果B開(kāi)始對(duì)全部傳入請(qǐng)求中的半數(shù)加以拒絕，則服務(wù)A的調(diào)用成功率將下降至0.25。

DAGOR概述

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

這里，我們有兩項(xiàng)基本任務(wù)需要解決：檢測(cè)過(guò)載情況，并在檢測(cè)到過(guò)載之后決定如何加以處理。

過(guò)載檢測(cè)

對(duì)于過(guò)載檢測(cè)，DAGOR著眼于待處理隊(duì)列中各請(qǐng)求的平均等待時(shí)間（或者說(shuō)排隊(duì)時(shí)間）。排隊(duì)時(shí)間的最大優(yōu)勢(shì)，在于能夠抵消呼叫圖中較低延遲的平均化影響（相較于請(qǐng)求處理時(shí)間等指標(biāo)）。即使本地服務(wù)器本身沒(méi)有發(fā)生過(guò)載，請(qǐng)求處理時(shí)間也有可能增加。DAGOR可采用基于窗口的監(jiān)控機(jī)制，其中的容器為1秒或者2000次請(qǐng)求，以先到者為準(zhǔn)。微信顯然一直處在高效緊張地的運(yùn)行狀態(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.”（對(duì)于過(guò)載檢測(cè)，假設(shè)微信中每個(gè)服務(wù)任務(wù)的默認(rèn)超時(shí)為500毫秒，則表示服務(wù)器過(guò)載的平均請(qǐng)求排隊(duì)時(shí)間閾值將設(shè)置為20毫秒。這種基于經(jīng)驗(yàn)的配置方式已經(jīng)在微信業(yè)務(wù)系統(tǒng)中應(yīng)用了超過(guò)五年之久，其有效性通過(guò)系統(tǒng)對(duì)微信業(yè)務(wù)活動(dòng)支持的穩(wěn)健性表現(xiàn)得到了證實(shí)。）

接納控制

一旦檢測(cè)到過(guò)載狀況，我們就必須決定如何加以處理?；蛘吒唧w地講，我們需要考量放棄哪些請(qǐng)求。這時(shí)，我們首先需要明確一點(diǎn)，各項(xiàng)請(qǐng)求之間并不是平等的：

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

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

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

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

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

“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)先級(jí)由入口服務(wù)通過(guò)以用戶ID為參數(shù)的哈希函數(shù)動(dòng)態(tài)生成。每項(xiàng)入口服務(wù)每小時(shí)變更一次其哈希函數(shù)，因此來(lái)自同一用戶的請(qǐng)求很可能在一小時(shí)之內(nèi)被分配予相同的用戶優(yōu)先級(jí)，但在數(shù)小時(shí)內(nèi)被分配予不同的用戶優(yōu)先級(jí)。）

這就提供了公平性，同時(shí)亦能夠在相對(duì)較長(zhǎng)的時(shí)間周期內(nèi)為個(gè)人用戶提供一致的使用體驗(yàn)。另外，其還有助于解決后續(xù)過(guò)載問(wèn)題，因?yàn)閬?lái)自被分配予高優(yōu)先級(jí)用戶的請(qǐng)求更有可能在整體調(diào)用圖中得到及時(shí)處理。

將業(yè)務(wù)優(yōu)先級(jí)與用戶優(yōu)先級(jí)結(jié)合起來(lái)，即可為每個(gè)業(yè)務(wù)優(yōu)先級(jí)提供配合128種用戶優(yōu)先級(jí)的復(fù)合接納級(jí)別。

圖：復(fù)合接納級(jí)別

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

另外值得一談的是，為什么要采用用戶ID而非會(huì)話ID來(lái)解決上述問(wèn)題：因?yàn)槿绻詴?huì)話ID為解決方案，用戶最終只會(huì)通過(guò)注銷并重新登錄的方式解決服務(wù)無(wú)影響問(wèn)題，而由此帶來(lái)的重新登錄風(fēng)暴將帶來(lái)新的過(guò)載沖擊！

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

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

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

圖：DAGOR過(guò)載控制工作流

實(shí)驗(yàn)

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

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

圖：不同工作負(fù)載類型下的過(guò)載控制

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

圖：過(guò)載控制的公平性

構(gòu)建處有系統(tǒng)中的三項(xiàng)經(jīng)驗(yàn)

即使你不打算完全按照微信的方式使用DAGOR，作者仍然總結(jié)出了三項(xiàng)寶貴的實(shí)踐經(jīng)驗(yàn)：

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

•過(guò)載控制應(yīng)當(dāng)考慮到各種反饋機(jī)制（例如DAGOR的協(xié)調(diào)接納控制），而非僅僅依賴于開(kāi)環(huán)啟發(fā)式機(jī)制。

•應(yīng)當(dāng)通過(guò)對(duì)實(shí)際工作負(fù)載的處理行為進(jìn)行分析，從而探索過(guò)載控制的設(shè)計(jì)思路。

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