为什么要有服务网关?
我们都知道在微服务架构中，系统会被拆分为很多个微服务。那么作为客户端要如何去调用这么多的微服务呢？难道要一个个的去调用吗？很显然这是不太实际的，我们需要有一个统一的接口与这些微服务打交道，这就是我们需要服务网关的原因。
我们已经知道，在微服务架构中，不同的微服务可以有不同的网络地址，各个微服务之间通过互相调用完成用户请求，客户端可能通过调用N个微服务的接口完成一个用户请求。比如：用户查看一个商品的信息，它可能包含商品基本信息、价格信息、评论信息、折扣信息、库存信息等等，而这些信息获取则来源于不同的微服务，诸如产品系统、价格系统、评论系统、促销系统、库存系统等等，那么要完成用户信息查看则需要调用多个微服务，这样会带来几个问题：
客户端多次请求不同的微服务，增加客户端代码或配置编写的复杂性
认证繁杂，访问每个服务都要进行一次认证
每个服务都通过http访问，导致http请求增加，效率不高拖慢系统性能
多个服务存在跨域请求问题，处理起来比较复杂
我们该如何解决这些问题呢？我们可以尝试想一下，不要让前端直接知道后台诸多微服务的存在，我们的系统本身就是从业务领域的层次上进行划分，形成多个微服务，这是后台的处理方式。对于前台而言，后台应该仍然类似于单体应用一样，一次请求即可，于是我们可以在客户端和服务端之间增加一个API网关，所有的外部请求先通过这个微服务网关。它只需跟网关进行交互，而由网关进行各个微服务的调用。
这样的话，我们就可以解决上面提到的问题，同时开发就可以得到相应的简化，还可以有如下优点：
减少客户端与微服务之间的调用次数，提高效率
便于监控，可在网关中监控数据，可以做统一切面任务处理
便于认证，只需要在网关进行认证即可，无需每个微服务都进行认证
降低客户端调用服务端的复杂度
这里可以联想到一个概念，面向对象设计中的门面模式，即对客户端隐藏细节，API网关也是类似的东西，只不过叫法不同而已。它是系统的入口，封装了应用程序的内部结构，为客户端提供统一服务，一些与业务本身功能无关的公共逻辑可以在这里实现，诸如认证、鉴权、监控、缓存、负载均衡、流量管控、路由转发等等。示意图
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 2.0之前的非Reactor模式的老版本。而为了提升网关的性能，SpringCloud Gateway是基于WebFlux框架实现的，而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。
总结一下，服务网关大概就是四个功能：统一接入、流量管控、协议适配、安全维护。而在目前的网关解决方案里，有Nginx+ Lua、Spring Cloud Zuul以及Spring Cloud Gateway等等。这里以Spring Cloud Gateway为例进行说明。
Spring Cloud Gateway 的目标，不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/指标，和限流。
提前声明：Spring Cloud Gateway 底层使用了高性能的通信框架Netty。
SpringCloud Gateway 特征
SpringCloud官方，对SpringCloud Gateway 特征介绍如下：
- 基于 Spring Framework 5，Project Reactor 和 Spring Boot 2.0
- 集成 Hystrix 断路器
- 集成 Spring Cloud DiscoveryClient
- Predicates 和 Filters 作用于特定路由，易于编写的 Predicates 和 Filters
- 具备一些网关的高级功能：动态路由、限流、路径重写
从以上的特征来说，和Zuul的特征差别不大，SpringCloud Gateway和Zuul主要的区别，还是在底层的通信框架上。
简单说明一下上文中的三个术语：
Filter（过滤器）：
和Zuul的过滤器在概念上类似，可以使用它拦截和修改请求，并且对上游的响应，进行二次处理。
过滤器为org.springframework.cloud.gateway.filter.GatewayFilter类的实例。
Route（路由）：
网关配置的基本组成模块，和Zuul的路由配置模块类似。
一个Route模块由一个 ID，一个目标 URI，一组断言和一组过滤器定义。如果断言为真，则路由匹配，目标URI会被访问。
Predicate（断言）：
一个 Java 8 的 Predicate，可以使用它来匹配来自 HTTP 请求的任何内容，例如 headers 或参数。断言的输入类型是一个 ServerWebExchange。
SpringCloud Gateway的核心架构
迎来了Webflux，Webflux的出现填补了Spring在响应式编程上的空白，Webflux的响应式编程不仅仅是编程风格的改变，而且对于一系列的著名框架，都提供了响应式访问的开发包，比如Netty、Redis等等。
SpringCloud Gateway 使用的Webflux中的reactor-netty响应式编程组件，底层使用了Netty通讯框架。
SpringCloud Zuul的核心架构
SpringCloud Zuul的IO模型
Springcloud中所集成的Zuul版本，采用的是Tomcat容器，使用的是传统的Servlet IO处理模型。
servlet由servlet container进行生命周期管理。
container启动时构造servlet对象并调用servlet init()进行初始化；
container关闭时调用servlet destory()销毁servlet；
container运行时接受请求，并为每个请求分配一个线程（一般从线程池中获取空闲线程）然后调用service()。
Servlet的IO模型
servlet是一个简单的网络IO模型，当请求进入servlet container时，servlet container就会为其绑定一个线程，在并发不高的场景下这种模型是适用的，但是一旦并发上升，线程数量就会上涨，而线程资源代价是昂贵的（上线文切换，内存消耗大）严重影响请求的处理时间。
在一些简单的业务场景下，不希望为每个request分配一个线程，只需要1个或几个线程就能应对极大并发的请求，这种业务场景下servlet模型没有优势。
Springcloud Zuul 是基于servlet之上的一个阻塞式处理模型，即spring实现了处理所有request请求的一个servlet（DispatcherServlet），并由该servlet阻塞式处理处理。
Springcloud Zuul无法摆脱servlet模型的弊端，虽然Zuul 2.0开始，使用了Netty，并且已经有了大规模Zuul 2.0集群部署的成熟案例，但是，Springcloud官方已经没有集成改版本的计划了。
Webflux 服务器
Webflux模式替换了旧的Servlet线程模型，用少量的线程处理request和response io操作，这些线程称为Loop线程，而业务交给响应式编程框架处理，响应式编程是非常灵活的，用户可以将业务中阻塞的操作提交到响应式框架的work线程中执行，而不阻塞的操作依然可以在Loop线程中进行处理，大大提高了Loop线程的利用率。官方结构图：
Webflux虽然可以兼容多个底层的通信框架，但是一般情况下，底层使用的还是Netty，Netty是目前业界认可的最高性能的通信框架。
而Webflux的Loop线程，正好就是著名的Reactor 模式IO处理模型的Reactor线程，如果使用的是高性能的通信框架Netty，这就是Netty的EventLoop线程。
Spring Cloud Gateway的处理流程
- GatewayClassPathWarningAutoConfiguration 作用检查是否配置我们webflux依赖。
- GatewayAutoConfiguration 加载了我们Gateway需要注入的类。
- GatewayLoadBalancerClientAutoConfiguration 网关需要使用的负载均衡，Lb//jarye-member// 根据服务名称查找真实地址
- GatewayRedisAutoConfiguration 网关整合Redis整合Lua实现限流
- GatewayDiscoveryClientAutoConfiguration 服务注册与发现功能
- 客户端向网关发送Http请求，会到达DispatcherHandler接受请求，匹配到RoutePredicateHandlerMapping。
- 根据RoutePredicateHandlerMapping匹配到具体的路由策略。
- FilteringWebHandler获取的路由的GatewayFilter数组，创建GatewayFilterChain处理过滤请求
- 执行我们的代理业务逻辑访问。
Spring Cloud Gateway的源码流程
过滤器默认有8种，采用责任链模式关联着：
