系列目錄

分散式架構-流量治理-服務容錯

分散式架構-流量治理-流量控制

引子

 任何一個系統的運算、儲存、網路資源都不是無限的，當系統資源不足以支撐外部超過預期的突發流量時，便應該要有取捨，建立面對超額流量自我保護的機制，這個機制就是微服務中常說的「限流」。

1.流量統計指標

• 每秒事務數（Transactions per Second，TPS）：TPS 是衡量資訊系統吞吐量的最終標準。「事務」可以理解為一個邏輯上具備原子性的業務操作。
• 每秒請求數（Hits per Second，HPS）：HPS 是指每秒從使用者端發向伺服器端的請求數（請將 Hits 理解為 Requests 而不是 Clicks，國內某些翻譯把它理解為「每秒點選數」多少有點望文生義的嫌疑）。
• 每秒查詢數（Queries per Second，QPS）：QPS 是指一臺伺服器能夠響應的查詢次數。

 目前，主流系統大多傾向使用 HPS 作為首選的限流指標，它是相對容易觀察統計的，而且能夠在一定程度上反應系統當前以及接下來一段時間的壓力。但限流指標並不存在任何必須遵循的權威法則，根據系統的實際需要，哪怕完全不選擇基於呼叫計數的指標都是有可能的。譬如下載、視訊、直播等 I/O 密集型系統，往往會把每次請求和響應報文的大小，而不是呼叫次數作為限流指標，譬如只允許單位時間通過 100MB 的流量。又譬如網路遊戲等基於長連線的應用，可能會把登陸使用者數作為限流指標，熱門的網遊往往超過一定使用者數就會讓你在登陸前排隊等候。

2.限流演演算法

對於具體如何進行限流，也有一些常見常用的設計模式可以參考使用，本節將介紹流量計數器、滑動時間窗、漏桶和令牌桶四種限流設計模式。

2.2.1 固定視窗計數器

固定一個時間段內流量計數到達閾值限流。時間視窗結束清空計數。存在跨視窗流量最多2N流量問題。

2.2.2 滑動視窗計數器

滑動時間視窗模式的限流完全解決了流量計數器的缺陷，可以保證任意時間片段內，只需經過簡單的呼叫計數比較，就能控制住請求次數一定不會超過限流的閾值，在單機限流或者分散式服務單點閘道器中的限流中很常用。不過，這種限流也有其缺點，它通常只適用於否決式限流，超過閾值的流量就必須強制失敗或降級，很難進行阻塞等待處理，也就很難在細粒度上對流量曲線進行整形，起不到削峰填谷的作用。下面筆者繼續介紹兩種適用於阻塞式限流的限流模式。

2.2.3 漏桶演演算法

在計算機網路中，專門有一個術語流量整形（Traffic Shaping）用來描述如何限制網路裝置的流量突變，使得網路報文以比較均勻的速度向外傳送。 流量整形通常都需要用到緩衝區來實現，當報文的傳送速度過快時，首先在緩衝區中暫存，然後再在控制演演算法的調節下均勻地傳送這些被緩衝的報文。常用的控制演演算法有漏桶演演算法（Leaky Bucket Algorithm）和令牌桶演演算法（Token Bucket Algorithm）兩種，這兩種演演算法的思路截然相反，但達到的效果又是相似的。

漏桶：一個水池，每秒以 X 升速度注水，同時又以 Y 升速度出水。漏桶在程式碼實現上非常簡單，就是一個以請求物件作為元素的先入先出佇列（FIFO Queue），佇列長度就相當於漏桶的大小，當佇列已滿時便拒絕新的請求進入。漏桶實現起來很容易，困難在於如何確定漏桶的兩個引數：桶的大小和水的流出速率。

2.2.4 令牌桶演演算法

假設我們要限制系統在 X 秒內最大請求次數不超過 Y，那就每間隔 X/Y 時間就往桶中放一個令牌，當有請求進來時，首先要從桶中取得一個准入的令牌，然後才能進入系統處理。任何時候，一旦請求進入桶中卻發現沒有令牌可取了，就應該馬上失敗或進入服務降級邏輯。

2.2.5 分散式限流

 前面討論過的那些限流演演算法，直接使用在單體架構的叢集上是完全可行的，但到了微服務架構下，它們就最多隻能應用於叢集最入口處的閘道器上，對整個服務叢集進行流量控制，而無法細粒度地管理流量在內部微服務節點中的流轉情況。所以，我們把前面介紹的限流模式都統稱為單機限流，把能夠精細控制分散式叢集中每個服務消耗量的限流演演算法稱為分散式限流。例如：阿里爸爸開源的面向分散式服務架構的流量控制框架Sentinel，這裡不展開討論。

2.2.6 總結

4種常見限流演演算法和常見工具的對比如下表：