流量激增不宕機，服務限流系統架構解密
今天我們來探索一下在分散式系統架構中的另一個常用的設計：服務限流。 那麼，什麼是「服務限流」呢？
解釋「服務限流」之前，我們來看一下前些時間網上很火的一個段子，說的是新浪微博的一名工程師正在家裡辦婚禮，突然接到公司的電話要緊急處理線上流量激增的問題，那天應該是某當紅明星突然在微博上公佈戀情，微博流量突增好幾倍，導致系統功能出現不穩定，使用者訪問不暢。然後這名工程師就只好晾開新娘，在婚禮現場穿著西裝開啟筆記本除錯程式碼了。
當時這名工程師內心肯定是崩潰的：為啥要在今天公佈戀情！等我把系統的擴容和服務限流機制做好先啊。
哈哈，看完了段子，基本上服務限流的作用也就明白：
「服務限流」其實是指當系統資源不夠，不足以應對大量請求，即系統資源與訪問量出現矛盾的時候，為了保證有限的資源能夠正常服務，因此我們對系統按照預設的規則進行流量限制或功能限制的一種方法。
一、為什麼要做服務限流設計
再舉一個我們生活中的例子：一些熱門的旅遊景點，往往對每日的旅遊參觀人數有嚴格的限制，比如北京的故宮、歡樂谷等，每天只賣固定數目的門票，如果去的晚了，可能當天的票就已經賣完，當天就無法進去遊玩，即使進去，排隊也能排到你懷疑人生。
為什麼旅遊景點要做這樣的限制呢？多賣一些門票多賺一些錢豈不是更好？
其實對於旅遊景點而言，她們也很無奈，因為景點的服務資源有限，每日能服務的人數也有限，一旦放開限制，景點的工作人員就會不夠用，衛生情況也得不到保障，安全也存在隱患，超密集的人群也會嚴重影響遊客體驗。但由於景區名氣大，來遊玩的旅客絡繹不絕，遠超出了景區的承載能力，因此景區只好做出限制每日人員流量的舉措。
同理，在IT軟體行業中，系統服務也是這樣。
如果你的系統理論是時間單位內可服務100W使用者，但是今天卻突然來了300W使用者，由於使用者流量的隨機性，如果不限流，很有可能這300W使用者瞬間就壓垮了系統，導致所有人都得不到服務。
因此為了保證系統至少還能為100W使用者提供正常服務，我們需要對系統進行限流設計。
有人可能會想，既然會有300W使用者來訪問，那為啥系統不乾脆設計成能足以支撐這麼大量使用者的叢集呢？
這是個好問題。如果系統是長期有300W的使用者來訪問，肯定是要做上述升級的，但是常常面臨的情況是，系統的日常訪問量就是100W，只不過偶爾有一些不可預知的特定原因導致短時間的流量激增，這個時候，公司往往出於節約成本的考慮，不會為了一個不常見的尖峰來把我們的系統擴容到最大的尺寸。
二、服務限流應該怎麼做
1、限流模式
對系統服務進行限流，一般有如下幾個模式：
熔斷
這個模式需要系統在設計之初，就把熔斷措施考慮進去。當系統出現問題時，如果短時間內無法修復，系統要自動做出判斷，開啟熔斷開關，拒絕流量訪問，避免大流量對後端的過載請求。系統也應該能夠動態監測後端程式的修復情況，當程式恢復穩定時，可以關閉熔斷開關，恢復正常服務。
服務降級
將系統的所有功能服務進行一個分級，當系統出現問題，需要緊急限流時，可以把不是那麼重要的功能進行降級處理，停止服務，這樣可以釋放出更多的資源供給核心功能的去用。
例如在電商平臺中，如果突發流量激增，可臨時將商品評論、積分等非核心功能進行降級，停止這些服務，釋放出機器和CPU等資源來保障使用者正常下單，而這些降級的功能服務可以等整個系統恢復正常後，再來啟動，進行補單/補償處理。除了功能降級以外，還可以採納不直接操作資料庫，而全部讀快取、寫快取這樣的方式作為臨時降級方案。
延遲處理
這個模式需要在系統的前端設定一個流量緩衝池，將所有的請求全部緩衝進這個池，不立即處理。然後後端真正的業務處理程式從這個池中取出請求依次處理，常見的可以用佇列模式來實現。這就相當於用非同步的方式減少了後端的處理壓力，但是當流量較大時，後端的處理能力有限，緩衝池裡的請求可能處理不及時，會有一定程度延遲。
特權處理
這個模式需要將使用者進行分類，通過預設的分類，讓系統優先處理需要高保障的使用者群體，其它使用者群的請求就會延遲處理或者直接不處理。
2、限制方法
那在實際專案中，對訪問流量的限制，可採用如下幾種技術方法：
熔斷技術
熔斷的技術可以重點參考Netflix的開源元件Hystrix的做法，主要有三個模組：熔斷請求判斷演算法、熔斷恢復機制、熔斷報警。
Hystrix參考連結：https://github.com/Netflix/Hystrix
計數器方法
系統維護一個計數器，來一個請求就加1，請求處理完成就減1，當計數器大於指定的閾值，就拒絕新的請求。
基於這個簡單的方法，可以再延伸出一些高階功能，比如閾值可以不是固定值，是動態調整的。另外，還可以有多組計數器分別管理不同的服務，以保證互不影響等。
佇列方法
就是基於FIFO佇列，所有請求都進入佇列，後端程式從佇列中取出待處理的請求依次處理。 基於佇列的方法，也可以延伸出更多的玩法來，比如可以設定多個佇列以配置不同的優先順序。
令牌桶方法
首先還是要基於一個佇列，請求放到佇列裡面。但除了佇列以外，還要設定一個令牌桶，另外有一個指令碼以持續恆定的速度往令牌桶裡面放令牌，後端處理程式每處理一個請求就必須從桶裡拿出一個令牌，如果令牌拿完了，那就不能處理請求了。我們可以控制指令碼放令牌的速度來達到控制後端處理的速度，以實現動態流控。
三、服務限流的注意事項
我們在做服務限流的時候，還是有一些原則和事項需要注意的：
-
實時監控： 系統必須要做好全鏈路的實時監控，才能保證限流的及時檢測和處理。
-
手動開關： 除系統自動限流以外，還需要有能手動控制的開關，以保證隨時都可以人工介入。
-
限流的效能： 限流的功能理論上是會在一定程度影響到業務正常效能的，因此需要做到限流的效能優化和控制。
四、總結
系統故障常常都是不可預測且難以避免的，因此作為系統設計師的我們，必須要提前預設各種措施，以應對隨時可能出現的系統風險。
作者：IVAN-jsjwk
來源：不止思考訂閱號（ID：bzsikao）
dbaplus社群歡迎廣大技術人員投稿，投稿郵箱：[email protected]