大家好，我是不才陳某~
這是《Spring Cloud 進階》第八篇文章，往期文章如下：
- 五十五張圖告訴你微服務的靈魂擺渡者Nacos究竟有多強？
- openFeign奪命連環9問，這誰受得了？
- 阿里面試這樣問：Nacos、Apollo、Config配置中心如何選型？這10個維度告訴你！
- 阿里面試敗北：5種微服務注冊中心如何選型？這幾個維度告訴你！
- 阿里限流神器Sentinel奪命連環 17 問？
- 對比7種分布式事務方案，還是偏愛阿里開源的Seata，真香！(原理+實戰)
- Spring Cloud Gateway奪命連環10問？
前一篇文章介紹了Spring Cloud Gateway的一些基礎知識點，今天陳某就來嘮一嘮網關層面如何做限流？
文章目錄如下：
網關如何限流？
Spring Cloud Gateway本身自帶的限流實現，過濾器是RequestRateLimiterGatewayFilterFactory，不過這種上不了台面的就不再介紹了，有興趣的可以實現下。
今天的重點是集成阿里的Sentinel實現網關限流，sentinel有不懂的可以看陳某的文章：阿里限流神器Sentinel奪命連環 17 問？
從1.6.0版本開始，Sentinel提供了SpringCloud Gateway的適配模塊，可以提供兩種資源維度的限流：
- route維度：即在配置文件中配置的路由條目，資源名為對應的
routeId，這種屬於粗粒度的限流，一般是對某個微服務進行限流。 - 自定義API維度：用戶可以利用Sentinel提供的API來自定義一些API分組，這種屬於細粒度的限流，針對某一類的uri進行匹配限流，可以跨多個微服務。
sentinel官方文檔：https://github.com/alibaba/Sentinel/wiki/網關限流
Spring Cloud Gateway集成Sentinel實現很簡單，這就是阿里的魅力，提供簡單、易操作的工具，讓程序員專注於業務。
新建項目
新建一個gateway-sentinel9026模塊，添加如下依賴：
<!--nacos注冊中心-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
<!--spring cloud gateway-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<!-- spring cloud gateway整合sentinel的依賴-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-alibaba-sentinel-gateway</artifactId>
</dependency>
<!-- sentinel的依賴-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
注意：這依然是一個網關服務，不要添加WEB的依賴
配置文件
配置文件中主要指定以下三種配置：
- nacos的地址
- sentinel控制台的地址
- 網關路由的配置
配置如下：
spring:
cloud:
## 整合sentinel，配置sentinel控制台的地址
sentinel:
transport:
## 指定控制台的地址，默認端口8080
dashboard: localhost:8080
nacos:
## 注冊中心配置
discovery:
# nacos的服務地址，nacos-server中IP地址:端口號
server-addr: 127.0.0.1:8848
gateway:
## 路由
routes:
## id只要唯一即可，名稱任意
- id: gateway-provider
uri: lb://gateway-provider
## 配置斷言
predicates:
## Path Route Predicate Factory斷言，滿足/gateway/provider/**這個請求路徑的都會被路由到http://localhost:9024這個uri中
- Path=/gateway/provider/**
上述配置中設置了一個路由gateway-provider，只要請求路徑滿足/gateway/provider/**都會被路由到gateway-provider這個服務中。
限流配置
經過上述兩個步驟其實已經整合好了Sentinel，此時訪問一下接口：http://localhost:9026/gateway/provider/port
然后在sentinel控制台可以看到已經被監控了，監控的路由是gateway-provider，如下圖：
此時我們可以為其新增一個route維度的限流，如下圖：
上圖中對gateway-provider這個路由做出了限流，QPS閾值為1。
此時快速訪問：http://localhost:9026/gateway/provider/port，看到已經被限流了，如下圖：
以上route維度的限流已經配置成功，小伙伴可以自己照着上述步驟嘗試一下。
API分組限流也很簡單，首先需要定義一個分組，API管理-> 新增API分組，如下圖：
匹配模式選擇了精確匹配（還有前綴匹配，正則匹配），因此只有這個uri：http://xxxx/gateway/provider/port會被限流。
第二步需要對這個分組添加流控規則，流控規則->新增網關流控，如下圖：
API名稱那里選擇對應的分組即可，新增之后，限流規則就生效了。
陳某不再測試了，小伙伴自己動手測試一下吧...............
陳某這里只是簡單的配置一下，至於限流規則持久化一些內容請看陳某的Sentinel文章，這里就不再過多的介紹了。
如何自定義限流異常信息？
從上面的演示中可以看到默認的異常返回信息是："Block........."，這種肯定是客戶端不能接受的，因此需要定制自己的異常返回信息。
下面介紹兩種不同的方式定制異常返回信息，開發中自己選擇其中一種。
直接配置文件中定制
開發者可以直接在配置文件中直接修改返回信息，配置如下：
spring:
cloud:
## 整合sentinel，配置sentinel控制台的地址
sentinel:
#配置限流之后，響應內容
scg:
fallback:
## 兩種模式，一種是response返回文字提示信息，
## 一種是redirect，重定向跳轉，需要同時配置redirect(跳轉的uri)
mode: response
## 響應的狀態
response-status: 200
## 響應體
response-body: '{"code": 200,"message": "請求失敗，稍后重試！"}'
上述配置中mode配置的是response，一旦被限流了，將會返回JSON串。
{
"code": 200,
"message": "請求失敗，稍后重試！"
}
重定向的配置如下：
spring:
cloud:
## 整合sentinel，配置sentinel控制台的地址
sentinel:
#配置限流之后，響應內容
scg:
fallback:
## 兩種模式，一種是response返回文字提示信息，一種是redirect，重定向跳轉，需要同時配置redirect(跳轉的uri)
mode: redirect
## 跳轉的URL
redirect: http://www.baidu.com
一旦被限流，將會直接跳轉到：http://www.baidu.com
編碼定制
這種就不太靈活了，通過硬編碼的方式，完整代碼如下：
@Configuration
public class GatewayConfig {
/**
* 自定義限流處理器
*/
@PostConstruct
public void initBlockHandlers() {
BlockRequestHandler blockHandler = (serverWebExchange, throwable) -> {
Map map = new HashMap();
map.put("code",200);
map.put("message","請求失敗，稍后重試！");
return ServerResponse.status(HttpStatus.OK)
.contentType(MediaType.APPLICATION_JSON_UTF8)
.body(BodyInserters.fromObject(map));
};
GatewayCallbackManager.setBlockHandler(blockHandler);
}
}
兩種方式介紹完了，根據業務需求自己選擇適合的方式，當然陳某更喜歡第一種，理由：約定>配置>編碼。
網關限流了，服務就安全了嗎？
很多人認為只要網關層面做了限流，躲在身后的服務就可以高枕無憂了，你是不是也有這種想法？
很顯然這種想法是錯誤的，復雜的微服務架構一個獨立服務不僅僅被一方調用，往往是多方調用，如下圖：
商品服務不僅僅被網關層調用，還被內部訂單服務調用，這時候僅僅在網關層限流，那么商品服務還安全嗎？
一旦大量的請求訂單服務，比如大促秒殺，商品服務不做限流會被瞬間擊垮。
因此需要根據公司業務場景對自己負責的服務也要進行限流兜底，最常見的方案：網關層集群限流+內部服務的單機限流兜底，這樣才能保證不被流量沖垮。
總結
文章介紹了Spring Cloud Gateway整合Sentinel對網關層進行限流，以及關於限流的一些思考。如有錯誤之處，歡迎留言指正。
項目源碼已經上傳Github，公號【碼猿技術專欄】回復關鍵詞：9528獲取！