我們先來理壹下過載可能導致的壹些現象。假設後臺模塊系統極限請求量是60萬，我們知道當實際請求量超過這個數值就會過載，那麽過載會發生什麽情況？是不是發送了70萬請求過來，只有60萬之外的那10萬請求不能被處理？答案顯然不是，實際情況要比這個糟很多。很顯然系統壹旦過載，可能就只能正常處理20萬的請求，原來的60萬極限值處理能力是保不住的，甚至還有可能雪崩，直至毫無處理能力。當然，這裏面的原因有很多，比如無效響應，失敗重試，級聯傳遞等等。
假如壹時間好多人發送了搖壹搖請求，這些請求都依次入隊準備去調用尋找同搖好友的CGI並等待響應結果。但是隊列很長，假設這些請求的超時時間是5秒，等待時間如果6秒過長就會導致RPC超時，壹旦超時調用方可能直接關閉不再等待響應，等隊列排到後執行完邏輯返回的響應調用方此時並不接收也等於是屬於無效的響應了。來舉個栗子，春運快到了，妳擠在車站排隊買車票，假設最後壹班發車只有60分鐘了，窩了個大叉，當妳排隊了半天到達售票窗口時已經用時80分鐘了，這時候售票員再給妳吐出壹張車票已經毫無意義了，車都跑了。這也叫“無效輸出”。
當然除了大部分無效的響應處理耗走了資源，別忘了還有失敗重試。壹般RPC框架都會設置失敗重試機制，當請求得不到響應調用端會重試，如果壹時間失敗過多將會導致短時間內大量重試請求的發起，導致進壹步過載，無疑是對本已經並無富裕的系統負載雪上加霜，滾雪球效應。
由於采用微服務架構，各模塊之間的調用相互影響。由於服務依賴的復雜性當前模塊的雪崩會導致上遊模塊的變慢，性能下降，如果此時上遊模塊也開始過載，繼續向上級聯，從而導致整個系統崩潰。怎麽理解呢？假設壹個餐廳裏的2個廚師，A桌定了2個大菜烹飪時間很長，那麽就會影響傳菜員的上菜速度，傳菜員要等待，假設全店傳菜員有限只有2個都在等廚師出A桌的2個菜後才能去服務其他桌，這個時候就影響了整個餐廳的顧客的用餐速度，最終可能導致好幾桌的顧客都吃不上菜且罵罵咧咧跑了。其實這個在Hystrix裏采用了資源隔離來解決這個問題，即壹個傳菜員只服務於壹桌，A服務員只服務A桌，B服務B桌，A慢的話就A這壹桌慢，B桌的傳菜員只傳他B桌的菜哪怕閑著玩手機也不理其他桌。
談完原因談解決方法。該怎麽處理呢？其實Hystrix的這套思想很好了，基本思想核心也相似，但今天主要是談微信後臺實踐的解決方案。
常見的過載保護方法
1.減少需求：調用端的請求限速
2.避免響應超時：根據調用端超時，設置T超時時間；控制隊列長度，容納T超時時間內的請求。
調用端限速
限多了，服務器能力沒有充分利用，限少了，過載問題沒解決。而且過載時，響應時間會階梯式上漲，這樣超時時間就會 波動 ，隊列長度難設定。雖然極限能力 絕對值 比較難找，但服務器最佳負載點容易找。所以過載保護的目標：盡量讓服務端維持在最佳負載點， 讓有效輸出接近最佳吞吐 。
古希臘水鐘
那如何維持在最佳負載點呢？水鐘的啟示：反饋控制系統。
如圖，圖中的浮子上浮，上水箱下水減速，相反如果下沈則加速上水箱下水。浮子起到了穩定液位的作用，使得中水箱的水位相對穩定，往下水箱的滴水速率自然也相對穩定，使得計時相對準確。
那麽OK啦，也就搞壹個像浮子壹樣的機制，多了及早拒絕，降低通過率，少了緩慢提升通過率。
1、通過反饋動態調整通過率：及早拒絕
根據CPU使用率和隊列等待時間，控制輸入，這裏有個算法FastReject V1計算的是 通過率 （ 過載時 按壹定概率通過請求），算法公式暫不展示，主要講究的是快降慢升。觸發降低通過率的場景比如有：比如每隔壹秒統計壹下隊列等待時間，超過n豪秒就降低通過率，或者當前CPU使用率超過閾值（比如85%）也降低通過率。及時反饋控制，不讓隊列等很久等到輪到自己被處理後前端已經關閉了請求，導致無效的響應。這樣請求要麽超載被直接拒絕，要麽是有效響應，保持原來的處理能力，不讓過載雪崩。這就是出隊時再判斷超時還是入隊時就判斷的區別。記得這個在Hystrix限流熔斷裏叫做“降級返回”。
2、同時計算業務的優先級權重：優先服務重要業務
這有點類似早高峰的公交專用道了，由公交車優先通行。實現其實也比較簡單，為每個業務（CGI）指定壹個優先級（這個優先級可以由後臺根據業務實際配置），每個請求帶個是屬於什麽業務的標識，FastReject對每個業務優先級維持壹個通過率，低優先級通過率降為0，開始拒絕更高優先級。比如聊天消息發送的優先級為1，上傳文件為2，數字越小優先級越高。當上傳文件的通過率降為0後開始降聊天消息的通過率，這樣保證了優先服務重要業務。這個在Hystrix裏類似服務的“優雅降級”。
這裏的優先級信息傳遞用的是RPC COOKIE。因為RPC框架支持cookie，那就剛好借用類似http cookie 的思想，請求/響應包預留cookie 字段，請求攜帶cookie跨模塊自動傳遞。比如CGI_ID標識或者下面分組提到的用戶ID。
3、用戶分組：保證要不過第壹次就不過
註意了，這裏的內容大家可能會比較感興趣。這裏要從剛剛上面的那個優先級說起。我們知道，微服務架構各模塊之間的調用相互影響，如果壹個請求服務端需要請求多個模塊才能處理完邏輯返回結果。那假如說請求R需要經過A模塊請求B模塊，B模塊再請求C，B再請求D等等（註意這裏B需要同時請求C、D兩個模塊獲取結果），那麽如果請求通過了A模塊的通過率，C模塊的通過率，到D模塊沒通過，那麽前面的處理是不是都白費了，又違背了我們之前所做的及時拒絕無效響應的原則。那怎麽解決呢？這裏采用了用戶分組的方式。舉個例子，比如現在根據QQ號對用戶進行分組，從0-9取尾號散列分為10組。QQ號為123的請求過來，首先用戶是被分到3組的，如果在C模塊被拒絕，那麽該用戶乃至該組的其他用戶直接在D模塊或者後續E,F等模塊的調用都會被全部拒絕，這就是按組拒絕。保證壹個用戶要不過第壹次請求就不過，不會說在聊天聊壹半發不了消息了或者消息在中途某個服務才開始失敗。 用戶分組思想類似單雙號限行。
這裏有個有趣的事情，比如某用戶被分到3組，3組被拒，那麽他是不是每次過來都是被拒的，這要是搶紅包那妳不是會直呼“不公平”。所以這裏做個小調整，如果這裏每隔壹段時間變換散列算法，前壹分鐘123可能是3組，後面可能是7組，這樣來解決同壹個用戶每次來都被拒的情況，而其他用戶都不會被拒的情況，也算是公平了。
4、讓調用端也帶FastReject接收服務端反饋：服務不行調用端就直接不發起請求了
這壹點也很好理解，RPC將每次返回信息也反饋給調用端，調用端在調RPC前先自我檢查，看看服務是不是已經不行了，如果不行了就幹脆直接不發起請求過來了，避免請求過多。這壹點有點類似Hystrix的熔斷器機制，接收反饋並自動作熔斷操作，服務降級。
總結：實際上，這和Hystrix思想其實大同小異，可以看下 《通俗壹點講“限流熔斷之Hystrix”》 就會發現太多的異曲同工之妙。就到這裏，說好的淺談輒止的，感謝品閱~~。
恭祝大家新年快樂！萬事大吉！
相關文獻：
《Overload control for scaling WeChat microservices》
《10億紅包從天而降，揭秘微信搖壹搖背後的技術細節》