這篇文章介紹下微服務中的一個重要角色:網關,對于網關如何選擇,由于阿裡系暫時未出網關,當然是選擇了Spring cloud Gateway,畢竟是親兒子。
為什麼需要網關?
傳統的單體架構中隻有一個服務開放給用戶端調用,但是微服務架構中是将一個系統拆分成多個微服務,那麼作為用戶端如何去調用這些微服務呢?如果沒有網關的存在,隻能在本地記錄每個微服務的調用位址。
無網關的微服務架構往往存在以下問題:
- 用戶端多次請求不同的微服務,增加用戶端代碼或配置編寫的複雜性。
- 認證複雜,每個服務都需要獨立認證。
- 存在跨域請求,在一定場景下處理相對複雜。
網關的基本功能?
網關是所有微服務的門戶,路由轉發僅僅是最基本的功能,除此之外還有其他的一些功能,比如:認證、鑒權、熔斷、限流、日志監控等等.........
“
以上這些應用場景會在後續的文章詳細介紹,不是今天的重點。
”
為什麼選擇Spring cloud Gateway?
在1.x版本中都是采用的Zuul網關;但在2.x版本中,zuul的更新一直跳票,Spring Cloud最後自己研發了一個網關替代Zuul,那就是Spring Cloud Gateway。
肯定選擇親兒子Spring Cloud Gateway,它的很多思想都是借鑒zuul,所謂青出于藍而勝于藍,功能和性能肯定是優于zuul,不然Spring Cloud 為嘛要釋出它?
重要的一點原因:
“
Spring Cloud Gateway 基于Spring Boot 2.x、Spring WebFlux和[Project Reactor建構。
”
對于Spring Boot 的整合友善相容性以及性能方面不必擔心。
Spring Cloud Gateway幾個必知的術語?
- 路由(route):gateway的基本構模組化塊。它由ID、目标URI、斷言集合和過濾器集合組成。如果聚合斷言結果為真,則比對到該路由。
- 斷言(Predicate ):參照Java8的新特性Predicate,允許開發人員比對HTTP請求中的任何内容,比如頭或參數。
- 過濾器(filter):可以在傳回請求之前或之後修改請求和響應的内容。
網關如何搭建?
為什麼要放這張圖?
“
一定要按照上圖中的版本進行适配,否則會出現意想不到的BUG,陳某遇到過,都是淚............
”
建立cloud-gateway9023,添加如下依賴:
<!--gateway-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
“
注意:一定要去掉spring-boot-starter-web依賴,否則啟動報錯
”
好了,項目搭建完成,其實就添加這麼一個依賴,關于詳細的配置下文介紹。
什麼是Predict(斷言)?
Predicate來自于java8的接口。Predicate接受一個輸入參數,傳回一個布爾值結果。該接口包含多種預設方法來将Predicate組合成其他複雜的邏輯(比如:與,或,非)。關注公z号:碼猿技術專欄,回複關鍵詞:1111 擷取阿裡内部性能調優手冊!
可以用于接口請求參數校驗、判斷新老資料是否有變化需要進行更新操作。
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隻要唯一即可,名稱任意
- 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
## id必須唯一
- id: gateway-provider_2
## 路由轉發的uri
uri: http://localhost:9025
## 配置斷言
predicates:
## Path Route Predicate Factory斷言,滿足/gateway/provider/**這個請求路徑的都會被路由到http://localhost:9024這個uri中
- Path=/gateway/provider/**
## Weight Route Predicate Factory,同一分組按照權重進行配置設定流量,這裡配置設定了20%
## 第一個group1是分組名,第二個參數是權重
- Weight=group1, 2
routes下就是配置的路由政策,各個元件如下:
- id:路由的唯一id,名稱任意
- uri:路由轉發的uri
- predicates:斷言配置,可以配置多個
Spring Cloud Gateway中的斷言命名都是有規範的,格式:xxxRoutePredicateFactory。
比如權重的斷言:WeightRoutePredicateFactory,那麼配置時直接取前面的Weight。
預設的路由轉發如果路由到了兩個,則是的按照配置先後順序轉發,上面都配置了路徑:Path=/gateway/provider/**,如果沒有配置權重,則肯定是轉發到http://localhost:9024。
但是既然配置配置了權重并且相同的分組,則按照權重比例進行配置設定流量。
什麼是過濾器?
過濾器這個概念很熟悉,在Spring mvc 就接觸過,Gateway的過濾器的作用以及生命周期都是類似的。
Gateway的生命周期:
- PRE:這種過濾器在請求被路由之前調用。我們可利用這種過濾器實作身份驗證、在叢集中選擇 請求的微服務、記錄調試資訊等。
- POST:這種過濾器在路由到微服務以後執行。這種過濾器可用來為響應添加标準的HTTP Header、收集統計資訊和名額、将響應從微服務發送給用戶端等。
Gateway 的Filter從作用範圍可分為兩種:
- GatewayFilter:應用到單個路由或者一個分組的路由上(需要在配置檔案中配置)。
- GlobalFilter:應用到所有的路由上(無需配置,全局生效)
GatewayFilter(局部過濾器)
Spring Cloud Gateway中内置了許多的局部過濾器,如下圖:
局部過濾器需要在指定路由配置才能生效,預設是不生效的。
以AddResponseHeaderGatewayFilterFactory這個過濾器為例,為原始響應添加Header,配置如下:
spring:
cloud:
gateway:
## 路由
routes:
## id隻要唯一即可,名稱任意
- id: gateway-provider_1
uri: http://localhost:9024
## 配置斷言
predicates:
## Path Route Predicate Factory斷言,滿足/gateway/provider/**這個請求路徑的都會被路由到http://localhost:9024這個uri中
- Path=/gateway/provider/**
## 配置過濾器(局部)
filters:
- AddResponseHeader=X-Response-Foo, Bar
浏覽器請求,發現響應頭中已經有了X-Response-Foo=Bar這個鍵值對,如下圖:
注意:過濾器的名稱隻需要寫字首,過濾器命名必須是xxxGatewayFilterFactory(包括自定義)。
“
更多過濾器的配置可以看官方文檔:https://docs.spring.io/spring-cloud-gateway/docs/2.2.9.RELEASE/reference/html/#gatewayfilter-factories
”
雖說内置的過濾器能夠解決很多場景,但是難免還是有些特殊需求需要定制一個過濾器,下面就來介紹一下如何自定義局部過濾器。
場景:模拟一個授權驗證的過程,如果請求頭或者請求參數中攜帶token則放行,否則直接攔截傳回401,代碼如下:
/**
* 名稱必須是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隻要唯一即可,名稱任意
- id: gateway-provider_1
uri: http://localhost:9024
## 配置斷言
predicates:
## Path Route Predicate Factory斷言,滿足/gateway/provider/**這個請求路徑的都會被路由到http://localhost:9024這個uri中
- 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,代碼就不再貼出來了,如下圖:
GlobalFilter(全局過濾器)
全局過濾器應用到全部路由上,無需開發者配置,Spring Cloud Gateway也内置了一些全局過濾器,如下圖:
GlobalFilter的功能其實和GatewayFilter是相同的,隻是GlobalFilter的作用域是所有的路由配置,而不是綁定在指定的路由配置上。多個GlobalFilter可以通過@Order或者getOrder()方法指定每個GlobalFilter的執行順序,order值越小,GlobalFilter執行的優先級越高。
注意,由于過濾器有pre和post兩種類型,pre類型過濾器如果order值越小,那麼它就應該在pre過濾器鍊的頂層,post類型過濾器如果order值越小,那麼它就應該在pre過濾器鍊的底層。示意圖如下:
當然除了内置的全局過濾器,實際工作中還需要定制過濾器,下面來介紹一下如何自定義。
場景:模拟Nginx的Access Log 功能,記錄每次請求的相關資訊。代碼如下:
/**
* 實作GlobalFilter
*/
@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的位址一旦修改了,路由配置中的uri必須修改
- 服務叢集中無法實作負載均衡
此時就需要內建的注冊中心,使得網關能夠從注冊中心自動擷取uri(負載均衡)。
這裡的注冊中心當然選擇Nacos,又不熟悉的小夥伴請看陳某《Spring Cloud 進階》專欄的第一篇文章:五十五張圖告訴你微服務的靈魂擺渡者Nacos究竟有多強?
pom檔案中新增Nacos依賴,如下:
<!--nacos注冊中心-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
啟動類上開啟注冊中心功能,如下圖:
配置檔案中指定nacos注冊中心的位址:
spring:
application:
## 指定服務名稱,在nacos中的名字
name: cloud-gateway
cloud:
nacos:
discovery:
# nacos的服務位址,nacos-server中IP位址:端口号
server-addr: 127.0.0.1:8848
路由配置中唯一不同的就是路由的uri,格式:lb://service-name,這是固定寫法:
- lb:固定格式,指的是從nacos中按照名稱擷取微服務,并遵循負載均衡政策
- service-name:nacos注冊中心的服務名稱,這裡并不是IP位址形式的
內建Nacos注冊中心完整的配置demo如下:
spring:
application:
## 指定服務名稱,在nacos中的名字
name: cloud-gateway
cloud:
nacos:
discovery:
# nacos的服務位址,nacos-server中IP位址:端口号
server-addr: 127.0.0.1:8848
gateway:
## 路由
routes:
## id隻要唯一即可,名稱任意
- id: gateway-provider_1
## 使用了lb形式,從注冊中心負載均衡的擷取uri
uri: lb://gateway-provider
## 配置斷言
predicates:
## Path Route Predicate Factory斷言,滿足/gateway/provider/**這個請求路徑的都會被路由到http://localhost:9024這個uri中
- Path=/gateway/provider/**
## 配置過濾器(局部)
filters:
- AddResponseHeader=X-Response-Foo, Bar
為什麼指定了lb就可以開啟負載均衡,前面說過全局過濾器LoadBalancerClientFilter就是負責路由尋址和負載均衡的,可以看到如下源碼:
如何實作動态路由?
上述例子都是将網關的一系列配置寫到項目的配置檔案中,一旦路由發生改變必須要重新項目,這樣維護成本很高。
其實我們可以将網關的配置存放到配置中心中,這樣由配置中心統一管理,一旦路由發生改變,隻需要在配置中心修改,這樣便能達到一處修改,多出生效的目的。
這裡當然要使用Nacos作為配置中心了,添加依賴如下:
<!-- nacos配置中心的依賴-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
在bootstrap.yml檔案中指定Nacos作為配置中心的一些相關配置:
spring:
application:
## 指定服務名稱,在nacos中的名字
name: cloud-gateway
cloud:
nacos:
## todo 此處作為示範,僅僅配置了字尾,其他分組,命名空間根據需要自己配置
config:
server-addr: 127.0.0.1:8848
## 指定檔案字尾未yaml
file-extension: yaml
在nacos中的public命名空間中建立dataId為cloud-gateway.yaml的配置(未指定環境),配置内容如下:
到這裡已經配置完成了。至于效果自己動動小手試試吧...............
如何自定義全局異常處理?
通過前面的測試可以看到一個現象:一旦路由的微服務下線或者失聯了,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的樣式根據架構需要自己定制。
”
總結
Spring Cloud Gateway今天就分享到這裡,主要介紹了以下幾個知識點:
- 為什麼需要網關?網關的基本功能
- 如何從零搭建一個微服務網關
- Predict(斷言)的概念
- 過濾器的概念、Spring Cloud Gateway内置的過濾器以及如何自定義
- 如何內建Nacos注冊中心并且實作負載均衡
- 如何內建Nacos實作動态路由,達到一處修改,多出生效的作用
- 全局異常的處理
你認為Spring Cloud Gateway就介紹完了?不可能,後續還有更深入以及實戰的介紹,下篇文章介紹.....
歡迎大家關注公衆号【Java爛豬皮】,回複【666】,擷取最新Java後端架構VIP學習資料以及視訊學習教程,然後一起學習,一文在手,面試我有。
公衆号【Java爛豬皮】裡面每天都會分享很多獨家的幹貨内容,比如:Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、Redis、MySQL、Spring、Spring Boot、Spring Cloud、RabbitMQ、Kafka、Linux等技術的大廠面試真題+詳解,每一道都是必須掌握的經典
每一個專欄都是大家非常關心,和非常有價值的話題,如果我的文章對你有所幫助,還請幫忙點贊、好評、轉發一下,你的支援會激勵我輸出更高品質的文章,非常感謝!