微服務 API閘道器限流

我們在api閘道器中已經介紹了，限流是保護閘道器的手段之一，和身份認證以及鑑權一起組成安全防禦大閘。其目的是對併發請求進行限速或限制乙個時間視窗內請求的數量，一旦達到閾值就排隊等待或降級甚至拒絕服務。

根據上面列出的原因，我們自然知道限流該怎麼限制法，但是具體要怎麼實現呢？也就是該怎麼設計演算法來實現呢？

閘道器每接受到乙個請求，計數器就增加1，每處理完乙個請求，計數器就減少1，計數器有最大值和最小值，最小值是0，最大值根據需要來設定，最大值相當於緩衝區，超過這個緩衝區，閘道器將不再接受請求。

由於請求會由不同的執行緒或者協程處理，所以計數器需要放在可以共享的地方，比如說記憶體資料庫redis裡面。

進一步的，如果我們想細粒度的控制流量，就需要設定多個不同的計數器，比如，某些特定的api需要設定特定的計數器，不同的客戶端要設定不同的計數器。除此以外閘道器還要解析請求頭裡面的資訊，比如ip來判斷屬於哪個使用者等等。

這種方法有個缺點，如果我們想要在一分鐘內限制請求1000次的話，用這種方法就無法實現，因為這種方法不能根據時間來做限制。那可以優化嗎？

優化哈哈，當然是可以的，我們不對計數器設定最大值，額外設定乙個***，這個***每分鐘計算一次新增的請求數，如果超過限值就拒絕後面的請求。

方案缺陷思考

有沒有發現這個方法有些問題？如果第一秒接受請求300次，第二秒接受請求300次，第三秒接受請求400次，那後面從第四秒到一分鐘的請求就都被拒絕了，但其實閘道器還能處理能力，所以這種方法無法做到平滑限流。

由上面方案的思考要做到平滑限流，可以設計乙個物件，這個物件可以勻速的生產令牌，每個請求在得到處理前都要先嘗試獲取乙個令牌，如果獲取失敗，閘道器就拒絕服務。

根據這個思路，我們可以設計出如下圖所示的方案：

方案分析：

這種方案不僅可以平滑限流，而且可以通過監控桶內令牌數的多少來判斷處理請求的能力，從而針對性的增強特定請求處理能力。

漏桶演算法和令牌桶演算法原理類似，利用底部破洞的桶，請求可以勻速流出，如下圖：

方案分析

與令牌桶不一樣的是, 漏桶演算法中消費請求是勻速的，可以用來進行流量整形。

為了實現全侷限流，我們需要把令牌桶或者漏桶設定在共享介質中，比如redis。此外對於桶的讀寫必須是源自操作。

限流和登入認證以及許可權控制共同組成api閘道器的防禦大閘，這裡面有個問題，這三者的順序應該怎麼排呢？

如果登入認證服務和許可權控**務能扛得住所有請求的壓力的話，那麼你怎麼排都沒有問題，但是如果請求量會非常大的話，建議還是把限流放在最外層，如果你不想自己實現限流功能的話，利用nginx也可以完成想要的功能，具體在nginx中如何配置這裡不做進一步講解。

微服務 API閘道器 限流