在高并發(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ù)器算法采用計(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限流

在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依賴，代碼如下：

 <dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifatId>spring-boot-starter-data-redis-reactive</artifactId>
</dependency>

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

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è)萘俊?/li>
• 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<String> 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<String> 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/SpringCloudLearning/tree/master/sc-f-gateway-limiter

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。