Spring Cloud Zuul通過zuul-ratelimit實現限流

一、限流

控制訪問流量，通過指定的策略消減流量（如網絡層面限制訪問流量、後服務實例使用技術手段限制併發數量等），使得落到後臺服務實例的請求在能承受的範圍內。高併發是常常討論的話題，如何限流，以及服務的實例能承受的範圍是多大，什麼情況下需要增加服務實例，調整資源，都需要結合實際進行嚴格的測試。
 

二、常用算法

計數器算法

計數器算法採用計數器實現限流有點簡單粗暴，一般我們會限制一秒鐘的能夠通過的請求數，比如限流qps爲100，算法的實現思路就是從第一個請求進來開始計時，在接下去的1s內，每來一個請求，就把計數加1，如果累加的數字達到了100，那麼後續的請求就會被全部拒絕。等到1s結束後，把計數恢復成0，重新開始計數。具體的實現可以是這樣的：對於每次服務調用，可以通過AtomicLong#incrementAndGet()方法來給計數器加1並返回最新值，通過這個最新值和閾值進行比較。這種實現方式，相信大家都知道有一個弊端：如果我在單位時間1s內的前10ms，已經通過了100個請求，那後面的990ms，只能眼巴巴的把請求拒絕，我們把這種現象稱爲“突刺現象”

漏桶算法

漏桶算法爲了消除"突刺現象"，可以採用漏桶算法實現限流，漏桶算法這個名字就很形象，算法內部有一個容器，類似生活用到的漏斗，當請求進來時，相當於水倒入漏斗，然後從下端小口慢慢勻速的流出。不管上面流量多大，下面流出的速度始終保持不變。不管服務調用方多麼不穩定，通過漏桶算法進行限流，每10毫秒處理一次請求。因爲處理的速度是固定的，請求進來的速度是未知的，可能突然進來很多請求，沒來得及處理的請求就先放在桶裏，既然是個桶，肯定是有容量上限，如果桶滿了，那麼新進來的請求就丟棄。

在算法實現方面，可以準備一個隊列，用來保存請求，另外通過一個線程池（ScheduledExecutorService）來定期從隊列中獲取請求並執行，可以一次性獲取多個併發執行。

這種算法，在使用過後也存在弊端：無法應對短時間的突發流量。

令牌桶算法

從某種意義上講，令牌桶算法是對漏桶算法的一種改進，桶算法能夠限制請求調用的速率，而令牌桶算法能夠在限制調用的平均速率的同時還允許一定程度的突發調用。在令牌桶算法中，存在一個桶，用來存放固定數量的令牌。算法中存在一種機制，以一定的速率往桶中放令牌。每次請求調用需要先獲取令牌，只有拿到令牌，纔有機會繼續執行，否則選擇選擇等待可用的令牌、或者直接拒絕。放令牌這個動作是持續不斷的進行，如果桶中令牌數達到上限，就丟棄令牌，所以就存在這種情況，桶中一直有大量的可用令牌，這時進來的請求就可以直接拿到令牌執行，比如設置qps爲100，那麼限流器初始化完成一秒後，桶中就已經有100個令牌了，這時服務還沒完全啓動好，等啓動完成對外提供服務時，該限流器可以抵擋瞬時的100個請求。所以，只有桶中沒有令牌時，請求才會進行等待，最後相當於以一定的速率執行。

實現思路：可以準備一個隊列，用來保存令牌，另外通過一個線程池定期生成令牌放到隊列中，每來一個請求，就從隊列中獲取一個令牌，並繼續執行。

三、zuul-ratelimit實現限流

pom引入

<dependency>

      <groupId>org.springframework.cloud</groupId>

      <artifactId>spring-cloud-starter-netflix-zuul</artifactId>

</dependency>

<dependency>

      <groupId>org.springframework.cloud</groupId>

      <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>

</dependency>

<dependency>

      <groupId>com.marcosbarbero.cloud</groupId>

      <artifactId>spring-cloud-zuul-ratelimit</artifactId> <version>2.0.6.RELEASE</version>

</dependency>

properties配置文件添加配置

####################################### 限流配置 ########################################
#按粒度拆分的臨時變量key前綴
zuul.ratelimit.key-prefix=springcloud-book 
zuul.ratelimit.enabled=true
#key存儲類型，默認是IN_MEMORY本地內存，此外還有多種形式
zuul.ratelimit.repository=IN_MEMORY
zuul.ratelimit.behind-proxy=true
#在一個單位時間窗口的請求數量
zuul.ratelimit.default-policy.limit=500
#在一個單位時間窗口的請求時間限制
zuul.ratelimit.default-policy.quota=2000
#單位時間窗口
zuul.ratelimit.default-policy.refresh-interval=60
#可指定限流粒度，user-用戶粒度，origin-客戶端地址粒度，url-url粒度
zuul.ratelimit.default-policy.type=url

代碼解釋：

對全局開啓了限流，策略是，60秒內訪問不允許超過 500次，並且這 500 次請求總耗時要小於 2000 秒。這些參數大家根據你對需要自己修改。