(无代码)服务网关与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
优势	模型简单，跟踪调试方便。	线程相对较少，对cpu、内存的开销少。可以接受相对较大的连接数。
劣势	cpu、内存消耗相对较大。IO阻塞容器导致线程池被耗尽。	由于是通过事件环线程监听的异步处理方式，没有明确的请求链路，很难进行断点联调。ThreadLocal机制无法工作。
性能	950.57 次 /s（单核）	大致比zuul1好20%左右
使用场景	适用于计算密集型 (CPU bound) 应用场景	适用于 IO 密集型 (IO bound) 场景

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

Gateway VS Zuul

	spring cloud gateway	zuul
基本介绍	Spring Cloud Gateway是Spring官方基于Spring 5.0，Spring Boot 2.0和Project Reactor等技术开发的网关，旨在为微服务架构提供一种简单而有效的统一的API路由管理方式。Spring 用其替代Netflix ZUUL，其不仅提供统一的路由方式，并且基于Filter链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。	Zuul1 是基于 Servlet 框架构建，采用的是阻塞和多线程方式，即一个线程处理一次连接请求，这种方式在内部延迟严重、设备故障较多情况下会引起存活的连接增多和线程增加的情况发生。
性能	WebFlux 模块的名称是 spring-webflux，名称中的 Flux 来源于 Reactor 中的类 Flux。Spring webflux 有一个全新的非堵塞的函数式 Reactive Web 框架，可以用来构建异步的、非堵塞的、事件驱动的服务，在伸缩性方面表现非常好。使用非阻塞API。 Websockets得到支持，并且由于它与Spring紧密集成。	本文的Zuul，指的是Zuul 1.x，是一个基于阻塞io的API Gateway。Zuul已经发布了Zuul 2.x，基于Netty，也是非阻塞的，支持长连接，但Spring Cloud暂时还没有整合计划。
源码维护组织	spring-cloud-Gateway是spring旗下spring-cloud的一个子项目。还有一种说法是因为zuul2连续跳票和zuul1的性能表现不是很理想，所以催生了spring孵化Gateway项目。	zuul则是netflix公司的项目，只是spring将zuul集成在spring-cloud中使用而已。关键目前spring不打算集成zuul2.x。
现不是很理想，所以催生了spring孵化Gateway项目。	zuul则是netflix公司的项目，只是spring将zuul集成在spring-cloud中使用而已。关键目前spring不打算集成zuul2.x。
版本	基于springboot2.0	springboot1.x