玩转微服务-GateWay
一. 背景在微服务架构中，1个系统会被拆分为了很多个服务，每个服务之间需要相互调用，相互共同来完成整体的业务功能，那么如此举行调用，它就会存在以下几个题目：
[*]每个服务中维护调用服务的信息，交互庞杂，维护困难；
[*]每个服务需要举行身份认证，每个服务都需要举行独立认证；
[*]在某些场景下存在跨域的题目；
[*]服务之间耦合性较高，扩展及重构复杂；
[*]轻易受到网络哀求计谋影响，访问上会有一定的题目。
微服务网关就可以解决以上题目，介于客户端与服务器之间的中间层，所有的外部哀求都会先经过微服务网关。客户端只需要与网关交互，简化了开辟同时兼具以下几个特点：
[*]易于监控，记录每个服务的哀求信息，记录日志；
[*]统一认证，认证通事后才可访问资源服务；
[*]限定并避免了应用直接交互带来的管理题目。
二. 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网关分类
https://img-blog.csdnimg.cn/direct/8114a0211dcc4d8b82ffa666a4d8a800.png
面临互联网复杂的业务系统，基本可以将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. 工作流程
https://img-blog.csdnimg.cn/direct/213009faab944fb6897962fd55406944.png
客户端向 SpringCloud Gateway 发出哀求，然后在 Gateway Handler Mapping 中找到与哀求相匹配的路由，将其发送到 Gateway Web Handler。Handler 再通过指定的过滤器链来将哀求发送到我们现实的服务实行业务逻辑，然后返回。过滤器之间用虚线分开是因为过滤器可能会在发送代理哀求之前（“pre”）或之后（“post”）实行业务逻辑。Filter 在“pre”范例的过滤器中可以做参数校验、权限校验、流量监控、日志输出、协议转换等。在“post”范例的过滤器中可以做响应内容、响应头的修改，日志的输出，流量监控等。
4. 运行原理
4.1 路由原理
https://img-blog.csdnimg.cn/direct/86e08e4e3b6247bc90f42a6fd117c953.png
流程图如下：
https://img-blog.csdnimg.cn/direct/c7395932d5cc499abd4431bf6e7e69f9.png
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重要包含以下几个属性：
https://img-blog.csdnimg.cn/direct/9d725e4097104833a4fb78a61e013d0a.png
Gateway重要通过接口RouteLocator接口来获取路由配置，RouteLocator代码如下：
public interface RouteLocator {
Flux<Route> getRoutes();
}
在Gateway的源码中，RouteLocator的实现类重要有：RouteDefinitionRouteLocator、CompositeRouteLocator、CachingRouteLocator。它们之间的关系如下图所示：
https://img-blog.csdnimg.cn/direct/a14b4e20e2bc4a4fb5882c40b3f5a349.png
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。
内置断言：
https://img-blog.csdnimg.cn/direct/cdf9525673d44c4b9da55c748f63b41e.png
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 内部也是通过一系列的内置全局过滤器对整个路由转发举行处理，如下：
https://img-blog.csdnimg.cn/direct/396aba48aeeb41f7bfb4653b4382110f.png
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]