溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹“SpringCloud Gateway服務(wù)網(wǎng)關(guān)的部署與使用的方法是什么”的相關(guān)知識，小編通過實際案例向大家展示操作過程，操作方法簡單快捷，實用性強，希望這篇“SpringCloud Gateway服務(wù)網(wǎng)關(guān)的部署與使用的方法是什么”文章能幫助大家解決問題。
傳統(tǒng)的單體架構(gòu)中只需要開放一個服務(wù)給客戶端調(diào)用，但是微服務(wù)架構(gòu)中是將一個系統(tǒng)拆分成多個微服務(wù)，如果沒有網(wǎng)關(guān)，客戶端只能在本地記錄每個微服務(wù)的調(diào)用地址，當需要調(diào)用的微服務(wù)數(shù)量很多時，它需要了解每個服務(wù)的接口，這個工作量很大。那有了網(wǎng)關(guān)之后，能夠起到怎樣的改善呢？
網(wǎng)關(guān)作為系統(tǒng)的唯一流量入口，封裝內(nèi)部系統(tǒng)的架構(gòu)，所有請求都先經(jīng)過網(wǎng)關(guān)，由網(wǎng)關(guān)將請求路由到合適的微服務(wù)，所以，使用網(wǎng)關(guān)的好處在于：
（1）簡化客戶端的工作。網(wǎng)關(guān)將微服務(wù)封裝起來后，客戶端只需同網(wǎng)關(guān)交互，而不必調(diào)用各個不同服務(wù)；
（2）降低函數(shù)間的耦合度。 一旦服務(wù)接口修改，只需修改網(wǎng)關(guān)的路由策略，不必修改每個調(diào)用該函數(shù)的客戶端，從而減少了程序間的耦合性
（3）解放開發(fā)人員把精力專注于業(yè)務(wù)邏輯的實現(xiàn)。由網(wǎng)關(guān)統(tǒng)一實現(xiàn)服務(wù)路由(灰度與ABTest)、負載均衡、訪問控制、流控熔斷降級等非業(yè)務(wù)相關(guān)功能，而不需要每個服務(wù) API 實現(xiàn)時都去考慮
但是 API 網(wǎng)關(guān)也存在不足之處，在微服務(wù)這種去中心化的架構(gòu)中，網(wǎng)關(guān)又成了一個中心點或瓶頸點，它增加了一個我們必須開發(fā)、部署和維護的高可用組件。正是由于這個原因，在網(wǎng)關(guān)設(shè)計時必須考慮即使 API 網(wǎng)關(guān)宕機也不要影響到服務(wù)的調(diào)用和運行，所以需要對網(wǎng)關(guān)的響應(yīng)結(jié)果有數(shù)據(jù)緩存能力，通過返回緩存數(shù)據(jù)或默認數(shù)據(jù)屏蔽后端服務(wù)的失敗。
在服務(wù)的調(diào)用方式上面，網(wǎng)關(guān)也有一定的要求，API 網(wǎng)關(guān)最好是支持 I/O 異步、同步非阻塞的，如果服務(wù)是同步阻塞調(diào)用，可以理解為微服務(wù)模塊之間是沒有徹底解耦的，即如果A依賴B提供的API，如果B提供的服務(wù)不可用將直接影響到A不可用，除非同步服務(wù)調(diào)用在API網(wǎng)關(guān)層或客戶端做了相應(yīng)的緩存。因此為了徹底解耦，在微服務(wù)調(diào)用上更建議選擇異步方式進行。而對于 API 網(wǎng)關(guān)需要通過底層多個細粒度的 API 組合的場景，推薦采用響應(yīng)式編程模型進行而不是傳統(tǒng)的異步回調(diào)方法組合代碼，其原因除了采用回調(diào)方式導(dǎo)致的代碼混亂外，還有就是對于 API 組合本身可能存在并行或先后調(diào)用，對于采用回調(diào)方式往往很難控制。
流量網(wǎng)關(guān)和服務(wù)網(wǎng)關(guān)在系統(tǒng)整體架構(gòu)中所處的位置如上圖所示，流量網(wǎng)關(guān)（如Nignx）是指提供全局性的、與后端業(yè)務(wù)應(yīng)用無關(guān)的策略，例如 HTTPS證書卸載、Web防火墻、全局流量監(jiān)控等。而微服務(wù)網(wǎng)關(guān)（如Spring Cloud Gateway）是指與業(yè)務(wù)緊耦合的、提供單個業(yè)務(wù)域級別的策略，如服務(wù)治理、身份認證等。也就是說，流量網(wǎng)關(guān)負責(zé)南北向流量調(diào)度及安全防護，微服務(wù)網(wǎng)關(guān)負責(zé)東西向流量調(diào)度及服務(wù)治理。
（1）Kong 網(wǎng)關(guān)：Kong 的性能非常好，非常適合做流量網(wǎng)關(guān)，但是對于復(fù)雜系統(tǒng)不建議業(yè)務(wù)網(wǎng)關(guān)用 Kong，主要是工程性方面的考慮
（2）Zuul1.x 網(wǎng)關(guān)：Zuul 1.0 的落地經(jīng)驗豐富，但是性能差、基于同步阻塞IO，適合中小架構(gòu)，不適合并發(fā)流量高的場景，因為容易產(chǎn)生線程耗盡，導(dǎo)致請求被拒絕的情況
（3）gateway 網(wǎng)關(guān)：功能強大豐富，性能好，官方基準測試 RPS (每秒請求數(shù))是Zuul的1.6倍，能與 SpringCloud 生態(tài)很好兼容，單從流式編程+支持異步上也足以讓開發(fā)者選擇它了。
（4）Zuul 2.x：性能與 gateway 差不多，基于非阻塞的，支持長連接，但 SpringCloud 沒有集成 zuul2 的計劃，并且 Netflix 相關(guān)組件都宣布進入維護期，前景未知。
綜上，gateway 網(wǎng)關(guān)更加適合 SpringCloud 項目，而從發(fā)展趨勢上看，gateway 替代 zuul 也是必然的。
（1）聲明依賴版本號：
<properties>
<spring-boot.version>2.3.2.RELEASE</spring-boot.version>
<spring-cloud.version>Hoxton.SR9</spring-cloud.version>
<spring-cloud-alibaba.version>2.2.6.RELEASE</spring-cloud-alibaba.version>
</properties>
<!-- 只聲明依賴，不引入依賴 -->
<dependencyManagement>
<dependencies>
<!-- 聲明springBoot版本 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>${spring-boot.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<!-- 聲明springCloud版本 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<!-- 聲明 springCloud Alibaba 版本 -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-alibaba-dependencies</artifactId>
<version>${spring-cloud-alibaba.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>（2）添加依賴：
<!-- 引入gateway網(wǎng)關(guān) --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-gateway</artifactId> <exclusions> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </exclusion> </exclusions> </dependency>
注意：一定要排除掉 spring-boot-starter-web 依賴，否則啟動報錯
（3）配置項目名與端口：
server:
port: 9023
servlet:
context-path: /${spring.application.name}
spring:
application:
name: gateway好了，網(wǎng)關(guān)項目搭建完成，其實就添加這么一個依賴，關(guān)于詳細的配置以及作用下文介紹。
在介紹 Spring Cloud Gateway 的配置項之前，我們先了解幾個 Spring Cloud Gateway 的核心術(shù)語：
斷言（Predicate）：參照 Java8 的新特性Predicate，允許開發(fā)人員匹配 HTTP 請求中的任何內(nèi)容，比如請求頭或請求參數(shù)，最后根據(jù)匹配結(jié)果返回一個布爾值。
路由（route）：由ID、目標URI、斷言集合和過濾器集合組成。如果聚合斷言結(jié)果為真，則轉(zhuǎn)發(fā)到該路由。
過濾器（filter）：可以在返回請求之前或之后修改請求和響應(yīng)的內(nèi)容。
Route 主要由 路由id、目標uri、斷言集合和過濾器集合組成，那我們簡單看看這些屬性到底有什么作用。
（1）id：路由標識，要求唯一，名稱任意（默認值 uuid，一般不用，需要自定義）
（2）uri：請求最終被轉(zhuǎn)發(fā)到的目標地址
（3）order： 路由優(yōu)先級，數(shù)字越小，優(yōu)先級越高
（4）predicates：斷言數(shù)組，即判斷條件，如果返回值是boolean，則轉(zhuǎn)發(fā)請求到 uri 屬性指定的服務(wù)中
（5）filters：過濾器數(shù)組，在請求傳遞過程中，對請求做一些修改
Predicate 來自于 Java8 的接口。Predicate 接受一個輸入?yún)?shù)，返回一個布爾值結(jié)果。該接口包含多種默認方法來將 Predicate 組合成其他復(fù)雜的邏輯（比如：與，或，非）。
Predicate 可以用于接口請求參數(shù)校驗、判斷新老數(shù)據(jù)是否有變化需要進行更新操作。Spring Cloud Gateway 內(nèi)置了許多 Predict，這些 Predict 的源碼在 org.springframework.cloud.gateway.handler.predicate 包中，有興趣可以閱讀一下。內(nèi)置的一些斷言如下圖：
以上11種斷言這里就不再介紹如何配置了，官方文檔寫的很清楚：https://docs.spring.io/spring-cloud-gateway/docs/2.2.9.RELEASE/reference/html/
下面就以最后一種權(quán)重斷言為例介紹一下如何配置。配置如下：
spring: cloud: gateway: # 路由數(shù)組：指當請求滿足什么樣的斷言時，轉(zhuǎn)發(fā)到哪個服務(wù)上 routes: # 路由標識，要求唯一，名稱任意 - id: gateway-provider_1 # 請求最終被轉(zhuǎn)發(fā)到的目標地址 uri: http://localhost:9024 # 設(shè)置斷言 predicates: # Path Route Predicate Factory 斷言，滿足 /gateway/provider/** 路徑的請求都會被路由到 http://localhost:9024 這個uri中 - Path=/gateway/provider/** # Weight Route Predicate Factory 斷言，同一分組按照權(quán)重進行分配流量，這里分配了80% # 第一個group1是分組名，第二個參數(shù)是權(quán)重 - Weight=group1, 8 # 配置過濾器（局部） filters: # StripPrefix：去除原始請求路徑中的前1級路徑，即/gateway - StripPrefix=1 - id: gateway-provider_2 uri: http://localhost:9025 # 設(shè)置斷言 predicates: - Path=/gateway/provider/** # Weight Route Predicate Factory，同一分組按照權(quán)重進行分配流量，這里分配了20% - Weight=group1, 2 # 配置過濾器（局部） filters: # StripPrefix：去除原始請求路徑中的前1級路徑，即/gateway - StripPrefix=1
Spring Cloud Gateway 中的斷言命名都是有規(guī)范的，格式：“xxx + RoutePredicateFactory”，比如權(quán)重斷言 WeightRoutePredicateFactory，那么配置時直接取前面的 “Weight”。
如果路由轉(zhuǎn)發(fā)匹配到了兩個或以上，則是的按照配置先后順序轉(zhuǎn)發(fā)，上面都配置了路徑：“ Path=/gateway/provider/** ”，如果沒有配置權(quán)重，則肯定是先轉(zhuǎn)發(fā)到 “http://localhost:9024”，但是既然配置配置了權(quán)重并且相同的分組，則按照權(quán)重比例進行分配流量。
Gateway 過濾器的生命周期：
PRE：這種過濾器在請求被路由之前調(diào)用。我們可利用這種過濾器實現(xiàn)身份驗證、在集群中選擇請求的微服務(wù)、記錄調(diào)試信息等。
POST：這種過濾器在路由到微服務(wù)以后執(zhí)行。這種過濾器可用來為響應(yīng)添加標準的 HTTP Header、收集統(tǒng)計信息和指標、將響應(yīng)從微服務(wù)發(fā)送給客戶端等。
Gateway 過濾器從作用范圍可分為兩種:
GatewayFilter：應(yīng)用到單個路由或者一個分組的路由上（需要在配置文件中配置）
GlobalFilter：應(yīng)用到所有的路由上（無需配置，全局生效）
（1）局部過濾器 GatewayFilter：
Spring Cloud Gateway 中內(nèi)置了許多的局部過濾器，如下圖：
局部過濾器需要在指定路由配置才能生效，默認是不生效的。以 “AddResponseHeaderGatewayFilterFactory” 這個過濾器為例，為原始響應(yīng)添加Header，配置如下：
spring: cloud: gateway: routes: - id: gateway-provider_1 uri: http://localhost:9024 predicates: - Path=/gateway/provider/** # 配置過濾器（局部） filters: - AddResponseHeader=X-Response-Foo, Bar # StripPrefix：去除原始請求路徑中的前1級路徑，即/gateway - StripPrefix=1
瀏覽器請求，發(fā)現(xiàn)響應(yīng)頭中已經(jīng)有了 X-Response-Foo=Bar 這個鍵值對，如下圖：
在前面的示例中，我們也使用到了另一個局部過濾器 StripPrefixGatewayFilterFactory，該過濾器主要用于截斷原始請求的路徑，當我們請求 localhost:9023/gateway/provider/test 時，實際請求會被轉(zhuǎn)發(fā)到 http://localhost:9024 服務(wù)上，并被截斷成 “http://localhost:9024/provider/test"
注意：過濾器的名稱只需要寫前綴，過濾器命名必須是 "xxx + GatewayFilterFactory“（包括自定義）。
更多過濾器的配置參考官方文檔：https://docs.spring.io/spring-cloud-gateway/docs/2.2.9.RELEASE/reference/html/#gatewayfilter-factories
（2）自定義局部過濾器：
雖說內(nèi)置的過濾器能夠解決很多場景，但是難免還是有些特殊需求需要定制一個過濾器，下面就來介紹一下如何自定義局部過濾器。
/**
* 名稱必須是xxxGatewayFilterFactory形式
* todo：模擬授權(quán)的驗證，具體邏輯根據(jù)業(yè)務(wù)完善
*/
@Component
@Slf4j
public class AuthorizeGatewayFilterFactory extends AbstractGatewayFilterFactory<AuthorizeGatewayFilterFactory.Config> {
private static final String AUTHORIZE_TOKEN = "token";
//構(gòu)造函數(shù)，加載Config
public AuthorizeGatewayFilterFactory() {
//固定寫法
super(AuthorizeGatewayFilterFactory.Config.class);
log.info("Loaded GatewayFilterFactory [Authorize]");
}
//讀取配置文件中的參數(shù) 賦值到 配置類中
@Override
public List<String> shortcutFieldOrder() {
//Config.enabled
return Arrays.asList("enabled");
}
@Override
public GatewayFilter apply(AuthorizeGatewayFilterFactory.Config config) {
return (exchange, chain) -> {
//判斷是否開啟授權(quán)驗證
if (!config.isEnabled()) {
return chain.filter(exchange);
}
ServerHttpRequest request = exchange.getRequest();
HttpHeaders headers = request.getHeaders();
//從請求頭中獲取token
String token = headers.getFirst(AUTHORIZE_TOKEN);
if (token == null) {
//從請求頭參數(shù)中獲取token
token = request.getQueryParams().getFirst(AUTHORIZE_TOKEN);
}
ServerHttpResponse response = exchange.getResponse();
//如果token為空，直接返回401，未授權(quán)
if (StringUtils.isEmpty(token)) {
response.setStatusCode(HttpStatus.UNAUTHORIZED);
//處理完成，直接攔截，不再進行下去
return response.setComplete();
}
/**
* todo chain.filter(exchange) 之前的都是過濾器的前置處理
*
* chain.filter().then(
* 過濾器的后置處理...........
* )
*/
//授權(quán)正常，繼續(xù)下一個過濾器鏈的調(diào)用
return chain.filter(exchange);
};
}
@Data
@AllArgsConstructor
@NoArgsConstructor
public static class Config {
// 控制是否開啟認證
private boolean enabled;
}
}局部過濾器需要在路由中配置才能生效，配置如下：
spring: cloud: gateway: routes: - id: gateway-provider_1 uri: http://localhost:9024 predicates: - Path=/gateway/provider/** ## 配置過濾器（局部） filters: - AddResponseHeader=X-Response-Foo, Bar ## AuthorizeGatewayFilterFactory自定義過濾器配置，值為true需要驗證授權(quán)，false不需要 - Authorize=true
此時直接訪問：http://localhost:9023/gateway/provider/port，不攜帶token，返回如下圖：
請求參數(shù)帶上token：http://localhost:9023/gateway/provider/port?token=abcdcdecd-ddcdeicd12，成功返回，如下圖：
上述的 AuthorizeGatewayFilterFactory 只是涉及到了過濾器的前置處理，后置處理是在 chain.filter().then() 中的 then() 方法中完成的，具體可以看下項目源碼中的 TimeGatewayFilterFactory，代碼就不再貼出來了，如下圖：
（3）GlobalFilter 全局過濾器：
全局過濾器應(yīng)用全部路由上，無需開發(fā)者配置，Spring Cloud Gateway 也內(nèi)置了一些全局過濾器，如下圖：
GlobalFilter 的功能其實和 GatewayFilter 是相同的，只是 GlobalFilter 的作用域是所有的路由配置，而不是綁定在指定的路由配置上。多個 GlobalFilter 可以通過 @Order 或者 getOrder() 方法指定執(zhí)行順序，order值越小，執(zhí)行的優(yōu)先級越高。
注意，由于過濾器有 pre 和 post 兩種類型，pre 類型過濾器如果 order 值越小，那么它就應(yīng)該在pre過濾器鏈的頂層，post 類型過濾器如果 order 值越小，那么它就應(yīng)該在 post 過濾器鏈的底層。示意圖如下：
（4）自定義全局過濾器：
當然除了內(nèi)置的全局過濾器，實際工作中還需要定制過濾器，下面來介紹一下如何自定義。我們模擬 Nginx 的 Access Log 功能，記錄每次請求的相關(guān)信息。代碼如下：
@Slf4j
@Component
@Order(value = Integer.MIN_VALUE)
public class AccessLogGlobalFilter implements GlobalFilter {
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
//filter的前置處理
ServerHttpRequest request = exchange.getRequest();
String path = request.getPath().pathWithinApplication().value();
InetSocketAddress remoteAddress = request.getRemoteAddress();
return chain
//繼續(xù)調(diào)用filter
.filter(exchange)
//filter的后置處理
.then(Mono.fromRunnable(() -> {
ServerHttpResponse response = exchange.getResponse();
HttpStatus statusCode = response.getStatusCode();
log.info("請求路徑:{},遠程IP地址:{},響應(yīng)碼:{}", path, remoteAddress, statusCode);
}));
}
}好了，全局過濾器不必在路由上配置，注入到IOC容器中即可全局生效。
此時發(fā)出一個請求，控制臺打印信息如下：
請求路徑:/gateway/provider/port,遠程IP地址:/0:0:0:0:0:0:0:1:64114,響應(yīng)碼:200 OK
上述 demo 中并沒有集成注冊中心，每次路由配置都是指定固定的服務(wù)uri，如下圖：
這樣做有什么壞處呢？
網(wǎng)關(guān)服務(wù)需要知道所有服務(wù)的域名或IP地址，另外，一旦服務(wù)的域名或IP地址發(fā)生修改，路由配置中的 uri 就必須修改
服務(wù)集群中無法實現(xiàn)負載均衡
那么此時我們可以集成的注冊中心，使得網(wǎng)關(guān)能夠從注冊中心自動獲取uri，并實現(xiàn)負載均衡，這里我們以 nacos 注冊中心為例介紹一下
（1）pom 文件中新增依賴：
<!--nacos注冊中心--> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> </dependency>
（2）啟動類添加 @EnableDiscoveryClient 注解開啟注冊中心功能，如下圖：
（3）配置 nacos 注冊中心的地址：
nacos:
namespace: 856a40d7-6548-4494-bdb9-c44491865f63
url: 120.76.129.106:80
spring:
cloud:
nacos:
discovery:
server-addr: ${nacos.url}
namespace: ${nacos.namespace}
register-enabled: true（4）服務(wù)路由配置：
spring: cloud: gateway: routes: - id: gateway-provider_1 ## 使用了lb形式，從注冊中心負載均衡的獲取uri uri: lb://gateway-provider ## 配置斷言 predicates: - Path=/gateway/provider/** filters: - AddResponseHeader=X-Response-Foo, Bar
路由配置中唯一不同的就是路由的 uri，格式：lb://service-name，這是固定寫法：
lb：固定格式，指的是從nacos中按照名稱獲取微服務(wù)，并遵循負載均衡策略
service-name：nacos注冊中心的服務(wù)名稱，這里并不是IP地址形式的
為什么指定了 lb 就可以開啟負載均衡，前面說過全局過濾器 LoadBalancerClientFilter 就是負責(zé)路由尋址和負載均衡的，可以看到如下源碼：
（5）開啟 gateway 自動路由配置：
隨著我們的系統(tǒng)架構(gòu)不斷地發(fā)展，系統(tǒng)中微服務(wù)的數(shù)量肯定會越來越多，我們不可能每添加一個服務(wù)，就在網(wǎng)關(guān)配置一個新的路由規(guī)則，這樣的維護成本很大；特別在很多種情況，我們在請求路徑中會攜帶一個路由標識方便進行轉(zhuǎn)發(fā)，而這個路由標識一般都是服務(wù)在注冊中心中的服務(wù)名，因此這是我們就可以開啟 spring cloud gateway 的自動路由功能，網(wǎng)關(guān)自動根據(jù)注冊中心的服務(wù)名為每個服務(wù)創(chuàng)建一個router，將以服務(wù)名開頭的請求路徑轉(zhuǎn)發(fā)到對應(yīng)的服務(wù)，配置如下：
# enabled：默認為false，設(shè)置為true表明spring cloud gateway開啟服務(wù)發(fā)現(xiàn)和路由的功能，網(wǎng)關(guān)自動根據(jù)注冊中心的服務(wù)名為每個服務(wù)創(chuàng)建一個router，將以服務(wù)名開頭的請求路徑轉(zhuǎn)發(fā)到對應(yīng)的服務(wù) spring.cloud.gateway.discovery.locator.enabled = true # lowerCaseServiceId：啟動 locator.enabled=true 自動路由時，路由的路徑默認會使用大寫ID，若想要使用小寫ID，可將lowerCaseServiceId設(shè)置為true spring.cloud.gateway.discovery.locator.lower-case-service-id = true
這里需要注意的是，由于我們的網(wǎng)關(guān)項目配置了 server.servlet.context-path 屬性，這會導(dǎo)致自動路由失敗的問題，因此我們需要做如下兩個修改：
# 重寫過濾鏈，解決項目設(shè)置了 server.servlet.context-path 導(dǎo)致 locator.enabled=true 默認路由策略404的問題 spring.cloud.gateway.discovery.locator.filters[0] = PreserveHostHeader
@Configuration
public class GatewayConfig
{
@Value ("${server.servlet.context-path}")
private String prefix;
/**
* 過濾 server.servlet.context-path 屬性配置的項目路徑，防止對后續(xù)路由策略產(chǎn)生影響，因為 gateway 網(wǎng)關(guān)不支持 servlet
*/
@Bean
@Order (-1)
public WebFilter apiPrefixFilter()
{
return (exchange, chain) ->
{
ServerHttpRequest request = exchange.getRequest();
String path = request.getURI().getRawPath();
path = path.startsWith(prefix) ? path.replaceFirst(prefix, "") : path;
ServerHttpRequest newRequest = request.mutate().path(path).build();
return chain.filter(exchange.mutate().request(newRequest).build());
};
}
}至此，我們就開啟了 spring cloud gateway 的自動路由功能，網(wǎng)關(guān)自動根據(jù)注冊中心的服務(wù)名為每個服務(wù)創(chuàng)建一個router，將以服務(wù)名開頭的請求路徑轉(zhuǎn)發(fā)到對應(yīng)的服務(wù)。假設(shè)我們的服務(wù)提供者在 nacos 注冊中心的服務(wù)名為 “gateway-provider”，這時我們只需要訪問 “http://localhost:9023/gateway/gateway-provider/test”，就可以將請求成功轉(zhuǎn)發(fā)過去了
上述例子都是將網(wǎng)關(guān)的一系列配置寫到項目的配置文件中，一旦路由策略發(fā)生改變必須要重啟項目，這樣維護成本很高，特別是服務(wù)網(wǎng)關(guān)作為系統(tǒng)的中心點，一旦重啟出現(xiàn)問題，影響面將是十分巨大的，因此，我們將網(wǎng)關(guān)的配置存放到配置中心中，這樣由配置中心統(tǒng)一管理，一旦路由發(fā)生改變，只需要在配置中心修改即可，降低風(fēng)險且實時失效。本部分就以 Apollo 配置中心為例介紹下如下實現(xiàn)動態(tài)路由配置：
（1）添加 apollo 配置中心依賴：
<!-- Apollo 統(tǒng)一配置中心 --> <dependency> <groupId>com.ctrip.framework.apollo</groupId> <artifactId>apollo-client</artifactId> <version>1.7.0</version> </dependency>
（2）添加 Apollo 路由更改監(jiān)聽刷新類：
import com.ctrip.framework.apollo.enums.PropertyChangeType;
import com.ctrip.framework.apollo.model.ConfigChange;
import com.ctrip.framework.apollo.model.ConfigChangeEvent;
import com.ctrip.framework.apollo.spring.annotation.ApolloConfigChangeListener;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.cloud.context.environment.EnvironmentChangeEvent;
import org.springframework.cloud.gateway.config.GatewayProperties;
import org.springframework.cloud.gateway.event.RefreshRoutesEvent;
import org.springframework.cloud.gateway.route.RouteDefinitionWriter;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
import org.springframework.context.ApplicationEventPublisher;
import org.springframework.context.ApplicationEventPublisherAware;
import org.springframework.context.annotation.Configuration;
import java.util.ArrayList;
/**
* Apollo路由更改監(jiān)聽刷新
*/
@Configuration
public class GatewayPropertRefresher implements ApplicationContextAware, ApplicationEventPublisherAware
{
private static final Logger logger = LoggerFactory.getLogger(GatewayPropertRefresher.class);
private static final String ID_PATTERN = "spring\\.cloud\\.gateway\\.routes\\[\\d+\\]\\.id";
private static final String DEFAULT_FILTER_PATTERN = "spring\\.cloud\\.gateway\\.default-filters\\[\\d+\\]\\.name";
private ApplicationContext applicationContext;
private ApplicationEventPublisher publisher;
@Autowired
private GatewayProperties gatewayProperties;
@Autowired
private RouteDefinitionWriter routeDefinitionWriter;
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
this.applicationContext = applicationContext;
}
@Override
public void setApplicationEventPublisher(ApplicationEventPublisher applicationEventPublisher) {
this.publisher = applicationEventPublisher;
}
/**
* 監(jiān)聽路由修改
*/
@ApolloConfigChangeListener(interestedKeyPrefixes = "spring.cloud.gateway.")
public void onChange(ConfigChangeEvent changeEvent)
{
refreshGatewayProperties(changeEvent);
}
/**
* 刷新路由信息
*/
private void refreshGatewayProperties(ConfigChangeEvent changeEvent)
{
logger.info("gateway網(wǎng)關(guān)配置 刷新開始！");
preDestroyGatewayProperties(changeEvent);
//更新配置
this.applicationContext.publishEvent(new EnvironmentChangeEvent(changeEvent.changedKeys()));
//更新路由
refreshGatewayRouteDefinition();
logger.info("gateway網(wǎng)關(guān)配置 刷新完成！");
}
/***
* GatewayProperties沒有@PreDestroy和destroy方法
* org.springframework.cloud.context.properties.ConfigurationPropertiesRebinder#rebind(java.lang.String)中destroyBean時不會銷毀當前對象
* 如果把spring.cloud.gateway.前綴的配置項全部刪除（例如需要動態(tài)刪除最后一個路由的場景），initializeBean時也無法創(chuàng)建新的bean，則return當前bean
* 若仍保留有spring.cloud.gateway.routes[n]或spring.cloud.gateway.default-filters[n]等配置，initializeBean時會注入新的屬性替換已有的bean
* 這個方法提供了類似@PreDestroy的操作，根據(jù)配置文件的實際情況把org.springframework.cloud.gateway.config.GatewayProperties#routes
* 和org.springframework.cloud.gateway.config.GatewayProperties#defaultFilters兩個集合清空
*/
private synchronized void preDestroyGatewayProperties(ConfigChangeEvent changeEvent)
{
logger.info("Pre Destroy GatewayProperties 操作開始!");
final boolean needClearRoutes = this.checkNeedClear(changeEvent, ID_PATTERN, this.gatewayProperties.getRoutes().size());
if (needClearRoutes)
{
this.gatewayProperties.setRoutes(new ArrayList());
}
final boolean needClearDefaultFilters = this.checkNeedClear(changeEvent, DEFAULT_FILTER_PATTERN, this.gatewayProperties.getDefaultFilters().size());
if (needClearDefaultFilters)
{
this.gatewayProperties.setRoutes(new ArrayList());
}
logger.info("Pre Destroy GatewayProperties 操作完成!");
}
private void refreshGatewayRouteDefinition()
{
logger.info("Refreshing Gateway RouteDefinition 操作開始!");
this.publisher.publishEvent(new RefreshRoutesEvent(this));
logger.info("Gateway RouteDefinition refreshed 操作完成!");
}
/***
* 根據(jù)changeEvent和定義的pattern匹配key，如果所有對應(yīng)PropertyChangeType為DELETED則需要清空GatewayProperties里相關(guān)集合
*/
private boolean checkNeedClear(ConfigChangeEvent changeEvent, String pattern, int existSize) {
return changeEvent.changedKeys().stream().filter(key -> key.matches(pattern)).filter(key ->
{
ConfigChange change = changeEvent.getChange(key);
return PropertyChangeType.DELETED.equals(change.getChangeType());
}).count() == existSize;
}
}（3）暴露endpoint端點：
# 暴露endpoint端點，暴露路由信息，有獲取所有路由、刷新路由、查看單個路由、刪除路由等方法
management.endpoints.web.exposure.include = *
management.endpoint.health.show-details = always
至此，我們就完成了 Gateway 網(wǎng)關(guān)整合 Apollo 配置中心實現(xiàn)動態(tài)路由配置，一旦路由發(fā)生改變，只需要在配置中心修改即可被監(jiān)聽到并實時失效
通過前面的測試可以看到一個現(xiàn)象：一旦路由的微服務(wù)下線或者失聯(lián)了，Spring Cloud Gateway直接返回了一個錯誤頁面，如下圖：
顯然這種異常信息不友好，前后端分離架構(gòu)中必須定制返回的異常信息。傳統(tǒng)的Spring Boot 服務(wù)中都是使用 @ControllerAdvice 來包裝全局異常處理的，但是由于服務(wù)下線，請求并沒有到達。因此必須在網(wǎng)關(guān)中也要定制一層全局異常處理，這樣才能更加友好的和客戶端交互。
Spring Cloud Gateway提供了多種全局處理的方式，今天只介紹其中一種方式，實現(xiàn)還算比較優(yōu)雅：
直接創(chuàng)建一個類 GlobalErrorExceptionHandler，實現(xiàn) ErrorWebExceptionHandler，重寫其中的 handle 方法，代碼如下：
/**
* 用于網(wǎng)關(guān)的全局異常處理
* @Order(-1)：優(yōu)先級一定要比ResponseStatusExceptionHandler低
*/
@Slf4j
@Order(-1)
@Component
@RequiredArgsConstructor
public class GlobalErrorExceptionHandler implements ErrorWebExceptionHandler {
private final ObjectMapper objectMapper;
@SuppressWarnings({"rawtypes", "unchecked", "NullableProblems"})
@Override
public Mono<Void> handle(ServerWebExchange exchange, Throwable ex) {
ServerHttpResponse response = exchange.getResponse();
if (response.isCommitted()) {
return Mono.error(ex);
}
// JOSN格式返回
response.getHeaders().setContentType(MediaType.APPLICATION_JSON);
if (ex instanceof ResponseStatusException) {
response.setStatusCode(((ResponseStatusException) ex).getStatus());
}
return response.writeWith(Mono.fromSupplier(() -> {
DataBufferFactory bufferFactory = response.bufferFactory();
try {
//todo 返回響應(yīng)結(jié)果，根據(jù)業(yè)務(wù)需求，自己定制
CommonResponse resultMsg = new CommonResponse("500",ex.getMessage(),null);
return bufferFactory.wrap(objectMapper.writeValueAsBytes(resultMsg));
}
catch (JsonProcessingException e) {
log.error("Error writing response", ex);
return bufferFactory.wrap(new byte[0]);
}
}));
}
}好了，全局異常處理已經(jīng)定制完成了，在測試一下，此時正常返回JSON數(shù)據(jù)了（JSON的樣式根據(jù)架構(gòu)需要自己定制），如下圖：
關(guān)于“SpringCloud Gateway服務(wù)網(wǎng)關(guān)的部署與使用的方法是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識，可以關(guān)注億速云行業(yè)資訊頻道，小編每天都會為大家更新不同的知識點。
免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點不代表本網(wǎng)站立場，如果涉及侵權(quán)請聯(lián)系站長郵箱：is@yisu.com進行舉報，并提供相關(guān)證據(jù)，一經(jīng)查實，將立刻刪除涉嫌侵權(quán)內(nèi)容。
億速云公眾號
手機網(wǎng)站二維碼