騰訊王卡業務第一代閘道器設計架構如上圖所示，也許有許多人會問，nginx本身就能做網關了，為什麼還需要另外開發閘道器呢？

答案是nginx開發閘道器，線上現有成員技術背景下，條件不成熟，為了快速構建我們的微服務架構，所以我們選擇了基於spring cloud zuul做閘道器開發，這樣技術棧單一，小團隊比較合適，運維維護成本較低。

閘道器能給我們帶來的好處如下：

• 客戶端認證
  無論是對內網還是外網的介面都是需要做使用者身份認證的，而使用者認證在一些規模大點的公司都會有統一的單點登入系統，如果每個微服務系統都是做對接單點登入系統的工作，那麼顯然比較浪費資源，開發效率低。可以將認證的部分抽取到閘道器層，然後微服務系統無需關注認證的邏輯只關注自身業務即可。

• 訪問控制
  對一些特定的介面設定白名單，訪問次數，訪問頻率等各類設定。而這些非業務功能的配置以及變更不會影響微服務的實現可以在閘道器層單獨做操作。

• 負載均衡
  可以靈活的在閘道器層制定負載均衡策略。

• 安全
  可以統一在閘道器層增加一個額外的保護層來防止惡意攻擊，如果客戶端直連微服務的話，每個暴露的微服務都需要面臨安全問題。

       下面我們回到本文的主題“訪問控制”

       訪問控制中，必談的就是限流演算法了，目前比較流行的演算法有“漏桶限流演算法”、“令牌桶限流演算法”，另外大家很少回去談及“滑動視窗演算法”

       漏桶(Leaky Bucket)演算法思路很簡單,水(請求)先進入到漏桶裡,漏桶以一定的速度出水(介面有響應速率),當水流入速度過大會直接溢位(訪問頻率超過介面響應速率),然後就拒絕請求,可以看出漏桶演算法能強行限制資料的傳輸速率.示意圖如下:

         可見這裡有兩個變數,一個是桶的大小,支援流量突發增多時可以存多少的水(burst),另一個是水桶漏洞的大小(rate)。

         漏桶本身具有一定容量，生產方的生產速率不受限制，當達到漏桶容量時將拒絕生產，消費方以固定速率消費。例如5r/s

         優點：消費方可以以固定速率消費，因為漏桶消費方限制了速率。
         缺點：缺點也很明顯，不能抵抗難於突發流量。

         舉例：漏桶允許以200r/s速率消費，如果突發流量為500r/s來襲，導致大量請求堆積或者拒絕。

        令牌桶演算法(Token Bucket)和 Leaky Bucket 效果一樣但方向相反的演算法,更加容易理解.隨著時間流逝,系統會按恆定1/QPS時間間隔(如果QPS=100,則間隔是10ms)往桶裡加入Token(想象和漏洞漏水相反,有個水龍頭在不斷的加水),如果桶已經滿了就不再加了.新請求來臨時,會各自拿走一個Token,如果沒有Token可拿了就阻塞或者拒絕服務.

        令牌桶的另外一個好處是可以方便的改變速度. 一旦需要提高速率,則按需提高放入桶中的令牌的速率. 一般會定時(比如100毫秒)往桶中增加一定數量的令牌, 有些變種演算法則實時的計算應該增加的令牌的數量.

      優點：可以抵抗突發流量。令牌桶中積累一定數量的令牌，消費速率不固定，在一個極小的時間視窗內，可以消費所有的令牌。
      缺點；事物具有兩面性，優點極可能就會導致缺點。難於平滑的、以固定的速率消費（比如5r/s），因為消費令牌並沒有限速
 
      舉例：假如我們的令牌桶容量是500，現有令牌數也是500，我們系統總併發也是500，生產令牌速率是5r/s，假如一次突發的500個請求，他會瞬間消費完所有令牌，後續請求可能是300r/s,200r/s....那麼所有請求將被快取或者拒絕（自己時間策略決定），難於平滑消費。

       通過以上分析，感覺令牌桶演算法更合適大家，他可以抵抗突發流量，同時又可以平滑消費（突發流量耗盡後，後面的令牌生產方生產速率是恆定的，這樣限制了消費速率也是恆定的）。可是大家有沒有發現一個問題，不論是 令牌桶限流 和 漏桶限流都存在一個問題，相連兩個時間單位內，流量可能會超過系統承受能力。為什麼呢？前一個時間單位的N請求沒有完全返回，
後一個時間單位的m個請求又來襲，導致n+m>系統總容量。

       滑動視窗限流

在傳送方一側會將要傳送的資料組成一個佇列，依次傳送佇列裡的資料。佇列裡面的資料包含幾個部分，有已經發送且已經確認的資料、已經發送但未確認的資料、即將傳送的資料、現在還不能傳送的資料這四個部分，其中的數字標號是資料序列號。上圖中提供的視窗即對方通告的視窗大小，可以看出為6個視窗，同時視窗的左邊界為3，表明在序列號3及之前的資料已經發送並完成確認，則可以算出視窗的右邊界為9。同時我們可以知道有多少已經發送但未收到確認的資料，總共有3個視窗，則傳送邊界為6，所以最後我們可知可用視窗，即馬上能傳送的資料序列號範圍為7-9。

      隨著時間的推移，當我們收到已經發送的資料的ACK時，滑動視窗的左邊界就能右移，如果視窗大小未發生改變，那麼視窗的右邊界也會右移，相當於整個視窗右移。其中在視窗的變化過程中有三個運動狀態：

• 關閉： 視窗左邊界右移。發生在收到已傳送資料的ACK時。
• 開啟： 視窗右邊界右移。發生在接收方已處理接收到的資料，使得接收方快取變大，會給傳送方通告新的變大的視窗值。
• 收縮： 視窗有邊界左移。發生再糊塗視窗中。

      滑動視窗優點：

1：他能抵抗突發流量，

2：他能解決兩個相鄰時刻瞬時流量超過系統總承載量

 作者也玩公眾號，歡迎關注《JAVA之庖丁解牛》