一、網關的基本概念

SpringCloudGateway網關是所有微服務的統一入口。

1.1 它的主要作用是：

反向代理（請求的轉發）

路由和負載均衡

身份認證和權限控制

對請求限流

1.2 相比于Zuul的優勢：

SpringCloudGateway基于Spring5中提供的WebFlux，是一種響應式編程的實現，性能更加優越。

Zuul的實現方式比較老式，基于Servlet的實現，它是一種阻塞式編程，在高并發下性能性能不佳。

拓展：

其實Nginx也可以作為網關，但是要使用Nginx自主實現網關的相關功能，還需要借助lua腳本語言，學習成本是比較高的，現在一般也不會使用它來做網關，但是只按性能來講Nginx，性能是最高的。

1.3 SpringCloudGateway架構圖：

微服務只接收來自網關的請求，而其它直接訪問微服務本身的請求拒絕。

這樣可以極大保護微服務免受不法侵害。

同時在請求壓力激增時，可以實施服務限流，保護微服務集群。

基于 Spring Boot + MyBatis Plus + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

二、SpringBoot中配置GateWay

2.1 引入GateWay的Maven依賴

 

org.springframework.cloud
spring-cloud-starter-gateway

 

com.alibaba.cloud
spring-cloud-starter-alibaba-nacos-discovery

2.2 配置application.yml文件

server:
port:10086#網關端口
spring:
application:
name:gateway#服務名稱
cloud:
nacos:
server-addr:localhost:8848#nacos地址
gateway:
routes:#網關路由配置
-id:user-service#路由id，自定義，只要唯一即可
#uri:http://127.0.0.1:8081#路由的目標地址(直接寫死地址的方式，不推薦)
uri:lb://userservice#路由的目標地址lb是負載均衡，后面跟服務名稱(推薦)
predicates:#路由斷言，判斷請求是否符合路由規則的條件
-Path=/user/**#按照路徑匹配，以/user/開頭的請求就符合要求
-id:card-service
uri:lb://cardservice
predicates:
-Path=/card/**

gateway配置中的注意點：

1.routes 后面的路由可以配置多個，相當于配置個數組，一個-開頭的配置就是其中的一個數組元素。

2.uri為什么選擇以服務名+負載均衡的方式？

主要是寫死地址的話，今后如果userservice的地址變了，那么又要去修改yml配置文件。而lb://userservice可以讓程序員一眼認出這是哪個微服務，以后地址變了也無需修改yml配置文件。

上述配置詳解：

將 /user/**開頭的請求，代理到lb://userservice。

將 /card/**開頭的請求，代理到lb://cardservice。

lb是負載均衡，根據服務名拉取服務列表，實現負載均衡。

http://127.0.0.1:10086/user/99 就算是/user/**開頭的請求，不要把協議、ip和端口計算在內。

有多少個需要配置的路由，都按上面的格式配置即可

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

三、GateWay路由配置詳解

路由主要有四個配置：

路由id（id）

路由目標（uri）

路由斷言（predicates）：判斷路由的規則，

路由過濾器（filters）：對請求或響應做處理

3.1 路由id

當前路由的唯一標識。

3.2 路由目標

路由的目標地址，http代表固定地址，lb代表根據服務名負載均衡。

一般都不會選擇寫死http固定地址的方式。而是選擇可維護性更強的lb根據服務名負載均衡的方式。

具體優勢如上所言。

3.3 路由斷言

路由斷言主要用來判斷路由的規則。

配置文件中寫的斷言規則只是字符串，這些字符串會被Predicate Factory讀取并處理。

例如Path=/user/**是按照路徑匹配，這個規則是由org.springframework.cloud.gateway.handler.predicate.PathRoutePredicateFactory類來處理。

像這樣的斷言工廠在SpringCloudGateway還有十幾個:

實際使用時，根絕業務要求選擇使用即可。

不過一般來講，最常用的是使用Path這種斷言工廠，僅用它就能滿足常見的需求了。

關于Path斷言工廠的補充：

Path=/card/**代表 以/card/路徑開頭的多級路徑請求，這么寫多級路徑請求和一級路徑請求都生效。

Path=/card/*代表 以/card/路徑開頭的一級路徑請求，這么寫多級路徑請求將不會生效。

今后如果有復雜的斷言工廠配置，可以參照官網文檔上的例子去實現。

3.4 路由過濾器（filters）

路由過濾器對請求或響應做處理。

客戶端請求先找到路由，路由匹配時經過過濾器層層篩選，最終訪問到微服務。

當然微服務的請求反悔時，也會經過過濾器的篩選，只不過我們一般只對請求過濾，而不會對響應過濾。

SpringCloudGateWay目前已經提供了34種不同的過濾器工廠。

常用的幾個有：

3.4.1 請求頭過濾器配置示例（局部過濾器）

spring:
cloud:
gateway:
routes:
-id:user-service
uri:lb://userservice
predicates:
-Path=/user/**
filters:#過濾器配置
-AddRequestHeader=token,test#添加請求頭

上述過濾器的含義：

給所有進入userservice的請求添加一個請求頭。

請求頭的key為token，value為test。

由于當前前過濾器寫在微服務的userservice路由下，因此僅僅對訪問微服務userservice的請求有效。

3.4.2 默認過濾器配置示例（全局過濾器）

spring:
cloud:
gateway:
routes:
-id:user-service
uri:lb://userservice
predicates:
-Path=/user/**
default-filters:#默認過濾器配置
-AddRequestHeader=token,test#添加請求頭

default-filters的配置和routes平級。

只要配置在default-filters下面的過濾器，會對routes配置的所有路由都生效。

過濾器工廠官方文檔：

今后如果有復雜的斷言工廠配置，可以參照官網文檔上的例子去實現。

四、自定義全局路由過濾器

有時候SpringCloudGateWay提供的過濾器工廠不能滿足自己的要求。

可能有時候需要在過濾時做一些其它的邏輯操作。

那么這時候可以選擇使用java代碼自定義全局過濾器。

代碼示例：

@Component
publicclassGateWayFilterimplementsGlobalFilter,Ordered{

@Override
publicMonofilter(ServerWebExchangeexchange,GatewayFilterChainchain){

//1.獲取請求參數
//1.這里的request并不是servlet中的request
//2.返回值是一個多鍵的map集合、也就是說這個map集合的鍵可以重復
MultiValueMapparams=exchange.getRequest().getQueryParams();
//2.獲取userName參數
StringuserName=params.getFirst("userName");
//3.校驗
if("root".equals(userName)){
//放行
returnchain.filter(exchange);
}
//4.攔截
//4.1.禁止訪問，設置狀態碼
exchange.getResponse().setStatusCode(500);
//4.2.結束處理
returnexchange.getResponse().setComplete();
}

@Override
publicintgetOrder(){
return-1;
}
}

當有多個過濾器時，Order的值決定了過濾器的執行順序。

數值越大優先級越低， 負的越多， 優先級越高。

設置Order的值有兩種方式：

1. 實現Ordered接口，并且重寫getOrder方法

@Component
publicclassGateWayFilterimplementsGlobalFilter,Ordered{

@Override
publicMonofilter(ServerWebExchangeexchange,GatewayFilterChainchain){

}

@Override
publicintgetOrder(){
return-1;
}
}

2. 使用@Order注解

@Order(-1)
@Component
publicclassGateWayFilterimplementsGlobalFilter,Ordered{
@Override
publicMonofilter(ServerWebExchangeexchange,GatewayFilterChainchain){

}
}

五、過濾路由過濾器的執行順序

5.1 過濾器的種類

SpringCloudGateWay中，有三種過濾器：

默認過濾器default-filters

只對具體某個路由生效的局部過濾器filters

使用java代碼編寫的全局過濾器GlobalFilter

5.2 過濾器的執行順序

由上圖知過濾器的執行順序為：默認過濾器 → 當前路由過濾器 → 全局過濾器。

六、網關的跨域問題

6.1 跨域的概念和原理

跨域：請求位置和被請求位置不同源就會發生跨域。

這里的不同源包括兩個點：

域名不同：www.baidu.com 和 www.taobao.com。（IP不同也是相同道理）

端口不同：127.0.0.1:8080和127.0.0.1:8081。

而瀏覽器又會禁止請求的發起者與服務端發生跨域AJAX請求。

如果發生了跨域請求，服務器端是能夠正常響應的，但是響應的結果會被瀏覽器攔截。

6.2 跨域常見解決方案

使用CORS方式。

CORS是一個W3C標準，全稱是"跨域資源共享"（Cross-origin resource sharing）。

它允許瀏覽器向跨源服務器，發出XMLHttpRequest請求，從而克服了AJAX只能同源使用的限制。

6.3 gateway中如何解決跨域問題

方式一：配置application.yml文件：

spring:
cloud:
gateway:
globalcors:#全局的跨域配置
add-to-simple-url-handler-mapping:true#解決options請求被攔截問題
#options請求就是一種詢問服務器是否瀏覽器可以跨域的請求
#如果每次跨域都有詢問服務器是否瀏覽器可以跨域對性能也是損耗
#可以配置本次跨域檢測的有效期maxAge
#在maxAge設置的時間范圍內，不去詢問，統統允許跨域
corsConfigurations:
'[/**]':
allowedOrigins:#允許哪些網站的跨域請求
-"http://localhost:8090"
allowedMethods:#允許的跨域ajax的請求方式
-"GET"
-"POST"
-"DELETE"
-"PUT"
-"OPTIONS"
allowedHeaders:"*"#允許在請求中攜帶的頭信息
allowCredentials:true#允許在請求中攜帶cookie
maxAge:360000#本次跨域檢測的有效期(單位毫秒)
#有效期內，跨域請求不會一直發option請求去增大服務器壓力

方式二：使用編碼方式定義配置類：

importorg.springframework.context.annotation.Bean;
importorg.springframework.context.annotation.Configuration;
importorg.springframework.http.HttpHeaders;
importorg.springframework.http.HttpMethod;
importorg.springframework.http.HttpStatus;
importorg.springframework.http.server.reactive.ServerHttpRequest;
importorg.springframework.http.server.reactive.ServerHttpResponse;
importorg.springframework.web.cors.reactive.CorsUtils;
importorg.springframework.web.server.ServerWebExchange;
importorg.springframework.web.server.WebFilter;
importorg.springframework.web.server.WebFilterChain;
importreactor.core.publisher.Mono;

@Configuration
publicclassCorsConfig{
privatestaticfinalStringMAX_AGE="18000L";

@Bean
publicWebFiltercorsFilter(){
return(ServerWebExchangectx,WebFilterChainchain)->{
ServerHttpRequestrequest=ctx.getRequest();
//使用SpringMvc自帶的跨域檢測工具類判斷當前請求是否跨域
if(!CorsUtils.isCorsRequest(request)){
returnchain.filter(ctx);
}
HttpHeadersrequestHeaders=request.getHeaders();//獲取請求頭
ServerHttpResponseresponse=ctx.getResponse();//獲取響應對象
HttpMethodrequestMethod=requestHeaders.getAccessControlRequestMethod();//獲取請求方式對象
HttpHeadersheaders=response.getHeaders();//獲取響應頭
headers.add(HttpHeaders.ACCESS_CONTROL_ALLOW_ORIGIN,requestHeaders.getOrigin());//把請求頭中的請求源（協議+ip+端口）添加到響應頭中（相當于yml中的allowedOrigins）
headers.addAll(HttpHeaders.ACCESS_CONTROL_ALLOW_HEADERS,requestHeaders.getAccessControlRequestHeaders());
if(requestMethod!=null){
headers.add(HttpHeaders.ACCESS_CONTROL_ALLOW_METHODS,requestMethod.name());//允許被響應的方法（GET/POST等，相當于yml中的allowedMethods）
}
headers.add(HttpHeaders.ACCESS_CONTROL_ALLOW_CREDENTIALS,"true");//允許在請求中攜帶cookie（相當于yml中的allowCredentials）
headers.add(HttpHeaders.ACCESS_CONTROL_EXPOSE_HEADERS,"*");//允許在請求中攜帶的頭信息（相當于yml中的allowedHeaders）
headers.add(HttpHeaders.ACCESS_CONTROL_MAX_AGE,MAX_AGE);//本次跨域檢測的有效期(單位毫秒，相當于yml中的maxAge)
if(request.getMethod()==HttpMethod.OPTIONS){//直接給option請求反回結果
response.setStatusCode(HttpStatus.OK);
returnMono.empty();
}
returnchain.filter(ctx);//不是option請求則放行
};
}

}