如此多數據、多次數的訪問為何不失控

查蘊初 李迎接 林芷伊 李澤朋

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

關鍵詞：網絡服務器；社交網絡；軟件

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

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

現在的微信后臺由3000多個移動服務構成，包括實時消息、社交網絡、移動支付和第三方認證等，平臺每天能處理大約1010～1011外部請求。每個請求可能觸發更多的內部請求，所以微信的后臺作為一個整體，需要每秒處理大約幾億個請求。

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

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

二、基于微服務的大型平臺過載控制的難點

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

特定請求的服務調用圖可能依賴于請求自身的數據和服務參數，甚至同一種請求的調用圖都可能不同。所以，當特定服務出現過載時，很難確定應該拒絕哪一種請求來緩解壓力。

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

“序列過載給有效的過載控制帶來了挑戰。直覺上，當服務過載時隨機進行load shedding能將系統的吞吐量維持在飽和狀態。但是，序列過載可能會導致吞吐量出現預期之外的下降……”

三、微信的過載控制系統DAGOR

微信的過載控制系統叫做DAGOR，它的目標是給所有服務提供過載控制，因此被設計成與服務無關。過載控制運行在單個服務器的力度上，因為中心化的全局協調太昂貴了。但是，它能夠與輕量級的服務器間合作協議配合使用，后者在處理序列過載的情況時是必須的。最后，DAGOR應當在load shedding不可避免時盡可能維持服務的成功率。消耗在失敗的任務上的計算資源（如CPU、I/O等）應當保持最小。

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

大規模微服務架構下的過載控制必須是去中心化，每個服務必須是自動化；

過載控制應該考慮各種反饋機制（例如DAGOR的協同控制），不要依賴于單一的開環啟發；

過載控制設計應當根據實際負載的處理行為進行。

也希望未來的微信能夠越來越好，引領通信潮流。

參考文獻：

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

[2]郭銀春，王益祥.基于云服務器與微信平臺的水表系統設計[J].單片機與嵌入式系統應用，2018，18（10）：75-77+82.

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

[4]何平.基于日志來動態調整的服務器性能優化的研究[J].微型電腦應用，2018，34（11）：67-69.