从零开始 Spring Cloud 7：Gateway

图源：laiketui.com

Spring Cloud Gateway 是 Spring Cloud 的一个全新项目，该项目是基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等响应式编程和事件流技术开发的网关，它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。

网关的核心功能特性：

• 请求路由

• 权限控制

• 限流

架构图：

权限控制：网关作为微服务入口，需要校验用户是是否有请求资格，如果没有则进行拦截。

路由和负载均衡：一切请求都必须先经过gateway，但网关不处理业务，而是根据某种规则，把请求转发到某个微服务，这个过程叫做路由。当然路由的目标服务有多个时，还需要做负载均衡。

限流：当请求流量过高时，在网关中按照下流的微服务能够接受的速度来放行请求，避免服务压力过大。

在SpringCloud中网关的实现包括两种：

• gateway

• zuul

Zuul是基于Servlet的实现，属于阻塞式编程。而SpringCloudGateway则是基于Spring5中提供的WebFlux，属于响应式编程的实现，具备更好的性能。

下面我们看如何用 gateway 作为项目的网关。

本文的示例代码在前文的示例项目基础上进行修改。

基础

需要先为网关创建一个单独的子模块 gateway。

添加依赖

<dependencies>
    <!--网关-->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-gateway</artifactId>
    </dependency>
    <!--nacos服务发现依赖-->
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    </dependency>
</dependencies>

这里添加 nacos 的服务发现依赖是必须的，因为网关负责将用户请求转发到具体的微服务实例，所以必须要能够用服务名称从服务的注册中心（这里是 Nacos）获取到关联的微服务实例地址。

添加启动类

@SpringBootApplication
public class GatewayApplication {
    public static void main(String[] args) {
        SpringApplication.run(GatewayApplication.class, args);
    }
}

添加配置文件

server:
  port: 10010
spring:
  application:
    name: gateway
  cloud:
    nacos:
      server-addr: localhost:8848
    gateway:
      routes:
        - id: shopping-user
          uri: lb://shopping-user
          predicates:
            - Path=/user/**
        - id: shopping-order
          uri: lb://shopping-order
          predicates:
            - Path=/order/**

配置中包含两部分，一部分是连接 Nacos 所需的配置信息，包括 Nacos 服务地址、应用名称等。另一部分是 Gateway 所需的配置。

Gateway 配置主要是 routes 配置项，它代表 Gateway 的路由规则。这个配置项是一个列表，每一个元素包含3个属性：

• id，路由的id，必须唯一。

• uri，路由对应的微服务地址。lb://表示用负载均衡（load balance）的方式访问目标服务。也可以直接指定具体微服务实例的地址，比如http://localhost:8081。

• predicates：断言。只有请求的路径符合断言，才会被路由到目标微服务。

测试

启动项目的所有子模块后，反问 http://localhost:10010/order/101 和 http://localhost:10010/user/1，这说明 Gateway 服务已经生效。

路由断言工厂

路由断言工厂（Route Predicate Factory）是 Spring Cloud 中的一系列类，它们有一个共同的抽象基类org.springframework.cloud.gateway.handler.predicate.AbstractRoutePredicateFactory。

其用途是读取配置文件中的 predicates 配置内容，并用其生成可以直接判断true或者false的Predicate对象，以便 Gateway 在对请求进行路由处理时提供判断依据。

Spring Cloud Gateway 默认提供以下路由工厂：

每种路由工厂处理不同的路由断言，比如PathRoutePredicateFactory就用于处理之前我们使用的Path=xxx这种路由断言。

再比如，如果我们需要限制某个微服务的请求需要在某个时间点之后才能路由（访问），可以：

spring:
  cloud:
    gateway:
      routes:
        - id: shopping-user
          uri: lb://shopping-user
          predicates:
            - Path=/user/**
            - After=2023-07-20T17:42:47.789+08:00[Asia/Shanghai]

这里的2023-07-20T17:42:47.789是格林尼治时间，所以要+08:00（上海是东八区）。

各种路由断言工厂对应的断言配置写法，可以参考官方文档。

网关过滤器

可以在 Gateway 中添加网关过滤器（Gateway Filter），其用途是改变请求或返回信息。

Gateway 的网关过滤器的用途与 Spring Boot 的过滤器用途是类似的。

网关过滤器的工作原理可以用下图表示：

网关过滤器分为三种：

• 具体路由的过滤器

• 默认路由的过滤器

• 全局过滤器

下面依次介绍其功能和用法。

具体路由的过滤器

具体路由的过滤器的使用方式与路由断言类似，都是在配置文件中定义，并由预定义的网关过滤器工厂（Gateway Filter Factory）类来进行处理。

Spring Cloud Gateway 提供了多种类型的网关过滤器工厂，下面是部分：

完整的列表可以参考官方文档。

下面通过使用AddRequestHeader过滤器给请求信息添加请求头来说明如何使用。

在子模块 gateway 的配置文件中为相关路由添加过滤器：

spring:
  cloud:
    gateway:
      routes:
        - id: shopping-user
          uri: lb://shopping-user
          predicates:
            - Path=/user/**
          filters:
            - AddRequestHeader=X-Request-color, blue

这里的AddRequestHeader=X-Request-color, blue意思是为路由添加一个AddRequestHeader过滤器工厂创建的过滤器，其用途是对所有通过 gateway 对 lb://shopping-user/user/** 的访问都添加上一个头信息X-Request-color=blue。

这里用,作为请求头的 key 和 value 的分隔符。

修改子模块 shopping-user 的 Controller，从请求中获取头信息 X-Request-color 并打印：

public class UserController {
    // ...
    @GetMapping("/{id}")
    public Result<User> getUserInfo(@Min(1) @NotNull @PathVariable Long id,
                                    @RequestHeader(value = "X-Request-color", required = false) String color) {
        System.out.println(String.format("color:%s", color));
        return Result.success(userService.findUserById(id));
    }
}

这里使用 Spring MVC 的注解@RequestHeader可以很方便地获取请求头信息。

重启所有微服务。

现在请求 http://localhost:10010/user/1，就能看到某个 shopping-user 实例的控制台输出color:blue。

这个过滤器仅对所在的路由起作用，所以如果请求 http://localhost:10010/order/101，是不会给请求添加新的请求头的。

此外还需要注意的是，过滤器仅对通过 Gateway 发起的请求有效，所以直接请求服务实例（比如 http://localhost:8081/user/1），同样不会生效。

默认路由的过滤器

如果我们需要为所有 Gateway 管理的路由添加一个过滤器，可以使用默认路由的过滤器：

spring:
  cloud:
    gateway:
      routes:
        - id: shopping-user
          uri: lb://shopping-user
          predicates:
            - Path=/user/**
            - After=2023-07-20T17:42:47.789+08:00[Asia/Shanghai]
          filters:
            - AddRequestHeader=X-Request-color, blue
        - id: shopping-order
          uri: lb://shopping-order
          predicates:
            - Path=/order/**
      default-filters:
        - AddRequestHeader=X-Request-msg, Hello world!

这里使用了一个配置项default-filters，让所有经过 Gateway 路由的请求都添加了一个请求头X-Request-msg。

可以用之前的方式进行验证，这里不再赘述。

全局过滤器

前面两种过滤器都只能通过修改配置文件来使用 Gateway 定义好的过滤器工厂，如果要自己定义过滤器的处理规则，就需要使用全局过滤器（Global Filter）：

package org.springframework.cloud.gateway.filter;
public interface GlobalFilter {
    Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain);
}

下面举例进行说明其用法。

在子模块 gateway 中添加一个类，并实现GlobalFilter接口：

@Component
@Order(1)
public class AuthrizeFilter implements GlobalFilter {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        return null;
    }
}

要让自定义的过滤器生效，必须将其注册为一个 bean，所以这里使用了@Component注解。

其次，如果存在多个自定义过滤器，就可能需要控制过滤器的执行顺序，所以这里添加@Order注解来指定过滤器的执行顺序。

• 和 AOP 编程中为 Aspect 指定顺序一样，除了使用@Order注解，还可以实现Ordered接口。

• Mono是 Java 响应式编程中定义的一个类型。

下面我们实现filter方法，可以通过exchange参数获取和变更请求和响应信息，并通过chain参数“推动”过滤器链，让控制流转到下一个过滤器：

@Component
@Order(1)
public class AuthrizeFilter implements GlobalFilter {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        MultiValueMap<String, String> queryParams = exchange.getRequest().getQueryParams();
        String auth = queryParams.getFirst("auth");
        if ("admin".equals(auth)){
            return chain.filter(exchange);
        }
        ServerHttpResponse response = exchange.getResponse();
        response.setStatusCode(HttpStatus.UNAUTHORIZED);
        return response.setComplete();
    }
}

重启子模块 gateway，访问 http://localhost:10010/order/101，此时浏览器会显示页面错误，错误代码是401。

HttpStatus.UNAUTHORIZED对应的就是 HTTP 错误码 401，意思是身份验证出错。

现在所有经过 Gateway 路由的请求，只有存在查询参数auth，并且值是admin的请求才会通过过滤器转发到相应的微服务，比如请求 http://localhost:10010/order/101?auth=admin。

执行顺序

全局过滤器的执行顺序由@Order注解或者Ordered接口指定。具体路由的过滤器和默认路由的过滤器由其定义的顺序决定。Gateway 会按照其定义的顺序从1开始分配序号。

也就是说，下面这种情况下，存在的三种过滤器的序号都是1：

spring:
  cloud:
    gateway:
      routes:
        - id: shopping-user
          uri: lb://shopping-user
          predicates:
            - Path=/user/**
            - After=2023-07-20T17:42:47.789+08:00[Asia/Shanghai]
          filters:
            - AddRequestHeader=X-Request-color, blue
        - id: shopping-order
          uri: lb://shopping-order
          predicates:
            - Path=/order/**
      default-filters:
        - AddRequestHeader=X-Request-msg, Hello world!

@Component
@Order(1)
public class AuthrizeFilter implements GlobalFilter {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // ...
    }
}

过滤器的工作过程是：对于某一个请求，将先匹配路由，匹配到路由后获取这个路由可以使用的所有过滤器（包括上面介绍的三种过滤器），然后按照过滤器序号进行排序并组成过滤器链后依次执行。如果存在过滤器种类不同，但序号相同的情况，会按照默认路由过滤器 > 具体路由过滤器 > 全局过滤器的顺序进行排序。

跨域问题

因为安全原因，浏览器在向服务端发送 AJAX 请求时，会检查当前页面的域名和端口号是否与目标服务的域名及端口号一致，如果不一致，默认会禁止请求的发送和接收。这就是所谓的“跨域问题”。

在企业开发中，通常前端框架与后端框架是单独部署的，所以必然会处在不同的域名和端口号下，所以一般我们都要解决跨域的问题。

• 也可以考虑将前端和后端用 Web Service 反向代理到同一个域名和端口下。

• 解决跨域有多种方案，这里讨论如何用 CORS 解决跨域问题。

在我们当前的项目中，因为我们使用了统一网关 Gateway，理论上所有用户请求都是通过 Gateway 路由和转发的，所以我们只需要处理浏览器对子模块 gateway 的跨域问题即可。

下面用实例说明如何在项目中解决跨域问题。

为了能够进行验证，首先我们需要利用 Web Service 运行一个与服务端端口不同的前端页面。

这里我使用的是 Nginx，配置如下：

    server {
       listen       8100;
       server_name  localhost;
​
       location / {
           root   html/test;
           index  index.html index.htm;
       }
    }

在 Nginx 的根目录下的 html 目录中添加一个 test 目录，在其中添加一个 index.html 文件：

<!DOCTYPE html>
<html lang="en">
<script src="https://unpkg.com/axios/dist/axios.min.js"></script>
<script>
  axios.get("http://localhost:10010/user/1?auth=admin")
  .then(resp => console.log(resp.data))
  .catch(err => console.log(err))
</script>
</html>

这个 html 文件只包含一个 AJAX 调用，显然是跨域的。因为运行页面的服务端口号是 8100，这个 AJAX 调用请求的服务端口号是 10010（也就是 Gateway 运行的实例地址）。

用浏览器请求 http://localhost:8100/ 可以看到控制台输出类似下面的内容：

Access to XMLHttpRequest at 'http://localhost:10010/user/1?auth=admin' from origin 'http://localhost:8100' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

说的很清楚，AJAX 请求被 CORS 规则阻止，因为服务端并没有按照约定返回 Access-Control-Allow-Origin 头信息来允许跨域访问。

修改子模块 gateway 的配置文件，以允许 CORS 跨域：

spring:
  cloud:
    gateway:
      globalcors: # 全局的跨域处理
        # ...
        add-to-simple-url-handler-mapping: true # 解决options请求被拦截问题
        corsConfigurations:
          '[/**]':
            allowedOrigins: # 允许哪些网站的跨域请求
              - "http://localhost:8100"
            allowedMethods: # 允许的跨域ajax的请求方式
              - "GET"
              - "POST"
              - "DELETE"
              - "PUT"
              - "OPTIONS"
            allowedHeaders: "*" # 允许在请求中携带的头信息
            allowCredentials: true # 是否允许携带cookie
            maxAge: 360000 # 这次跨域检测的有效期,单位 秒

重启子模块 gateway 后再访问 http://localhost:8100/ 就会发现已经可以正常访问，控制台正确输出了返回信息。

有一个 JS 报错，不影响测试，忽略即可。

The End，谢谢阅读。

可以从这里获取本文的完整示例代码。