一. 背景

在微服务架构中，1个系统会被拆分为了很多个服务，每个服务之间需要互相调用，互相配合来完成整体的业务功能，那么如此进行调用，它就会存在以下几个问题：

• 每个服务中维护调用服务的信息，交互错杂，维护困难；
• 每个服务需要进行身份认证，每个服务都需要进行独立认证；
• 在某些场景下存在跨域的问题；
• 服务之间耦合性较高，扩展及重构复杂；
• 容易受到网络请求策略影响，访问上会有一定的问题。

微服务网关就可以解决以上问题，介于客户端与服务器之间的中间层，所有的外部请求都会先经过微服务网关。客户端只需要与网关交互，简化了开发同时兼具以下几个特点：

1. 易于监控，记录每个服务的请求信息，记录日志；
2. 统一认证，认证通过后才可访问资源服务；
3. 限制并避免了应用直接交互带来的管理问题。

二. API网关

1. 概念

• API网关的观念其实和当前流行的SOA架构和微服务架构模式有关。在传统大型企业比较流行的SOA架构中，有一个企业服务总线（ESB）的概念，再ESB中融合了管理、注册、中介、编排、治理等功能，是一个访问高度频繁、功能高度集中的地方，因此常常也是性能瓶颈所在。而在微服务架构中，伴随着去中心化的理念，几乎没有EBS的的概念，分布式服务架构技术不再依赖于具体的服务中心容器技术（ ESB），而是将服务寻址和调用完全分开，这样就不需要通过容器作为服务代理，在运行期实现最高效的直连调用。
• 在微服务架构中，服务的粒度被进一步细分，各个业务服务可以被独立的设计、开发、测试、部署和管理。各个独立部署单元可以用不同的开发测试团队维护，可以使用不同的编程语言和技术平台进行设计，这就要求必须使用一种语言和平台无关的服务协议作为各个单元间的通讯方式。而REST API 由于其简单、高效、跨平台、易开发、易测试、易集成，成为了不二选择。此时如果都是采用客户端和服务器直连的话，那么此时系统就会出现大量的冗余代码和功能，维护起来工作量巨大，而且随着服务增多，出错性也大大的增加。因此一个类似综合前置的系统就产生了，这就是 API 网关（API Gateway）。API 网关作为分散在各个业务系统微服务的 API 聚合点和统一接入点，外部请求通过访问这个接入点，即可访问内部所有的 REST API 服务。

2. API网关定义

网关的角色是作为一个 API 架构，用来保护、增强和控制对于 API 服务的访问。

• API 网关是一个处于应用程序或服务（提供 REST API 接口服务）之前的系统，用来管理授权、访问控制和流量限制等，这样 REST API 接口服务就被 API 网关保护起来，对所有的调用者透明。因此，隐藏在 API 网关后面的业务系统就可以专注于创建和管理服务，而不用去处理这些策略性的基础设施。
• 通俗的说API网关中就是做一些通用的基础设施功能。类似AOP中的横切关注点概念，把业务系统中涉及的一些通用功能（日志分析、鉴权、路由等）抽取到API网关中统一管理。API 网关不是一个典型的业务系统， 而是一个为了让业务系统更专注与业务服务本身，给API服务提供更多附加能力的一个中间层。

3. API网关的四大职能

**请求接入：**作为所有 API 接口服务请求的接入点，管理所有的接入请求；

**业务聚合：**作为所有后端业务服务的聚合点，所有的业务服务都可以在这里被调用；

**中介策略：**实现安全、验证、路由、过滤、流控，缓存等策略，进行一些必要的中介处理；

**统一管理：**提供配置管理工具，对所有 API 服务的调用生命周期和相应的中介策略进行统一管理。

4. API网关分类

面对互联网复杂的业务系统，基本可以将API网关分成两类：流量网关和业务网关。

**流量网关：**跟具体的后端业务系统和服务完全无关的部分，比如安全策略、全局性流控策略、流量分发策略等。流量网关的功能跟 Web 应用防火墙（WAF）非常类似。WAF一般是基于 Nginx/OpenResty 的 ngx_lua 模块开发的 Web 应用防火墙。

**业务网关：**针对具体的后端业务系统，或者是服务和业务有一定关联性的部分，并且一般被直接部署在业务服务的前面。业务网关一般部署在流量网关之后，业务系统之前，比流量网关更靠近系统。我们大部分情况下说的 API 网关，狭义上指的是业务网关。并且如果系统的规模不大，我们也会将两者合二为一，使用一个网关来处理所有的工作

5. 开源API网关介绍

**Nginx+lua：**Open Resty、Kong、Orange、Abtesting gateway 等

**Java：**Zuul/Zuul2、Spring Cloud Gateway、Kaazing KWG、gravitee、Dromara soul 等

**Go：**Janus、fagongzi、Grpc-gateway

**Dotnet：**Ocelot

**NodeJS：**Express Gateway、Micro Gateway

6. 开源网关的选择

脱离场景谈性能，脱离业务谈架构，都是耍流氓。

• （1）Kong 的性能非常不错，非常适合做流量网关，并且对于 service、route、upstream、consumer、plugins 的抽象，也是自研网关值得借鉴的。对于复杂系统，不建议业务网关用 Kong，或者更明确的说是不建议在 Java 技术栈的系统深度定制 Kong 或 OpenResty，主要是工程性方面的考虑。毕竟维护lua脚本的工作量和成本不低。
• （2）pring Cloud Gateway/Zuul2 对于 Java 技术栈来说比较方便，可以依赖业务系统的一些 common jar。Lua 不方便，不光是语言的问题，更是复用基础设施的问题。另外，对于网关系统来说，性能不是差一个数量级，问题不大，多加 2 台机器就可以搞定。
• （3）目前来看 Zuul2 的坑还是比较多的，因此作为java技术栈，比较建议使用 Spring Cloud Gateway 作为基础骨架。

三. Spring Cloud Gateway

Spring Cloud Gateway 是 SpringCloud 的一个全新项目，基于 Spring5、SpringBoot2 和 Project Reactor 等技术开发的网关，它旨在提供一种简答有效的统一的 API路由管理方式。SpringCloud Gateway 作为 SpringCloud 生态系统中的网关，目标是代替 Zuul，在 SpringCloud 2.0 以上版本中，没有对新版本的 Zuul 2.0 以上的最新高性能版本进行集成，仍然还是使用的 Zuul 1.x 非 Reactor 模式的老版本，而为了提升网关的性能，SpringCloud Gateway 是基于 WebFlux 框架实现的，而 WebFlux 框架底层则使用了高性能的 Reactor 模式通信框架 Netty。SpringCloud Gateway 的目标提供统一的路由方式且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/指标和限流。

1. 文档地址

https://spring.io/projects/spring-cloud-gateway

2. 三个核心概念

• Route(路由)：路由是网关最基础的部分，路由信息由一个 ID、一个目的 URL、一组断言工厂和一组 Filter 组成。如果断言为真，则说明 请求 URL 和配置的路由匹配。

• 断言（predicates）：Java8 中的断言函数，SpringCloud Gateway 中的断言函数输入类型是 Spring 5.0 框架中的 ServerWebExchange。SpringCloud Gateway 中的断言函数允许开发者去定义匹配来自 HttpRequest 中的任何信息，比如请求头和参数等。

• 过滤器（Filter）：一个标准的 Spring WebFilter，SpringCloud Gateway 中的 Filter 分为两种类型，分别是 Gateway Filter 和 Global Filter。过滤器 Filter 可以对请求和响应进行处理

3. 工作流程

客户端向 SpringCloud Gateway 发出请求，然后在 Gateway Handler Mapping 中找到与请求相匹配的路由，将其发送到 Gateway Web Handler。Handler 再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前（“pre”）或之后（“post”）执行业务逻辑。Filter 在“pre”类型的过滤器中可以做参数校验、权限校验、流量监控、日志输出、协议转换等。在“post”类型的过滤器中可以做响应内容、响应头的修改，日志的输出，流量监控等。

4. 运行原理

4.1 路由原理

流程图如下：

GateWay接收请求的流程如图所示

1. Gateway Client 向 Spring Cloud Gateway 发送请求
2. 请求首先会被Netty的服务端HttpServerHandle处理
3. 然后被HttpWebHandlerAdapter 进行提取组装成网关上下文，组装ServerWebExchange类型的exchange对象；ServerWebExchange是一个HTTP请求-响应交互的契约。存放着重要的请求-响应属性、请求实例和响应实例，提供对HTTP请求和响应的访问，并公开额外的服务器端处理相关属性和特性，如请求属性等等，有点像 Context 的角色。
4. 接着网关的上下文会传递到 DispatcherHandler ，它负责将请求分发给 RoutePredicateHandlerMapping
RoutePredicateHandlerMapping 负责路由查找，并根据路由断言判断路由是否可用
如果过断言成功，由FilteringWebHandler 创建过滤器链并调用；
这个handler在Gateway启动时会将所有的 GlobalFilter 构建一个GatewayFilterAdapter(内部类)，而GatewayFilterAdapter对象仅持有GlobalFilter接口方法，GatewayFilterAdapter对象在转换成OrderedGatewayFilter后也持有了getOrder方法，根据getOrder方法的返回值顺序组成ArrayList。处理请求时会调用DefaultGatewayFilterChain 用来处理filter，DefaultGatewayFilterChain 类持有了filter链；整个过滤链都是在这个过滤器中进行的，过滤器的执行顺序由order决定。
通过特定于请求的 Fliter 链运行请求，Filter可以在发送代理请求之前（pre）和之后（post）运行逻辑
执行所有pre过滤器逻辑，然后进行代理请求；发出代理请求后，将运行post过滤器逻辑。
处理完毕之后将 Response 返回到 Gateway 客户端。

4.2 RouteLocator

一个Route主要包含以下几个属性：

Gateway主要通过接口RouteLocator接口来获取路由配置，RouteLocator代码如下：

public interface RouteLocator {

	Flux<Route> getRoutes();

}

在Gateway的源码中，RouteLocator的实现类主要有：RouteDefinitionRouteLocator、CompositeRouteLocator、CachingRouteLocator。它们之间的关系如下图所示：

RouteDefinitionLocator 提供RouteDefinition ，由 RouteDefinition 构造路由。可以存在多个RouteLocator ，这些实例提供的路由最终会由 CompositeRouteLocator 整合，再由 CachingRouteLocator 缓存。CachingRouteLocator 会把下层的 RouteLocator 返回的路由缓存起来，后续直接返回使用，同时监听RefreshRoutesEvent来定时刷新缓存的路由。

5. Predicate 断言

Spring Cloud Gateway将路由匹配作为Spring WebFlux HandlerMapping基础架构的一部分。
Spring Cloud Gateway包括许多内置的Route Predicate工厂。所有这些Predicate都与HTTP请求的不同属性匹配。多个Route Predicate工厂可以进行组合

Spring Cloud Gateway 创建 Route 对象时， 使用 RoutePredicateFactory 创建 Predicate 对象，Predicate 对象可以赋值给 Route。

所有这些 Predicate 都匹配HTTP请求的不同属性。多种 Predicate Factory 可以组合，并通过逻辑 and。

内置断言：

6. 过滤器 Filter

路由过滤器可用于修改进入的HTTP请求和返回的HTTP响应，路由过滤器只能指定路由进行使用。Spring Cloud Gateway 内置了多种路由过滤器，它们都由GatewayFilter的工厂类来产生。

6.1. 过滤器的生命周期

SpringCloud Gateway 的 Filter 的生命周期只有两个：“pre”和“post”。

PRE：这种过滤器在请求被路由之前调用。我们可以利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。
POST：这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的 HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等。

6.2 过滤器类型

SpringCloud Gateway 的 Filter 从作用范围可分为另外两种 GatewayFilter 和 GlobalFilter。

• GatewayFilter：应用到单个路由或者一个分组的路由上。
• GlobalFilter：应用到所有的路由上。

6.2.1 局部过滤器

局部过滤器（GatewayFilter），是针对单个路由的过滤器，可以对访问的 URL 过滤，进行切面处理。在 SpringCloud Gateway 中通过 GatewayFliter 的形式内置了很多不同类型的局部过滤器。这里简单将 SpringCloud Gateway 内置的所有过滤器工厂整理成了一张表格，虽然不是很详细，但能作为速览使用。如下：

xxxxxxxxxxxxxxxxxxxxxx

每一个过滤器工厂都对应一个实现类，并且这些类的名称必须以 GatewayFilterFactory 结尾，这是 SpringCloud Gateway 的一个约定，例如 AddRequestHeader 对应的实现类为 AddRequestHeaderGatewayFilterFactory。

6.2.3 全局过滤器

全局过滤器（GlobalFilter）作用于所有路由，SpringCloud Gateway 定义了 GlobalFilter 接口，用户可以自定义实现自己的 Global Filter。通过全局过滤器可以实现对权限的统一校验，安全性验证等功能，并且全局过滤器也是程序员使用比较多的过滤器。

SpringCloud Gateway 内部也是通过一系列的内置全局过滤器对整个路由转发进行处理，如下：