前言
我们要了解一个事物，从三个维度去了解就行了；是什么、做什么、为什么。
是什么
在SpringCloud微服务体系中，有个很重要的组件就是网关，在1.x版本中都是采用的Zuul网关；但在2.x版本中，zuul的升级一直跳票，SpringCloud最后自己研发了一个网关替代Zuul，那就是SpringCloud Gateway。
还有一点就是Gateway是基于WebFlux的。这里引出了WebFlux名词，那什么是WebFlux？
WebFlux
我们知道传统的Web框架，比如说：struts2，springmvc等都是基于Servlet API与Servlet容器基础之上运行的，在Servlet3.1之后才有了异步非阻塞的支持。
而WebFlux是一个典型非阻塞异步的框架，它的核心是基于Reactor的相关API实现的。相对于传统的web框架来说，它可以运行在诸如Netty，Undertow及支持Servlet3.1的容器上。
根据官方的说法，webflux主要在如下两方面体现出独有的优势：
1）非阻塞式
其实在servlet3.1提供了非阻塞的API，WebFlux提供了一种比其更完美的解决方案。使用非阻塞的方式可以利用较小的线程或硬件资源来处理并发进而提高其可伸缩性
2) 函数式编程端点
老生常谈的编程方式了，Spring5必须让你使用java8，那么函数式编程就是java8重要的特点之一，而WebFlux支持函数式编程来定义路由端点处理请求。
做什么
网关可以理解为网络关卡，是整个微服务的统一入口（门卫）。
可以和服务注册中心完美的整合，如：Eureka、Consol、Nacos
Spring Cloud Gateway 功能特征
- 基于 Spring Framework 5，Project Reactor 和 Spring Boot 2.0
- 动态路由
- Predicates 和 Filters 作用于特定路由
- 集成 Hystrix 断路器
- 集成 Spring Cloud DiscoveryClient
- 易于编写的 Predicates 和 Filters
- 限流
- 路径重写
上图中是核心的流程图，最主要的就是Route、Predicates 和 Filters 作用于特定路由。
1）Route：路由是网关的基本构件。它由ID、目标URI、谓词集合和过滤器集合定义。如果聚合谓词为真，则匹配路由。
2）Predicate：参照Java8的新特性Predicate。这允许开发人员匹配HTTP请求中的任何内容，比如头或参数。
**3）Filter：**可以在发送下游请求之前或之后修改请求和响应。
Spring Cloud Gateway 工作原理
客户端向 Spring Cloud Gateway 发出请求。然后在 Gateway Handler Mapping 中找到与请求相匹配的路由，将其发送到 Gateway Web Handler。Handler 再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前（“pre”）或之后（“post”）执行业务逻辑。
Filter在**“pre”类型的过滤器可以做参数校验、权限校验、流量监控、日志输出、协议转换等，在“post”类型的过滤器中可以做响应内容、响应头的修改，日志的输出，流量监控**等有着非常重要的作用。
核心逻辑就是路由转发，执行过滤器链。
为什么
我们为什么选择Gateway？
一方面因为Zuul已经进入了维护阶段，而且Gateway是SpringCloud团队研发的，是亲儿子产品，值得信赖。而且很多功能Zuul都没有；用起来也非常的简单便捷。
Gateway是基于异步非阻塞模型上进行开发的，性能方面不需要担心。虽然Netflix 早就发布了最新的 Zuul 2.x，但 Spring Cloud 貌似没有整合计划。而且Netflix相关组件都宣布进入维护期；不知前景如何？
多方面综合考虑Gateway是很理想的网关选择。
