認識 Spring Cloud Gateway
Spring Cloud Gateway 是一款基於 Spring 5,Project Reactor 以及 Spring Boot 2 構建的 API 閘道器,是 Spring Cloud 微服務生態的主要元件之一。Spring Cloud Gateway 主要負責介面請求的路由分發,並且支援對請求的安全驗證,流量監控和流量控制等擴充套件操作。另外值得一提的點是,Spring Cloud Gateway 預設採用了非阻塞 I/O 模型實現請求路由的分發。對於處理一些I/O 耗時長的請求上,相比其他一樣用 Java 編寫採用的同步阻塞I/O 模型的閘道器效能更高,處理的併發數也更高,避免了因為 I/O 阻塞(網路呼叫,資料庫操作等)導致執行緒空閒下來,仍能繼續處理響應其他請求。
Spring Cloud Gateway 適用場景
作為 API 閘道器,Spring Cloud Gateway 所提供的功能也很強大,整合了對負載均衡,動態路由,訪問控制,限流熔斷,埋點監控等功能的支援。如果現有的微服務體系是以 Java 生態甚至 Spring 生態為基礎的,那麼就十分適合使用 Spring Cloud Gateway 作為 API 應用閘道器了,讓聚合管理多個微服務 API,對外進行統一的輸出。
同時秉承 Spring 家族的傳統,Spring Cloud Gateway 也旨在提供一個簡單,且高效的方式來進行 API 路由和請求關注點的擴充套件,對於已經熟悉 Spring 或者 Spring Boot 的開發者來說,Spring Cloud Gateway 學習成本並不高,利用底層框架所帶的註解驅動和自動化配置等特性,使用和擴充套件起來難度都不算高。
快速上手 Spring Cloud Gateway
利用 Spring Cloud Gateway 能快速搭建一個 API 閘道器,但在這之前,先介紹一下使用 Spring Cloud Gateway 框架所涉及的一些專用概念,來加深對 Spring Cloud Gateway 的認識,方便後面的使用。
- 路由:是 Spring Cloud Gateway 中基礎的元件,通常由一個 id 標識,目標 URI,以及一系列斷言(Predicate)和過濾器組成。
- 斷言(Predicate):是 Java 8 函式庫的 Predicate 物件,具體型別為
Predicate<ServerWebExchange>
,用於匹配 HTTP 請求上資料資訊,如請求頭資訊,請求體資訊。如果對於某個請求的斷言為 true,那麼它所關聯的路由就算匹配成功,然後將請求給這個路由處理。 - 過濾器:用於某一個路由的請求或者響應進行修改的元件,在 Spring Cloud Gateway 都要實現 GatewayFilter 介面,並且需要由基於 GatewayFilterFactory 具體實現類構造。
認識上面三個概念之後,再看上圖所示,就能清楚看出 Spring Cloud Gateway 對客戶端請求的處理過程了,這幫助我們用好 Spring Cloud Gateway 幫助很大。
- 客戶端請求首先被 GatewayHandlerMapping 獲取,然後根據斷言匹配找到對應的路由
- 找到路由後,走完所關聯的一組請求過濾器的處理方法,請求到目標 URI 所對應的服務程式,獲得服務響應。
- 閘道器收到響應後,通過關聯的響應過濾器的處理方法後,同樣由 GatewayHandlerMapping 返回響應給客戶端。
額外需要注意的是 Spring Cloud Gateway 的過濾器是有序執行的,統一以 order 值的大小決定執行順序,值越小優先順序越高,就越先執行。
如何實現 API 聚合
認識 Spring Cloud Gateway 整體處理請求過程之後,我們現在就快速構建一個基於 Spring Cloud Gateway 的 API 閘道器,看看在實際應用中還需要注意的哪些地方,需要注意的是本文所使用的 Spring Cloud Gateway 屬於最新的里程碑版本 2.2.3,對應 Spring Boot 版本為 2.3.1, 並且 Spring Cloud 版本為 Hoxton.SR6 。利用 Spring Initializr ,選擇對應的版本和依賴後快速新建一個專案 spring-cloud-gateway-quick-start
,並且為了實現請求的路由,表現閘道器的效果,再分別新建使用者服務應用 demo-userservice
和訂單服務應用 demo-orderservice
,各自提供一個可呼叫 API 介面。
使用者服務暴露 8071 埠,提供 /user/get 介面:
// demo-userservice 專案
@RestController
@RequestMapping("/user")
public class UserServiceController {
@RequestMapping("/get")
public User get() {
return User.mock();
}
}
類似,訂單服務暴露 8061 埠,提供 /order/get 介面:
// demo-orderservice 專案
@RestController
@RequestMapping("/order")
public class OrderServiceController {
@RequestMapping("/get")
public Order get() {
return Order.mock();
}
}
接下來要通過 Spring Cloud Gateway 將兩個服務介面聚合在 spring-cloud-gateway-quick-start 專案中,首先來看下利用 Spring Cloud Gateway API 方式的實現:
@SpringBootApplication
public class DemogatewayApplication {
public static void main(String[] args) {
SpringApplication.run(DemogatewayApplication.class, args);
}
@Bean
public RouteLocator customRouteLocator(RouteLocatorBuilder builder) {
return builder.routes().route("user-service", r -> r.path("/user/*").uri("http://localhost:8071"))
.route("order-service", r -> r.path("/order/*").uri("http://localhost:8061"))
.build();
}
}
接下來要通過 Spring Cloud Gateway 將兩個服務介面聚合在 spring-cloud-gateway-quick-start
專案中,首先來看下利用 Spring Cloud Gateway API 方式的實現:
上述程式碼就已經實現 API 路由的功能,是不是很快速,同時啟動 spring-cloud-gateway-quick-start
和其他服務應用,就可以統一通過閘道器應用訪問使用者服務和訂單服務了:
one@192 ~ % curl http://localhost:8080/user/get
{"id":4720186416534735290,"token":"86b6118d-7dc6-4d30-a5f3-3d5fc6348f9a"}
one@192 ~ % curl http://localhost:8080/order/get
{"id":5832646761962425508,"title":"My Order"}
回到 API 實現的程式碼, DemogatewayApplication#customRouteLocator
方法中定義了兩個 id 分別為 user-service 和 order-service 的路由,並且設定了匹配請求的斷言,以及真正目標請求地址。這裡路由的斷言採用了路徑匹配的規則,只要原始請求地址符合對應的規則就算匹配到此路由,但 Spring Cloud Gate 還支援豐富的斷言規則,如主機匹配,請求體欄位匹配,請求資料匹配等等,足以滿足定製路由斷言的規則了。
由於使用 API 就是硬編碼方式將路由規則定義在程式裡了,這樣做擴充套件性很差,也不好維護。於是更推薦另外一種實現方式:配置化。來看下要實現相同功能,在 application.properties 裡該如何配置:
spring.cloud.gateway.routes[0].id=order-service
spring.cloud.gateway.routes[0].uri=http://localhost:8061
spring.cloud.gateway.routes[0].predicates[0].name=Path
spring.cloud.gateway.routes[0].predicates[0].args[pattern]=/order/*
spring.cloud.gateway.routes[1].id=user-service
spring.cloud.gateway.routes[1].uri=http://localhost:8071
spring.cloud.gateway.routes[1].predicates[0].name=Path
spring.cloud.gateway.routes[1].predicates[0].args[pattern]=/user/*
使用上面的配置,重啟閘道器應用,同樣能完成之前 API 方式的效果,由於路由規則轉移到了配置檔案中,就大大方便對 API 的管理,為實現動態路由也提供了可能。當然需要實現動態路由,除了路由配置,還需要進行額外的擴充套件實現路由規則的動態重新整理,涉及 Spring Cloud Gateway 更高階的用法,本文就不再詳細贅述了,可以等後續進階使用和分析的文章或者參考網上其他實現資料。
如何自定義過濾器
為了能對 API 的請求或者響應處理,Spring Cloud Gateway 提供過濾器元件來實現這一功能,並且內建了很多功能強大。另外過濾器分兩類,全域性過濾器和閘道器過濾器,對於全域性過濾器,所有匹配到路由的請求處理時都會經過全域性過濾器處理;而閘道器過濾器只有顯示在指定路由上時才會起到左右。
Spring Cloud Gateway 預設的全域性過濾器有 8個:
- ForwardRoutingFilter
- LoadBalancerClientFilter(棄用)
- ReactiveLoadBalancerClientFilter
- WebClientHttpRoutingFilter
- NettyWriteResponseFilter
- RouteToRequestUrlFilter
- WebsocketRoutingFilter
- GatewayMetricsFilter
而閘道器過濾器就更多了,並且由對應工廠類來構造,比如用於熔斷的 HystrixGatewayFilterFactory ,用於限流的 RequestRateLimiterGatewayFilterFactory,用於修改請求資料的 ModifyRequestBodyGatewayFilterFactory 等等,當然也支援開發者進行定義自己的過濾器。
首先來看下如何自定義一個全域性過濾器,程式碼實現比較簡單:
@Component
public class CustomGlobalFilter implements GlobalFilter, Ordered {
private Logger log = LoggerFactory.getLogger(MyAuthFilterFactory.class);
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
log.info("執行自定過濾器");
return chain.filter(exchange);
}
@Override
public int getOrder() {
return -1;
}
}
這樣就可以為所有路由新增一個全域性的過濾器了。不同於全域性過濾器的定義,閘道器過濾器必須在指定路由上進行申明才能生效,參考官方內建的閘道器攔截器,自定義一個用於授權的簡易閘道器攔截器工廠如下:
@Component
public class MyAuthGatewayFilterFactory extends AbstractGatewayFilterFactory<MyAuthGatewayFilterFactory.Config> {
private Logger logger = LoggerFactory.getLogger(MyAuthGatewayFilterFactory.class);
public MyAuthGatewayFilterFactory() {
super(Config.class);
}
@Override
public GatewayFilter apply(Config config) {
return new GatewayFilter() {
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
ServerHttpRequest request = exchange.getRequest();
MultiValueMap<String, String> queryParams = request.getQueryParams();
String from = queryParams.getFirst(config.getAuthKey());
ServerHttpResponse response = exchange.getResponse();
logger.warn("校驗授權開始");
if (config.getAuthValue().equals(from)) {
logger.warn("校驗授權成功");
return chain.filter(exchange);
} else {
logger.warn("校驗授權失敗");
response.setStatusCode(HttpStatus.OK);
response.getHeaders().setContentType(MediaType.valueOf("text/html;charset=utf-8"));
DataBuffer wrap = response.bufferFactory().wrap(config.getAuthFailMsg().getBytes(Charset.forName("UTF-8")));
return response.writeWith(Flux.just(wrap));
}
}
};
}
public static class Config {
private String authKey = "from";
private String authValue = "system";
private String authFailMsg = "授權失敗";
public String getAuthKey() {
return authKey;
}
public void setAuthKey(String authKey) {
this.authKey = authKey;
}
public String getAuthValue() {
return authValue;
}
public void setAuthValue(String authValue) {
this.authValue = authValue;
}
public String getAuthFailMsg() {
return authFailMsg;
}
public void setAuthFailMsg(String authFailMsg) {
this.authFailMsg = authFailMsg;
}
}
}
如果要在 user-service 路由下使用,需要在 application.properties 配置檔案新增如下配置:
spring.cloud.gateway.routes[1].filters[0].name=MyAuth
這裡的名稱就需要跟 MyAuthGatewayFilterFactory 類的 MyAuth 保持一致,Spring Cloud Gateway 會自動拼接上 AuthGatewayFilterFactory 去查詢對應的閘道器過濾器,沒有找到就會導致啟動失敗,丟擲異常:
java.lang.IllegalArgumentException: Unable to find GatewayFilterFactory with name MyAuth2
配置完對閘道器應用進行重啟,這是使用原來的方式去請求使用者服務,已經無法正常訪問,只會返回校驗授權失敗的資訊,必須以 http://localhost:8080/user/get?from=system
方式訪問才能成功獲取到資料,說明定義的授權攔截器已經起了作用。
這裡我們就將全域性攔截器和閘道器攔截器都實現了自定義,通常情況我們都會在閘道器攔截器上進行擴充套件定製,也結合內建的過濾器使用。最後將完整的實現程式碼上傳到 Gitlab :https://github.com/wrcj12138aaa/spring-cloud-gateway-quick-start ,感興趣的朋友也可以參考下。
本文由部落格一文多發平臺 OpenWrite 釋出!