【SpringCloud 2021.0.0】12、路由网关Gateway之简介 (spring-boot 2.6.3)

参考自：

Spring cloud gateway 详解和配置使用

【尚学堂】SpringCloudGateway微服务网关组件完整版实战

感谢分享！

1、简介

1）网关是怎么演化来的

单体应用拆分成多个服务后，对外需要一个统一入口，解耦客户端与内部服务

2）网关的基本功能

网关核心功能是路由转发，因此不要有耗时操作在网关上处理，让请求快速转发到后端服务上
网关还能做统一的熔断、限流、认证、日志监控等

可以和服务注册中心完美的整合，如：Eureka、Consul、Nacos

3）关于Spring Cloud Gateway

在SpringCloud微服务体系中，有个很重要的组件就是网关，在1.x版本中都是采用的Zuul网关；但在2.x版本中，zuul的升级一直跳票，SpringCloud最后自己研发了一个网关替代Zuul，那就是SpringCloud Gateway

网上很多地方都说Zuul是阻塞的，Gateway是非阻塞的，这么说是不严谨的，准确的讲Zuul1.x是阻塞的，而在2.x的版本中，Zuul也是基于Netty，也是非阻塞的，如果一定要说性能，其实这个真没多大差距。

而官方出过一个测试项目，创建了一个benchmark的测试项目：spring-cloud-gateway-bench，其中对比了：

Spring Cloud Gateway
Zuul1.x
Linkerd

Proxy	Avg Latency	Avg Req/Sec/Thread
gateway	6.61ms	3.24k
linkered	7.62ms	2.82k
zuul	12.56ms	2.09k
none	2.09ms	11.77k

还有一点就是Gateway是基于 WebFlux 的。这里引出了WebFlux名词，那什么是WebFlux？

WebFlux 介绍

左侧是传统的基于Servlet的 Spring Web MVC 框架，传统的Web框架，比如说：struts2，springmvc 等都是基于 Servlet API 与 Servlet 容器基础之上运行的，在 Servlet3.1 之后才有了 异步非阻塞 的支持。
右侧是5.0版本新引入的基于 Reactive Streams 的Spring WebFlux框架，从上到下依次是 Router Functions，WebFlux，Reactive Streams 三个新组件。
Router Functions: 对标@Controller，@RequestMapping等标准的Spring MVC注解，提供一套函数式风格的API，用于创建Router，Handler和Filter。
WebFlux: 核心组件，协调上下游各个组件提供响应式编程支持。
Reactive Streams: 一种支持背压（Backpressure）的异步数据流处理标准，主流实现有RxJava和Reactor，Spring WebFlux默认集成的是Reactor
在Web容器的选择上，Spring WebFlux既支持像Tomcat，Jetty这样的的传统容器（前提是支持Servlet 3.1 Non-Blocking IO API），又支持像Netty，Undertow那样的异步容器。不管是何种容器，Spring WebFlux都会将其输入输出流适配成Flux<DataBuffer>格式，以便进行统一处理
值得一提的是，除了新的Router Functions接口，Spring WebFlux同时支持使用老的Spring MVC注解声明Reactive Controller。和传统的MVC Controller不同，Reactive Controller操作的是非阻塞的ServerHttpRequest和ServerHttpResponse，而不再是Spring MVC里的HttpServletRequest和HttpServletResponse。

根据官方的说法，webflux主要在如下两方面体现出独有的优势：

非阻塞式

其实在servlet3.1提供了非阻塞的API，WebFlux提供了一种比其更完美的解决方案。使用非阻塞的方式可以利用较小的线程或硬件资源来处理并发进而提高其可伸缩性

函数式编程端点

老生常谈的编程方式了，Spring5必须让你使用java8，那么函数式编程就是java8重要的特点之一，而WebFlux支持函数式编程来定义路由端点处理请求。

4）Spring Cloud Gateway 功能特征

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

上图中是核心的流程图，最主要的就是Route、Predicates 和 Filters 作用于特定路由。

Route：路由是网关的基本构件。它由ID、目标URI、谓词集合和过滤器集合定义。如果聚合谓词为真，则匹配路由。

Predicate：参照Java8的新特性Predicate。这允许开发人员匹配HTTP请求中的任何内容，比如头或参数。

Filter：可以在发送下游请求之前或之后修改请求和响应。

我们为什么选择Gateway？

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

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

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

Spring Cloud Gateway 工作原理

客户端向 Spring Cloud Gateway 发出请求。然后在 Gateway Handler Mapping 中找到与请求相匹配的路由，将其发送到 Gateway Web Handler。Handler 再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前（“pre”）或之后（“post”）执行业务逻辑。

Filter在“pre”类型的过滤器可以做参数校验、权限校验、流量监控、日志输出、协议转换等，

在“post”类型的过滤器中可以做响应内容、响应头的修改，日志的输出，流量监控等有着非常重要的作用。

核心逻辑就是 路由转发，执行过滤器链

在上面的处理过程中，有一个重要的点就是讲请求和路由进行匹配，这时候就需要用到predicate，它是决定了一个请求走哪一个路由。