SpringCloud Gateway基础入门与使用实践总结

官网文档：点击查看官网文档

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

【1】Gateway简介

① SpringCloud Gateway 是什么

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.0以上最新高性能版本进行集成，仍然还是使用的Zuul 1.x非Reactor模式的老版本。而为了提升网关的性能，SpringCloud Gateway是基于WebFlux框架实现的，而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。

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

SpringCloud Gateway 使用的Webflux中的reactor-netty响应式编程组件，底层使用了Netty通讯框架。

② 为什么选择SpringCloud Gateway

一方面因为Zuul1.0已经进入了维护阶段，而且Gateway是SpringCloud团队研发的，是亲儿子产品，值得信赖。而且很多功能Zuul都没有用起来也非常的简单便捷。

Gateway是基于异步非阻塞模型上进行开发的，性能方面不需要担心。虽然Netflix早就发布了最新的 Zuul 2.x，但 Spring Cloud 貌似没有整合计划。而且Netflix相关组件都宣布进入维护期，不知前景如何。

多方面综合考虑Gateway是很理想的网关选择。

Spring Cloud Gateway 具有如下特性：

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

③ Spring Cloud Gateway 与 Zuul的区别

在SpringCloud Finchley 正式版之前，Spring Cloud 推荐的网关是 Netflix 提供的Zuul：

1、Zuul 1.x，是一个基于阻塞 I/ O 的 API Gateway

2、Zuul 1.x 基于Servlet 2. 5使用阻塞架构它不支持任何长连接(如 WebSocket) 。Zuul 的设计模式和Nginx较像，每次 I/ O 操作都是从工作线程中选择一个执行，请求线程被阻塞到工作线程完成，但是差别是Nginx 用C++ 实现，Zuul 用 Java 实现，而 JVM 本身会有第一次加载较慢的情况，使得Zuul 的性能相对较差。

3、Zuul 2.x理念更先进，想基于Netty非阻塞和支持长连接，但SpringCloud目前还没有整合。 Zuul 2.x的性能较 Zuul 1.x 有较大提升。在性能方面，根据官方提供的基准测试， Spring Cloud Gateway 的 RPS（每秒请求数）是Zuul 的 1. 6 倍。

4、Spring Cloud Gateway 建立 在 Spring Framework 5、 Project Reactor 和 Spring Boot 2 之上， 使用非阻塞 API。

传统的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 来实现响应式流规范。

5、Spring Cloud Gateway 还 支持 WebSocket， 并且与Spring紧密集成拥有更好的开发体验。

④ Spring Cloud Gateway的核心概念

① Route(路由)

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

② Predicate(断言)

参考的是Java8的java.util.function.Predicate。

开发人员可以匹配HTTP请求中的所有内容(例如请求头或请求参数)，如果请求与断言相匹配则进行路由。

③ Filter(过滤)

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

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

• predicate就是我们的匹配条件；
• 而filter，就可以理解为一个无所不能的拦截器。

有了这两个元素，再加上目标uri，就可以实现一个具体的路由了

【2】Gateway工作流程

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

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

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

【3】实践实例

① IP端口路由

pom文件引入依赖

<!--gateway-->
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-gateway</artifactId>
</dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-eureka-client</artifactId></dependency>

yml配置：

server:port: 9527
eureka:instance:hostname: cloud-gateway-serviceclient:service-url:register-with-eureka:  truefetch-registry:  truedefaultZone: http://eureka7001.com:7001/eureka  
spring:application:name: cloud-gatewaycloud: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/**         # 断言，路径相匹配的进行路由

主启动类：

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

这样就可以实现访问http://localhost:9527/payment/get/31 请求会路由到http://localhost:8001 ，也就是 http://localhost:8001/payment/get/31

这里可以看到uri直接使用了IP和端口，其实这是不太合适的。在微服务体系中，我们推荐使用服务实例名称进行路由。

② 服务实例路由

修改yml文件如下所示：

server:port: 9527
spring:application:name: cloud-gatewaycloud:gateway:discovery:locator:enabled: true # 开启从服务在注册中心动态创建路由的功能routes: # 可以配置多个路由- id: payment_routh # 路由id，没有固定规则但要求唯一
#          uri:  http://localhost:8001 # 匹配后提供服务的路由地址uri:  lb://cloud-payment-servicepredicates:- Path=/payment/get/** # 路径相匹配的进行路由- After=2020-05-26T17:07:03.043+08:00[Asia/Shanghai]
#            - Cookie=username,wxh- id: payment_routh2 # 路由id，没有
#          uri:  http://localhost:8001 # 匹配后提供服务的路由地址uri:  lb://cloud-payment-servicepredicates:- Path=/payment/create # 路径相匹配的进行路由eureka:instance:hostname: cloud-gateway-serviceclient:service-url:register-with-eureka:  truefetch-registry:  truedefaultZone: http://eureka7001.com:7001/eureka

默认情况下Gateway会根据注册中心注册的服务列表，以注册中心上微服务名为路径创建动态路由进行转发，从而实现动态路由的功能。

需要注意的是uri的协议为lb，表示启用Gateway的负载均衡功能。lb://serviceName是spring cloud gateway在微服务中自动为我们创建的负载均衡uri

【4】编码注册路由

上面是通过配置方式注册的路由，gateway同样支持通过编码方式注册路由。

@Configuration
public class GateWayConfig {@Beanpublic RouteLocator routeLocator(RouteLocatorBuilder routeLocatorBuilder){RouteLocatorBuilder.Builder  routes = routeLocatorBuilder.routes();/** 代表访问http://localhost:9527/guonei* 跳转到http://news.baidu.com/guonei* */routes.route("route1",r->r.path("/guonei").uri("http://news.baidu.com/guonei")).build();return routes.build();}
}