gateway网关_(无代码)服务网关与Gateway，Zuul详解

服务网关

什么是服务网关

服务网关是统一管理API的一个网络关口、通道，是整个微服务平台所有请求的唯一入口，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。

1、路由转发：接收一切外界请求，转发到后端的微服务上去；

2、过滤器：在服务网关中可以完成一系列的横切功能，例如权限校验、限流以及监控等，

这些都可以通过过滤器完成（其实路由转发也是通过过滤器实现的）。

为什么需要服务网关

上述所说的横切功能（以权限校验为例）可以写在三个位置：

1. 每个服务自己实现一遍
2. 写到一个公共的服务中，然后其他所有服务都依赖这个服务
3. 写到服务网关的前置过滤器中，所有请求过来进行权限校验

第一种，缺点太明显，基本不用；

第二种，相较于第一点好很多，代码开发不会冗余，但是有两个缺点：

• 由于每个服务引入了这个公共服务，那么相当于在每个服务中都引入了相同的权限校验的代码，使得每个服务的jar包大小无故增加了一些，尤其是对于使用docker镜像进行部署的场景，jar越小越好；
• 由于每个服务都引入了这个公共服务，那么我们后续升级这个服务可能就比较困难，而且公共服务的功能越多，升级就越难，而且假设我们改变了公共服务中的权限校验的方式，想让所有的服务都去使用新的权限校验方式，我们就需要将之前所有的服务都重新引包，编译部署。

而服务网关恰好可以解决这样的问题：

将权限校验的逻辑写在网关的过滤器中，后端服务不需要关注权限校验的代码，所以服务的jar包中也不会引入权限校验的逻辑，不会增加jar包大小；

如果想修改权限校验的逻辑，只需要修改网关中的权限校验过滤器即可，而不需要升级所有已存在的微服务。

网关的作用

微服务提供的API粒度与客户端的要求不一定完全匹配，微服务一般提供细粒度的API，这意味着客户端通常需要与多个服务进行交互，网关要起到客户端与微服务间的隔离作用，随着业务需求的变化和时间的演进，网关背后的各个微服务的划分和实现可能需要做相应的调整和升级，这种调整和升级要求对客户端透明。

API网关的作用主要体现在以下三个方面：

• 解耦：API网关使客户端和服务器端在调用关系和部署环境上进行解耦，向客户端隐藏了应用如何被划分到微服务的细节。
• API优化：要求对每个客户端提供最优的API，在多客户端场景中，对于同一个业务请求，不同的客户端一般需要不同的数据。
• 简化调用过程：可以对返回数据进行处理，API网关减少了请求往返的次数，从而简化客户端的调用，提高服务访问的性能。

但是需要注意的是，API网关也增加了系统的复杂性和响应时间，通过API网关也多了一层网络跳转，但是我们认为API网关模式的缺点相比优点是微不足道的。

网关的功能

网关的基本功能基本包含五点，具体细分如下图：

• 功能1-NIO接入和异步接出：由于API网关作为客户端和微服务之间提供了桥梁，增加了一层网络跳转，为了解决网络跳转带来的性能影响，在实现上需要提供NIO接入和异步接出功能。
• 功能2-报文格式转换：API网关作为单一入口，可构建异构系统，通过协议转换整合后基于REST、AMQP和Dubbo等不同风格和实现技术的微服务。

• 功能3-安全性控制：API网关是统一管理安全性的绝佳场所，可以将认证的部分抽离到网关层，然后微服务系统无需关注认证的逻辑只关注自身业务即可。
• 功能4-访问控制：需要控制客户端的访问次数和访问频率等功能。
• 功能5-业务路由支持：可在网关层制定灵活的路由策略，对于特定API可设置白名单、路由规则等限制，非业务功能的配置及变更在网关层单独操作。

Zuul和Spring Cloud Gateway

目前能和spring cloud体系紧密集成的有两种API网关：zuul（zuul1）和spring cloud gateway。

Zuul

​ 目前zuul有两个版本：zuul1和zuul2，目前spring cloud只集成了zuul1。zuul2是Netflix在2018年5月推出，它最大的特点就是支持异步调用 (zuul1仅支持同步) ，可惜springcloud暂时没有计划集成zuul2，而且还推出spring cloud gateway来替代zuul1。

​ 来看下zuul1的编程模型（同步阻塞）

​ 本质上就是一个同步 Servlet，每来一个请求，zuul会专门分配一个线程去处理，然后转发到后端服务，后端再启线程处理请求，后端处理时网关的线程会阻塞，当请求数量比较大时，很容易造成线程池被沾满而无法接受新的请求，Netflix 为此还专门研发了Hystrix熔断组件来解决慢服务耗尽资源问题。

zuul2的编程模型（异步非阻塞）

​ zuul2是基于Netty实现的异步非阻塞编程模型，一般异步模式的本质都是使用队列 Queue(或称总线 Bus)。网关中会有一个队列专门处理用户请求，一个队列专门负责后端服务调用，中间有个事件环线程 (Event Loop Thread)同时监听两个队列，它的主要作用是将请求转发给后端，并将后端服务的处理结果返回给客户端，用队列的形式减轻了前端请求数量的压力。

Gateway

​ Spring Cloud Gateway构建于 Spring 5+，基于 Spring Boot 2.x 响应式的、非阻塞式的 API。同时，它支持 websockets，和 Spring 框架紧密集成，开发体验相对来说十分不错。由于zuul2没有被spring cloud所集成，所以拿zuul1与spring cloud gateway做一些简单的比较。

核心概念

网关提供API全托管服务，丰富的API管理功能，辅助企业管理大规模的API，以降低管理成本和安全风险，包括协议适配、协议转发、安全策略、防刷、流量、监控日志等贡呢。一般来说网关对外暴露的URL或者接口信息，我们统称为路由信息。如果研发过网关中间件或者使用过Zuul的人，会知道网关的核心是Filter以及Filter Chain（Filter责任链）。Sprig Cloud Gateway也具有路由和Filter的概念。下面介绍一下Spring Cloud Gateway中几个重要的概念。

• 路由。路由是网关最基础的部分，路由信息有一个ID、一个目的URL、一组断言和一组Filter组成。如果断言路由为真，则说明请求的URL和配置匹配
• 断言。Java8中的断言函数。Spring Cloud Gateway中的断言函数输入类型是Spring5.0框架中的ServerWebExchange。Spring Cloud Gateway中的断言函数允许开发者去定义匹配来自于http request中的任何信息，比如请求头和参数等。
• 过滤器。一个标准的Spring webFilter。Spring cloud gateway中的filter分为两种类型的Filter，分别是Gateway Filter和Global Filter。过滤器Filter将会对请求和响应进行修改处理

如上图所示，Spring cloudGateway发出请求。然后再由Gateway Handler Mapping中找到与请求相匹配的路由，将其发送到Gateway web handler。Handler再通过指定的过滤器链将请求发送到我们实际的服务执行业务逻辑，然后返回。

核心逻辑: 路由转发+执行过滤器链

Zuul1 VS Zuul2

Zuul1 同步编程模型简单，门槛低，开发运维方便，容易调试定位问题。Zuul2 门槛高，调试不方便。 Zuul1 监控埋点容易，比如和调用链监控工具 CAT 集成，如果你用 Zuul2 的话，CAT 不好埋点是个问题。 Zuul1 已经开源超过 6 年，稳定成熟，坑已经被踩平。Zuul2 刚开源很新，实际落地案例不多，难说有 bug 需要踩坑。 大部分公司达不到 Netflix 那个量级，Netflix 是要应对每日千亿级流量，它们才挖空心思搞异步，一般公司亿级可能都不到，Zuul1 绰绰有余。 Zuul1 可以集成 Hystrix 熔断组件，可以部分解决后台服务慢阻塞网关线程的问题。 Zuul1 可以使用 Servlet 3.0 规范支持的 AsyncServlet 进行优化，可以实现前端异步，支持更多的连接数，达到和 Zuul2 一样的效果，但是不用引入太多异步复杂性。

Gateway VS Zuul