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;
    }
}

 

# gateway
Logo
向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

avatar 云原生

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

avatar 云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...

avatar 云原生