背景
在之前的文章中，我們介紹過微服務網關
Spring Cloud Netflix Zuul，前段時間有兩篇文章專門介紹了Spring Cloud的全新項目
Spring Cloud Gateway，以及其中的
過濾器工廠。本文将會介紹将微服務網關由Zuul遷移到Spring Cloud Gateway。
Spring Cloud Netflix Zuul是由Netflix開源的API網關，在微服務架構下，網關作為對外的門戶，實作動态路由、監控、授權、安全、排程等功能。
Zuul基于servlet 2.5（使用3.x），使用阻塞API。 它不支援任何長連接配接，如websockets。而Gateway建立在Spring Framework 5，Project Reactor和Spring Boot 2之上，使用非阻塞API。 比較完美地支援異步非阻塞程式設計，先前的Spring系大多是同步阻塞的程式設計模式，使用thread-per-request處理模型。即使在Spring MVC Controller方法上加@Async注解或傳回DeferredResult、Callable類型的結果，其實仍隻是把方法的同步調用封裝成執行任務放到線程池的任務隊列中，還是thread-per-request模型。Gateway 中Websockets得到支援，并且由于它與Spring緊密內建，是以将會是一個更好的開發體驗。
在一個微服務內建的項目中microservice-integration，我們整合了包括網關、auth權限服務和backend服務。提供了一套微服務架構下，網關服務路由、鑒權和授權認證的項目案例。整個項目的架構圖如下：
Zuul網關
在該項目中，Zuul網關的主要功能為路由轉發、鑒權授權和安全通路等功能。
Zuul中，很容易配置動态路由轉發，如：
1zuul:
2 ribbon:
3 eager-load:
4 enabled: true #zuul饑餓加載
5 host:
6 maxTotalConnections: 200
7 maxPerRouteConnections: 20
8 routes:
9 user:
10 path: /user/**
11 ignoredPatterns: /consul
12 serviceId: user
13 sensitiveHeaders: Cookie,Set-Cookie
預設情況下，Zuul在請求路由時，會過濾HTTP請求頭資訊中的一些敏感資訊，這裡我們不過多介紹。
網關中還配置了請求的鑒權，結合Auth服務，通過Zuul自帶的Pre過濾器可以實作該功能。當然還可以利用Post過濾器對請求結果進行适配和修改等操作。
除此之外，還可以配置限流過濾器和斷路器，下文中将會增加實作這部分功能。
遷移到Spring Cloud Gateway
筆者建立了一個
gateway-enhanced
的項目，因為變化很大，不适合在之前的
gateway
項目基礎上修改。實作的主要功能如下：路由轉發、權重路由、斷路器、限流、鑒權和黑白名單等。本文基于主要實作如下的三方面功能：
- 路由斷言
- 過濾器（包括全局過濾器，如斷路器、限流等）
- 全局鑒權
- 路由配置
- CORS
依賴
本文采用的Spring Cloud Gateway版本為
2.0.0.RELEASE
。增加的主要依賴如下，具體的細節可以參見Github上的項目。
1 <dependencies>
2 <dependency>
3 <groupId>org.springframework.cloud</groupId>
4 <artifactId>spring-cloud-starter-gateway</artifactId>
5 <!--<version>2.0.1.RELEASE</version>-->
6 </dependency>
7 <dependency>
8 <groupId>org.springframework.cloud</groupId>
9 <artifactId>spring-cloud-gateway-webflux</artifactId>
10 </dependency>
11 </dependencies>
12
13 <dependencyManagement>
14 <dependencies>
15 <dependency>
16 <groupId>org.springframework.cloud</groupId>
17 <artifactId>spring-cloud-dependencies</artifactId>
18 <version>Finchley.RELEASE</version>
19 <type>pom</type>
20 <scope>import</scope>
21 </dependency>
22 </dependencies>
23 </dependencyManagement>
Spring Cloud Gateway對于路由斷言、過濾器和路由的定義，同時支援配置檔案的shortcut和Fluent API。我們将以在本項目中實際使用的功能進行講解。
路由斷言在網關進行轉發請求之前進行判斷路由的具體服務，通常可以根據請求的路徑、請求體、請求方式（GET/POST）、請求位址、請求時間、請求的HOST等資訊。我們主要用到的是基于請求路徑的方式，如下：
1spring:
2 cloud:
3 gateway:
4 routes:
5 - id: service_to_web
6 uri: lb://authdemo
7 predicates:
8 - Path=/demo/**
我們定義了一個名為
service_to_web
的路由，将請求路徑以
/demo/**
的請求都轉發到authdemo服務執行個體。
我們在本項目中路由斷言的需求并不複雜，下面介紹通過Fluent API配置的其他路由斷言：
1 @Bean
2 public RouteLocator routeLocator(RouteLocatorBuilder builder) {
3 return builder.routes()
4 .route(r -> r.host("**.changeuri.org").and().header("X-Next-Url")
5 .uri("http://blueskykong.com"))
6 .route(r -> r.host("**.changeuri.org").and().query("url")
7 .uri("http://blueskykong.com"))
8 .build();
9 }
在如上的路由定義中，我們配置了以及請求HOST、請求頭部和請求的參數。在一個路由定義中，可以配置多個斷言，采取與或非的關系判斷。
以上增加的配置僅作為擴充，讀者可以根據自己的需要進行配置相應的斷言。
過濾器
過濾器分為全局過濾器和局部過濾器。我們通過實作
GlobalFilter
、
GatewayFilter
接口，自定義過濾器。
全局過濾器
本項目中，我們配置了如下的全局過濾器：
- 基于令牌桶的限流過濾器
- 基于漏桶算法的限流過濾器
- 全局斷路器
- 全局鑒權過濾器
定義全局過濾器，可以通過在配置檔案中，增加
spring.cloud.gateway.default-filters
，或者實作
GlobalFilter
接口。
随着時間流逝，系統會按恒定 1/QPS 時間間隔（如果 QPS=100，則間隔是 10ms）往桶裡加入 Token，如果桶已經滿了就不再加了。每個請求來臨時，會拿走一個 Token，如果沒有 Token 可拿了，就阻塞或者拒絕服務。
令牌桶的另外一個好處是可以友善的改變速度。一旦需要提高速率，則按需提高放入桶中的令牌的速率。一般會定時（比如 100 毫秒）往桶中增加一定數量的令牌，有些變種算法則實時的計算應該增加的令牌的數量。
在Spring Cloud Gateway中提供了預設的實作，我們需要引入redis的依賴：
1 <dependency>
2 <groupId>org.springframework.boot</groupId>
3 <artifactId>spring-boot-starter-data-redis-reactive</artifactId>
4 </dependency>
并進行如下的配置：
1spring:
2 redis:
3 host: localhost
4 password: pwd
5 port: 6378
6 cloud:
7 default-filters:
8 - name: RequestRateLimiter
9 args:
10 key-resolver: "#{@remoteAddrKeyResolver}"
11 rate-limiter: "#{@customRateLimiter}" # token
注意到，在配置中使用了兩個SpEL表達式，分别定義限流鍵和限流的配置。是以，我們需要在實作中增加如下的配置：
1 @Bean(name = "customRateLimiter")
2 public RedisRateLimiter myRateLimiter(GatewayLimitProperties gatewayLimitProperties) {
3 GatewayLimitProperties.RedisRate redisRate = gatewayLimitProperties.getRedisRate();
4 if (Objects.isNull(redisRate)) {
5 throw new ServerException(ErrorCodes.PROPERTY_NOT_INITIAL);
6 }
7 return new RedisRateLimiter(redisRate.getReplenishRate(), redisRate.getBurstCapacity());
8 }
9
10 @Bean(name = RemoteAddrKeyResolver.BEAN_NAME)
11 public RemoteAddrKeyResolver remoteAddrKeyResolver() {
12 return new RemoteAddrKeyResolver();
13 }
在如上的實作中，初始化好
RedisRateLimiter
和
RemoteAddrKeyResolver
兩個Bean執行個體，
RedisRateLimiter
是定義在Gateway中的redis限流屬性；而
RemoteAddrKeyResolver
使我們自定義的，基于請求的位址作為限流鍵。如下為該限流鍵的定義：
1public class RemoteAddrKeyResolver implements KeyResolver {
2 private static final Logger LOGGER = LoggerFactory.getLogger(RemoteAddrKeyResolver.class);
3
4 public static final String BEAN_NAME = "remoteAddrKeyResolver";
5
6 @Override
7 public Mono<String> resolve(ServerWebExchange exchange) {
8 LOGGER.debug("token limit for ip: {} ", exchange.getRequest().getRemoteAddress().getAddress().getHostAddress());
9 return Mono.just(exchange.getRequest().getRemoteAddress().getAddress().getHostAddress());
10 }
11
12}
RemoteAddrKeyResolver
實作了
KeyResolver
接口，覆寫其中定義的接口，傳回值為請求中的位址。
如上，即實作了基于令牌桶算法的鍊路過濾器，具體細節不再展開。
漏桶（Leaky Bucket）算法思路很簡單，水（請求）先進入到漏桶裡，漏桶以一定的速度出水（接口有響應速率），當水流入速度過大會直接溢出（通路頻率超過接口響應速率），然後就拒絕請求，可以看出漏桶算法能強行限制資料的傳輸速率。
這部分實作讀者參見GitHub項目以及文末配套的書，此處略過。
關于Hystrix斷路器，是一種服務容錯的保護措施。
斷路器
本身是一種開關裝置，用于在電路上保護線路過載，當線路中有發生短路狀況時，
斷路器
能夠及時的切斷故障電路，防止發生過載、起火等情況。
微服務架構中，斷路器模式的作用也是類似的，當某個服務單元發生故障之後，通過斷路器的故障監控，直接切斷原來的主邏輯調用。關于斷路器的更多資料和Hystrix實作原理，讀者可以參考文末配套的書。
這裡需要引入
spring-cloud-starter-netflix-hystrix
依賴：
1 <dependency>
2 <groupId>org.springframework.cloud</groupId>
3 <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
4 <optional>true</optional>
5 </dependency>
并增加如下的配置：
1 default-filters:
2 - name: Hystrix
3 args:
4 name: fallbackcmd
5 fallbackUri: forward:/fallbackcontroller
如上的配置，将會使用
HystrixCommand
打包剩餘的過濾器，并命名為
fallbackcmd
，我們還配置了可選的參數
fallbackUri
，降級邏輯被調用，請求将會被轉發到URI為
/fallbackcontroller
的控制器處理。定義降級處理如下：
1 @RequestMapping(value = "/fallbackcontroller")
2 public Map<String, String> fallBackController() {
3 Map<String, String> res = new HashMap();
4 res.put("code", "-100");
5 res.put("data", "service not available");
6 return res;
7 }
我們通過自定義一個全局過濾器實作，對請求合法性的鑒權。具體功能不再贅述了，通過實作
GlobalFilter
接口，差別的是Webflux傳入的是
ServerWebExchange
，通過判斷是不是外部接口（外部接口不需要登入鑒權），執行之前實作的處理邏輯。
1public class AuthorizationFilter implements GlobalFilter, Ordered {
2
3 //....
4
5 @Override
6 public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
7 ServerHttpRequest request = exchange.getRequest();
8 if (predicate(exchange)) {
9 request = headerEnhanceFilter.doFilter(request);
10 String accessToken = extractHeaderToken(request);
11
12 customRemoteTokenServices.loadAuthentication(accessToken);
13 LOGGER.info("success auth token and permission!");
14 }
15
16 return chain.filter(exchange);
17 }
18 //提出頭部的token
19 protected String extractHeaderToken(ServerHttpRequest request) {
20 List<String> headers = request.getHeaders().get("Authorization");
21 if (Objects.nonNull(headers) && headers.size() > 0) { // typically there is only one (most servers enforce that)
22 String value = headers.get(0);
23 if ((value.toLowerCase().startsWith(OAuth2AccessToken.BEARER_TYPE.toLowerCase()))) {
24 String authHeaderValue = value.substring(OAuth2AccessToken.BEARER_TYPE.length()).trim();
25 // Add this here for the auth details later. Would be better to change the signature of this method.
26 int commaIndex = authHeaderValue.indexOf(',');
27 if (commaIndex > 0) {
28 authHeaderValue = authHeaderValue.substring(0, commaIndex);
29 }
30 return authHeaderValue;
31 }
32 }
33
34 return null;
35 }
36
37}
定義好全局過濾器之後，隻需要配置一下即可：
1 @Bean
2 public AuthorizationFilter authorizationFilter(CustomRemoteTokenServices customRemoteTokenServices,
3 HeaderEnhanceFilter headerEnhanceFilter,
4 PermitAllUrlProperties permitAllUrlProperties) {
5 return new AuthorizationFilter(customRemoteTokenServices, headerEnhanceFilter, permitAllUrlProperties);
6 }
局部過濾器
我們常用的局部過濾器有增減請求和相應頭部、增減請求的路徑等多種過濾器。我們這裡用到的是去除請求的指定字首，這部分字首隻是使用者網關進行路由判斷，在轉發到具體服務時，需要去除字首：
1 - id: service_to_user
2 uri: lb://user
3 order: 8000
4 predicates:
5 - Path=/user/**
6 filters:
7 - AddRequestHeader=X-Request-Foo, Bar
8 - StripPrefix=1
還可以通過Fluent API，如下：
1 @Bean
2 public RouteLocator retryRouteLocator(RouteLocatorBuilder builder) {
3 return builder.routes()
4 .route("retry_java", r -> r.path("/test/**")
5 .filters(f -> f.stripPrefix(1)
6 .retry(config -> config.setRetries(2).setStatuses(HttpStatus.INTERNAL_SERVER_ERROR)))
7 .uri("lb://user"))
8 .build();
9 }
除了設定字首過濾器外，我們還設定了重試過濾器，可以參見：Spring Cloud Gateway中的過濾器工廠：重試過濾器
路由定義在上面的示例中已經有列出，可以通過配置檔案和定義
RouteLocator
的對象。這裡需要注意的是，配置中的
uri
屬性，可以是具體的服務位址（IP+端口号），也可以是通過服務發現加上負載均衡定義的：
lb://user
，表示轉發到user的服務執行個體。當然這需要我們進行一些配置。
引入服務發現的依賴：
1 <dependency>
2 <groupId>org.springframework.cloud</groupId>
3 <artifactId>spring-cloud-starter-consul-discovery</artifactId>
4 </dependency>
網關中開啟
spring.cloud.gateway.discovery.locator.enabled=true
即可。
CORS配置
在Spring 5 Webflux中，配置CORS，可以通過自定義
WebFilter
實作：
1 private static final String ALLOWED_HEADERS = "x-requested-with, authorization, Content-Type, Authorization, credential, X-XSRF-TOKEN";
2 private static final String ALLOWED_METHODS = "GET, PUT, POST, DELETE, OPTIONS";
3 private static final String ALLOWED_ORIGIN = "*";
4 private static final String MAX_AGE = "3600";
5
6 @Bean
7 public WebFilter corsFilter() {
8 return (ServerWebExchange ctx, WebFilterChain chain) -> {
9 ServerHttpRequest request = ctx.getRequest();
10 if (CorsUtils.isCorsRequest(request)) {
11 ServerHttpResponse response = ctx.getResponse();
12 HttpHeaders headers = response.getHeaders();
13 headers.add("Access-Control-Allow-Origin", ALLOWED_ORIGIN);
14 headers.add("Access-Control-Allow-Methods", ALLOWED_METHODS);
15 headers.add("Access-Control-Max-Age", MAX_AGE);
16 headers.add("Access-Control-Allow-Headers",ALLOWED_HEADERS);
17 if (request.getMethod() == HttpMethod.OPTIONS) {
18 response.setStatusCode(HttpStatus.OK);
19 return Mono.empty();
20 }
21 }
22 return chain.filter(ctx);
23 };
24 }
上述代碼實作比較簡單，讀者根據實際的需要配置
ALLOWED_ORIGIN
等參數。
總結
在高并發和潛在的高延遲場景下，網關要實作高性能高吞吐量的一個基本要求是全鍊路異步，不要阻塞線程。Zuul網關采用同步阻塞模式不符合要求。
Spring Cloud Gateway基于Webflux，比較完美地支援異步非阻塞程式設計，很多功能實作起來比較友善。Spring5必須使用java 8，函數式程式設計就是java8重要的特點之一，而WebFlux支援函數式程式設計來定義路由端點處理請求。
通過如上的實作，我們将網關從Zuul遷移到了Spring Cloud Gateway。在Gateway中定義了豐富的路由斷言和過濾器，通過配置檔案或者Fluent API可以直接調用和使用，非常友善。在性能上，也是勝于之前的Zuul網關。
原文釋出時間為：2018-10-16
本文作者：aoho
本文來自雲栖社群合作夥伴“雲時代架構”，了解相關資訊可以關注“雲時代架構”。
![Java String.format方法的簡單使用[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)