摘要:歡迎訪問我的歡迎訪問我的內容所有原創文章分類匯總及配套源碼,涉及等本篇概覽本篇概覽本文是實戰系列的第八篇,經過前面的學習,咱們對過濾器已了解得差不多,今天來補全過濾器的最后一個版塊限流默認的限流器是基于實現的,限流算法是大家熟悉的令牌桶關于
https://github.com/zq2599/blog_demos
內容:所有原創文章分類匯總及配套源碼,涉及Java、Docker、Kubernetes、DevOPS等;
本文是《Spring Cloud Gateway實戰》系列的第八篇,經過前面的學習,咱們對過濾器已了解得差不多,今天來補全過濾器的最后一個版塊:限流(RequestRateLimiter )
默認的限流器是基于redis實現的,限流算法是大家熟悉的令牌桶(Token Bucket Algorithm),關于令牌捅的原理就不在此展開了,聰明的您看一眼下圖應該就懂了:裝令牌的桶容量有限,例如最多20個,令牌進入桶的速度恒定(注意,這里是和漏桶算法的區別),例如每秒10個,底部每個請求能拿到令牌才會被處理:
名稱 | 鏈接 | 備注 |
---|---|---|
項目主頁 | https://github.com/zq2599/blog_demos | 該項目在GitHub上的主頁 |
git倉庫地址(https) | https://github.com/zq2599/blog_demos.git | 該項目源碼的倉庫地址,https協議 |
git倉庫地址(ssh) | git@github.com:zq2599/blog_demos.git | 該項目源碼的倉庫地址,ssh協議 |
@GetMapping("/userinfo") public String userInfo(@RequestParam("username") String username) { return Constants.HELLO_PREFIX + " " + username + ", " + dateStr(); }
spring-cloud-tutorials com.bolingcavalry 1.0-SNAPSHOT 4.0.0 gateway-requestratelimiter com.bolingcavalry common ${project.version} org.springframework.cloud spring-cloud-starter-gateway org.springframework.boot spring-boot-starter-data-redis-reactive
server: #服務端口 port: 8081spring: application: name: circuitbreaker-gateway # redis配置 redis: host: 192.168.50.43 port: 6379 cloud: gateway: routes: - id: path_route uri: http://127.0.0.1:8082 predicates: - Path=/hello/** filters: - name: RequestRateLimiter args: # 令牌入桶的速度為每秒100個,相當于QPS redis-rate-limiter.replenishRate: 100 # 桶內能裝200個令牌,相當于峰值,要注意的是:第一秒從桶內能去200個,但是第二秒只能取到100個了,因為入桶速度是每秒100個 redis-rate-limiter.burstCapacity: 200 # 每個請求需要的令牌數 redis-rate-limiter.requestedTokens: 1
package com.bolingcavalry.gateway.config;import org.springframework.cloud.gateway.filter.ratelimit.KeyResolver;import org.springframework.context.annotation.Bean;import org.springframework.context.annotation.Configuration;import reactor.core.publisher.Mono;import java.util.Objects;@Configurationpublic class CustomizeConfig { @Bean KeyResolver userKeyResolver() { return exchange -> Mono.just(exchange.getRequest().getQueryParams().getFirst("username")); }}
package com.bolingcavalry.gateway;import org.springframework.boot.SpringApplication;import org.springframework.boot.autoconfigure.SpringBootApplication;@SpringBootApplicationpublic class RequestRateLimiterApplication { public static void main(String[] args) { SpringApplication.run(RequestRateLimiterApplication.class,args); }}
首先驗證的是桶容量等于入桶速度時的效果,請修改gateway-requestratelimiter應用的application.yml中文件,使得redis-rate-limiter.replenishRate和redis-rate-limiter.burstCapacity的值都等于100,也就是說桶的大小等于100,每秒放入的令牌數也是100
確保redis已經啟動,并且與application.yml中的配置保持一直
啟動nacos(provider-hello依賴)
啟動服務提供者provider-hello
啟動gateway-requestratelimiter
為了模擬web請求,我這里使用了Apache Benchmark,windows版本的下載地址:
https://www.apachelounge.com/download/VS16/binaries/httpd-2.4.48-win64-VS16.zip
上述文件下載解壓后即可使用,在控制臺進入Apache24/bin后執行以下命令,意思是向指定地址發送10000個請求,并發數為2:
ab -n 10000 -c 2 http://localhost:8081/hello/userinfo?username=Tom
接下來試試桶容量大于入桶速度時的限流效果,這對于我們控制峰值響應有很重要的參考價值
請修改gateway-requestratelimiter應用的application.yml中文件,redis-rate-limiter.replenishRate維持100不變,但是redis-rate-limiter.burstCapacity改成200,也就是說每秒放入的令牌數還是100,但桶的容量翻倍了
重啟應用gateway-requestratelimiter
再次執行以下命令,意思是向指定地址發送10000個請求,并發數為2:
ab -n 10000 -c 2 http://localhost:8081/hello/userinfo?username=Tom
接下來驗證限流的維度,究竟是不是按照請求參數username的值來限流的
咱們打開兩個命令行,同時發送請求(動作要快),第一個的username等于Tom,第二個等于Jerry,理論上推測,如果都是8秒內完成,那么每個命令都有900個請求能成功
測試結果如下圖,可見符合預期,每個username用的是自己的令牌:
微信搜索「程序員欣宸」,我是欣宸,期待與您一同暢游Java世界...
https://github.com/zq2599/blog_demos
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/124538.html
摘要:以流量為切入點,從流量控制熔斷降級系統負載保護等多個維度保護服務的穩定性分布式系統的流量防衛兵。歡迎關注我們獲得更多的好玩實踐 之前分享過 一篇 《Spring Cloud Gateway 原生的接口限流該怎么玩》, 核心是依賴Spring Cloud Gateway 默認提供的限流過濾器來實現 原生RequestRateLimiter 的不足 配置方式 spring: clou...
摘要:以流量為切入點,從流量控制熔斷降級系統負載保護等多個維度保護服務的穩定性分布式系統的流量防衛兵。歡迎關注我們獲得更多的好玩實踐 之前分享過 一篇 《Spring Cloud Gateway 原生的接口限流該怎么玩》, 核心是依賴Spring Cloud Gateway 默認提供的限流過濾器來實現 原生RequestRateLimiter 的不足 配置方式 spring: clou...
摘要:常見的限流方式,比如適用線程池隔離,超過線程池的負載,走熔斷的邏輯。在令牌桶算法中,存在一個桶,用來存放固定數量的令牌。,令牌桶每秒填充平均速率。 轉載請標明出處: https://www.fangzhipeng.com本文出自方志朋的博客 在高并發的系統中,往往需要在系統中做限流,一方面是為了防止大量的請求使服務器過載,導致服務不可用,另一方面是為了防止網絡攻擊。 常見的限流方式,...
摘要:應對突發請求時額外允許的請求數目。勻速排隊模式下的最長排隊時間,單位是毫秒,僅在勻速排隊模式下生效。和為后續參數匹配特性預留,目前未實現。 1. 前言 4月25號,Sentinel 1.6.0 正式發布,帶來 Spring Cloud Gateway 支持、控制臺登錄功能、改進的熱點限流和注解 fallback 等多項新特性,該出手時就出手,緊跟時代潮流,昨天剛發布,今天我就要給大家分...
閱讀 1263·2021-11-23 09:51
閱讀 2638·2021-09-03 10:47
閱讀 2234·2019-08-30 15:53
閱讀 2414·2019-08-30 15:44
閱讀 1375·2019-08-30 15:44
閱讀 1194·2019-08-30 10:57
閱讀 1924·2019-08-29 12:25
閱讀 1086·2019-08-26 11:57