[導(dǎo)讀]來源：https://www.aneasystone.com/archives/2020/08/spring-cloud-gateway-current-limiting.html話說在SpringCloudGateway問世之前，SpringCloud的微服務(wù)世界里，網(wǎng)關(guān)一定非...

來源：https://www.aneasystone.com/archives/2020/08/spring-cloud-gateway-current-limiting.html

話說在 Spring Cloud Gateway 問世之前，Spring Cloud 的微服務(wù)世界里，網(wǎng)關(guān)一定非 Netflix Zuul 莫屬。但是由于 Zuul 1.x 存在的一些問題，比如阻塞式的 API，不支持 WebSocket 等，一直被人所詬病，而且 Zuul 升級(jí)新版本依賴于 Netflix 公司，經(jīng)過幾次跳票之后，Spring 開源社區(qū)決定推出自己的網(wǎng)關(guān)組件，替代 Netflix Zuul。
從 18 年 6 月 Spring Cloud 發(fā)布的 Finchley 版本開始，Spring Cloud Gateway 逐漸嶄露頭角，它基于 Spring 5.0、Spring Boot 2.0 和 Project Reactor 等技術(shù)開發(fā)，不僅支持響應(yīng)式和無阻塞式的 API，而且支持 WebSocket，和 Spring 框架緊密集成。盡管 Zuul 后來也推出了 2.x 版本，在底層使用了異步無阻塞式的 API，大大改善了其性能，但是目前看來 Spring 并沒有打算繼續(xù)集成它的計(jì)劃。根據(jù)官網(wǎng)的描述，Spring Cloud Gateway 的主要特性如下：

Built on Spring Framework 5, Project Reactor and Spring Boot 2.0
Able to match routes on any request attribute
Predicates and filters are specific to routes
Hystrix Circuit Breaker integration
Spring Cloud DiscoveryClient integration
Easy to write Predicates and Filters
Request Rate Limiting
Path Rewriting

可以看出 Spring Cloud Gateway 可以很方便的和 Spring Cloud 生態(tài)中的其他組件進(jìn)行集成（比如：斷路器和服務(wù)發(fā)現(xiàn)），而且提供了一套簡(jiǎn)單易寫的?斷言（Predicates，有的地方也翻譯成?謂詞）和?過濾器（Filters）機(jī)制，可以對(duì)每個(gè)?路由（Routes）進(jìn)行特殊請(qǐng)求處理。最近在項(xiàng)目中使用了 Spring Cloud Gateway，并在它的基礎(chǔ)上實(shí)現(xiàn)了一些高級(jí)特性，如限流和留痕，在網(wǎng)關(guān)的使用過程中遇到了不少的挑戰(zhàn)，于是趁著項(xiàng)目結(jié)束，抽點(diǎn)時(shí)間系統(tǒng)地學(xué)習(xí)并總結(jié)下。這篇文章主要學(xué)習(xí)限流技術(shù)，首先我會(huì)介紹一些常見的限流場(chǎng)景和限流算法，然后介紹一些關(guān)于限流的開源項(xiàng)目，學(xué)習(xí)別人是如何實(shí)現(xiàn)限流的，最后介紹我是如何在網(wǎng)關(guān)中實(shí)現(xiàn)限流的，并分享一些實(shí)現(xiàn)過程中的經(jīng)驗(yàn)和遇到的坑。

一、常見的限流場(chǎng)景

緩存、降級(jí)?和?限流?被稱為高并發(fā)、分布式系統(tǒng)的三駕馬車，網(wǎng)關(guān)作為整個(gè)分布式系統(tǒng)中的第一道關(guān)卡，限流功能自然必不可少。通過限流，可以控制服務(wù)請(qǐng)求的速率，從而提高系統(tǒng)應(yīng)對(duì)突發(fā)大流量的能力，讓系統(tǒng)更具彈性。限流有著很多實(shí)際的應(yīng)用場(chǎng)景，比如雙十一的秒殺活動(dòng)， 12306 的搶票等。

1.1 限流的對(duì)象

通過上面的介紹，我們對(duì)限流的概念可能感覺還是比較模糊，到底限流限的是什么？顧名思義，限流就是限制流量，但這里的流量是一個(gè)比較籠統(tǒng)的概念。如果考慮各種不同的場(chǎng)景，限流是非常復(fù)雜的，而且和具體的業(yè)務(wù)規(guī)則密切相關(guān)，可以考慮如下幾種常見的場(chǎng)景：

限制某個(gè)接口一分鐘內(nèi)最多請(qǐng)求 100 次
限制某個(gè)用戶的下載速度最多 100KB/S
限制某個(gè)用戶同時(shí)只能對(duì)某個(gè)接口發(fā)起 5 路請(qǐng)求
限制某個(gè) IP 來源禁止訪問任何請(qǐng)求

從上面的例子可以看出，根據(jù)不同的請(qǐng)求者和請(qǐng)求資源，可以組合出不同的限流規(guī)則。可以根據(jù)請(qǐng)求者的 IP 來進(jìn)行限流，或者根據(jù)請(qǐng)求對(duì)應(yīng)的用戶來限流，又或者根據(jù)某個(gè)特定的請(qǐng)求參數(shù)來限流。而限流的對(duì)象可以是請(qǐng)求的頻率，傳輸?shù)乃俾?，或者并發(fā)量等，其中最常見的兩個(gè)限流對(duì)象是請(qǐng)求頻率和并發(fā)量，他們對(duì)應(yīng)的限流被稱為?請(qǐng)求頻率限流（Request rate limiting）和?并發(fā)量限流（Concurrent requests limiting）。傳輸速率限流?在下載場(chǎng)景下比較常用，比如一些資源下載站會(huì)限制普通用戶的下載速度，只有購買會(huì)員才能提速，這種限流的做法實(shí)際上和請(qǐng)求頻率限流類似，只不過一個(gè)限制的是請(qǐng)求量的多少，一個(gè)限制的是請(qǐng)求數(shù)據(jù)報(bào)文的大小。這篇文章主要介紹請(qǐng)求頻率限流和并發(fā)量限流。

1.2 限流的處理方式

在系統(tǒng)中設(shè)計(jì)限流方案時(shí)，有一個(gè)問題值得設(shè)計(jì)者去仔細(xì)考慮，當(dāng)請(qǐng)求者被限流規(guī)則攔截之后，我們?cè)撊绾畏祷亟Y(jié)果。一般我們有下面三種限流的處理方式：

拒絕服務(wù)
排隊(duì)等待
服務(wù)降級(jí)

最簡(jiǎn)單的做法是拒絕服務(wù)，直接拋出異常，返回錯(cuò)誤信息（比如返回 HTTP 狀態(tài)碼 429 Too Many Requests），或者給前端返回 302 重定向到一個(gè)錯(cuò)誤頁面，提示用戶資源沒有了或稍后再試。但是對(duì)于一些比較重要的接口不能直接拒絕，比如秒殺、下單等接口，我們既不希望用戶請(qǐng)求太快，也不希望請(qǐng)求失敗，這種情況一般會(huì)將請(qǐng)求放到一個(gè)消息隊(duì)列中排隊(duì)等待，消息隊(duì)列可以起到削峰和限流的作用。第三種處理方式是服務(wù)降級(jí)，當(dāng)觸發(fā)限流條件時(shí)，直接返回兜底數(shù)據(jù)，比如查詢商品庫存的接口，可以默認(rèn)返回有貨。

1.3 限流的架構(gòu)

針對(duì)不同的系統(tǒng)架構(gòu)，需要使用不同的限流方案。如下圖所示，服務(wù)部署的方式一般可以分為單機(jī)模式和集群模式：實(shí)戰(zhàn)?Spring?Cloud?Gateway?之限流篇

單機(jī)模式的限流非常簡(jiǎn)單，可以直接基于內(nèi)存就可以實(shí)現(xiàn)，而集群模式的限流必須依賴于某個(gè)“中心化”的組件，比如網(wǎng)關(guān)或 Redis，從而引出兩種不同的限流架構(gòu)：網(wǎng)關(guān)層限流?和?中間件限流。實(shí)戰(zhàn)?Spring?Cloud?Gateway?之限流篇

網(wǎng)關(guān)作為整個(gè)分布式系統(tǒng)的入口，承擔(dān)了所有的用戶請(qǐng)求，所以在網(wǎng)關(guān)中進(jìn)行限流是最合適不過的。網(wǎng)關(guān)層限流有時(shí)也被稱為?接入層限流。除了我們使用的 Spring Cloud Gateway，最常用的網(wǎng)關(guān)層組件還有 Nginx，可以通過它的 ngx_http_limit_req_module 模塊，使用 limit_conn_zone、limit_req_zone、limit_rate 等指令很容易的實(shí)現(xiàn)并發(fā)量限流、請(qǐng)求頻率限流和傳輸速率限流。這里不對(duì) Nginx 作過多的說明，關(guān)于這幾個(gè)指令的詳細(xì)信息可以?參考 Nginx 的官方文檔。另一種限流架構(gòu)是中間件限流，可以將限流的邏輯下沉到服務(wù)層。但是集群中的每個(gè)服務(wù)必須將自己的流量信息統(tǒng)一匯總到某個(gè)地方供其他服務(wù)讀取，一般來說用 Redis 的比較多，Redis 提供的過期特性和 lua 腳本執(zhí)行非常適合做限流。除了 Redis 這種中間件，還有很多類似的分布式緩存系統(tǒng)都可以使用，如 Hazelcast、Apache Ignite、Infinispan 等。我們可以更進(jìn)一步擴(kuò)展上面的架構(gòu)，將網(wǎng)關(guān)改為集群模式，雖然這還是網(wǎng)關(guān)層限流架構(gòu)，但是由于網(wǎng)關(guān)變成了集群模式，所以網(wǎng)關(guān)必須依賴于中間件進(jìn)行限流，這和上面討論的中間件限流沒有區(qū)別。實(shí)戰(zhàn)?Spring?Cloud?Gateway?之限流篇

二、常見的限流算法

通過上面的學(xué)習(xí)，我們知道限流可以分為請(qǐng)求頻率限流和并發(fā)量限流，根據(jù)系統(tǒng)架構(gòu)的不同，又可以分為網(wǎng)關(guān)層限流和分布式限流。在不同的應(yīng)用場(chǎng)景下，我們需要采用不同的限流算法。這一節(jié)將介紹一些主流的限流算法。有一點(diǎn)要注意的是，利用池化技術(shù)也可以達(dá)到限流的目的，比如線程池或連接池，但這不是本文的重點(diǎn)。

2.1 固定窗口算法（Fixed Window）

固定窗口算法是一種最簡(jiǎn)單的限流算法，它根據(jù)限流的條件，將請(qǐng)求時(shí)間映射到一個(gè)時(shí)間窗口，再使用計(jì)數(shù)器累加訪問次數(shù)。譬如限流條件為每分鐘 5 次，那么就按照分鐘為單位映射時(shí)間窗口，假設(shè)一個(gè)請(qǐng)求時(shí)間為 11:00:45，時(shí)間窗口就是 11:00:00 ~ 11:00:59，在這個(gè)時(shí)間窗口內(nèi)設(shè)定一個(gè)計(jì)數(shù)器，每來一個(gè)請(qǐng)求計(jì)數(shù)器加一，當(dāng)這個(gè)時(shí)間窗口的計(jì)數(shù)器超過 5 時(shí)，就觸發(fā)限流條件。當(dāng)請(qǐng)求時(shí)間落在下一個(gè)時(shí)間窗口內(nèi)時(shí)（11:01:00 ~ 11:01:59），上一個(gè)窗口的計(jì)數(shù)器失效，當(dāng)前的計(jì)數(shù)器清零，重新開始計(jì)數(shù)。計(jì)數(shù)器算法非常容易實(shí)現(xiàn)，在單機(jī)場(chǎng)景下可以使用 AtomicLong、LongAdder 或 Semaphore 來實(shí)現(xiàn)計(jì)數(shù)，而在分布式場(chǎng)景下可以通過 Redis 的 INCR 和 EXPIRE 等命令并結(jié)合 EVAL 或 lua 腳本來實(shí)現(xiàn)，Redis 官網(wǎng)提供了幾種簡(jiǎn)單的實(shí)現(xiàn)方式。無論是請(qǐng)求頻率限流還是并發(fā)量限流都可以使用這個(gè)算法。不過這個(gè)算法的缺陷也比較明顯，那就是存在嚴(yán)重的臨界問題。由于每過一個(gè)時(shí)間窗口，計(jì)數(shù)器就會(huì)清零，這使得限流效果不夠平滑，惡意用戶可以利用這個(gè)特點(diǎn)繞過我們的限流規(guī)則。如下圖所示，我們的限流條件本來是每分鐘 5 次，但是惡意用戶在 11:00:00 ~ 11:00:59 這個(gè)時(shí)間窗口的后半分鐘發(fā)起 5 次請(qǐng)求，接下來又在 11:01:00 ~ 11:01:59 這個(gè)時(shí)間窗口的前半分鐘發(fā)起 5 次請(qǐng)求，這樣我們的系統(tǒng)就在 1 分鐘內(nèi)承受了 10 次請(qǐng)求。實(shí)戰(zhàn)?Spring?Cloud?Gateway?之限流篇

2.2 滑動(dòng)窗口算法（Rolling Window 或 Sliding Window）

為了解決固定窗口算法的臨界問題，可以將時(shí)間窗口劃分成更小的時(shí)間窗口，然后隨著時(shí)間的滑動(dòng)刪除相應(yīng)的小窗口，而不是直接滑過一個(gè)大窗口，這就是滑動(dòng)窗口算法。我們?yōu)槊總€(gè)小時(shí)間窗口都設(shè)置一個(gè)計(jì)數(shù)器，大時(shí)間窗口的總請(qǐng)求次數(shù)就是每個(gè)小時(shí)間窗口的計(jì)數(shù)器的和。如下圖所示，我們的時(shí)間窗口是 5 秒，可以按秒進(jìn)行劃分，將其劃分成 5 個(gè)小窗口，時(shí)間每過一秒，時(shí)間窗口就滑過一秒：實(shí)戰(zhàn)?Spring?Cloud?Gateway?之限流篇

每次處理請(qǐng)求時(shí)，都需要計(jì)算所有小時(shí)間窗口的計(jì)數(shù)器的和，考慮到性能問題，劃分的小時(shí)間窗口不宜過多，譬如限流條件是每小時(shí) N 個(gè)，可以按分鐘劃分為 60 個(gè)窗口，而不是按秒劃分成 3600 個(gè)。當(dāng)然如果不考慮性能問題，劃分粒度越細(xì)，限流效果就越平滑。相反，如果劃分粒度越粗，限流效果就越不精確，出現(xiàn)臨界問題的可能性也就越大，當(dāng)劃分粒度為 1 時(shí)，滑動(dòng)窗口算法就退化成了固定窗口算法。由于這兩種算法都使用了計(jì)數(shù)器，所以也被稱為?計(jì)數(shù)器算法（Counters）。進(jìn)一步思考我們發(fā)現(xiàn)，如果劃分粒度最粗，也就是只有一個(gè)時(shí)間窗口時(shí)，滑動(dòng)窗口算法退化成了固定窗口算法；那如果我們把劃分粒度調(diào)到最細(xì)，又會(huì)如何呢？那么怎樣才能讓劃分的時(shí)間窗口最細(xì)呢？時(shí)間窗口細(xì)到一定地步時(shí)，意味著每個(gè)時(shí)間窗口中只能容納一個(gè)請(qǐng)求，這樣我們可以省略計(jì)數(shù)器，只記錄每個(gè)請(qǐng)求的時(shí)間，然后統(tǒng)計(jì)一段時(shí)間內(nèi)的請(qǐng)求數(shù)有多少個(gè)即可。具體的實(shí)現(xiàn)可以參考Redis sorted set 技巧?和Sliding window log 算法。

2.3 漏桶算法（Leaky Bucket）

除了計(jì)數(shù)器算法，另一個(gè)很自然的限流思路是將所有的請(qǐng)求緩存到一個(gè)隊(duì)列中，然后按某個(gè)固定的速度慢慢處理，這其實(shí)就是漏桶算法（Leaky Bucket）。漏桶算法假設(shè)將請(qǐng)求裝到一個(gè)桶中，桶的容量為 M，當(dāng)桶滿時(shí)，請(qǐng)求被丟棄。在桶的底部有一個(gè)洞，桶中的請(qǐng)求像水一樣按固定的速度（每秒 r 個(gè)）漏出來。我們用下面這個(gè)形象的圖來表示漏桶算法：實(shí)戰(zhàn)?Spring?Cloud?Gateway?之限流篇

桶的上面是個(gè)水龍頭，我們的請(qǐng)求從水龍頭流到桶中，水龍頭流出的水速不定，有時(shí)快有時(shí)慢，這種忽快忽慢的流量叫做 Bursty flow。如果桶中的水滿了，多余的水就會(huì)溢出去，相當(dāng)于請(qǐng)求被丟棄。從桶底部漏出的水速是固定不變的，可以看出漏桶算法可以平滑請(qǐng)求的速率。漏桶算法可以通過一個(gè)隊(duì)列來實(shí)現(xiàn)，如下圖所示：實(shí)戰(zhàn)?Spring?Cloud?Gateway?之限流篇

當(dāng)請(qǐng)求到達(dá)時(shí)，不直接處理請(qǐng)求，而是將其放入一個(gè)隊(duì)列，然后另一個(gè)線程以固定的速率從隊(duì)列中讀取請(qǐng)求并處理，從而達(dá)到限流的目的。注意的是這個(gè)隊(duì)列可以有不同的實(shí)現(xiàn)方式，比如設(shè)置請(qǐng)求的存活時(shí)間，或?qū)㈥?duì)列改造成 PriorityQueue，根據(jù)請(qǐng)求的優(yōu)先級(jí)排序而不是先進(jìn)先出。當(dāng)然隊(duì)列也有滿的時(shí)候，如果隊(duì)列已經(jīng)滿了，那么請(qǐng)求只能被丟棄了。漏桶算法有一個(gè)缺陷，在處理突發(fā)流量時(shí)效率很低，于是人們又想出了下面的令牌桶算法。

2.4 令牌桶算法（Token Bucket）

令牌桶算法（Token Bucket）是目前應(yīng)用最廣泛的一種限流算法，它的基本思想由兩部分組成：生成令牌?和?消費(fèi)令牌。

生成令牌：假設(shè)有一個(gè)裝令牌的桶，最多能裝 M 個(gè)，然后按某個(gè)固定的速度（每秒 r 個(gè)）往桶中放入令牌，桶滿時(shí)不再放入；
消費(fèi)令牌：我們的每次請(qǐng)求都需要從桶中拿一個(gè)令牌才能放行，當(dāng)桶中沒有令牌時(shí)即觸發(fā)限流，這時(shí)可以將請(qǐng)求放入一個(gè)緩沖隊(duì)列中排隊(duì)等待，或者直接拒絕；

令牌桶算法的圖示如下：實(shí)戰(zhàn)?Spring?Cloud?Gateway?之限流篇

在上面的圖中，我們將請(qǐng)求放在一個(gè)緩沖隊(duì)列中，可以看出這一部分的邏輯和漏桶算法幾乎一模一樣，只不過在處理請(qǐng)求上，一個(gè)是以固定速率處理，一個(gè)是從桶中獲取令牌后才處理。仔細(xì)思考就會(huì)發(fā)現(xiàn)，令牌桶算法有一個(gè)很關(guān)鍵的問題，就是桶大小的設(shè)置，正是這個(gè)參數(shù)可以讓令牌桶算法具備處理突發(fā)流量的能力。譬如將桶大小設(shè)置為 100，生成令牌的速度設(shè)置為每秒 10 個(gè)，那么在系統(tǒng)空閑一段時(shí)間的之后（桶中令牌一直沒有消費(fèi)，慢慢的會(huì)被裝滿），突然來了 50 個(gè)請(qǐng)求，這時(shí)系統(tǒng)可以直接按每秒 50 個(gè)的速度處理，隨著桶中的令牌很快用完，處理速度又會(huì)慢慢降下來，和生成令牌速度趨于一致。這是令牌桶算法和漏桶算法最大的區(qū)別，漏桶算法無論來了多少請(qǐng)求，只會(huì)一直以每秒 10 個(gè)的速度進(jìn)行處理。當(dāng)然，處理突發(fā)流量雖然提高了系統(tǒng)性能，但也給系統(tǒng)帶來了一定的壓力，如果桶大小設(shè)置不合理，突發(fā)的大流量可能會(huì)直接壓垮系統(tǒng)。通過上面對(duì)令牌桶的原理分析，一般會(huì)有兩種不同的實(shí)現(xiàn)方式。第一種方式是啟動(dòng)一個(gè)內(nèi)部線程，不斷的往桶中添加令牌，處理請(qǐng)求時(shí)從桶中獲取令牌，和上面圖中的處理邏輯一樣。第二種方式不依賴于內(nèi)部線程，而是在每次處理請(qǐng)求之前先實(shí)時(shí)計(jì)算出要填充的令牌數(shù)并填充，然后再從桶中獲取令牌。下面是第二種方式的一種經(jīng)典實(shí)現(xiàn)，其中 capacity 表示令牌桶大小，refillTokensPerOneMillis 表示填充速度，每毫秒填充多少個(gè)，availableTokens 表示令牌桶中還剩多少個(gè)令牌，lastRefillTimestamp 表示上一次填充時(shí)間。 1public?class?TokenBucket?{
2
3????private?final?long?capacity;
4????private?final?double?refillTokensPerOneMillis;
5????private?double?availableTokens;
6????private?long?lastRefillTimestamp;
7
8????public?TokenBucket(long?capacity,?long?refillTokens,?long?refillPeriodMillis)?{
9????????this.capacity?=?capacity;
10????????this.refillTokensPerOneMillis?=?(double)?refillTokens?/?(double)?refillPeriodMillis;
11????????this.availableTokens?=?capacity;
12????????this.lastRefillTimestamp?=?System.currentTimeMillis();
13????}
14
15????synchronized?public?boolean?tryConsume(int?numberTokens)?{
16????????refill();
17????????if?(availableTokens?18????????????return?false;
19????????}?else?{
20????????????availableTokens?-=?numberTokens;
21????????????return?true;
22????????}
23????}
24
25????private?void?refill()?{
26????????long?currentTimeMillis?=?System.currentTimeMillis();
27????????if?(currentTimeMillis?>?lastRefillTimestamp)?{
28????????????long?millisSinceLastRefill?=?currentTimeMillis?-?lastRefillTimestamp;
29????????????double?refill?=?millisSinceLastRefill?*?refillTokensPerOneMillis;
30????????????this.availableTokens?=?Math.min(capacity,?availableTokens? ?refill);
31????????????this.lastRefillTimestamp?=?currentTimeMillis;
32????????}
33????}
34}
可以像下面這樣創(chuàng)建一個(gè)令牌桶（桶大小為 100，且每秒生成 100 個(gè)令牌）:1TokenBucket?limiter?=?new?TokenBucket(100,?100,?1000);
從上面的代碼片段可以看出，令牌桶算法的實(shí)現(xiàn)非常簡(jiǎn)單也非常高效，僅僅通過幾個(gè)變量的運(yùn)算就實(shí)現(xiàn)了完整的限流功能。核心邏輯在于 refill()?這個(gè)方法，在每次消費(fèi)令牌時(shí)，計(jì)算當(dāng)前時(shí)間和上一次填充的時(shí)間差，并根據(jù)填充速度計(jì)算出應(yīng)該填充多少令牌。在重新填充令牌后，再判斷請(qǐng)求的令牌數(shù)是否足夠，如果不夠，返回 false，如果足夠，則減去令牌數(shù)，并返回 true。在實(shí)際的應(yīng)用中，往往不會(huì)直接使用這種原始的令牌桶算法，一般會(huì)在它的基礎(chǔ)上作一些改進(jìn)，比如，填充速率支持動(dòng)態(tài)調(diào)整，令牌總數(shù)支持透支，基于 Redis 支持分布式限流等，不過總體來說還是符合令牌桶算法的整體框架，我們?cè)诤竺鎸W(xué)習(xí)一些開源項(xiàng)目時(shí)對(duì)此會(huì)有更深的體會(huì)。

三、一些開源項(xiàng)目

有很多開源項(xiàng)目中都實(shí)現(xiàn)了限流的功能，這一節(jié)通過一些開源項(xiàng)目的學(xué)習(xí)，了解限流是如何實(shí)現(xiàn)的。

3.1 Guava 的 RateLimiter

Google Guava 是一個(gè)強(qiáng)大的核心庫，包含了很多有用的工具類，例如：集合、緩存、并發(fā)庫、字符串處理、I/O 等等。其中在并發(fā)庫中，Guava 提供了兩個(gè)和限流相關(guān)的類：RateLimiter 和 SmoothRateLimiter。Guava 的 RateLimiter 基于令牌桶算法實(shí)現(xiàn)，不過在傳統(tǒng)的令牌桶算法基礎(chǔ)上做了點(diǎn)改進(jìn)，支持兩種不同的限流方式：平滑突發(fā)限流（SmoothBursty）?和?平滑預(yù)熱限流（SmoothWarmingUp）。下面的方法可以創(chuàng)建一個(gè)平滑突發(fā)限流器（SmoothBursty）：

1RateLimiter?limiter?=?RateLimiter.create(5);

RateLimiter.create(5)?表示這個(gè)限流器容量為 5，并且每秒生成 5 個(gè)令牌，也就是每隔 200 毫秒生成一個(gè)。我們可以使用 limiter.acquire()?消費(fèi)令牌，如果桶中令牌足夠，返回 0，如果令牌不足，則阻塞等待，并返回等待的時(shí)間。我們連續(xù)請(qǐng)求幾次：

1System.out.println(limiter.acquire());
2System.out.println(limiter.acquire());
3System.out.println(limiter.acquire());
4System.out.println(limiter.acquire());

輸出結(jié)果如下：

可以看出限流器創(chuàng)建之后，初始會(huì)有一個(gè)令牌，然后每隔 200 毫秒生成一個(gè)令牌，所以第一次請(qǐng)求直接返回 0，后面的請(qǐng)求都會(huì)阻塞大約 200 毫秒。另外，SmoothBursty 還具有應(yīng)對(duì)突發(fā)的能力，而且?還允許消費(fèi)未來的令牌，比如下面的例子：

1RateLimiter?limiter?=?RateLimiter.create(5);
2System.out.println(limiter.acquire(10));
3System.out.println(limiter.acquire(1));
4System.out.println(limiter.acquire(1));

會(huì)得到類似下面的輸出：

限流器創(chuàng)建之后，初始令牌只有一個(gè)，但是我們請(qǐng)求 10 個(gè)令牌竟然也通過了，只不過看后面請(qǐng)求發(fā)現(xiàn)，第二次請(qǐng)求花了 2 秒左右的時(shí)間把前面的透支的令牌給補(bǔ)上了。
Guava 支持的另一種限流方式是平滑預(yù)熱限流器（SmoothWarmingUp），可以通過下面的方法創(chuàng)建：

1RateLimiter?limiter?=?RateLimiter.create(2,?3,?TimeUnit.SECONDS);
2System.out.println(limiter.acquire(1));
3System.out.println(limiter.acquire(1));
4System.out.println(limiter.acquire(1));
5System.out.println(limiter.acquire(1));
6System.out.println(limiter.acquire(1));

第一個(gè)參數(shù)還是每秒創(chuàng)建的令牌數(shù)量，這里是每秒 2 個(gè)，也就是每 500 毫秒生成一個(gè)，后面的參數(shù)表示從冷啟動(dòng)速率過渡到平均速率的時(shí)間間隔，也就是所謂的熱身時(shí)間間隔（warm up period）。我們看下輸出結(jié)果：

第一個(gè)請(qǐng)求還是立即得到令牌，但是后面的請(qǐng)求和上面平滑突發(fā)限流就完全不一樣了，按理來說 500 毫秒就會(huì)生成一個(gè)令牌，但是我們發(fā)現(xiàn)第二個(gè)請(qǐng)求卻等了 1.3s，而不是 0.5s，后面第三個(gè)和第四個(gè)請(qǐng)求也等了一段時(shí)間。不過可以看出，等待時(shí)間在慢慢的接近 0.5s，直到第五個(gè)請(qǐng)求等待時(shí)間才開始變得正常。從第一個(gè)請(qǐng)求到第五個(gè)請(qǐng)求，這中間的時(shí)間間隔就是熱身階段，可以算出熱身的時(shí)間就是我們?cè)O(shè)置的 3 秒。

3.2 Bucket4j

Bucket4j是一個(gè)基于令牌桶算法實(shí)現(xiàn)的強(qiáng)大的限流庫，它不僅支持單機(jī)限流，還支持通過諸如 Hazelcast、Ignite、Coherence、Infinispan 或其他兼容 JCache API (JSR 107)?規(guī)范的分布式緩存實(shí)現(xiàn)分布式限流。在使用 Bucket4j 之前，我們有必要先了解 Bucket4j 中的幾個(gè)核心概念：

Bucket
Bandwidth
Refill

Bucket 接口代表了令牌桶的具體實(shí)現(xiàn)，也是我們操作的入口。它提供了諸如 tryConsume 和 tryConsumeAndReturnRemaining 這樣的方法供我們消費(fèi)令牌?？梢酝ㄟ^下面的構(gòu)造方法來創(chuàng)建Bucket:

1Bucket?bucket?=?Bucket4j.builder().addLimit(limit).build();
2if(bucket.tryConsume(1))?{
3????System.out.println("ok");
4}?else?{
5????System.out.println("error");
6}

Bandwidth 的意思是帶寬，可以理解為限流的規(guī)則。Bucket4j 提供了兩種方法來創(chuàng)建 Bandwidth：simple 和 classic。下面是 simple 方式創(chuàng)建的 Bandwidth，表示桶大小為 10，填充速度為每分鐘 10 個(gè)令牌:

1Bandwidth?limit?=?Bandwidth.simple(10,?Duration.ofMinutes(1));

simple方式桶大小和填充速度是一樣的，classic 方式更靈活一點(diǎn)，可以自定義填充速度，下面的例子表示桶大小為 10，填充速度為每分鐘 5 個(gè)令牌:

1Refill?filler?=?Refill.greedy(5,?Duration.ofMinutes(1));
2Bandwidth?limit?=?Bandwidth.classic(10,?filler);

其中，Refill 用于填充令牌桶，可以通過它定義填充速度，Bucket4j 有兩種填充令牌的策略：間隔策略（intervally）?和?貪婪策略（greedy）。在上面的例子中我們使用的是貪婪策略，如果使用間隔策略可以像下面這樣創(chuàng)建 Refill：

1Refill?filler?=?Refill.intervally(5,?Duration.ofMinutes(1));

所謂間隔策略指的是每隔一段時(shí)間，一次性的填充所有令牌，比如上面的例子，會(huì)每隔一分鐘，填充 5 個(gè)令牌，如下所示：
實(shí)戰(zhàn)?Spring?Cloud?Gateway?之限流篇

而貪婪策略會(huì)盡可能貪婪的填充令牌，同樣是上面的例子，會(huì)將一分鐘劃分成 5 個(gè)更小的時(shí)間單元，每隔 12 秒，填充 1 個(gè)令牌，如下所示：實(shí)戰(zhàn)?Spring?Cloud?Gateway?之限流篇

在了解了 Bucket4j 中的幾個(gè)核心概念之后，我們?cè)賮砜纯垂倬W(wǎng)介紹的一些特性：

基于令牌桶算法
高性能，無鎖實(shí)現(xiàn)
不存在精度問題，所有計(jì)算都是基于整型的
支持通過符合 JCache API 規(guī)范的分布式緩存系統(tǒng)實(shí)現(xiàn)分布式限流
支持為每個(gè) Bucket 設(shè)置多個(gè) Bandwidth
支持同步和異步 API
支持可插拔的監(jiān)聽 API，用于集成監(jiān)控和日志
不僅可以用于限流，還可以用于簡(jiǎn)單的調(diào)度

Bucket4j 提供了豐富的文檔，推薦在使用 Bucket4j 之前，先把官方文檔中的?基本用法?和?高級(jí)特性?仔細(xì)閱讀一遍。另外，關(guān)于 Bucket4j 的使用，推薦這篇文章 Rate limiting Spring MVC endpoints with bucket4j，這篇文章詳細(xì)的講解了如何在 Spring MVC 中使用攔截器和 Bucket4j 打造業(yè)務(wù)無侵入的限流方案，另外還講解了如何使用 Hazelcast 實(shí)現(xiàn)分布式限流；另外，Rate Limiting a Spring API Using Bucket4j 這篇文章也是一份很好的入門教程，介紹了 Bucket4j 的基礎(chǔ)知識(shí)，在文章的最后還提供了 Spring Boot Starter 的集成方式，結(jié)合 Spring Boot Actuator 很容易將限流指標(biāo)集成到監(jiān)控系統(tǒng)中。和 Guava 的限流器相比，Bucket4j 的功能顯然要更勝一籌，畢竟 Guava 的目的只是用作通用工具類，而不是用于限流的。使用 Bucket4j 基本上可以滿足我們的大多數(shù)要求，不僅支持單機(jī)限流和分布式限流，而且可以很好的集成監(jiān)控，搭配 Prometheus 和 Grafana 簡(jiǎn)直完美。值得一提的是，有很多開源項(xiàng)目譬如 JHipster API Gateway 就是使用 Bucket4j 來實(shí)現(xiàn)限流的。Bucket4j 唯一不足的地方是它只支持請(qǐng)求頻率限流，不支持并發(fā)量限流，另外還有一點(diǎn)，雖然 Bucket4j 支持分布式限流，但它是基于 Hazelcast 這樣的分布式緩存系統(tǒng)實(shí)現(xiàn)的，不能使用 Redis，這在很多使用 Redis 作緩存的項(xiàng)目中就很不爽，所以我們還需要在開源的世界里繼續(xù)探索。

3.3 Resilience4j

Resilience4j 是一款輕量級(jí)、易使用的高可用框架。用過 Spring Cloud 早期版本的同學(xué)肯定都聽過 Netflix Hystrix，Resilience4j 的設(shè)計(jì)靈感就來自于它。自從 Hystrix 停止維護(hù)之后，官方也推薦大家使用 Resilience4j 來代替 Hystrix。實(shí)戰(zhàn)?Spring?Cloud?Gateway?之限流篇

Resilience4j 的底層采用 Vavr，這是一個(gè)非常輕量級(jí)的 Java 函數(shù)式庫，使得 Resilience4j 非常適合函數(shù)式編程。Resilience4j 以裝飾器模式提供對(duì)函數(shù)式接口或 lambda 表達(dá)式的封裝，提供了一波高可用機(jī)制：重試（Retry）、熔斷（Circuit Breaker）、限流（Rate Limiter）、限時(shí)（Timer Limiter）、隔離（Bulkhead）、緩存（Caceh）?和?降級(jí)（Fallback）。我們重點(diǎn)關(guān)注這里的兩個(gè)功能：限流（Rate Limiter）?和?隔離（Bulkhead），Rate Limiter 是請(qǐng)求頻率限流，Bulkhead 是并發(fā)量限流。Resilience4j 提供了兩種限流的實(shí)現(xiàn)：SemaphoreBasedRateLimiter 和 AtomicRateLimiter。SemaphoreBasedRateLimiter 基于信號(hào)量實(shí)現(xiàn)，用戶的每次請(qǐng)求都會(huì)申請(qǐng)一個(gè)信號(hào)量，并記錄申請(qǐng)的時(shí)間，申請(qǐng)通過則允許請(qǐng)求，申請(qǐng)失敗則限流，另外有一個(gè)內(nèi)部線程會(huì)定期掃描過期的信號(hào)量并釋放，很顯然這是令牌桶的算法。AtomicRateLimiter 和上面的經(jīng)典實(shí)現(xiàn)類似，不需要額外的線程，在處理每次請(qǐng)求時(shí)，根據(jù)距離上次請(qǐng)求的時(shí)間和生成令牌的速度自動(dòng)填充。關(guān)于這二者的區(qū)別可以參考文章 Rate Limiter Internals in Resilience4j。Resilience4j 也提供了兩種隔離的實(shí)現(xiàn)：SemaphoreBulkhead 和 ThreadPoolBulkhead，通過信號(hào)量或線程池控制請(qǐng)求的并發(fā)數(shù)，具體的用法參考官方文檔，這里不再贅述。下面是一個(gè)同時(shí)使用限流和隔離的例子：

 1//?創(chuàng)建一個(gè)?Bulkhead，最大并發(fā)量為?150
 2BulkheadConfig?bulkheadConfig?=?BulkheadConfig.custom()
 3????.maxConcurrentCalls(150)
 4????.maxWaitTime(100)
 5????.build();
 6Bulkhead?bulkhead?=?Bulkhead.of("backendName",?bulkheadConfig);
 7
 8//?創(chuàng)建一個(gè)?RateLimiter，每秒允許一次請(qǐng)求
 9RateLimiterConfig?rateLimiterConfig?=?RateLimiterConfig.custom()
10????.timeoutDuration(Duration.ofMillis(100))
11????.limitRefreshPeriod(Duration.ofSeconds(1))
12????.limitForPeriod(1)
13????.build();
14RateLimiter?rateLimiter?=?RateLimiter.of("backendName",?rateLimiterConfig);
15
16//?使用?Bulkhead?和?RateLimiter?裝飾業(yè)務(wù)邏輯
17Supplier?supplier?=?()?->?backendService.doSomething();
18Supplier?decoratedSupplier?=?Decorators.ofSupplier(supplier)
19??.withBulkhead(bulkhead)
20??.withRateLimiter(rateLimiter)
21??.decorate();
22
23//?調(diào)用業(yè)務(wù)邏輯
24Try?try?=?Try.ofSupplier(decoratedSupplier);
25assertThat(try.isSuccess()).isTrue();

Resilience4j 在功能特性上比 Bucket4j 強(qiáng)大不少，而且還支持并發(fā)量限流。不過最大的遺憾是，Resilience4j 不支持分布式限流。

3.4 其他

網(wǎng)上還有很多限流相關(guān)的開源項(xiàng)目，不可能一一介紹，這里列出來的只是冰山之一角：

https://github.com/mokies/ratelimitj
https://github.com/wangzheng0822/ratelimiter4j
https://github.com/wukq/rate-limiter
https://github.com/marcosbarbero/spring-cloud-zuul-ratelimit
https://github.com/onblog/SnowJena
https://gitee.com/zhanghaiyang/spring-boot-starter-current-limiting
https://github.com/Netflix/concurrency-limits

可以看出，限流技術(shù)在實(shí)際項(xiàng)目中應(yīng)用非常廣泛，大家對(duì)實(shí)現(xiàn)自己的限流算法樂此不疲，新算法和新實(shí)現(xiàn)層出不窮。但是找來找去，目前還沒有找到一款開源項(xiàng)目完全滿足我的需求。我的需求其實(shí)很簡(jiǎn)單，需要同時(shí)滿足兩種不同的限流場(chǎng)景：請(qǐng)求頻率限流和并發(fā)量限流，并且能同時(shí)滿足兩種不同的限流架構(gòu)：?jiǎn)螜C(jī)限流和分布式限流。下面我們就開始在 Spring Cloud Gateway 中實(shí)現(xiàn)這幾種限流，通過前面介紹的那些項(xiàng)目，我們?nèi)￠L(zhǎng)補(bǔ)短，基本上都能用比較成熟的技術(shù)實(shí)現(xiàn)，只不過對(duì)于最后一種情況，分布式并發(fā)量限流，網(wǎng)上沒有搜到現(xiàn)成的解決方案，在和同事討論了幾個(gè)晚上之后，想出一種新型的基于雙窗口滑動(dòng)的限流算法，我在這里拋磚引玉，歡迎大家批評(píng)指正，如果大家有更好的方法，也歡迎討論。

四、在網(wǎng)關(guān)中實(shí)現(xiàn)限流

在文章一開始介紹 Spring Cloud Gateway 的特性時(shí)，我們注意到其中有一條 Request Rate Limiting，說明網(wǎng)關(guān)自帶了限流的功能，但是 Spring Cloud Gateway 自帶的限流有很多限制，譬如不支持單機(jī)限流，不支持并發(fā)量限流，而且它的請(qǐng)求頻率限流也是不盡人意，這些都需要我們自己動(dòng)手來解決。

4.1 實(shí)現(xiàn)單機(jī)請(qǐng)求頻率限流

Spring Cloud Gateway 中定義了關(guān)于限流的一個(gè)接口 RateLimiter，如下：

1public?interface?RateLimiter<C>?extends?StatefulConfigurable<C>?{
2????Mono?isAllowed(String?routeId,?String?id);
3}

這個(gè)接口就一個(gè)方法 isAllowed，第一個(gè)參數(shù) routeId 表示請(qǐng)求路由的 ID，根據(jù) routeId 可以獲取限流相關(guān)的配置，第二個(gè)參數(shù) id 表示要限流的對(duì)象的唯一標(biāo)識(shí)，可以是用戶名，也可以是 IP，或者其他的可以從 ServerWebExchange 中得到的信息。我們看下 RequestRateLimiterGatewayFilterFactory 中對(duì) isAllowed 的調(diào)用邏輯：

 1@Override
 2public?GatewayFilter?apply(Config?config)?{
 3????//?從配置中得到?KeyResolver
 4????KeyResolver?resolver?=?getOrDefault(config.keyResolver,?defaultKeyResolver);
 5????//?從配置中得到?RateLimiter
 6????RateLimiter