摘要：常見的限流方式，比如適用線程池隔離，超過線程池的負(fù)載，走熔斷的邏輯。在令牌桶算法中，存在一個(gè)桶，用來存放固定數(shù)量的令牌。，令牌桶每秒填充平均速率。

轉(zhuǎn)載請標(biāo)明出處： 
https://www.fangzhipeng.com
本文出自方志朋的博客

在高并發(fā)的系統(tǒng)中，往往需要在系統(tǒng)中做限流，一方面是為了防止大量的請求使服務(wù)器過載，導(dǎo)致服務(wù)不可用，另一方面是為了防止網(wǎng)絡(luò)攻擊。

常見的限流方式，比如Hystrix適用線程池隔離，超過線程池的負(fù)載，走熔斷的邏輯。在一般應(yīng)用服務(wù)器中，比如tomcat容器也是通過限制它的線程數(shù)來控制并發(fā)的；也有通過時(shí)間窗口的平均速度來控制流量。常見的限流緯度有比如通過Ip來限流、通過uri來限流、通過用戶訪問頻次來限流。

一般限流都是在網(wǎng)關(guān)這一層做，比如Nginx、Openresty、kong、zuul、Spring Cloud Gateway等；也可以在應(yīng)用層通過Aop這種方式去做限流。

本文詳細(xì)探討在 Spring Cloud Gateway 中如何實(shí)現(xiàn)限流。

計(jì)數(shù)器算法采用計(jì)數(shù)器實(shí)現(xiàn)限流有點(diǎn)簡單粗暴，一般我們會(huì)限制一秒鐘的能夠通過的請求數(shù)，比如限流qps為100，算法的實(shí)現(xiàn)思路就是從第一個(gè)請求進(jìn)來開始計(jì)時(shí)，在接下去的1s內(nèi)，每來一個(gè)請求，就把計(jì)數(shù)加1，如果累加的數(shù)字達(dá)到了100，那么后續(xù)的請求就會(huì)被全部拒絕。等到1s結(jié)束后，把計(jì)數(shù)恢復(fù)成0，重新開始計(jì)數(shù)。具體的實(shí)現(xiàn)可以是這樣的：對于每次服務(wù)調(diào)用，可以通過AtomicLong#incrementAndGet()方法來給計(jì)數(shù)器加1并返回最新值，通過這個(gè)最新值和閾值進(jìn)行比較。這種實(shí)現(xiàn)方式，相信大家都知道有一個(gè)弊端：如果我在單位時(shí)間1s內(nèi)的前10ms，已經(jīng)通過了100個(gè)請求，那后面的990ms，只能眼巴巴的把請求拒絕，我們把這種現(xiàn)象稱為“突刺現(xiàn)象”

漏桶算法為了消除"突刺現(xiàn)象"，可以采用漏桶算法實(shí)現(xiàn)限流，漏桶算法這個(gè)名字就很形象，算法內(nèi)部有一個(gè)容器，類似生活用到的漏斗，當(dāng)請求進(jìn)來時(shí)，相當(dāng)于水倒入漏斗，然后從下端小口慢慢勻速的流出。不管上面流量多大，下面流出的速度始終保持不變。不管服務(wù)調(diào)用方多么不穩(wěn)定，通過漏桶算法進(jìn)行限流，每10毫秒處理一次請求。因?yàn)樘幚淼乃俣仁枪潭ǖ?，請求進(jìn)來的速度是未知的，可能突然進(jìn)來很多請求，沒來得及處理的請求就先放在桶里，既然是個(gè)桶，肯定是有容量上限，如果桶滿了，那么新進(jìn)來的請求就丟棄。

在算法實(shí)現(xiàn)方面，可以準(zhǔn)備一個(gè)隊(duì)列，用來保存請求，另外通過一個(gè)線程池（ScheduledExecutorService）來定期從隊(duì)列中獲取請求并執(zhí)行，可以一次性獲取多個(gè)并發(fā)執(zhí)行。

這種算法，在使用過后也存在弊端：無法應(yīng)對短時(shí)間的突發(fā)流量。

從某種意義上講，令牌桶算法是對漏桶算法的一種改進(jìn)，桶算法能夠限制請求調(diào)用的速率，而令牌桶算法能夠在限制調(diào)用的平均速率的同時(shí)還允許一定程度的突發(fā)調(diào)用。在令牌桶算法中，存在一個(gè)桶，用來存放固定數(shù)量的令牌。算法中存在一種機(jī)制，以一定的速率往桶中放令牌。每次請求調(diào)用需要先獲取令牌，只有拿到令牌，才有機(jī)會(huì)繼續(xù)執(zhí)行，否則選擇選擇等待可用的令牌、或者直接拒絕。放令牌這個(gè)動(dòng)作是持續(xù)不斷的進(jìn)行，如果桶中令牌數(shù)達(dá)到上限，就丟棄令牌，所以就存在這種情況，桶中一直有大量的可用令牌，這時(shí)進(jìn)來的請求就可以直接拿到令牌執(zhí)行，比如設(shè)置qps為100，那么限流器初始化完成一秒后，桶中就已經(jīng)有100個(gè)令牌了，這時(shí)服務(wù)還沒完全啟動(dòng)好，等啟動(dòng)完成對外提供服務(wù)時(shí)，該限流器可以抵擋瞬時(shí)的100個(gè)請求。所以，只有桶中沒有令牌時(shí)，請求才會(huì)進(jìn)行等待，最后相當(dāng)于以一定的速率執(zhí)行。

實(shí)現(xiàn)思路：可以準(zhǔn)備一個(gè)隊(duì)列，用來保存令牌，另外通過一個(gè)線程池定期生成令牌放到隊(duì)列中，每來一個(gè)請求，就從隊(duì)列中獲取一個(gè)令牌，并繼續(xù)執(zhí)行。

在Spring Cloud Gateway中，有Filter過濾器，因此可以在“pre”類型的Filter中自行實(shí)現(xiàn)上述三種過濾器。但是限流作為網(wǎng)關(guān)最基本的功能，Spring Cloud Gateway官方就提供了RequestRateLimiterGatewayFilterFactory這個(gè)類，適用Redis和lua腳本實(shí)現(xiàn)了令牌桶的方式。具體實(shí)現(xiàn)邏輯在RequestRateLimiterGatewayFilterFactory類中，lua腳本在如下圖所示的文件夾中：

具體源碼不打算在這里講述，讀者可以自行查看，代碼量較少，先以案例的形式來講解如何在Spring Cloud Gateway中使用內(nèi)置的限流過濾器工廠來實(shí)現(xiàn)限流。

首先在工程的pom文件中引入gateway的起步依賴和redis的reactive依賴，代碼如下：

 
    org.springframework.cloud
    spring-cloud-starter-gateway



    org.springframework.boot
    spring-boot-starter-data-redis-reactive

在配置文件中做以下的配置：

server:
  port: 8081
spring:
  cloud:
    gateway:
      routes:
      - id: limit_route
        uri: http://httpbin.org:80/get
        predicates:
        - After=2017-01-20T17:42:47.789-07:00[America/Denver]
        filters:
        - name: RequestRateLimiter
          args:
            key-resolver: "#{@hostAddrKeyResolver}"
            redis-rate-limiter.replenishRate: 1
            redis-rate-limiter.burstCapacity: 3
  application:
    name: gateway-limiter
  redis:
    host: localhost
    port: 6379
    database: 0

在上面的配置文件，指定程序的端口為8081，配置了 redis的信息，并配置了RequestRateLimiter的限流過濾器，該過濾器需要配置三個(gè)參數(shù)：

burstCapacity，令牌桶總?cè)萘俊?/p>

replenishRate，令牌桶每秒填充平均速率。

key-resolver，用于限流的鍵的解析器的 Bean 對象的名字。它使用 SpEL 表達(dá)式根據(jù)#{@beanName}從 Spring 容器中獲取 Bean 對象。

KeyResolver需要實(shí)現(xiàn)resolve方法，比如根據(jù)Hostname進(jìn)行限流，則需要用hostAddress去判斷。實(shí)現(xiàn)完KeyResolver之后，需要將這個(gè)類的Bean注冊到Ioc容器中。

public class HostAddrKeyResolver implements KeyResolver {

    @Override
    public Mono resolve(ServerWebExchange exchange) {
        return Mono.just(exchange.getRequest().getRemoteAddress().getAddress().getHostAddress());
    }

}

 @Bean
    public HostAddrKeyResolver hostAddrKeyResolver() {
        return new HostAddrKeyResolver();
    }

可以根據(jù)uri去限流，這時(shí)KeyResolver代碼如下：

public class UriKeyResolver  implements KeyResolver {

    @Override
    public Mono resolve(ServerWebExchange exchange) {
        return Mono.just(exchange.getRequest().getURI().getPath());
    }

}

 @Bean
    public UriKeyResolver uriKeyResolver() {
        return new UriKeyResolver();
    }

 

也可以以用戶的維度去限流：

   @Bean
    KeyResolver userKeyResolver() {
        return exchange -> Mono.just(exchange.getRequest().getQueryParams().getFirst("user"));
    }

用jmeter進(jìn)行壓測，配置10thread去循環(huán)請求lcoalhost:8081，循環(huán)間隔1s。從壓測的結(jié)果上看到有部分請求通過，由部分請求失敗。通過redis客戶端去查看redis中存在的key。如下：

可見，RequestRateLimiter是使用Redis來進(jìn)行限流的，并在redis中存儲(chǔ)了2個(gè)key。關(guān)注這兩個(gè)key含義可以看lua源代碼。

https://github.com/forezp/Spr...

http://cloud.spring.io/spring...

https://windmt.com/2018/05/09...

http://www.spring4all.com/art...

掃一掃，支持下作者吧: