查蘊(yùn)初 李迎接 林芷伊 李澤朋

摘要：微信作為當(dāng)之無愧的國民級應(yīng)用，系統(tǒng)復(fù)雜程度超乎想象：其后臺由三千多個移動服務(wù)構(gòu)成，每天需處理大約十的10～11次方個外部請求，整體需要每秒處理大約幾億個請求！那么微信究竟是如何保證系統(tǒng)穩(wěn)定性并有序處理各類請求的？本文的作者從技術(shù)上深入解讀了《用于擴(kuò)展微信微服務(wù)的過載控制》一文，介紹了已在微信上運(yùn)行了五年之久的過載控制系統(tǒng)DAGOR。

關(guān)鍵詞：網(wǎng)絡(luò)服務(wù)器；社交網(wǎng)絡(luò)；軟件

首先，我們能了解一些微信后臺的內(nèi)部消息；其次，作者分享了一種經(jīng)過實(shí)踐檢驗(yàn)的過載控制系統(tǒng)DAGOR，該系統(tǒng)已經(jīng)在微信上運(yùn)行了五年。友情提示，這個系統(tǒng)在設(shè)計(jì)時就考慮了微服務(wù)架構(gòu)的特殊情況，所以如果你想在自己的微服務(wù)上采用某種策略，那最好還是以這個系統(tǒng)為起點(diǎn)參考。

一、每秒需要處理幾億請求的微信后臺

現(xiàn)在的微信后臺由3000多個移動服務(wù)構(gòu)成，包括實(shí)時消息、社交網(wǎng)絡(luò)、移動支付和第三方認(rèn)證等，平臺每天能處理大約1010～1011外部請求。每個請求可能觸發(fā)更多的內(nèi)部請求，所以微信的后臺作為一個整體，需要每秒處理大約幾億個請求。

“微信的微服務(wù)包含3000多個服務(wù)，運(yùn)行在微信業(yè)務(wù)系統(tǒng)中的20000多臺機(jī)器上，隨著微信越來越流行，這個數(shù)字還在不斷增加……由于微信一直在不斷發(fā)展，它的微服務(wù)系統(tǒng)也在迅速更新。例如，從2018年3月到5月間，微信的微服務(wù)平均每天大約有1000個修改?！?/p>

微信將微服務(wù)分類為“入口層”服務(wù)（接收外部請求的前端服務(wù)）、“共享層”服務(wù)（中間層協(xié)調(diào)服務(wù)）和“基本服務(wù)”（不調(diào)用其他服務(wù)的服務(wù)，請求在這里終結(jié)）。

二、基于微服務(wù)的大型平臺過載控制的難點(diǎn)

過載控制……對于在任何不可預(yù)測的負(fù)載高峰下都要保證24x7服務(wù)大型在線應(yīng)用來說極其重要?！眰鹘y(tǒng)的過載控制機(jī)制主要用于只有少量服務(wù)組件的情況，通常包括一個較窄的“前門”，加上一些不重要的依賴?！啊F(xiàn)代的在線服務(wù)的架構(gòu)和依賴變得越來越復(fù)雜，遠(yuǎn)遠(yuǎn)超過了傳統(tǒng)過載控制的設(shè)計(jì)考慮?！卑l(fā)送到微信后臺的請求沒有單一的入口點(diǎn)，而傳統(tǒng)方式是在全局入口點(diǎn)（網(wǎng)關(guān)）上以中心化的負(fù)載監(jiān)視為主，因此無法使用。

特定請求的服務(wù)調(diào)用圖可能依賴于請求自身的數(shù)據(jù)和服務(wù)參數(shù)，甚至同一種請求的調(diào)用圖都可能不同。所以，當(dāng)特定服務(wù)出現(xiàn)過載時，很難確定應(yīng)該拒絕哪一種請求來緩解壓力。

過度的請求拒絕（特別是在調(diào)用圖深處或者請求處理后期拒絕）會浪費(fèi)大量計(jì)算資源，而且會由于高延遲而影響用戶體驗(yàn)。由于服務(wù)的調(diào)用圖非常復(fù)雜，而且在不斷變化，有效的跨服務(wù)協(xié)調(diào)的維護(hù)成本和系統(tǒng)額外開銷非常高。由于一個服務(wù)可能向它依賴的服務(wù)發(fā)出多個請求，還可能給多個后臺服務(wù)發(fā)出請求，所以在處理過載控制時必須謹(jǐn)慎。作者采用了“序列過載”來描述多于一個過載服務(wù)被調(diào)用的情況，或一個過載服務(wù)被調(diào)用多次的情況。

“序列過載給有效的過載控制帶來了挑戰(zhàn)。直覺上，當(dāng)服務(wù)過載時隨機(jī)進(jìn)行l(wèi)oad shedding能將系統(tǒng)的吞吐量維持在飽和狀態(tài)。但是，序列過載可能會導(dǎo)致吞吐量出現(xiàn)預(yù)期之外的下降……”

三、微信的過載控制系統(tǒng)DAGOR

微信的過載控制系統(tǒng)叫做DAGOR，它的目標(biāo)是給所有服務(wù)提供過載控制，因此被設(shè)計(jì)成與服務(wù)無關(guān)。過載控制運(yùn)行在單個服務(wù)器的力度上，因?yàn)橹行幕娜謪f(xié)調(diào)太昂貴了。但是，它能夠與輕量級的服務(wù)器間合作協(xié)議配合使用，后者在處理序列過載的情況時是必須的。最后，DAGOR應(yīng)當(dāng)在load shedding不可避免時盡可能維持服務(wù)的成功率。消耗在失敗的任務(wù)上的計(jì)算資源（如CPU、I/O等）應(yīng)當(dāng)保持最小。

最后針對開發(fā)者，即使你不會完全按照該論文描述的方式使用DAGOR，也提三條非常有價值的建議：

大規(guī)模微服務(wù)架構(gòu)下的過載控制必須是去中心化，每個服務(wù)必須是自動化；

過載控制應(yīng)該考慮各種反饋機(jī)制（例如DAGOR的協(xié)同控制），不要依賴于單一的開環(huán)啟發(fā)；

過載控制設(shè)計(jì)應(yīng)當(dāng)根據(jù)實(shí)際負(fù)載的處理行為進(jìn)行。

也希望未來的微信能夠越來越好，引領(lǐng)通信潮流。

參考文獻(xiàn)：

[1]呂金秋.新媒體時代微信營銷策略[J].合作經(jīng)濟(jì)與科技，2018（24）：110-111.

[2]郭銀春，王益祥.基于云服務(wù)器與微信平臺的水表系統(tǒng)設(shè)計(jì)[J].單片機(jī)與嵌入式系統(tǒng)應(yīng)用，2018，18（10）：75-77+82.

[3]CSDN資訊<2W臺服務(wù)器、每秒數(shù)億請求，微信如何不“失控”？>

[4]何平.基于日志來動態(tài)調(diào)整的服務(wù)器性能優(yōu)化的研究[J].微型電腦應(yīng)用，2018，34（11）：67-69.