保障系統高可用性之限流
我們經常可以看到各大雲服務廠商號稱自己的服務五個九，這裏的五個九指的就是系統服務時間佔整體時間的99.999%，按照一年來算的話，系統宕機時間必須小於5分16秒。對於某些核心系統而言，系統服務一旦宕機會給很多下游服務和客戶帶來影響，所以一個可靠的系統必須具備高可用性。今天主要談談和系統開發相關的--限流。
1.引言
首先，借用比較火的微服務中的概念，級聯故障(Cascading failure),來說明限流的重要性。級聯故障在計算機系統中，可以描述成，某個服務節點失敗，而導致請求重新分配至其他服務節點，導致其他服務節點過載而相繼失效的問題。
下圖是wiki上，說明級聯故障的圖示。
1.1 避免資源消耗殆盡
我們如果把系統服務看做某種資源，比如掘金首頁的信息流文章，由於服務器資源有限，所以很多情況下，我們做限流的主要目的是，爲了能夠儘可能地保證服務資源不被消耗殆盡，避免導致上面講的級聯故障的問題。
1.2 服務資源管理
有些時候，由於服務產品等級不同，可能需要對用戶等級進行區分，進而控制各等級用戶使用資源的層級，這也是限流的用武之地。典型的比如Saas多租戶，對於普通客戶來說，可能只能使用共享的服務資源，而對於付費購買的客戶，可能會單獨分配服務資源，這兩者就需要使用限流進行資源分配。
1.3 避免開銷成本
隨着Serveless技術成熟，越來越多的產品遷移至無服務器架構上，這樣做的優點很多，動態擴容可以合理利用服務器資源，避免過度浪費。然而，在不同的場景下，都可能會有突發流量的問題出現，比如某個點流量翻倍，但是持續時間很短，這個時候是否採用動態擴容就會造成服務成本的上漲，而限流可能是個更好的辦法。
2.限流手段
相應地，限流方法也多種多樣，針對不同的場景，其要求也不盡相同，而瞭解這些手段，可以方便後續的系統設計和決策。
2.1 非限流措施
通常情況下，對於系統設計而言，我們需要有個兜底的方案，也就是說即使限流手段都失敗的情況下，系統依然能夠將正常的錯誤系統和提示反饋出來。常見的系統過載時，系統服務可以設置固定超時時間，服務熔斷來保證服務調用方獲得服務異常原因(理論上講，熔斷屬於限流的一種)。
2.2 服務降級
針對某些重要的服務，往往在面對大量負載時，需要將部分請求進行降級處理，因爲某些情況下，數據庫或計算資源是有限的，而單次請求計算又比較昂貴，這時就可以通過服務降級的方式，而降低系統的整體負載，比如：
如果服務返回的信息中包含大量內容，可以只將關鍵信息返回，其他信息不進行獲取。
使用緩存結果替代真實結果，可能會出現數據的不一致性，但是滿足了服務的高可用性，短暫情況下是可以允許的。
甚至直接返回固定的結果，這個策略反而很多時候簡單粗暴，可以大大降低系統的複雜度。
2.3 延遲處理
在某些內部系統中，部分請求的實時性不高，或者不需要返回結果的情況下，系統面對高負載時，可以進行延遲處理，也是變相地降低某個時間段內系統處理的頻率。簡單的做法，可以是延遲一段時間進行處理;更多的時候，需要使用消息系統做任務的轉存，方便任務處理失敗或超時情況下的重試。
2.4 服務限流
對於大部分場景而言，可能需要我們對服務的請求負載進行限流處理，保證系統負載平穩，正常。常見的限流方法如下：
計數器方式，其主要想法是通過維護計數，來保證系統運行時，不會出現過多的服務請求。
漏桶算法，漏桶算法相比計數器方式而言，增加了勻速處理流程，保證系統處理速度在過載情況下，仍然能夠勻速進行。
令牌桶算法，令牌桶算法，則是將服務請求抽象爲資源，通過系統生成令牌的方式，保證系統在某個時刻處理固定的令牌數請求，達到保護系統的目的。
固定時間窗口方式，該方法是通過指定某個固定的時間窗口內，系統可以處理的固定請求數來達到保護系統的目的。
滑動窗口方式，該方法可以解決固定時間窗口的缺陷，在固定時間窗口中，存在突發流量不能平滑處理的問題，比如，固定時間窗口是一分鐘最多處理一千次請求，而在後續的一秒鐘內，系統接收到兩千次請求，就會出現後續的一千次請求需要等待到下一個時間窗口上去。而滑動窗口通過將窗口分成若干小間隔，保證每個小間隔都能處理適當的請求，可以讓系統在面對突發的流量下，負載更加平滑。
動態限流，該類限流主要的優點在於，可以根據系統運行期狀態，動態調整限流規則。有些類似TCP擁堵算法，通過算法流程進行限流控制;有些則參考歷史負載情況，對於短期負載進行智能適應。
上述具體算法詳解與實現過程，詳見下篇文章《保障系統高可用性 之 限流(二)》
問題
常說“不要過早優化”，而限流等手段卻是需要在系統設計時就要考慮的，這兩者的關係如何權衡?
不同的限流算法，對系統負載的影響如何，如何根據系統場景來選擇合適的限流算法?
作者：編城之路
鏈接：https://juejin.im/post/5eb959c9e51d451b2e0332ea
來源：掘金
