SpringCloud(5) 服务网关
2023-08-09 14:53:19 # Backend # SpringCloud

服务网关

1 Zuul

Zuul开发人员窝里斗,实属明日黄花

重点关注Gateway

2 Gateway

2.1 Gateway是什么

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

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

SpringCloud Gateway是Spring Cloud的一个全新项目,基于Spring 5.0+Spring Boot 2.0和Project Reactor等技术开发的网关,它旨在为微服务架构提供—种简单有效的统一的API路由管理方式。

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

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

  • 作用
    • 反向代理
    • 鉴权
    • 流量控制
    • 熔断
    • 日志监控

微服务架构中网关的位置

image-20220730160741357

2.2 Gateway非阻塞异步模型

  • SpringCloud Gateway具有如下特性
    • 基于Spring Framework 5,Project Reactor和Spring Boot 2.0进行构建;
    • 动态路由: 能够匹配任何请求属性;
    • 可以对路由指定Predicate (断言)和Filter(过滤器);
    • 集成Hystrix的断路器功能;
    • 集成Spring Cloud 服务发现功能;
    • 易于编写的Predicate (断言)和Filter (过滤器);
    • 请求限流功能;
    • 支持路径重写。
  • SpringCloud Gateway与Zuul的区别
    • 在SpringCloud Finchley正式版之前,Spring Cloud推荐的网关是Netflix提供的Zuul。
    • Zuul 1.x,是一个基于阻塞I/O的API Gateway。
    • Zuul 1.x基于Servlet 2.5使用阻塞架构它不支持任何长连接(如WebSocket),Zuul的设计模式和Nginx较像,每次I/О操作都是从工作线程中选择一个执行,请求线程被阻塞到工作线程完成,但是差别是Nginx用C++实现,Zuul用Java实现,而JVM本身会有第一次加载较慢的情况,使得Zuul的性能相对较差。
    • Zuul 2.x理念更先进,想基于Netty非阻塞和支持长连接,但SpringCloud目前还没有整合。Zuul .x的性能较Zuul 1.x有较大提升。在性能方面,根据官方提供的基准测试,Spring Cloud Gateway的RPS(每秒请求数)是Zuul的1.6倍。
    • Spring Cloud Gateway建立在Spring Framework 5、Project Reactor和Spring Boot2之上,使用非阻塞API。
    • Spring Cloud Gateway还支持WebSocket,并且与Spring紧密集成拥有更好的开发体验
  • Zuul1.x模型
    • Springcloud中所集成的Zuul版本,采用的是Tomcat容器,使用的是传统的Serviet IO处理模型。
    • 上述模式的缺点:
      • Servlet是一个简单的网络IO模型,当请求进入Servlet container时,Servlet container就会为其绑定一个线程,在并发不高的场景下这种模型是适用的。但是一旦高并发(如抽风用Jmeter压),线程数量就会上涨,而线程资源代价是昂贵的(上线文切换,内存消耗大)严重影响请求的处理时间。在一些简单业务场景下,不希望为每个request分配一个线程,只需要1个或几个线程就能应对极大并发的请求,这种业务场景下servlet模型没有优势。
      • 所以Zuul 1.X是基于servlet之上的一个阻塞式处理模型,即Spring实现了处理所有request请求的一个servlet (DispatcherServlet),并由该servlet阻塞式处理请求。所以SpringCloud Zuul无法摆脱servlet模型的弊端。
  • Gateway模型
    • 传统的Web框架,比如说: Struts2,SpringMVC等都是基于Servlet APl与Servlet容器基础之上运行的。
    • 但是在Servlet3.1之后有了异步非阻塞的支持。而WebFlux是一个典型非阻塞异步的框架,它的核心是基于Reactor的相关API实现的。相对于传统的web框架来说,它可以运行在诸如Netty,Undertow及支持Servlet3.1的容器上。非阻塞式+函数式编程(Spring 5必须让你使用Java 8)。
    • Spring WebFlux是Spring 5.0 引入的新的响应式框架,区别于Spring MVC,它不需要依赖Servlet APl,它是完全异步非阻塞的,并且基于Reactor来实现响应式流规范。

2.3 Gateway工作流程

  • 三大核心概念
    • Route(路由) - 路由是构建网关的基本模块,它由ID,目标URI,一系列的断言和过滤器组成,如断言为true则匹配该路由
    • Predicate(断言) - 参考的是Java8的java.util.function.Predicate,开发人员可以匹配HTTP请求中的所有内容(例如请求头或请求参数),如果请求与断言相匹配则进行路由
    • Filter(过滤) - 指的是Spring框架中GatewayFilter的实例,使用过滤器,可以在请求被路由前或者之后对请求进行修改。

image-20220730164442245

  • web请求,通过一些匹配条件,定位到真正的服务节点。并在这个转发过程的前后,进行一些精细化控制。

  • predicate就是我们的匹配条件;而fliter,就可以理解为一个无所不能的拦截器。有了这两个元素,再加上目标uri,就可以实现一个具体的路由了

  • Gateway工作流程

    image-20220730164513367

    • 客户端向Spring Cloud Gateway发出请求。然后在Gateway Handler Mapping 中找到与请求相匹配的路由,将其发送到GatewayWeb Handler。
    • Handler再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑,然后返回。
    • 过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前(“pre”)或之后(“post”)执行业务逻辑。
    • Filter在“pre”类型的过滤器可以做参数校验、权限校验、流量监控、日志输出、协议转换等,在“post”类型的过滤器中可以做响应内容、响应头的修改,日志的输出,流量监控等有着非常重要的作用。
  • 核心逻辑: 路由转发 + 执行过滤器链。

2.4 Gateway9527搭建

  1. 新建Module cloud08-gateway-gateway9527

  2. POM: 添加gateway,删除web

    <?xml version="1.0" encoding="UTF-8"?>
    <project xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <parent>
    <artifactId>LearnCloud</artifactId>
    <groupId>com.lun.springcloud</groupId>
    <version>1.0.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>

    <artifactId>cloud-gateway-gateway9527</artifactId>

    <dependencies>
    <!--gateway-->
    <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
    </dependency>
    <!--eureka-client-->
    <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
    </dependency>
    <!-- 引入自己定义的api通用包,可以使用Payment支付Entity -->
    <dependency>
    <groupId>com.lun.springcloud</groupId>
    <artifactId>cloud-api-commons</artifactId>
    <version>${project.version}</version>
    </dependency>
    <!--一般基础配置类-->
    <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-devtools</artifactId>
    <scope>runtime</scope>
    <optional>true</optional>
    </dependency>
    <dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <optional>true</optional>
    </dependency>
    <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <scope>test</scope>
    </dependency>
    </dependencies>

    </project>
  3. YML

    server:
    port: 9527

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

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

    eureka:
    instance:
    hostname: cloud-gateway-service
    client: #服务提供者provider注册进eureka服务列表内
    register-with-eureka: true
    fetch-registry: true
    service-url:
    defaultZone: http://eureka7001.com:7001/eureka
  4. 主启动类

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

2.5 Gateway配置路由的两种方式

  • 在配置文件yml中配置,见上一章节
  • 代码中注入RouteLocator的Bean

2.6 GateWay配置动态路由

默认情况下Gateway会根据注册中心注册的服务列表,以注册中心上微服务名为路径创建动态路由进行转发,从而实现动态路由的功能(不写死一个地址)。

  • 启动eureka7001,payment8001/8002

  • YAML

    • 需要注意的是uri的协议为lb,表示启用Gateway的负载均衡功能。
    • lb://serviceName是spring cloud gateway在微服务中自动为我们创建的负载均衡uri。
    cloud:
    gateway:
    discovery:
    locator:
    enabled: true #开启从注册中心动态创建路由的功能,利用微服务名进行路由
    routes:
    - id: payment_routh #payment_route #路由的ID,没有固定规则但要求唯一,建议配合服务名
    #uri: http://localhost:8001 #匹配后提供服务的路由地址
    uri: lb://cloud-payment-service #匹配后提供服务的路由地址
    predicates:
    - Path=/payment/get/** # 断言,路径相匹配的进行路由

    - id: payment_routh2 #payment_route #路由的ID,没有固定规则但要求唯一,建议配合服务名
    #uri: http://localhost:8001 #匹配后提供服务的路由地址
    uri: lb://cloud-payment-service #匹配后提供服务的路由地址
    predicates:
    - Path=/payment/lb/** # 断言,路径相匹配的进行路由
  • 测试

2.7 GateWay常用的Predicate