Spring Cloud Gateway 是 springcloud 全新推出的第二代微服務網關，基於 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技術，用來替代Zuul。Gateway 不僅提供了統一的路由方式，並且基於 Filter 鏈的方式提供了網關基本的功能，如轉發、限流、熔斷監控和權限校驗等。
Spring Cloud Gateway 的特徵：
- 基於 Spring Framework 5，Project Reactor 和 Spring Boot 2.0
- 動態路由
- Predicates 和 Filters 作用於特定路由
- 集成 Hystrix 斷路器
- 集成 Spring Cloud DiscoveryClient
- 易於編寫的 Predicates 和 Filters
- 限流
- 路徑重寫
一、構成和核心概念
Spring Cloud Gateway 依賴 Spring Boot 和 Spring WebFlux，基於 Netty 運行。它不能在傳統的 servlet 容器中工作，也不能構建成 war 包。Gateway 由一個netty server，一個netty client，Route（包含Predicate和Filter）構成。在 Gateway 中最重要的應該是Route（Netty Server和Client已經封裝好了），它由RouteLocatorBuilder構建，內部包含Predicate和Filter。
1、Route（路由）
Route 是網關的基礎元素，由 ID、目標 URI、斷言、過濾器組成。當請求到達網關時，由 Gateway Handler Mapping 通過斷言進行路由匹配（Mapping），當斷言爲真時，匹配到路由。
2、Predicate（斷言）（匹配條件）
Predicate 是 Java 8 中提供的一個函數。輸入類型是 Spring Framework ServerWebExchange。它允許開發人員匹配來自 HTTP 的請求，例如請求頭或者請求參數。簡單來說它就是匹配條件。
3、Filter（過濾器）
Filter 是 Gateway 中的過濾器，可以在請求發出前後進行一些業務上的處理。
二、工作原理
Spring Cloud Gateway 的工作原理跟 Zuul 的差不多，最大的區別就是 Gateway 的 Filter 只有 pre（之前） 和 post（之後）兩種。如下是 Gateway 的工作原理圖，
客戶端向 Spring Cloud Gateway 發出請求，如果請求與網關程序定義的路由匹配，則該請求就會被髮送到網關 Web 處理程序，此時處理程序運行特定的請求過濾器鏈。（如果 Gateway Handler Mapping 中找到與請求相匹配的路由，將其發送到 Gateway Web Handler。Handler 再通過指定的過濾器鏈來將請求發送到我們實際的服務執行業務邏輯，然後返回。）
過濾器之間用虛線分開的原因是過濾器可能會在發送代理請求的前後執行邏輯。所有 pre 過濾器邏輯先執行，然後執行代理請求；代理請求完成後，執行 post 過濾器邏輯。
三、Spring Cloud Gateway 的使用
1、路由、斷言、過濾器配置示例
Spring Cloud Gateway 的配置項可以查詢官網，這裏簡單舉例下，
server.port: 8082
spring:
application:
name: gateway
cloud:
gateway:
routes:
- id: path_route
uri: http://localhost:8000 # 還可以用這種Robbin的形式：lb://service-consumer
order: 0
predicates:
- Path=/foo/**
- Method=GET # 斷言中可以指定方法類型，POST、GET、PUT、DELTE等
- Header=X-Request-Id, \d+ # 可以指定header匹配規則
filters:
- StripPrefix=1
- AddRequestParameter=foo, bar #可以在filter上加參數，會自動添加foo=bar
說明：上面給出了一個根據請求路徑來匹配目標uri的例子，如果請求的路徑爲/foo/bar，則目標uri爲 http://localhost:8000/bar。如果上面例子中沒有加一個StripPrefix=1過濾器，則目標uri 爲http://localhost:8000/foo/bar，StripPrefix過濾器是去掉一個路徑。
2、Gateway 跨域
Gateway 還提供了 CROS 跨域配置，在實際項目中也是比較實用的。
spring:
cloud:
gateway:
globalcors:
corsConfigurations:
'[/**]':
allowedOrigins: "https://docs.spring.io"
allowedMethods:
- GET
allowHeaders:
- Content-Type
上面示例中，允許來自https://docs.spring.io的get請求進行訪問,並且表明服務器允許請求頭中攜帶字段Content-Type。
3、Gateway 限流
a）Spring Cloud Gateway本身集成了限流操作，限流需要使用 Redis，需要引入 Redis 依賴。
b）然後yml中，配置 Redis 的信息，並配置 RequestRateLimiter 的限流過濾器，該過濾器需要配置三個參數：
- burstCapacity：令牌桶的總容量。
- replenishRate：令牌通每秒填充平均速率。
- key-resolver：用於限流的解析器的Bean對象的名字。它使用SpEL表達式#{@beanName}從Spring容器中獲取bean對象。
spring:
cloud:
gateway:
routes:
- id: rate_limit_route
uri: lb://service-consumer
predicates:
- Path=/user/**
filters:
- name: RequestRateLimiter
args:
key-resolver: "#{@hostAddrKeyResolver}"
redis-rate-limiter.replenishRate: 1
redis-rate-limiter.burstCapacity: 3
- StripPrefix=1
consul:
host: 127.0.0.1
port: 8500
discovery:
service-name: service-gateway
instance-id: service-gateway-233
redis:
host: localhost
port: 6379
注意：這裏 filter下的name必須是RequestRateLimiter。
c）Key-resolver參數後面的bean需要自己實現，然後注入到Spring容器中。KeyResolver需要實現resolve方法，比如根據ip進行限流，則需要用hostAddress去判斷。實現完KeyResolver之後，需要將這個類的Bean註冊到Ioc容器中。還可以根據uri限流，同hostname限流是一樣的。例如以ip限流爲例，在gateway模塊中添加以下實現：
public class HostAddrKeyResolver implements KeyResolver {
@Override
public Mono<String> resolve(ServerWebExchange exchange) {
return Mono.just(exchange.getRequest().getRemoteAddress().getAddress().getHostAddress());
}
public HostAddrKeyResolver hostAddrKeyResolver() {
return new HostAddrKeyResolver();
}
}
把該類注入到spring容器中：
@SpringBootApplication
@EnableDiscoveryClient
public class GatewayApplication {
public static void main(String[] args) {
SpringApplication.run(GatewayApplication.class, args);
}
@Bean
public HostAddrKeyResolver hostAddrKeyResolver(){
return new HostAddrKeyResolver();
}
}
基於上述配置，可以對請求基於ip的訪問進行限流。
4、Gateway 重試
通過簡單的配置，Spring Cloud Gateway就可以支持請求重試功能（filters --> args --> retries: 3）。Retry Gateway Filter 通過四個參數來控制重試機制，參數說明如下：
- retries：重試次數，默認值是 3 次。
- statuses：HTTP 的狀態返回碼，取值請參考：org.springframework.http.HttpStatus。
- methods：指定哪些方法的請求需要進行重試邏輯，默認值是 GET 方法，取值參考：org.springframework.http.HttpMethod。
- series：一些列的狀態碼配置，取值參考：org.springframework.http.HttpStatus.Series。符合的某段狀態碼纔會進行重試邏輯，默認值是 SERVER_ERROR，值是 5，也就是 5XX(5 開頭的狀態碼)，共有5個值。
spring:
cloud:
gateway:
routes:
- id: header_route
uri: http://localhost:8080/test/hello
predicates:
- Path=/test/**
filters:
- name: Retry
args:
retries: 3 # 重試次數
status: 503 # 503時重試
- StripPrefix=1
使用上述配置進行測試，當後臺服務不可用時，會在控制檯看到請求三次的日誌，證明此配置有效。
5、Gateway 熔斷
網關是流量的入口，訪問請求非常大，Gateway也可以利用Hystrix的熔斷特性，在流量過大時進行服務降級。建議在網關微服務中加入Hystrix依賴，配置熔斷，如下
spring:
cloud:
gateway:
routes:
- id: hystrix_route
uri: lb://consumer-service
predicates:
- Path=/consumer/**
filters:
- name: Hystrix
args:
name: fallbackcmd
fallbackUri: forward:/fallback
- StripPrefix=1
hystrix:
command:
fallbackcmd:
execution:
isolation:
thread:
timeoutInMilliseconds: 5000 #超時時間，若不設置超時時間則有可能無法觸發熔斷
上述配置中給出了熔斷之後返回路徑 fallbackUri: forward:/fallback，這個配置了 fallback 時要會調的路徑，當調用 Hystrix 的 fallback 被調用時，請求將轉發到/fallback這個 URI，並以此路徑的返回值作爲返回結果。
@RestController
public class GatewayController {
@RequestMapping(value = "/fallback")
public String fallback(){
return "fallback nothing";
}
}
6、自定義 GatewayFilter 和 GlobalFilter
Spring Cloud Gateway根據作用範圍分爲GatewayFilter和GlobalFilter，二者區別如下：
- GatewayFilter ：需要通過spring.cloud.routes.filters 配置在具體路由下，只作用在當前路由上或通過spring.cloud.default-filters配置在全局，作用在所有路由上。（需要在yml中配置，局部過濾）
- GlobalFilter：全局過濾器，不需要在配置文件中配置，作用在所有的路由上，最終通過GatewayFilterAdapter包裝成GatewayFilterChain可識別的過濾器，它爲請求業務以及路由的URI轉換爲真實業務服務的請求地址的核心過濾器，不需要配置，系統初始化時加載，並作用在每個路由上。（不需要在yml中配置，全局過濾）
在Spring Cloud Gateway自定義過濾器，過濾器需要實現 GatewayFilter 和 Ordered 這兩個接口。
a）自定義GatewayFilter類型的過濾器：RequestTimeFilter，以log日誌的形式記錄每次請求耗費的時間。
public class RequestTimeFilter implements GatewayFilter, Ordered {
private static final Log log = LogFactory.getLog(GatewayFilter.class);
private static final String REQUEST_TIME_BEGIN = "requestTimeBegin";
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
exchange.getAttributes().put(REQUEST_TIME_BEGIN, System.currentTimeMillis());
return chain.filter(exchange).then(
Mono.fromRunnable(() -> {
Long startTime = exchange.getAttribute(REQUEST_TIME_BEGIN);
if (startTime != null) {
log.info("請求路徑："+exchange.getRequest().getURI().getRawPath() + "消耗時間: " + (System.currentTimeMillis() - startTime) + "ms");
}
})
);
}
@Override
public int getOrder() {
return 0;
}
}
- getOrder()方法，是來給過濾器定優先級的，值越大優先級越低。
- filter(...) 方法，先記錄了請求的開始時間，並保存在ServerWebExchange中，此處是一個“pre”類型的過濾器。然後再chain.filter()的內部類中的run()方法中相當於"post"過濾器，在此處打印了請求所消耗的時間。
GatewayFilter 類型的過濾器寫完後，還需要再yml中配置，和普通的過濾器配置一樣。
b）自定義 GlobalFilter 類型的過濾器：TokenFilter，判斷所有請求中是否含參數token，如果不合法，則校驗不通過；合法，則通過。
public class TokenFilter implements GlobalFilter, Ordered {
Logger logger= LoggerFactory.getLogger( TokenFilter.class );
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
String token = exchange.getRequest().getQueryParams().getFirst("token");
if (token == null || token.isEmpty()) {
logger.info( "token 爲空，無法進行訪問." );
exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
return exchange.getResponse().setComplete();
}
return chain.filter(exchange);
}
@Override
public int getOrder() {
return 0;
}
}