SpringCould（四）服务网关GateWay

SpringCould（四）服务网关GateWay

文章目录

• • 服务网关GateWay
  • • 和Zuul的对比：
    • • Zuul模型
      • GateWay模型：
    • GateWay工作流程
    • GateWay搭建
    • • 入门配置
      • 实现动态路由
      • GateWay常用的Predicate
      • GateWay的Filter

Spring Could主要内容结构图：

---

---

服务网关GateWay

SpringCloud Gateway是什么

Cloud全家桶中有个很重要的组件就是网关，在1.x版本中都是采用的Zuul网关。但在2.x版本中，zuul的升级一直跳票，SpringCloud最后自己研发了一个网关替代Zuul,那就是SpringCloud Gateway
一句话: gateway是原zuul1.x版的替代

Gateway是在Spring生态系统之上构建的API网关服务，基于Spring 5，Spring Boot2和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以上版本中，没有对新版本的Zuul 2.0O以上最新高性能版本进行集成，仍然还是使用的Zuul 1.x非Reactor模式的老版本。而为了提升网关的性能，SpringCcloud Gateway是基于WebFlux框架实现的，而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty.

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

微服务框架中网关所在的位置：

Spring Cloud Gateway具有如下特性:

• 基于Spring framework 5, Project Reactor和Spring Boot 2.0进行构建;
• 动态路由:能够匹配任何请求属性;
• 可以对路由指定Predicate(断言）和 Filter (过滤器）;
• 集成Hystrix的断路器功能;
• 集成Spring Cloud服务发现功能;
• 易于编写的 Predicate (断言)和Filter (过滤器);
• 请求限流功能;l
• 支持路径重写。

和Zuul的对比： Zuul模型

Springcloud中所集成的Zuul版本，采用的是Tomcat容器，使用的是传统的Servlet lO处理模型。
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模型：

GateWay是基于WebFlux

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

传统的Web框架，比如说: struts2，springmvc等都是基于Servlet API与Servlet容器基础之上运行的。

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

GateWay工作流程

相关概念：

• Route(路由)
  路由是构建网关的基本模块，它由ID，目标URI，一系列的断言和过滤器组成，如果断言为true则匹配该路由

• Predicate(断言)
  开发人员可以匹配HTTP请求中的所有内容(例如请求头或请求参数)，如果请求与断言相匹配则进行路由
  参考的是Java8的java.util.function.Predicate

• Filter(过滤)
  指的是Spring框架中GatewayFilter的实例，使用过滤器，可以在请求被路由前或者之后对请求进行修改。

predicate就是我们的匹配条件;
web请求，通过一些匹配条件，定位到真正的服务节点。并在这个转发过程的前后，进行一些精细化控制。
而filter，就可以理解为一个无所不能的拦截器。有了这两个元素，再加上目标uri，就可以实现一个具体的路由了

流程的核心逻辑：路由转发+执行过滤器链

客户端向Spring Cloud Gateway发出请求。然后在Gateway Handler Mapping 中找到与请求相匹配的路由，将其发送到Gateway Web Handler。

Handler再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。
过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前(“pre”）或之后(“post”)执行业务逻辑。

Filter在“pre”类型的过滤器可以做参数校验、权限秘验、流量监控、日志输出、协议转换等，
在“post”类型的过滤器中可以做响应内容、响应头的修改，日志的输出，流量监控等有着非常重要的作用。

GateWay搭建 入门配置

pom文件

    
        
        
            org.springframework.cloud
            spring-cloud-starter-gateway
        
        
        
            org.springframework.cloud
            spring-cloud-starter-netflix-eureka-client
        
        
        
            com.atguigu.springcloud
            cloud-api-commons
            ${project.version}
        
        
        
        
        
        
        
        
            org.projectlombok
            lombok
            true
        
        
            org.springframework.boot
            spring-boot-starter-test
            test
        
    

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
    @Override
    public int getOrder() {
        return 0;
    }
}