关于java:5种API网关技术选型yyds

大家好，我是不才陈某~

本文筹备围绕七个点来讲网关，别离是网关的基本概念、网关设计思路、网关设计重点、流量网关、业务网关、常见网关比照，对根底概念相熟的敌人能够依据目录查看本人感兴趣的局部。

什么是网关

网关，很多中央将网关比方成门，没什么问题，然而须要辨别网关与网桥的区别，

网桥 工作在数据链路层，在不同或雷同类型的 LAN 之间存储并转发数据帧，必要时进行链路层上的协定转换。可连贯两个或多个网络，在其中传送信息包。

网关 是一个大概念，不具体特指一类产品，只有连贯两个不同的网络都能够叫网关，网桥个别只转发信息，而网关可能进行包装。

网关艰深了解

依据网关的个性，举个例子:

如果你要去找团体老板(这儿只是举个例子)，大家都晓得老板必定不是谁想见就能见的，也怕好人嘛，那么你去老板所在的办公楼，如果是团体总部，大楼这个门就充当了网关的角色，大门个别都有看门员，看门员会做哪些事件呢?

首先所有想见老板的人必定都得从这个门进 ( 对立入口 )，这个门相当于将办公室和外界隔离了，次要为了爱护外面的平安以及失常工作，来到这个门之后，门卫必定会让你出示相干证件( 鉴权测验 )，意思就是判断你要见老板这个申请是否正当，如果不合理间接就回绝了，让你回家等音讯，如果鉴权之后，发现你找老板其实只是为了和他谈谈两元店的生意，门卫会跟你说这个用不着找老板，你去团体投资部就行了( 动静路由 ，将申请路由到不同的后端集群中)，此时会对你进行一些 包装，例如给你出具一个拜访证相似的，而后通知你路该怎么走，等等。

你看看，网关的作用是不是就是这三个，最终目标就是缩小你与团体的耦合，具体到计算机上就是缩小客户端与服务端的耦合，如果没有网关意味着所有申请都会间接调用服务器上的资源，这样耦合太强了，服务器出了问题，客户端会间接报错，例如老板换工作的中央了，如果没有网关你间接去原来的中央找，必定会被告知老板不在这儿。

为什么须要网关

当应用单体应用程序架构时，客户端（Web 或挪动端）通过向后端应用程序发动一次 REST 调用来获取数据。负载均衡器将申请路由给 N 个雷同的应用程序实例中的一个。而后应用程序会查问各种数据库表，并将响应返回给客户端。微服务架构下，单体利用被切割成多个微服务，如果将所有的微服务间接对外裸露，势必会呈现平安方面的各种问题，另外内外耦合重大。

客户端能够间接向每个微服务发送申请，其问题次要如下：

• 客户端需要和每个微服务裸露的细粒度 API 不匹配。
• 局部服务应用的协定不是 Web 敌对协定。可能应用 Thrift 二进制 RPC，也可能应用 AMQP 消息传递协定。
• 微服务难以重构。如果合并两个服务，或者将一个服务拆分成两个或更多服务，这类重构就十分艰难了。

服务端的各个服务间接裸露给客户端调用势必会引起各种问题。同时，服务端的各个服务可扩大和伸缩性很差。API 网关是微服务架构中的根底组件，位于接入层之下和业务服务层之上，如前所述的这些性能适宜在 API 网关实现。

网关与服务器集群

回到咱们服务器上，上面图介绍了网关 (Gateway) 作用，可知 Gateway 形式下的架构，能够细到为每一个服务的实例配置一个本人的 Gateway，也能够粗到为一组服务配置一个，甚至能够粗到为整个架构配置一个接入的 Gateway。于是，整个零碎架构的复杂度就会变得简略可控起来。

这张图展现了一个多层 Gateway 架构，其中有一个总的 Gateway 接入所有的流量 ( 流量网关 )，并分发给不同的子系统，还有第二级 Gateway 用于做各个子系统的接入 Gateway( 业务网关)。能够看到，网关所治理的服务粒度可粗可细。通过网关，咱们能够把分布式架构组织成一个星型架构，由网络对服务的申请进行路由和散发。上面来聊聊好的网关应该具备哪些性能，也就是网关设计模式。

网关设计思路

一个网关须要有以下的性能:

1. 申请路由

网关肯定要有申请路由的性能。这样一来，对于调用端来说，也是一件十分不便的事件。因为调用端不须要晓得本人须要用到的其它服务的地址，全副对立地交给 Gateway 来解决。

2. 服务注册

为了可能代理前面的服务，并把申请路由到正确的地位上，网关应该有服务注册性能，也就是后端的服务实例能够把其提供服务的地址注册、勾销注册。一般来说，注册也就是注册一些 API 接口。比方，HTTP 的 Restful 申请，能够注册相应 API 的 URI、办法、HTTP 头。这样，Gateway 就能够依据接管到的申请中的信息来决定路由到哪一个后端的服务上。

3. 负载平衡

因为一个网关能够接管多个服务实例，所以网关还须要在各个对等的服务实例上做负载平衡策略。简略点就是间接 Round-Robin 轮询，简单点的能够设置上权重进行散发，再简单一点还能够做到 session 粘连。

4. 弹力设计

网关还能够把弹力设计中的那些异步、重试、幂等、流控、熔断、监督等都能够实现进去。这样，同样能够像 Service Mesh 那样，让应用服务只关怀本人的业务逻辑（或是说数据面上的事）而不是管制逻辑（管制面）。

5. 平安方面

SSL 加密及证书治理、Session 验证、受权、数据校验，以及对申请源进行歹意攻打的防备。错误处理越靠前的地位就是越好，所以，网关能够做到一个全站的接入组件来对后端的服务进行爱护。当然，网关还能够做更多更乏味的事件，比方：灰度公布、API 聚合、API 编排。

灰度公布

网关齐全能够做到对雷同服务不同版本的实例进行导流，还能够收集相干的数据。这样对于软件品质的晋升，甚至产品试错都有十分踊跃的意义。

API 聚合

应用网关能够将多个独自申请聚合成一个申请。在微服务体系的架构中，因为服务变小了，所以一个显著的问题是，客户端可能须要屡次申请能力失去所有的数据。这样一来，客户端与后端之间的频繁通信会对应用程序的性能和规模产生十分不利的影响。于是，咱们能够让网关来帮客户端申请多个后端的服务（有些场景下齐全能够并发申请），而后把后端服务的响应后果拼装起来，回传给客户端（当然，这个过程也能够做成异步的，但这须要客户端的配合）。

API 编排

同样在微服务的架构下，要走完一个残缺的业务流程，咱们须要调用一系列 API，就像一种工作流一样，这个事齐全能够通过网页来编排这个业务流程。咱们可能通过一个 DSL 来定义和编排不同的 API，也能够通过像 AWS Lambda 服务那样的形式来串联不同的 API。

网关设计重点

网关设计重点次要是三个，高性能、高可用、高扩大:

1. 高性能

在技术设计上，网关不应该也不能成为性能的瓶颈。对于高性能，最好应用高性能的编程语言来实现，如 C、C++、Go 和 Java。网关对后端的申请，以及对前端的申请的服务肯定要应用异步非阻塞的 I/O 来确保后端提早不会导致应用程序中呈现性能问题。C 和 C++ 能够参看 Linux 下的 epoll 和 Windows 的 I/O Completion Port 的异步 IO 模型，Java 下如 Netty、Spring Reactor 的 NIO 框架。

2. 高可用

因为所有的流量或调用通过网关，所以网关必须成为一个高可用的技术组件，它的稳固间接关系到了所有服务的稳固。网关如果没有设计，就会成变一个单点故障。因而，一个好的网关至多要做到以下几点。

• 集群化。网关要成为一个集群，其最好能够本人组成一个集群，并能够本人同步集群数据，而不须要依赖于一个第三方零碎来同步数据。
• 服务化。网关还须要做到在不间断的状况下批改配置，一种是像 Nginx reload 配置那样，能够做到不停服务，另一种是最好做到服务化。也就是说，得要有本人的 Admin API 来在运行时批改本人的配置。
• 继续化。比方重启，就是像 Nginx 那样优雅地重启。有一个主管申请散发的主过程。当咱们须要重启时，新的申请被调配到新的过程中，而老的过程解决完正在解决的申请后就退出。

3. 高扩大

因为网关须要承接所有的业务流量和申请，所以肯定会有或多或少的业务逻辑。而咱们都晓得，业务逻辑是多变和不确定的。比方，须要在网关上退出一些和业务相干的货色。因而，一个好的 Gateway 还须要是能够扩大的，并能进行二次开发的。当然，像 Nginx 那样通过 Module 进行二次开发的诚然能够。

另外，在 运维方面，网关应该有以下几个设计准则。

• 业务松耦合，协定紧耦合。在业务设计上，网关不应与前面的服务之间造成服务耦合，也不应该有业务逻辑。网关应该是在网络应用层上的组件，不应该解决通信协定体，只应该解析和解决通信协定头。另外，除了服务发现外，网关不应该有第三方服务的依赖。
• 利用监督，提供剖析数据。网关上须要思考利用性能的监控，除了有相应后端服务的高可用的统计之外，还须要应用 Tracing ID 施行分布式链路跟踪，并统计好肯定工夫内每个 API 的吞吐量、响应工夫和返回码，以便启动弹力设计中的相应策略。
• 用弹力设计爱护后端服务。网关上肯定要实现熔断、限流、重试和超时等弹力设计。如果一个或多个服务调用破费的工夫过长，那么可承受超时并返回一部分数据，或是返回一个网关里的缓存的上一次胜利申请的数据。你能够考虑一下这样的设计。
• DevOps。因为网关这个组件太要害了，所以须要 DevOps 这样的货色，将其产生故障的概率降到最低。这个软件须要通过精良的测试，包含性能和性能的测试，还有浸泡测试。还须要有一系列自动化运维的管控工具。

网关设计注意事项

1. 不要在网关中的代码里内置聚合后端服务的性能，而应思考将聚合服务放在网关外围代码之外。能够应用 Plugin 的形式，也能够放在网关前面造成一个 Serverless 服务。
2. 网关应该凑近后端服务，并和后端服务应用同一个内网，这样能够保障网关和后端服务调用的低提早，并能够缩小很多网络上的问题。这里多说一句，网关解决的动态内容应该凑近用户（应该放到 CDN 上），而网关和此时的动静服务应该凑近后端服务。
3. 网关也须要做容量扩大，所以须要成为一个集群来分担前端带来的流量。这一点，要么通过 DNS 轮询的形式实现，要么通过 CDN 来做流量调度，或者通过更为底层的性能更高的负载平衡设施。
4. 对于服务发现，能够做一个工夫不长的缓存，这样不须要每次申请都去查一下相干的服务所在的中央。当然，如果你的零碎不简单，能够思考把服务发现的性能间接集成进网关中。
5. 为网关思考 bulkhead 设计形式。用不同的网关服务不同的后端服务，或是用不同的网关服务前端不同的客户。

另外，因为网关是为用户申请和后端服务的桥接安装，所以须要思考一些平安方面的事宜。具体如下：

1. 加密数据。能够把 SSL 相干的证书放到网关上，由网关做对立的 SSL 传输治理。
2. 校验用户的申请。一些根本的用户验证能够放在网关上来做，比方用户是否已登录，用户申请中的 token 是否非法等。然而，咱们须要衡量一下，网关是否须要校验用户的输出。因为这样一来，网关就须要从只关怀协定头，到须要关怀协定体。而协定体中的货色一方面不像协定头是规范的，另一方面解析协定体还要消耗大量的运行工夫，从而升高网关的性能。对此，我想说的是，看具体需要，一方面如果协定体是规范的，那么能够干；另一方面，对于解析协定所带来的性能问题，须要做相应的隔离。
3. 检测异样拜访。网关须要检测一些异样拜访，比方，在一段比拟短的工夫内申请次数超过肯定数值；还比方，同一客户端的 4xx 申请出错率太高……对于这样的一些申请拜访，网关一方面要把这样的申请屏蔽掉，另一方面须要收回正告，有可能会是一些比拟重大的平安问题，如被黑客攻击。

流量网关

流量网关，顾名思义就是管制流量进入集群的网关，有很多工作须要在这一步做，对于一个服务集群，势必有很多非法的申请或者有效的申请，这时候要将申请拒之门外，升高集群的流量压力。

定义全局性的、跟具体的后端业务利用和服务齐全无关的策略网关就是上图所示的架构模型——流量网关。流量网关通常只专一于全局的 Api 管理策略，比方全局流量监控、日志记录、全局限流、黑白名单管制、接入申请到业务零碎的负载平衡等，有点相似防火墙。Kong 就是典型的流量网关。

上面是 kong 的架构图，来自官网：https://konghq.com

这里须要补充一点的是，业务网关个别部署在流量网关之后、业务零碎之前，比流量网关更凑近业务零碎。通常 API 网指的是业务网关。有时候咱们也会含糊流量网关和业务网关，让一个网关承当所有的工作，所以这两者之间并没有严格的界限。

业务网关

当一个单体利用被拆分成许许多多的微服务利用后，也带来了一些问题。一些与业务非强相干的性能，比方权限管制、日志输入、数据加密、熔断限流等，每个微服务利用都须要，因而存在着大量反复的代码实现。而且因为零碎的迭代、人员的更替，各个微服务中这些性能的实现细节呈现了较大的差别，导致保护老本变高。另一方面，原先单体利用下非常容易做的接口治理，在服务拆分后没有了一个集中管理的中央，无奈统计已存在哪些接口、接口定义是什么、运行状态如何。

网关就是为了解决上述问题。作为微服务体系中的外围基础设施，个别须要具备接口治理、协定适配、熔断限流、平安防护等性能，各种开源的网关产品（比方 zuul）都提供了优良高可扩展性的架构、能够很不便的实现咱们须要的一些性能、比方鉴权、日志监控、熔断限流等。

与流量网关绝对应的就是业务网关，业务网关更凑近咱们的业务，也就是与服务器应用层打交道，那么有很多应用层须要思考的事件就能够依靠业务网关，例如在线程模型、协定适配、熔断限流，服务编排等。上面看看业务网关体系结构:

从这个途中能够看出业务网关主要职责以及所做的事件，目前业务网关比拟成熟的 API 网关框架产品有三个 别离是:Zuul1、Zuul2 和 SpringCloud Gateway，前面再进行比照。

常见网关比照

既然比照，就先宏观上对各种网关有一个理解，前面再挑一些罕用的或者说利用宽泛的具体理解。

目前常见的开源网关大抵上依照语言分类有如下几类：

• Nginx+lua：OpenResty、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

依照应用数量、成熟度等来划分，支流的有 5 个：

• OpenResty
• Kong
• Zuul、Zuul2
• Spring Cloud Gateway

1. OpenResty

OpenResty 是一个流量网关，依据后面对流量网关的介绍就能够晓得流量网关的指摘。

OpenResty 基于 Nginx 与 Lua 的高性能 Web 平台，其外部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于不便地搭建可能解决超高并发、扩展性极高的动静 Web 利用、Web 服务和动静网关。

通过揉和泛滥设计良好的 Nginx 模块，OpenResty 无效地把 Nginx 服务器转变为一个弱小的 Web 应用服务器，基于它开发人员能够应用 Lua 编程语言对 Nginx 外围以及现有的各种 Nginx C 模块进行脚本编程，构建出能够解决一万以上并发申请的极其高性能的 Web 利用

OpenResty 最早是适应 OpenAPI 的潮流做的，所以 Open 取自“凋谢”之意，而 Resty 便是 REST 格调的意思。尽管起初也能够基于 ngx_openresty 实现任何模式的 web service 或者传统的 web 利用。

也就是说 Nginx 不再是一个简略的动态网页服务器，也不再是一个简略的反向代理了。第二代的 openresty 致力于通过一系列 nginx 模块，把 nginx 扩大为全功能的 web 应用服务器。

ngx_openresty 是用户驱动的我的项目，起初也有不少国内用户的参加，从 openresty.org 的点击量散布上看，国内和国外的点击量根本持平。

ngx_openresty 目前有两大利用指标：

1. 通用目标的 web 应用服务器。在这个指标下，现有的 web 利用技术都能够算是和 OpenResty 或多或少有些相似，比方 Nodejs，PHP 等等。ngx_openresty 的性能（包含内存应用和 CPU 效率）算是最大的卖点之一。
2. Nginx 的脚本扩大编程，用于构建灵便的 Web 利用网关和 Web 利用防火墙。有些相似的是 NetScaler。其劣势在于 Lua 编程带来的微小灵活性。

2. Kong

Kong 基于 OpenResty 开发，也是流量层网关，是一个云原生、疾速、可扩大、分布式的 Api 网关。继承了 OpenResty 的高性能、易扩展性等特点。Kong 通过简略的减少机器节点，能够很容易的程度扩大。同时性能插件化，可通过插件来扩大其能力。而且在任何基础架构上都能够运行。具备以下个性：

• 提供了多样化的认证层来爱护 Api。
• 可对出入流量进行管制。
• 提供了可视化的流量查看、监督剖析 Api。
• 可能及时的转换申请和相应。
• 提供 log 解决方案
• 可通过 api 调用 Serverless 函数。

Kong 解决了什么问题

当咱们决定对利用进行微服务革新时，利用客户端如何与微服务交互的问题也随之而来，毕竟服务数量的减少会间接导致部署受权、负载平衡、通信治理、剖析和扭转的难度减少。

面对以上问题，API GATEWAY 是一个不错的解决方案，其所提供的拜访限度、平安、流量管制、剖析监控、日志、申请转发、合成和协定转换性能，能够解放开发者去把精力集中在具体逻辑的代码，而不是把工夫破费在思考如何解决利用和其余微服务链接的问题上。

图片来自 Kong 官网:

能够看到 Kong 解决的问题。专一于全局的 Api 管理策略，全局流量监控、日志记录、全局限流、黑白名单管制、接入申请到业务零碎的负载平衡等。

Kong 的长处以及性能

在泛滥 API GATEWAY 框架中，Mashape 开源的高性能高可用 API 网关和 API 服务管理层——KONG（基于 NGINX+Lua）特点尤为突出，它能够通过插件扩大已有性能，这些插件（应用 lua 编写）在 API 申请响应循环的生命周期中被执行。于此同时，KONG 自身提供包含 HTTP 根本认证、密钥认证、CORS、TCP、UDP、文件日志、API 申请限流、申请转发及 NGINX 监控等基本功能。目前，Kong 在 Mashape 治理了超过 15，000 个 API，为 200，000 开发者提供了每月数十亿的申请反对。

Kong 架构

Kong 提供一些列的服务，这就不得不谈谈外部的架构:

首先最底层是基于 Nginx，Nginx 是高性能的根底层，一个良好的负载平衡、反向代理器，而后在此基础上减少 Lua 脚本库，造成了 OpenResty，拦挡申请，响应生命周期，能够通过 Lua 编写脚本，所以插件比拟丰盛。

对于 Kong 的一些插件库以及如何配置，能够参考简书: 开源 API 网关零碎（Kong 教程）入门到精通：https://www.jianshu.com/p/a68…

3. Zuul1.0

Zuul 是所有从设施和 web 站点到 Netflix 流媒体应用程序后端申请的前门。作为一个边缘服务应用程序，Zuul 被构建来反对动静路由、监督、弹性和安全性。它还能够依据须要将申请路由到多个 Amazon 主动伸缩组。

Zuul 应用了一系列不同类型的过滤器，使咱们可能疾速灵便地将性能利用到服务中。

过滤器

过滤器是 Zuul 的外围性能。它们负责应用程序的业务逻辑，能够执行各种工作。

• Type：通常定义过滤器利用在哪个阶段
• Async：定义过滤器是同步还是异步
• Execution Order：执行程序
• Criteria：过滤器执行的条件
• Action：如果条件满足，过滤器执行的动作

Zuul 提供了一个动静读取、编译和运行这些过滤器的框架。过滤器之间不间接通信，而是通过每个申请特有的 RequestContext 共享状态。

上面是 Zuul 的一些过滤器:

Incoming

Incoming 过滤器在申请被代理到 Origin 之前执行。这通常是执行大部分业务逻辑的中央。例如: 认证、动静路由、速率限度、DDoS 爱护、指标。

Endpoint

Endpoint 过滤器负责基于 incoming 过滤器的执行来解决申请。Zuul 有一个内置的过滤器（ProxyEndpoint），用于将申请代理到后端服务器，因而这些过滤器的典型用处是用于动态端点。例如: 健康检查响应，动态谬误响应，404 响应。

Outgoing

Outgoing 过滤器在从后端接管到响应当前执行解决操作。通常状况下，它们更多地用于造成响应和增加指标，而不是用于任何沉重的工作。例如: 存储统计信息、增加 / 剥离规范题目、向实时流发送事件、gziping 响应。

过滤器类型

上面是与一个申请典型的生命周期对应的规范的过滤器类型：

• PRE：路由到 Origin 之前执行
• ROUTING：路由到 Origin 期间执行
• POST：申请被路由到 Origin 之后执行
• ERROR：产生谬误的时候执行

这些过滤器帮忙咱们执行以下性能：

• 身份验证和安全性：辨认每个资源的身份验证需要，并回绝不满足它们的申请
• 监控：在边缘跟踪有意义的数据和统计数据，以便给咱们一个精确的生产视图
• 动静路由：动静路由申请到不同的后端集群
• 压力测试：逐步减少集群的流量，以评估性能
• 限流：为每种申请类型调配容量，并抛弃超过限度的申请
• 动态响应解决：间接在边缘构建一些响应，而不是将它们转发到外部集群

Zuul 1.0 申请生命周期

Netflix 发表了通用 API 网关 Zuul 的架构转型。Zuul 本来采纳同步阻塞架构，转型后叫作 Zuul2，采纳异步非阻塞架构。Zuul2 和 Zuul1 在架构方面的次要区别在于，Zuul2 运行在异步非阻塞的框架上，比方 Netty。Zuul1 依赖多线程来反对吞吐量的增长，而 Zuul 2 应用的 Netty 框架依赖事件循环和回调函数。

4. Zuul2.0

Zuul 2.0 架构图

上图是 Zuul2 的架构，和 Zuul1 没有本质区别，两点变动：

1. 前端用 Netty Server 代替 Servlet，目标是反对前端异步。后端用 Netty Client 代替 Http Client，目标是反对后端异步。
2. 过滤器换了一下名字，用 Inbound Filters 代替 Pre-routing Filters，用 Endpoint Filter 代替 Routing Filter，用 Outbound Filters 代替 Post-routing Filters。

Inbound Filters：路由到 Origin 之前执行，能够用于身份验证、路由和装璜申请

Endpoint Filters：可用于返回动态响应，否则内置的 ProxyEndpoint 过滤器将申请路由到 Origin

Outbound Filters：从 Origin 那里获取响应后执行，能够用于度量、装璜用户的响应或增加自定义 header

有两种类型的过滤器：sync 和 async。因为 Zuul 是运行在一个事件循环之上的，因而从来不要在过滤中阻塞。如果你非要阻塞，能够在一个异步过滤器中这样做，并且在一个独自的线程池上运行，否则能够应用同步过滤器。

上文提到过Zuul2 开始采纳了异步模型

劣势 是异步非阻塞模式启动的线程很少，基本上一个 CPU core 上只需启一个事件环解决线程，它应用的线程资源就很少，上下文切换 (Context Switch) 开销也少。非阻塞模式能够承受的连接数大大增加，能够简略了解为申请来了只须要进队列，这个队列的容量能够设得很大，只有不超时，队列中的申请都会被顺次解决。

有余，异步模式让编程模型变得复杂。一方面 Zuul2 自身的代码要比 Zuul1 简单很多，Zuul1 的代码比拟容易看懂，Zuul2 的代码看起来就比拟吃力。另一方面异步模型没有一个明确清晰的申请 -> 解决 -> 响应执行流程(call flow)，它的流程是通过事件触发的，申请解决的流程随时可能被切换断开，外部实现要通过一些关联 id 机制能力把整个执行流再串联起来，这就给开发调试运维引入了很多复杂性，比方你在 IDE 外头调试异步申请流就十分艰难。另外 ThreadLocal 机制在这种异步模式下就不能简略工作，因为只有一个事件环线程，不是每个申请一个线程，也就没有线程部分的概念，所以对于 CAT 这种依赖于 ThreadLocal 能力工作的监控工具，调用链埋点就不好搞(理论能够工作但须要进行非凡解决)。

总体上，异步非阻塞模式比拟实用于 IO 密集型 (IO bound) 场景，这种场景下零碎大部分工夫在解决 IO，CPU 计算比拟轻，大量事件环线程就能解决。

Zuul 与 Zuul 2 性能比照

Netflix 给出了一个比拟含糊的数据，大抵 Zuul2 的性能比 Zuul1 好 20% 左右，这里的性能次要指每节点每秒解决的申请数。为什么说含糊呢？因为这个数据受理论测试环境，流量场景模式等泛滥因素影响，你很难复现这个测试数据。即使这个 20% 的性能晋升是的确的，其实这个性能晋升也并不大，和异步引入的复杂性相比，这 20% 的晋升是否值得是个问题。Netflix 自身在其博文 22 和 ppt11 中也是有点含糊其词，甚至本身都有一些疑难的。

5. Spring Cloud 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。

Spring Cloud Gateway 的指标，不仅提供对立的路由形式，并且基于 Filter 链的形式提供了网关根本的性能，例如：平安，监控 / 指标，和限流。

Spring Cloud Gateway 底层应用了高性能的通信框架 Netty。

SpringCloud Gateway 特色

SpringCloud 官网，对 SpringCloud Gateway 特色介绍如下：

（1）基于 Spring Framework 5，Project Reactor 和 Spring Boot 2.0

（2）集成 Hystrix 断路器

（3）集成 Spring Cloud DiscoveryClient

（4）Predicates 和 Filters 作用于特定路由，易于编写的 Predicates 和 Filters

（5）具备一些网关的高级性能：动静路由、限流、门路重写

从以上的特色来说，和 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。

几种网关的比照

<hr/>

举荐浏览（求关注，别白嫖！）

1. 花了 2 周工夫收集汇总的大厂面经，节后筹备跳槽的看过去！
2. 阿里终面：说说 OAuth2.0 与 单点登录的区别？
3. 实战干货！Spring Cloud Gateway 整合 OAuth2.0 实现分布式对立认证受权！
4. 从实现原理来讲，Nacos 为什么这么强？
5. 阿里限流神器 Sentinel 夺命连环 17 问？
6. openFeign 夺命连环 9 问，这谁受得了？
7. Spring Cloud Gateway 夺命连环 10 问？
8. 链路追踪自从用了 SkyWalking，睡的真香！