一個優秀的RPC框架，限流是必不可少的功能。
在上一篇文章聊聊服務註冊與發現中，我們講了微服務架構中核心功能之一服務註冊與發現。在本文中，我們將著重講下微服務的另外一個核心功能點：流量控制。
在微服務系統中，整個系統是以一系列固有功能的微服務組成，如果某一個服務，因為流量異常或者其他原因，導致響應異常，那麼同樣的也會影響到呼叫該服務的其他服務，從而引起了一系列連鎖反應，最終導致整個系統崩潰。針對此種問題，我們在之前的文章微服務架構之雪崩效應有講解過解決方案，今天我們針對方案中的限流控制來進行深入講解。
引言
限流這件事，對於微服務架構來說，最直接的就是跟系統承載能力正相關。任何系統都有它服務能力上限，如果在請求鏈路上，某個子服務的請求量超過其承載能力，那麼該鏈路上的請求將無法正常響應，而此時，如果在client端對於不能返回的請求不斷重試(retry)，那麼對原本已經超過負載上限的子服務來說，無異於雪上加霜。而這一的模式在拖垮了鏈路上的某個子服務後，可能會影響到其上游服務，導致影響範圍持續擴大，進而讓其它原本正常的服務也跟著失效，從而引起雪崩，雪崩效應會加速整個系統無法提供服務。
解決這個問題的方式，就是限流。如果監測到這個現象時候(錯誤率增高，rt變大或者是服務負載高於其安全閾值)，就直接開啟某些策略，在服務負載恢復前，丟棄新的request，以使得整個系統安全可靠。這個就是限流的目的。不過，這個機制困難的不在於要挑選哪種框架或者給某個服務來使用，而是是否有辦法精準掌握系統內各個子服務的負載上限，並且有能力做好整合，進一步做到自動化調節限流策略。
概念
在解釋什麼是限流之前，我們先了解一個點，就是服務的請求上限，也可以理解為是服務承載量，即該服務支援一定時間內最多能夠支援多少請求。只有將服務承載量進行量化，能夠被測量，才能根據這個測量值，採取一定的對應措施。
服務承載量，指的是單位時間內的處理量。北京地鐵早高峰，地鐵站都會做一件事情，就是限流了！想法很直接，就是想在一定時間內把請求限制在一定範圍內，保證系統不被沖垮，同時儘可能提升系統的吞吐量。
再以我家裡的頻寬為例，是聯通100m的，也就是說，每一秒鐘，聯通提供最大100m bits的資料傳輸量。那麼聯通是如何限制這個上限的呢？假如我是聯通，可能有以下幾個方面：
- 每秒總共傳輸量，在1秒內只要不超過100m bits，能傳多快就多塊
- 按照位來平均，每傳1bit需要花費0.01ns，因此沒傳完1bits後必須得到0.01ns後才能繼續傳
- 只要60秒內部超過60*100Mb就行
- ....
看到上面這些方案，就會發現，做到真正的限制，不是那麼容易的。因為每一個方案實現原理都不同，也就意味著程式碼實現不同。
現在，假如我們使用方案2來實現，等真正測試或者上線後，會崩潰吧，因為QPS控制根本不是像我們預期的那樣進行控制，這是因為重新計算流量的過程有可能已經超了0.01ns。顯然要儘可能精準的控制流量，需要回答下面兩個問題：
- 如何定義流量的計算方式？是選擇1s、10s還是60s？
- 如果流量超了之後，該怎麼做？是直接返回空值還是一個預設值？
顯然，我們在想清楚上面兩個問題後，實現方案基本就能定下來了。收到了新的request，只要確認目前的服務是否還有能力處理這個request即可。這個時候流量是直接丟棄，還是返回其他值，根據具體情況進行具體分析。
常用方式
限流常用的方式有：
- 計數器
- 滑動視窗
- 漏桶
- 令牌桶
下面我將深入講解上述的四種限流方式，先講解原理，然後是實現，最後分析其特點。
計數器
確定方法的最大訪問量MAX，每次進入方法前計數器+1，將結果和最大併發量MAX比較，如果大於等於MAX，則直接返回；如果小於MAX，則繼續執行。
計數器的實現方式，簡單粗暴。在一段時間內，進行計數，與閥值進行比較，到了時間臨界點，將計數器清0。
圖一、計數器
在上圖中，我們以1分鐘即60秒為一個時間片，在該時間片內最多處理請求為1000，如果超過了上限，則拒絕服務(具體依賴於實際業務場景)。
原理
我們將計數器的思路在明確下就是：
- 設定單位時間T（如10s）內的最大訪問量req_max，在單位時間T內維護計數器count；
- 當請求到達時，判斷時間是否進入下一個單位時間；
- 如果是，則重置計數器為0；
- 如果不是，計數器count,並判斷計數器count是否超過最大訪問量req_max，如超過，則拒絕訪問。
實現
針對上面的計數器原理，程式碼實現如下：
class CounterController {
public:
CounterController(int max, int duration) {
max_ = max;
duration_ = duration;
last_update_time_ = time(nullptr);
}
bool IsValid() {
uint64_t now = time(nullptr);
if (now < last_update_time_ + duration_) {
++req_num_;
return max_ > req_num_;
} else {
last_update_time_ = now;
req_num_ = 1;
return max_ > req_num_;
}
}
private:
int max_;
int duration_;
int last_update_time_;
int req_num_ = 0;
};
在實現程式碼中，其中有四個成員變數：
- max_ 代表時間片內最多處理的請求個數
- duration_ 程式碼時間片，單位為秒
- last_update_time_ 上一次更新計數器的時間
- req_num_ 當前時間片內的處理的請求數
其中，計數器限流方案的實現是在成員函式IsValid()中實現的，即為該次請求是否有效。在該函式中，我們首先判斷當前時間戳與上次更新時間戳之差是否超過了時間片，如果當前時間戳處於上次更新後的時間片內，則請求數+1，然後判斷請求數是否超過了該時間片的處理上限。如果不處於上次更新後的時間片內，則重置更新時間以及請求數。
特點
- 優點：實現簡單，容易理解
- 缺點：
- 一段時間內（不超過時間視窗）系統服務不可用。以圖一為例，時間片為60s，在時間片內的第一秒內，處理請求量就達到了上限，那麼在後面的59s內，所有的請求都將被拒絕
- 在時間片切換時刻，可能會產生兩倍於上限的請求。仍然以圖一為例，時間片為60s，在時間片內的前59s都無請求過來，在第60s的時候來了1000個請求，然後時間片切換，在新的時間片內的第一秒內，來了1000個請求，也就是說在2秒內(上一個時間片的最後一秒 + 當前時間片的第一秒)來了2000個請求，這個時候明顯超過我們的時間片內的上限值，可能導致系統崩潰
滑動視窗
計數器滑動視窗演算法是計數器固定視窗演算法的改進，解決了固定視窗切換時可能會產生兩倍於閾值流量請求的缺點。
滑動視窗的意思是說把固定時間片，進行劃分，並且隨著時間的流逝，進行移動，這樣就巧妙的避開了計數器的臨界點問題。也就是說這些固定數量的可以移動的格子，將會進行計數判斷閥值，因此格子的數量影響著滑動視窗演算法的精度。
在TCP中，也使用了滑動視窗來進行網路流量控制，感興趣的同學可以閱讀TCP之滑動視窗原理。
滑動視窗
計數器方式是一種特殊的滑動視窗，其視窗大小為1個時間片;
原理
滑動視窗演算法在固定視窗的基礎上，將一個計時視窗分成了若干個小視窗，然後每個小視窗維護一個獨立的計數器。當請求的時間大於當前視窗的最大時間時，則將計時視窗向前平移一個小視窗。平移時，將第一個小視窗的資料丟棄，然後將第二個小視窗設定為第一個小視窗，同時在最後面新增一個小視窗，將新的請求放在新增的小視窗中。同時要保證整個視窗中所有小視窗的請求數目之後不能超過設定的閾值。
滑動視窗
實現
class SlidingWindowController {
public:
SlidingWindowController(int window_size, int limit, int split_num) {
limit_ = limit;
window_size_ = window_size;
counters_.resize(split_num);
split_num_ = split_num;
}
int IsValid() {
uint64_t now_ms = 0;
GetCurrentTimeMs(&now_ms);
int window_num = std::max(now_ms - window_size_ - start_time_, 0) / (window_size_ / split_num_);
SlidingWindow(window_num);
int count = 0;
for(int i = 0;i < split_num_; ++i){
count += counters_[i];
}
if(count >= limit){
return false;
}else{
counters_[index] ++;
return true;
}
return true;
}
private:
void SlidingWindow(int window_num) {
if (window_num == 0) {
return;
}
int slide_num = std::min(window_num, split_num_);
for (int i = 0; i < slide_num; ++i) {
index_ = (index_ + 1) % split_num;
counters_[index_] = 0;
}
start_time_ = start_time_ + wind_num * (window_size_ / split_num_); // 更新滑動視窗時間
}
int window_size_; // 視窗大小，單位為毫秒
int limit_; // 視窗內限流大小
std::vector counters_;
uint64_t start_time_; // 視窗開始時間
int index_ = 0; // 當前視窗計時器索引
int split_num_;
};
特點
- 避免了計數器固定視窗演算法固定視窗切換時可能會產生兩倍於閾值流量請求的問題
- 實現精度依賴於視窗的細分粒度，分的越細，即視窗分塊越多，控制的限流越平滑
漏桶
漏桶演算法思路很簡單，水（請求）先進入到漏桶裡，漏桶以一定的速度出水，當水流入速度過大會直接溢位，可以看出漏桶演算法能強行限制資料的傳輸速率。
以固定速率從桶中流出水滴，以任意速率往桶中放入水滴，桶容量大小是不會發生改變的。
流入：以任意速率往桶中放入水滴。
流出：以固定速率從桶中流出水滴。
因為桶中的容量是固定的，如果流入水滴的速率>流出的水滴速率，桶中的水滴可能會溢位。那麼溢位的水滴請求都是拒絕訪問的，或者直接呼叫服務降級方法。前提是同一時刻。
但是對於很多場景來說，除了要求能夠限制資料的平均傳輸速率外，還要求允許某種程度的突發傳輸。這時候漏桶演算法可能就不合適了，令牌桶演算法更為適合。
漏桶
原理
請求來了之後會首先進到漏斗裡，然後漏斗以恆定的速率將請求流出進行處理，從而起到平滑流量的作用。當請求的流量過大時，漏斗達到最大容量時會溢位，此時請求被丟棄。從系統的角度來看，我們不知道什麼時候會有請求來，也不知道請求會以多大的速率來，這就給系統的安全性埋下了隱患。但是如果加了一層漏斗演算法限流之後，就能夠保證請求以恆定的速率流出。在系統看來，請求永遠是以平滑的傳輸速率過來，從而起到了保護系統的作用。
實現
class LeakyBucketController {
public:
LeakyBucketController(int rate) {
capacity_ = rate;
last_update_time_ = time(nullptr);
}
bool IsValid() {
// 計算這段時間，漏了多少水
uint64_t now = time(nullptr);
int out = (new - last_update_time_) * rate;
if (out > 0) {
last_update_time_ = now;
}
// 計算桶中剩餘的水
water_ = std::max(0, water_ - out);
// 如果桶沒有滿，則表示有效
if (water_ < capacity_) {
++water_;
return true;
}
return false;
}
private:
int capacity_;
int water_ = 0;
uint64_t last_update_time_;
};
特點
-
漏桶的漏出速率是固定的 由於漏出速率固定，因此即使流量流入速率不定，但是經過漏斗之後，變成了有固定速率的穩定流量，可以對下游系統起到保護作用
-
不能解決流量突發的問題。 假設我們設定漏斗速率為10個/秒，桶的容量為50個。此時突然來了100個請求，那麼只有50個請求被接收，另外50個被拒絕。這個時候，你可能會認為瞬間接受了50個請求，不就解決了流量突發問題麼？不，這50個請求只是被接受了，但是沒有馬上被處理，處理的速度仍然是我們設定的10個/秒，所以沒有解決流量突發的問題。而接下來我們要談的令牌桶演算法能夠在一定程度上解決流量突發的問題。
令牌桶
令牌桶演算法是對漏斗演算法的一種改進，除了能夠起到限流的作用外，還允許一定程度的流量突發。
令牌桶演算法是以恆定的速率將令牌放入桶中，這個時候如果來了突發流量，如果桶中有令牌，則可以直接獲取令牌，並處理請求，基於該原理，就解決了漏桶演算法中不能 處理突發流量 的問題。
原理
在令牌桶演算法中，令牌以恆定速率放入桶中。桶也有一定的容量，如果滿了令牌就無法放進去了。當請求來了之後，會受限到桶中去拿令牌，如何取到了令牌，則該請求被處理，並消耗掉拿到的令牌，否則，該請求被丟棄。
令牌桶
實現
class TokenBucketController {
public:
TokenBucketController(int num, uint64_t duration) :
duration_(duration), rate_(num > 0 ? (num / duration_ / 1000) : 0),
limit_(num), modulo_(num > 0 ?(num % (duration * 1000)) : 0) {
GetCurrentTimeMs(&last_update_time_);
::curr_idx = 0;
}
bool IsValid();
private:
void Update();
const uint64_t duration_;
const int rate_;
const int limit_;
const uint64_t modulo_;
uint64_t last_update_time_;
uint64_t loss_ = 0;
uint64_t counts_ = 0;
};
void TokenBucketController::Update() {
uint64_t cur_time_ms;
GetCurrentTimeMs(&cur_time_ms);
uint64_t time_passed_since_last_update = cur_time_ms - last_update_time_;
if (time_passed_since_last_update == 0) {
return;
}
if (counts_ == static_cast<uint64_t>(limit_)) {
last_update_time_ = cur_time_ms;
return;
}
uint64_t count_to_add = rate_ * time_passed_since_last_update;
loss_ += modulo_ * time_passed_since_last_update;
if (loss_ >= duration_ * 1000) {
count_to_add += loss_ / duration_ / 1000;
loss_ %= (duration_ * 1000);
}
counts_ += count_to_add;
if (counts_ > static_cast<uint64_t>(limit_)) {
counts_ = limit_;
}
last_update_time_ = cur_time_ms;
}
bool TokenBucketController::IsValid() {
if (limit_ < 0) {
return true;
}
if (counts_ >= 1) {
counts_ -= 1;
return true;
}
Update();
if (counts_ >= 1) {
counts_ -= 1;
return true;
}
return false;
}
在實現上，令牌桶跟漏桶的區別，是一個控制進，一個控制出。 在InValid函式中，先判斷桶中是否有令牌，如果有則返回true，否則，進行更新桶中令牌(Update函式)，然後再進行判斷是否有令牌可用。
特點
令牌桶演算法來作為限流，在業界使用最多，除了能夠在限制呼叫的平均速率的同時還允許一定程度的流量突發。
結語
下面我們把本文中的四種限流策略做下簡單對比，來作為對本文的一個總結。 計數器演算法：該演算法實現簡單，容易理解。但是在時間片切換時刻，容易出現兩倍於閾值的流量，也可以說是滑動視窗演算法的簡版(視窗只有一個)。
滑動視窗演算法：解決了計數器演算法中的2倍閾值的問題，其流量控制精度依賴於視窗個數，視窗個數越多，精度控制越準。
漏桶演算法：以任意速率往桶中放入水滴，如果桶中的水滴沒有滿的話，可以訪問服務，不能處理突發流量。
令牌桶演算法：以固定的速率(平均速率)生成對應的令牌放到桶中，客戶端只需要在桶中獲取到令牌後，就可以訪問服務請求，與漏桶演算法相比，其可以處理一定的突發流量。
令牌桶演算法是通過控制令牌生成的速度進行限流，
漏桶演算法是控制請求從桶中流出的速度進行限流。
簡單理解為：令牌桶控制進，漏桶控制出。
如果要讓自己的系統不被打垮，用令牌桶。如果保證被別人的系統不被打垮，用漏桶演算法。
以上四種限流演算法都有自身的特點，具體使用時還是要結合自身的場景進行選取，沒有最好的演算法，只有最合適的演算法。比如令牌桶演算法一般用於保護自身的系統，對呼叫者進行限流，保護自身的系統不被突發的流量打垮。如果自身的系統實際的處理能力強於配置的流量限制時，可以允許一定程度的流量突發，使得實際的處理速率高於配置的速率，充分利用系統資源。而漏斗演算法一般用於保護第三方的系統，比如自身的系統需要呼叫第三方的介面，為了保護第三方的系統不被自身的呼叫打垮，便可以通過漏斗演算法進行限流，保證自身的流量平穩的打到第三方的介面上。
演算法是死的，而演算法中的思想精髓才是值得我們學習的。實際的場景中完全可以靈活運用，還是那句話，沒有最好的演算法，只有最合適的演算法。