官方地址 ： https://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.2.2.RELEASE/reference/html/
简介
Cloud 全家桶中很重要的一个组件就是网关，在 1.x 版本中都是采用 Zuul 网关，
但是在 2.x 版本中，zuul 升级一种跳票，SpringCloud 最后自己研发了一个网关替代Zuul, 那就是 SpringCloud GateWay 换句话说 gateway 就是原 zuul 1.x 版本的替代方案
SpringCloud GateWay 是 Spring Cloud 的一个全新的项目， 基于 Spring 5.0 + Spring Boot 2.0 和 Project Reactor 等技术开发的网关，它旨在为微服务架构通过一种简单有效的统一的API 路由管理方式
Spring Cloud GateWay 作为 Spring Cloud 生态系统的网关， 目标是替代 Zuul ， 在Spring Cloud2.0 以上版本种，没有对新版本的 Zuul 2.0 以上版本最高性能版本进行集成，仍然还是使用的 Zuul 1.x 非 Reactor 模式的老版本，为了提升网关性能， Spring Cloud GateWay 基于 WebFlux 框架实现的，而WebFlux 框架底层则使用了高性能的Reactor 模式通讯框架 Netty
Spring Cloud GateWay 的目标是提供统一的路由方式且基于Filter 链的方式提供网关的基本功能，例如：安全，监控/指标 和 限流。
网关在架构中的位置
网关是在微服务访问的入口，对外是负载均衡 Nginx
zuul 和 gateway
1、为什选择 gateway
- netflix 不靠谱，zuul2.0 一直跳票，迟迟不发布
-
一方面zuul 1.0 已经进入了维护阶段，而且GateWay 是spring cloud 团队研发的，值得信赖。 而且很多功能Zuul 都没用起来也非常的简单便捷。
-
GateWay 是基于异步非阻塞模型上进行开发的， 性能方面都不需要担心，虽然 Netflix
早就发布去了最新的 Zuul 2.x 但是 Spring Cloud 没有整合计划。 而且Netflix 相关组件都宣布进行维护期；不知前景如何？ -
多方考虑Gateway 是很理想的网关选择
-
- springcloud gateway 具有如下特征
- 基于 Spring Framework5 . 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/0的 API Gateway - Zuul 1.x 基于 Servlet 2.5 使用阻塞架构他不支持任何常链接（如 WebSocket ） Zuul 的涉及模式和 Niginx 很像， 每次 I / 0 操作都是从工作线程种选择一个执行，请求线程被阻塞到工作线程完成，但是差别是 Nginx 使用的是 C++ 实现，Zuul 使用的是Java 实现，而JVM 本身会有第一次加载比较慢的情况，使得 Zuul 的性能相对较差
- Zuul2.x 理想更为陷阱，想基于Netty 非阻塞和支持常谅解， 但是 SpringCloud 目前没有整合。 Zuul2.x 的性能较 Zuul1.x 有较大的提升。在性能方面，根据官方提供的基准测试， Spring Cloud Gateway 的 RPS（每秒请求数）是Zuul 的 1.6 倍
- Spring Cloud Gateway 建立在
Spring Framework5、 Project Reactor 和Spring Boot 2之上，使用非阻塞 API。 - Spring Cloud Gateway 还支持
websocket， 并且与 Spring 紧密集成拥有更好的开发体验。
2、zuul1.0 模型
Springcloud 中集成的Zuul 版本， 采用的是 Tomcat 容器，使用的是 传统的 Servlet IO 处理模型。
servlet 由 servlet container 进行生命周期管理。
- container 启动时，构造 servlet 对象并调用 servlet init（） 进行初始化；
- container 运行时接受请求，并为每一个请求分配一个线程（一般从线程池中获取空闲线程，）然后调用service（）
- container 关闭时调用 servlet destory ()销毁 servlet
上述模型的缺点：
servlet 是一个简单的网络 I/O 模型，当前请求进入servlet container 时，servlet container 就会为其绑定一个线程， 在并发不高的场景下，这种模型适用的。但是一旦在高并发（比如用jmeter压测）， 线程数量就会上涨， 而线程资源代价时昂贵的（上下文切换，内存消耗大）严重影响请求的处理时间。在一些简单业务场景下， 不希望为每个 request分配一个线程，只需要1个或这几个线程就能应对极大的并发请求。这种场景下servlet 模型没有优势。
所以 zuul1.x 时基于 servelt 开发的一个阻塞式处理模型，即 spring 实现了， 处理并发request 请求的 servlet （DispatcherServlet ） 并由该 servlet 阻塞式处理。所以 ，springcloud zuul 无法摆脱 servlet 模型的弊端。
3、gateway 模型
传统 Web 框架， 比如说： struts2 , spring mvc 等都是基于 Servlet API 与 Servlet 容器之上运行的。
- 在Servlet3.1 之后有了异步非阻塞的支持。 而WebFlux 是一个典型的非阻塞的异步的框架，它的核心是基于 Reactor 的相关 API 实现的 ， 相对于传统的Web 框架来说，他可以运行在诸如 Netty ，Undertow 支持 Servlet 3.1 的容器上。 非阻塞+ 函数式编程 （Spring 5 必须让你使用 java8）
- Spring WebFlux 是Spring 5.0 引入的新的响应式框架，区别于 Spring MVC， 它不需要依赖 Servlet API， 它完全是异步非阻塞的， 并且基于 Reactor 来实现响应式流规范。
三大核心概念
Route(路由)
构建网关的基本模块，由id，目标URL，一系列的的断言和过滤组成，如果断言为true则匹配该路由
Predicate(断言)
参考 Java8 的 java.util.funcation.Predicate 开发人员可以指定HTTP 请求中的所有内容（例如请求头或请求参数），如果请求与断言适配类则进行路由
Filter(过滤)
spring框架中GatewayFilter实例，使用过滤器，可以在请求被路由前或后对请求进行修改
