六. SpringCloud网关

1. Gateway概述

1.1 Gateway是什么

服务网关还可以用Zuul网关,但是Zuul网关由于一些维护问题,所以这里我们学习Gateway网关,SpringCloud全家桶里有个很重要的组件就是网关, 在1.x的版本中都是采用Zuul网关;但在2.x版本中,Zuul的升级一直跳票,SpringCloud最后自己研发了一个网关代替Zuul,也就是说SpringCloud Gateway是原Zuul1.x版的替代品。

SpringCloud Gateway是在Spring生态系统之上构建的API网关服务,基于Spring5,SpringBoot2和Project Reactor等技术。

Gateway旨在提供一种简单而有效的方式来对API进行路由,以及提供一些强大的过滤功能,例如熔断、限流、重试等。

SpringCloud Gateway作为SpringCloud生态系统中的网关,目的是替代Zuul,在SpringCloud2.0以上版本中,没有对新版本的Zuul2.0以上最新高新能版本进行集成,仍然使用的是Zuul 1.x非Reactor模式的老版本。而为了提升网关的性能,SpringCloud Gateway是基于WebFlux框架实现的,而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。

SpringCloud Gateway的目标是提供统一的路由方式且基于Filter链的方式提供了网关基本的功能,例如:安全、监控/指标、限流等。

一句话:Spring Cloud Gateway使用的Webflux中的reactor-netty响应式编程组件,底层使用了Netty通讯框架

源码架构:

六. SpringCloud网关
1.2 整个微服务架构中网关的位置

可以看到网关是所有微服务的入口

六. SpringCloud网关
1.3 Gateway能做什么

反向代理、鉴权、流量控制、熔断、日志监控等。

SpringCloud Gateway具有如下特性:

  • 基于Spring Framework 5, Project Reactor和SpringBoot 2.x进行构建
  • 动态路由:能够匹配任何请求属性
  • 可以对路由指定Predicate(断言)和Filter(过滤器)
  • 集成Hystrix的熔断器功能
  • 集成SpringCloud服务发现功能
  • 请求限流功能
  • 支持路径重写等待
1.4 Gateway与Zuul的区别

在SpringCloud Finchley正式版以前,SpringCloud推荐的网关是Netflix提供的Zuul:

  • Zuul 1.x 是一个基于阻塞I/O的API Gateway
  • Zuul 1.x 基于Servlet 2.5使用阻塞架构,它不支持任何长连接(如WebSocket),Zuul的设计模式和Nginx比较像,每次I/O操作都是从工作线程中选择一个执行,请求线程被阻塞到工作线程完成,但是差别是Nginx是用C++实现的,Zuul用Java实现,而JVM本身会有第一次加载较慢的情况,使得Zuul的性能相对较差
  • Zuul 2.x 理念更先进,想基于Netty非阻塞和支持长连接,但是SpringCloud目前还没有整合。Zuul 2.x 的性能较Zull 1.x有很大提升。根据官方提供的基准测试,SpringCloud Gateway的RPS(每秒请求数)是Zuul的1.6倍
  • SpringCloud Gateway基于Spring Framework 5, Project Reactor和SpringBoot 2.x进行构建,使用非阻塞API,还支持WebSocket,并且与Spring Cloud紧密集成有更好的开发体验
1.5 模型对比

Zuul1.x模型:

SpringCloud中所集成的Zuul版本,采用的是Tomcat容器,使用的是传统的Servlet IO处理模型.

Servlet的声明周期?=> Servlet由Servlet Container进行生命周期管理,Container启动时构造Servlet对象并调用Servlet init() 进行初始化,Container运行时接受请求,并为每一个请求分配一个线程(一般从线程池中获取空闲线程)然后调用Service()方法,Container关闭时嗲用Servlet destory() 销毁Servlet。

上述模式的缺点:Servlet是一个简单的网络IO模型,当请求进入Servlet Container时,Servlet Container就会为其绑定一个线程,在 并发不高的场景下 这种模型是适合的,但是一旦高并发(比如使用jemeter加压),线程数量就会上涨,而线程资源代价是昂贵的(上下文切换,内存消耗大)严重影响请求的处理时间。在一些简单业务场景下,不希望为每个request分配一个线程,只需要1个或几个线程就能应对极大并发的请求,这种业务场景下Servlet模型没有优势。

所以Zuul 1.x 是 基于Servlet之上的一个阻塞式处理模型,即Spring实现了处理所有request请求的一个Servlet(DispatcherServlet)并由该Servlet阻塞式处理处理。所以SpringCloud Zuul无法摆脱Servlet模型的弊端。

Gateway模型:

传统的Web框架,如struts2,SpringMVC等都是基于Servlet API与Servlet容器基础之上运行的。

但是 在Servlet3.1之后又了异步非阻塞的支持,而WebFlux是一个典型非阻塞异步的框架,它的核心是基于Reactor的相关API实现的。相对于传统的Web框架来说,它可以运行在诸如Netty,Undertow及支持Servlet3.1的容器上。非阻塞+函数式编程(Spring5必须使用Java8)。

Spring WebFlux是Spring 5.0引入的新的响应式框架,区别于Spring MVC,它不需要依赖于Servlet API,它是完全异步非阻塞的,并且基于Reactor来实现响应式流规范。

2. Gateway核心概念

  • 路由 Route 路由是构建网关的基本模块,它由ID、目标URI、一系列的断言和过滤器组成,如果断言为true则匹配路由。
  • 断言 Predicate 参考的是Java8的 java.util.function.Predicate,开发人员可以匹配HTTP请求中的所有内容(例如请求头或请求参数), 如果请求与断言匹配则进行路由。
  • 过滤器 Filter Spring框架中GatewayFilter的实例,使用过滤器,可以在请求被路由之前或者之后对请求进行修改。客户当发送Web请求,通过一些匹配条件,定位到真正的服务节点,并在这个转发过程的前后,进行一些精细化的控制,而断言就是这些匹配条件,过滤器可以理解为一个无所不能的拦截器,用来实现这些精细化的控制,有了断言和过滤器,再加上目标的URI,就可以实现一个具体的路由。
六. SpringCloud网关

3. 网关工作流程

客户端向Spring Cloud Gateway发出请求。如果 网关处理程序映射(Gateway Handler Mapping)确定请求与路由匹配,则将其发送到 网关Web处理程序(Gateway Web Handler)。该处理程序通过特定于请求的 过滤器链 来运行请求。

过滤器器由虚线分隔的原因是,过滤器可以在发送代理请求 之前之后 运行逻辑。所有“前置”过滤器逻辑均被执行。然后发出代理请求。发出代理请求后,将运行“后置”过滤器逻辑。图中虚线左边的对应于前置过滤器,虚线右边的对应于 后置过滤器

六. SpringCloud网关

前置过滤器可以做参数校验、权限校验、流量监控、日志输出、协议转换等

后置过滤器可以做响应内容、响应头的修改、日志的输出、流量监控等

SpringCloud Gateway的核心逻辑其实就是 路由转发和执行过滤器链

4. 配置案例(两种方式)

yml配置文件实现SpringCloud Gateway的路由配置

新建Module:cloud-gateway-gateway9527作为网关微服务,在网关模块的POM文件在服务注册中心必要的依赖以外还需要 引入SpringCloud Gateway的依赖(版本号已经在父工程中统一配置),需要注意的是,网关微服务 不需要引入Web启动器(gateway做的是网关不需要web):

<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>

老规矩编写其配置类application.yml,以9527端口,服务名为cloud-gateway将自己注册进Eureka服务注册中心

server:
  port: 9527

spring:
  application:
    name: cloud-gateway

eureka:
  instance:
    hostname: cloud-gateway-service
  client:
    register-with-eureka: true
    fetchRegistry: true
    service-url:
      defaultZone: http://localhost:7001/eureka

网关嘛,就是挡在微服务之前看大门的,所以先不编写其业务类。

编写网关的主启动类:

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

设定9527网关要对服务提供方提供的8001端口微服务进行路由处理,我们不想暴露8001端口,希望在8001端口外面套上一层网关的9527端口,在8001微服务中有如下的两个服务:

@GetMapping("/payment/get/{id}")
public CommonResult getPaymentById(@PathVariable("id") Integer id);

@GetMapping("/payment/lb")
public String getPaymentLB();

为了配置对上面两个服务的路由,我们修改9527网关微服务的配置文件application.yml,修改后的配置文件如下:

server:
  port: 9527

spring:
  application:
    name: cloud-gateway
  cloud:
    gateway:
      routes:
        - id: payment_routh # payment_route    # 路由的ID,没有固定规则但要求唯一,建议配合服务名
          uri: http://localhost:8001          # 匹配后提供服务的路由地址
          predicates:
            - Path=/payment/get/**         # 断言,路径相匹配的进行路由

        - id: payment_routh2 # payment_route    # 路由的ID,没有固定规则但要求唯一,建议配合服务名
          uri: http://localhost:8001          # 匹配后提供服务的路由地址
          predicates:
            - Path=/payment/lb/**         # 断言,路径相匹配的进行路由
eureka:
  instance:
    hostname: cloud-gateway-service
  client:
    register-with-eureka: true
    fetchRegistry: true
    service-url:
      defaultZone: http://localhost:7001/eureka

在路由routes中我们配置了两个路由,一个是针对8001的getPaymentById服务,另一个是针对8001的getPaymentLB服务,然后我们分别启动Eureka服务注册中心、服务提供方8001微服务、9527网关微服务。我们发现,在添加网关前,我们需要通过http://localhost:8001/payment/get/1 来访问服务提供方的服务,但是现在不仅访问提供服务方可以访问其服务,我们通过访问网关也可以访问到服务提供方的微服务:

六. SpringCloud网关

这样的话用网关对微服务进行路由访问,就可以不再对外暴露微服务的真实地址,而是统一暴露为网关的地址。

SpringCloud Gateway的网关路由有两种配置方式,一种就是上面通过配置文件application.yml进行网关路由配置,还可以 在代码中注入RouteLocator的Bean进行配置,下面实现用编码的方式,实现通过9527网关对百度新闻的访问。

非配置文件,编码方式实现SpringCloud Gateway的路由配置

案例:通过9527网关访问到外网的百度新闻地址

在9527网关微服务中编写如下的配置类:

@Configuration
public class GateWayConfig {

    @Bean
    public RouteLocator customRouteLocator(RouteLocatorBuilder routeLocatorBuilder) {
        RouteLocatorBuilder.Builder routes = routeLocatorBuilder.routes();
        routes.route("path_route",
                r -> r.path("/guonei")
                        .uri("http://news.baidu.com/guonei")).build();
        return routes.build();
    }
}

上面的配置类注入RouteLocator的Bean,其配置的一个id为"path_route"的路由,当访问地址http://localhost:9527/guonei 时,该路由会将访问自动转发到http://news.baidu.com/guonei

5. 通过微服务名实现动态路由

在上面的yml配置文件中,我们把路由地址写死了,这明显应该是程序中避免的。所以更好的方式是通过微服务名来实现动态路由。

默认情况下 Gateway会根据注册中心注册的服务列表,以注册中心上微服务名为路径创建动态路由进行转发,从而实现动态路由的功能。为了演示SpringCloud Gateway实现的动态路由,我们启用服务提供方集群,使8001/8002微服务都启动,让CLOUD-PAYMENT-SERVICE服务对应于两个具体服务实例。

为了实现网关根据微服务名对服务进行动态路由,需要在网关微服务配置文件中开启从注册中心动态创建路由的功能,添加如下配置:

spring:
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true # 开启从注册中心动态创建路由的功能,利用微服务名进行路由

然后将原来配置文件中写死的路由地址改为注册中心的服务名:

需要注意的是uri的协议为lb,,表示启用Gateway的负载均衡功能。

uri: lb://cloud-payment-service # 匹配后提供服务的路由地址

然后通过网关我们访问CLOUD-PAYMENT-SERVICE服务,可以看到网关同之前用过的Ribbon一样,可以实现动态路由,可以看出其默认的负载均衡算法也是轮询负载均衡。

6. Predicate详解

6.1 predicate是什么

启动gateway9527

六. SpringCloud网关

Gateway将路由匹配作为Spring WebFlux HandlerMapping基础架构的一部分。

Gateway包括许多内置的Route Predicate工厂。所有这些Predicate都与HTTP请求的不同属性匹配。多个Route Predicate工厂可以进行组合。

Gateway 创建Route对象时,使用RoutePredicateFactory创建Predicate对象,Predicate对象可以赋值给Route。Gateway包括许多内置的Route Predicate Factories。

所有这些谓词都匹配HTTP请求的不同属性。多种谓词工厂可以组合,并通过逻辑and。

6.2 常用的Route Predicate

说白了,Predicate就是为了实现一组匹配规则,让请求过来找到对应的Route进行处理。

六. SpringCloud网关
  • After Route Predicate
spring:
  cloud:
    gateway:
      routes:
        - id: after_route
          uri: https://example.ort
          predicates:
            - After=2021-03-04T09:07:25.143+08:00[Asia/Shanghai]

After好理解,但是时间串怎么获得?↓

public static void main(String[] args) {
    ZonedDateTime zbj = ZonedDateTime.now();//默认时区
    System.out.println(zbj);//2021-03-04T09:07:25.143+08:00[Asia/Shanghai]
}
  • Before Route Predicate
  • Between Route Predicate
  • Cookie Route Predicate

Cookie Route Predicate需要两个参数,一个是Cookie name,一个是正则表达式。路由规则会通过获取对应的Cookie name值和正则表达式去匹配,如果匹配上就会执行路由,如果没有匹配上则不执行

predicates:
    - Cookie=username,zzyy

不带Cookie的访问 curl http://localhost:9588/paymentInfo

六. SpringCloud网关

带Cookies的访问 curl http://localhost:9588/paymentInfo --cookie "username=zzyy"

六. SpringCloud网关
  • Header Route Predicate
predicates:
    - Header=X-Request-Id,\d+ # 请求头要由X-Request-Id属性并且值为正数的正则表达式

两个参数:一个是属性名称和一个正则表达式,这个属性值和正则表达式匹配则执行。

curl http://localhost:9588/paymentInfo -H "X-Reqeust-Id:123"

六. SpringCloud网关
  • Host Route Predicate

Host Route Predicate接收一组参数,一组匹配的域名列表,这个模板是一个ant 分割的模板,用.号作为分割符。它通过参数中的主机地址作为匹配规则。

predicates:
    - Host=**.somehost.org,**.anotherhost.org
  • Method Route Predicate
predicates:
    - Method=GET
  • Path Route Predicate
  • Query Route Predicate

支持传入两个参数,一个是属性名,一个是属性值,属性值可以是正则表达式

http: //localhost:9527/payment/lb?username=1

predicates:
    - Query=username,\d+ # 要有参数名username并且值还要是整数才能路由
  • Remote Addr Route Predicate
  • Weight Route Predicate

7. Filter详解

7.1 Filter是什么

路由过滤器可用于修改进入的HTTP请求和返回的HTTP响应,路由过滤器只能指定路由进行使用。

Gateway内置了多种路由过滤器,它们都是由GatewayFilter的工厂类来产生。

7.2 Gateway的Filter

生命周期

  • pre

  • post

种类

  • GatewayFilter (31个)
  • GlobalFilter (10个)
7.3 常用的GatewayFilter
  • AddRequestParameter
spring:
  cloud:
    gateway:
      routes:
        - id: after_route
          uri: https://example.ort
          filters:
            # 过滤器工厂会在匹配的请求头加上一对请求头,名为X-Reqeust-Id,值为1024
            - AddRequestParameter=X-Reqeust-Id,1024 
          predicates:
            - After=2021-03-04T09:07:25.143+08:00[Asia/Shanghai]
  • ...
7.4 自定义过滤器

一般我们使用自定义过滤器

SpringCloud Gateway中自定义过滤器要是实现两个接口

org.springframework.cloud.gateway.filter.GlobalFilter
org.springframework.core.Ordered

前者实现了全局过滤器,而后者规定了过滤器的执行顺序,该顺序数字越小,过滤器越先被执行。

下面编写具体的过滤器并实现上面两个接口的方法:

@Component
@Slf4j
public class MyLogGateWayFilter implements GlobalFilter, Ordered {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        log.info("===> 全局过滤器:" + new Date());
        //获得uname属性
        String uname = exchange.getRequest().getQueryParams().getFirst("uname");
        //如果不包含该属性,则过滤器对请求进行拦截
        if (uname == null) {
            log.info("===> 用户名为null,非法用户");
            exchange.getResponse().setStatusCode(HttpStatus.NOT_ACCEPTABLE);
            return exchange.getResponse().setComplete();
        }
        return chain.filter(exchange);
    }

    /** 加载过滤器的顺序,数字越小优先级越高 */
    @Override
    public int getOrder() {
        return 3;
    }
}

我们对服务进行访问我们可以发现,当我们包含请求参数uname时,可以正常访问,如果不含该请求参数,则访问无法正常进行。

这里需要注意的是,在getOrder()方法中,为了保证过滤器可拓展,尽量不要用0/1 这种拓展性不够好的数字,用0/1会使该自定义过滤器几乎永远先被执行。

上一篇:代码分析平台CodeQL学习手记(十一)


下一篇:【asp.net core 系列】8 实战之 利用 EF Core 完成数据操作层的实现