溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹“SpringCloud Gateway服務網關的部署與使用的方法是什么”的相關知識，小編通過實際案例向大家展示操作過程，操作方法簡單快捷，實用性強，希望這篇“SpringCloud Gateway服務網關的部署與使用的方法是什么”文章能幫助大家解決問題。
傳統的單體架構中只需要開放一個服務給客戶端調用，但是微服務架構中是將一個系統拆分成多個微服務，如果沒有網關，客戶端只能在本地記錄每個微服務的調用地址，當需要調用的微服務數量很多時，它需要了解每個服務的接口，這個工作量很大。那有了網關之后，能夠起到怎樣的改善呢？
網關作為系統的唯一流量入口，封裝內部系統的架構，所有請求都先經過網關，由網關將請求路由到合適的微服務，所以，使用網關的好處在于：
（1）簡化客戶端的工作。網關將微服務封裝起來后，客戶端只需同網關交互，而不必調用各個不同服務；
（2）降低函數間的耦合度。 一旦服務接口修改，只需修改網關的路由策略，不必修改每個調用該函數的客戶端，從而減少了程序間的耦合性
（3）解放開發人員把精力專注于業務邏輯的實現。由網關統一實現服務路由(灰度與ABTest)、負載均衡、訪問控制、流控熔斷降級等非業務相關功能，而不需要每個服務 API 實現時都去考慮
但是 API 網關也存在不足之處，在微服務這種去中心化的架構中，網關又成了一個中心點或瓶頸點，它增加了一個我們必須開發、部署和維護的高可用組件。正是由于這個原因，在網關設計時必須考慮即使 API 網關宕機也不要影響到服務的調用和運行，所以需要對網關的響應結果有數據緩存能力，通過返回緩存數據或默認數據屏蔽后端服務的失敗。
在服務的調用方式上面，網關也有一定的要求，API 網關最好是支持 I/O 異步、同步非阻塞的，如果服務是同步阻塞調用，可以理解為微服務模塊之間是沒有徹底解耦的，即如果A依賴B提供的API，如果B提供的服務不可用將直接影響到A不可用，除非同步服務調用在API網關層或客戶端做了相應的緩存。因此為了徹底解耦，在微服務調用上更建議選擇異步方式進行。而對于 API 網關需要通過底層多個細粒度的 API 組合的場景，推薦采用響應式編程模型進行而不是傳統的異步回調方法組合代碼，其原因除了采用回調方式導致的代碼混亂外，還有就是對于 API 組合本身可能存在并行或先后調用，對于采用回調方式往往很難控制。
流量網關和服務網關在系統整體架構中所處的位置如上圖所示，流量網關（如Nignx）是指提供全局性的、與后端業務應用無關的策略，例如 HTTPS證書卸載、Web防火墻、全局流量監控等。而微服務網關（如Spring Cloud Gateway）是指與業務緊耦合的、提供單個業務域級別的策略，如服務治理、身份認證等。也就是說，流量網關負責南北向流量調度及安全防護，微服務網關負責東西向流量調度及服務治理。
（1）Kong 網關：Kong 的性能非常好，非常適合做流量網關，但是對于復雜系統不建議業務網關用 Kong，主要是工程性方面的考慮
（2）Zuul1.x 網關：Zuul 1.0 的落地經驗豐富，但是性能差、基于同步阻塞IO，適合中小架構，不適合并發流量高的場景，因為容易產生線程耗盡，導致請求被拒絕的情況
（3）gateway 網關：功能強大豐富，性能好，官方基準測試 RPS (每秒請求數)是Zuul的1.6倍，能與 SpringCloud 生態很好兼容，單從流式編程+支持異步上也足以讓開發者選擇它了。
（4）Zuul 2.x：性能與 gateway 差不多，基于非阻塞的，支持長連接，但 SpringCloud 沒有集成 zuul2 的計劃，并且 Netflix 相關組件都宣布進入維護期，前景未知。
綜上，gateway 網關更加適合 SpringCloud 項目，而從發展趨勢上看，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網關 --> <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好了，網關項目搭建完成，其實就添加這么一個依賴，關于詳細的配置以及作用下文介紹。
在介紹 Spring Cloud Gateway 的配置項之前，我們先了解幾個 Spring Cloud Gateway 的核心術語：
斷言（Predicate）：參照 Java8 的新特性Predicate，允許開發人員匹配 HTTP 請求中的任何內容，比如請求頭或請求參數，最后根據匹配結果返回一個布爾值。
路由（route）：由ID、目標URI、斷言集合和過濾器集合組成。如果聚合斷言結果為真，則轉發到該路由。
過濾器（filter）：可以在返回請求之前或之后修改請求和響應的內容。
Route 主要由 路由id、目標uri、斷言集合和過濾器集合組成，那我們簡單看看這些屬性到底有什么作用。
（1）id：路由標識，要求唯一，名稱任意（默認值 uuid，一般不用，需要自定義）
（2）uri：請求最終被轉發到的目標地址
（3）order： 路由優先級，數字越小，優先級越高
（4）predicates：斷言數組，即判斷條件，如果返回值是boolean，則轉發請求到 uri 屬性指定的服務中
（5）filters：過濾器數組，在請求傳遞過程中，對請求做一些修改
Predicate 來自于 Java8 的接口。Predicate 接受一個輸入參數，返回一個布爾值結果。該接口包含多種默認方法來將 Predicate 組合成其他復雜的邏輯（比如：與，或，非）。
Predicate 可以用于接口請求參數校驗、判斷新老數據是否有變化需要進行更新操作。Spring Cloud Gateway 內置了許多 Predict，這些 Predict 的源碼在 org.springframework.cloud.gateway.handler.predicate 包中，有興趣可以閱讀一下。內置的一些斷言如下圖：
以上11種斷言這里就不再介紹如何配置了，官方文檔寫的很清楚：https://docs.spring.io/spring-cloud-gateway/docs/2.2.9.RELEASE/reference/html/
下面就以最后一種權重斷言為例介紹一下如何配置。配置如下：
spring: cloud: gateway: # 路由數組：指當請求滿足什么樣的斷言時，轉發到哪個服務上 routes: # 路由標識，要求唯一，名稱任意 - id: gateway-provider_1 # 請求最終被轉發到的目標地址 uri: http://localhost:9024 # 設置斷言 predicates: # Path Route Predicate Factory 斷言，滿足 /gateway/provider/** 路徑的請求都會被路由到 http://localhost:9024 這個uri中 - Path=/gateway/provider/** # Weight Route Predicate Factory 斷言，同一分組按照權重進行分配流量，這里分配了80% # 第一個group1是分組名，第二個參數是權重 - Weight=group1, 8 # 配置過濾器（局部） filters: # StripPrefix：去除原始請求路徑中的前1級路徑，即/gateway - StripPrefix=1 - id: gateway-provider_2 uri: http://localhost:9025 # 設置斷言 predicates: - Path=/gateway/provider/** # Weight Route Predicate Factory，同一分組按照權重進行分配流量，這里分配了20% - Weight=group1, 2 # 配置過濾器（局部） filters: # StripPrefix：去除原始請求路徑中的前1級路徑，即/gateway - StripPrefix=1
Spring Cloud Gateway 中的斷言命名都是有規范的，格式：“xxx + RoutePredicateFactory”，比如權重斷言 WeightRoutePredicateFactory，那么配置時直接取前面的 “Weight”。
如果路由轉發匹配到了兩個或以上，則是的按照配置先后順序轉發，上面都配置了路徑：“ Path=/gateway/provider/** ”，如果沒有配置權重，則肯定是先轉發到 “http://localhost:9024”，但是既然配置配置了權重并且相同的分組，則按照權重比例進行分配流量。
Gateway 過濾器的生命周期：
PRE：這種過濾器在請求被路由之前調用。我們可利用這種過濾器實現身份驗證、在集群中選擇請求的微服務、記錄調試信息等。
POST：這種過濾器在路由到微服務以后執行。這種過濾器可用來為響應添加標準的 HTTP Header、收集統計信息和指標、將響應從微服務發送給客戶端等。
Gateway 過濾器從作用范圍可分為兩種:
GatewayFilter：應用到單個路由或者一個分組的路由上（需要在配置文件中配置）
GlobalFilter：應用到所有的路由上（無需配置，全局生效）
（1）局部過濾器 GatewayFilter：
Spring Cloud Gateway 中內置了許多的局部過濾器，如下圖：
局部過濾器需要在指定路由配置才能生效，默認是不生效的。以 “AddResponseHeaderGatewayFilterFactory” 這個過濾器為例，為原始響應添加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
瀏覽器請求，發現響應頭中已經有了 X-Response-Foo=Bar 這個鍵值對，如下圖：
在前面的示例中，我們也使用到了另一個局部過濾器 StripPrefixGatewayFilterFactory，該過濾器主要用于截斷原始請求的路徑，當我們請求 localhost:9023/gateway/provider/test 時，實際請求會被轉發到 http://localhost:9024 服務上，并被截斷成 “http://localhost:9024/provider/test"
注意：過濾器的名稱只需要寫前綴，過濾器命名必須是 "xxx + GatewayFilterFactory“（包括自定義）。
更多過濾器的配置參考官方文檔：https://docs.spring.io/spring-cloud-gateway/docs/2.2.9.RELEASE/reference/html/#gatewayfilter-factories
（2）自定義局部過濾器：
雖說內置的過濾器能夠解決很多場景，但是難免還是有些特殊需求需要定制一個過濾器，下面就來介紹一下如何自定義局部過濾器。
/**
* 名稱必須是xxxGatewayFilterFactory形式
* todo：模擬授權的驗證，具體邏輯根據業務完善
*/
@Component
@Slf4j
public class AuthorizeGatewayFilterFactory extends AbstractGatewayFilterFactory<AuthorizeGatewayFilterFactory.Config> {
private static final String AUTHORIZE_TOKEN = "token";
//構造函數，加載Config
public AuthorizeGatewayFilterFactory() {
//固定寫法
super(AuthorizeGatewayFilterFactory.Config.class);
log.info("Loaded GatewayFilterFactory [Authorize]");
}
//讀取配置文件中的參數 賦值到 配置類中
@Override
public List<String> shortcutFieldOrder() {
//Config.enabled
return Arrays.asList("enabled");
}
@Override
public GatewayFilter apply(AuthorizeGatewayFilterFactory.Config config) {
return (exchange, chain) -> {
//判斷是否開啟授權驗證
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) {
//從請求頭參數中獲取token
token = request.getQueryParams().getFirst(AUTHORIZE_TOKEN);
}
ServerHttpResponse response = exchange.getResponse();
//如果token為空，直接返回401，未授權
if (StringUtils.isEmpty(token)) {
response.setStatusCode(HttpStatus.UNAUTHORIZED);
//處理完成，直接攔截，不再進行下去
return response.setComplete();
}
/**
* todo chain.filter(exchange) 之前的都是過濾器的前置處理
*
* chain.filter().then(
* 過濾器的后置處理...........
* )
*/
//授權正常，繼續下一個過濾器鏈的調用
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需要驗證授權，false不需要 - Authorize=true
此時直接訪問：http://localhost:9023/gateway/provider/port，不攜帶token，返回如下圖：
請求參數帶上token：http://localhost:9023/gateway/provider/port?token=abcdcdecd-ddcdeicd12，成功返回，如下圖：
上述的 AuthorizeGatewayFilterFactory 只是涉及到了過濾器的前置處理，后置處理是在 chain.filter().then() 中的 then() 方法中完成的，具體可以看下項目源碼中的 TimeGatewayFilterFactory，代碼就不再貼出來了，如下圖：
（3）GlobalFilter 全局過濾器：
全局過濾器應用全部路由上，無需開發者配置，Spring Cloud Gateway 也內置了一些全局過濾器，如下圖：
GlobalFilter 的功能其實和 GatewayFilter 是相同的，只是 GlobalFilter 的作用域是所有的路由配置，而不是綁定在指定的路由配置上。多個 GlobalFilter 可以通過 @Order 或者 getOrder() 方法指定執行順序，order值越小，執行的優先級越高。
注意，由于過濾器有 pre 和 post 兩種類型，pre 類型過濾器如果 order 值越小，那么它就應該在pre過濾器鏈的頂層，post 類型過濾器如果 order 值越小，那么它就應該在 post 過濾器鏈的底層。示意圖如下：
（4）自定義全局過濾器：
當然除了內置的全局過濾器，實際工作中還需要定制過濾器，下面來介紹一下如何自定義。我們模擬 Nginx 的 Access Log 功能，記錄每次請求的相關信息。代碼如下：
@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
//繼續調用filter
.filter(exchange)
//filter的后置處理
.then(Mono.fromRunnable(() -> {
ServerHttpResponse response = exchange.getResponse();
HttpStatus statusCode = response.getStatusCode();
log.info("請求路徑:{},遠程IP地址:{},響應碼:{}", path, remoteAddress, statusCode);
}));
}
}好了，全局過濾器不必在路由上配置，注入到IOC容器中即可全局生效。
此時發出一個請求，控制臺打印信息如下：
請求路徑:/gateway/provider/port,遠程IP地址:/0:0:0:0:0:0:0:1:64114,響應碼:200 OK
上述 demo 中并沒有集成注冊中心，每次路由配置都是指定固定的服務uri，如下圖：
這樣做有什么壞處呢？
網關服務需要知道所有服務的域名或IP地址，另外，一旦服務的域名或IP地址發生修改，路由配置中的 uri 就必須修改
服務集群中無法實現負載均衡
那么此時我們可以集成的注冊中心，使得網關能夠從注冊中心自動獲取uri，并實現負載均衡，這里我們以 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）服務路由配置：
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中按照名稱獲取微服務，并遵循負載均衡策略
service-name：nacos注冊中心的服務名稱，這里并不是IP地址形式的
為什么指定了 lb 就可以開啟負載均衡，前面說過全局過濾器 LoadBalancerClientFilter 就是負責路由尋址和負載均衡的，可以看到如下源碼：
（5）開啟 gateway 自動路由配置：
隨著我們的系統架構不斷地發展，系統中微服務的數量肯定會越來越多，我們不可能每添加一個服務，就在網關配置一個新的路由規則，這樣的維護成本很大；特別在很多種情況，我們在請求路徑中會攜帶一個路由標識方便進行轉發，而這個路由標識一般都是服務在注冊中心中的服務名，因此這是我們就可以開啟 spring cloud gateway 的自動路由功能，網關自動根據注冊中心的服務名為每個服務創建一個router，將以服務名開頭的請求路徑轉發到對應的服務，配置如下：
# enabled：默認為false，設置為true表明spring cloud gateway開啟服務發現和路由的功能，網關自動根據注冊中心的服務名為每個服務創建一個router，將以服務名開頭的請求路徑轉發到對應的服務 spring.cloud.gateway.discovery.locator.enabled = true # lowerCaseServiceId：啟動 locator.enabled=true 自動路由時，路由的路徑默認會使用大寫ID，若想要使用小寫ID，可將lowerCaseServiceId設置為true spring.cloud.gateway.discovery.locator.lower-case-service-id = true
這里需要注意的是，由于我們的網關項目配置了 server.servlet.context-path 屬性，這會導致自動路由失敗的問題，因此我們需要做如下兩個修改：
# 重寫過濾鏈，解決項目設置了 server.servlet.context-path 導致 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 屬性配置的項目路徑，防止對后續路由策略產生影響，因為 gateway 網關不支持 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 的自動路由功能，網關自動根據注冊中心的服務名為每個服務創建一個router，將以服務名開頭的請求路徑轉發到對應的服務。假設我們的服務提供者在 nacos 注冊中心的服務名為 “gateway-provider”，這時我們只需要訪問 “http://localhost:9023/gateway/gateway-provider/test”，就可以將請求成功轉發過去了
上述例子都是將網關的一系列配置寫到項目的配置文件中，一旦路由策略發生改變必須要重啟項目，這樣維護成本很高，特別是服務網關作為系統的中心點，一旦重啟出現問題，影響面將是十分巨大的，因此，我們將網關的配置存放到配置中心中，這樣由配置中心統一管理，一旦路由發生改變，只需要在配置中心修改即可，降低風險且實時失效。本部分就以 Apollo 配置中心為例介紹下如下實現動態路由配置：
（1）添加 apollo 配置中心依賴：
<!-- Apollo 統一配置中心 --> <dependency> <groupId>com.ctrip.framework.apollo</groupId> <artifactId>apollo-client</artifactId> <version>1.7.0</version> </dependency>
（2）添加 Apollo 路由更改監聽刷新類：
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路由更改監聽刷新
*/
@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;
}
/**
* 監聽路由修改
*/
@ApolloConfigChangeListener(interestedKeyPrefixes = "spring.cloud.gateway.")
public void onChange(ConfigChangeEvent changeEvent)
{
refreshGatewayProperties(changeEvent);
}
/**
* 刷新路由信息
*/
private void refreshGatewayProperties(ConfigChangeEvent changeEvent)
{
logger.info("gateway網關配置 刷新開始！");
preDestroyGatewayProperties(changeEvent);
//更新配置
this.applicationContext.publishEvent(new EnvironmentChangeEvent(changeEvent.changedKeys()));
//更新路由
refreshGatewayRouteDefinition();
logger.info("gateway網關配置 刷新完成！");
}
/***
* GatewayProperties沒有@PreDestroy和destroy方法
* org.springframework.cloud.context.properties.ConfigurationPropertiesRebinder#rebind(java.lang.String)中destroyBean時不會銷毀當前對象
* 如果把spring.cloud.gateway.前綴的配置項全部刪除（例如需要動態刪除最后一個路由的場景），initializeBean時也無法創建新的bean，則return當前bean
* 若仍保留有spring.cloud.gateway.routes[n]或spring.cloud.gateway.default-filters[n]等配置，initializeBean時會注入新的屬性替換已有的bean
* 這個方法提供了類似@PreDestroy的操作，根據配置文件的實際情況把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 操作完成!");
}
/***
* 根據changeEvent和定義的pattern匹配key，如果所有對應PropertyChangeType為DELETED則需要清空GatewayProperties里相關集合
*/
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 網關整合 Apollo 配置中心實現動態路由配置，一旦路由發生改變，只需要在配置中心修改即可被監聽到并實時失效
通過前面的測試可以看到一個現象：一旦路由的微服務下線或者失聯了，Spring Cloud Gateway直接返回了一個錯誤頁面，如下圖：
顯然這種異常信息不友好，前后端分離架構中必須定制返回的異常信息。傳統的Spring Boot 服務中都是使用 @ControllerAdvice 來包裝全局異常處理的，但是由于服務下線，請求并沒有到達。因此必須在網關中也要定制一層全局異常處理，這樣才能更加友好的和客戶端交互。
Spring Cloud Gateway提供了多種全局處理的方式，今天只介紹其中一種方式，實現還算比較優雅：
直接創建一個類 GlobalErrorExceptionHandler，實現 ErrorWebExceptionHandler，重寫其中的 handle 方法，代碼如下：
/**
* 用于網關的全局異常處理
* @Order(-1)：優先級一定要比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 返回響應結果，根據業務需求，自己定制
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]);
}
}));
}
}好了，全局異常處理已經定制完成了，在測試一下，此時正常返回JSON數據了（JSON的樣式根據架構需要自己定制），如下圖：
關于“SpringCloud Gateway服務網關的部署與使用的方法是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識，可以關注億速云行業資訊頻道，小編每天都會為大家更新不同的知識點。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
