【SpringCloud技术专题】「Gateway网关系列」（1）微服务网关服务的Gateway组件的原理介绍分析-编程知识

为什么要有服务网关?

我们都知道在微服务架构中，系统会被拆分为很多个微服务。那么作为客户端要如何去调用这么多的微服务呢？难道要一个个的去调用吗？很显然这是不太实际的，我们需要有一个统一的接口与这些微服务打交道，这就是我们需要服务网关的原因。

我们已经知道，在微服务架构中，不同的微服务可以有不同的网络地址，各个微服务之间通过互相调用完成用户请求，客户端可能通过调用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 服务注册与发现功能