API 网关性能比较：NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd

一时失言乱红尘 2022-12-02 13:55 124阅读 0赞

**本文根据众多互联网博客内容整理后形成，引用内容的版权归原始作者所有，仅限于学习研究使用。**

# 1 前言 #

Spring Cloud在云服务和微服务中扮演很重要的角色，而Spring Cloud的组件ZUUL 网关API也发展使用很广。最近无意中了解ZUUL ，网上查了查资料，发现了这篇文章，这里转载一下。

原文： [https://www.infoq.cn/article/comparing-api-gateway-performances][https_www.infoq.cn_article_comparing-api-gateway-performances]

OpsGenie 公司（一家致力于 Dev & Ops 的公司）的资深工程师 Turgay Çelik 博士写的一篇文章（链接在文末），文中介绍了他们最初也是采用 Nginx 作为单体应用的网关，后来接触到微服务架构后开始逐渐采用了其他组件。

# 2 技术介绍 #

文中针对 Nginx、ZUUL、Spring Cloud、Linkerd 等技术进行了对比（其实还有 Envoy 和 UnderTow 也是属于可选的 API 网关，本文不予涉及），那我就分别进行介绍，当然，首先得介绍 API 网关。

## 3 API 网关 ##

API 网关出现的原因是微服务架构的出现，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信，会有以下的问题：

1.  **客户端会多次请求不同的微服务，增加了客户端的复杂性。**
2.  **存在跨域请求，在一定场景下处理相对复杂。**
3.  **认证复杂，每个服务都需要独立认证。**
4.  **难以重构，随着项目的迭代，可能需要重新划分微服务。例如，可能将多个服务合并成一个或者将一个服务拆分成多个。如果客户端直接与微服务通信，那么重构将会很难实施。**
5.  **某些微服务可能使用了防火墙 / 浏览器不友好的协议，直接访问会有一定的困难。**

以上这些问题可以借助 API 网关解决。API 网关是介于客户端和服务器端之间的中间层，所有的外部请求都会先经过 API 网关这一层。也就是说，API 的实现方面更多的考虑业务逻辑，而安全、性能、监控可以交由 API 网关来做，这样既提高业务灵活性又不缺安全性，典型的架构图如图所示：

[![API网关性能比较：NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd]][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd]

使用 API 网关后的优点如下：

*  易于监控。可以在网关收集监控数据并将其推送到外部系统进行分析。
 *  易于认证。可以在网关上进行认证，然后再将请求转发到后端的微服务，而无须在每个微服务中进行认证。
 *  减少了客户端与各个微服务之间的交互次数。

## 3.1 NGINX 服务 ##

Nginx 由内核和模块组成，内核的设计非常微小和简洁，完成的工作也非常简单，仅仅通过查找配置文件与客户端请求进行 URL 匹配，用于启动不同的模块去完成相应的工作。

下面这张图反应的是 HTTP 请求的常规处理流程：

[![API网关性能比较：NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 1]][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 1]

Nginx 的模块直接被编译进 Nginx，因此属于静态编译方式。启动 Nginx 后，Nginx 的模块被自动加载，不像 Apache，首先将模块编译为一个 so 文件，然后在配置文件中指定是否进行加载。在解析配置文件时，Nginx 的每个模块都有可能去处理某个请求，但是同一个处理请求只能由一个模块来完成。

Nginx 在启动后，会有一个 Master 进程和多个 Worker 进程，Master 进程和 Worker 进程之间是通过进程间通信进行交互的，如图所示。Worker 工作进程的阻塞点是在像 select()、epoll\_wait() 等这样的 I/O 多路复用函数调用处，以等待发生数据可读 / 写事件。Nginx 采用了异步非阻塞的方式来处理请求，也就是说，Nginx 是可以同时处理成千上万个请求的。一个 Worker 进程可以同时处理的请求数只受限于内存大小，而且在架构设计上，不同的 Worker 进程之间处理并发请求时几乎没有同步锁的限制，Worker 进程通常不会进入睡眠状态，因此，当 Nginx 上的进程数与 CPU 核心数相等时（最好每一个 Worker 进程都绑定特定的 CPU 核心），进程间切换的代价是最小的。

[![API网关性能比较：NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 2]][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 2]![20200831144041215.gif][]

## 3.2 Netflix 的 Zuul ##

[![API网关性能比较：NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 3]][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 3]![20200831144041267.gif][]

Zuul 是 Netflix 开源的微服务网关组件，它可以和 Eureka、Ribbon、Hystrix 等组件配合使用。Zuul 的核心是一系列的过滤器，这些过滤器可以完成以下功能：

*  身份认证与安全：识别每个资源的验证要求，并拒绝那些与要求不符的请求。
 *  审查与监控：与边缘位置追踪有意义的数据和统计结果，从而带来精确的生产视图。
 *  动态路由：动态地将请求路由到不同的后端集群。
 *  压力测试：逐渐增加指向集群的流量，以了解性能。
 *  负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求。
 *  静态响应处理：在边缘位置直接建立部分响应，从而避免其转发到内部集群。
 *  多区域弹性：跨越 AWS Region 进行请求路由，旨在实现 ELB（Elastic Load Balancing，弹性负载均衡）使用的多样化，以及让系统的边缘更贴近系统的使用者。

上面提及的这些特性是 Nigix 所没有的，这是因为 Netflix 公司创造 Zuul 是为了解决云端的诸多问题（特别是帮助 AWS 解决跨 Region 情况下的这些特性实现），而不仅仅是做一个类似于 Nigix 的反向代理，当然，我们可以仅使用反向代理功能，这里不多做描述。

Zuul1 是基于 Servlet 框架构建，如图所示，采用的是阻塞和多线程方式，即一个线程处理一次连接请求，这种方式在内部延迟严重、设备故障较多情况下会引起存活的连接增多和线程增加的情况发生。

![20200831144041300.gif][][![API网关性能比较：NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 4]][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 4]

**Zuul2 的巨大区别是它运行在异步和无阻塞框架上**，每个 CPU 核一个线程，处理所有的请求和响应，请求和响应的生命周期是通过事件和回调来处理的，这种方式减少了线程数量，因此开销较小。又由于数据被存储在同一个 CPU 里，可以复用 CPU 级别的缓存，前面提及的延迟和重试风暴问题也通过队列存储连接数和事件数方式减轻了很多（较线程切换来说轻量级很多，自然消耗较小）。这一变化一定会大大提升性能，我们在后面的测试环节看看结果。

![20200831144041292.gif][][![API网关性能比较：NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 5]][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 5]

我们今天谈的是 API 网关性能，这一点也涉及到高可用，简单介绍 Zuul 的高可用特性，高可用是非常关键的，因为外部请求到后端微服务的流量都会经过 Zuul，所以在生产环境中一般都需要部署高可用的 Zuul 来避免单点故障。一般我们有两种部署方案：

**1. Zuul 客户端注册到 Eureka Server**

这种情况是比较简单的情况，只需要将多个 Zuul 节点注册到 Eureka Server 上，就可以实现 Zuul 的高可用。事实上，这种情况下的高可用和其他服务做高可用的方案没有什么区别。我们来看下面这张图，当 Zuul 客户端注册到 Eureka Server 上时，只需要部署多个 Zuul 节点就可以实现高可用。Zuul 客户端会自动从 Eureka Server 查询 Zuul Server 列表，然后使用负载均衡组件（例如 Ribbon）请求 Zuul 集群。

[![API网关性能比较：NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 6]][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 6]![20200831144041296.gif][]

**2. Zuul 客户端不能注册到 Eureka Server**

假如说我们的客户端是手机端 APP，那么不可能通过方案 1 的方式注册到 Eureka Server 上。这种情况下，我们可以通过额外的负载均衡器来实现 Zuul 的高可用，例如 Nginx、HAProxy、F5 等。

如图所示，Zuul 客户端将请求发送到负载均衡器，负载均衡器将请求转发到其代理的其中一个 Zuul 节点，这样就可以实现 Zuul 的高可用。

[![API网关性能比较：NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 7]][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 7]![20200831144041270.gif][]

## 3.3 Spring Cloud ##

虽然 Spring Cloud 带有“Cloud”，但是它并不是针对云计算的解决方案，而是在 Spring Boot 基础上构建的，用于快速构建分布式系统的通用模式的工具集。

使用 Spring Cloud 开发的应用程序非常适合在 Docker 或者 PaaS 上部署，所以又叫云原生应用。云原生可以简单理解为面向云环境的软件架构。

既然是工具集，那么它一定包含很多工具，我们来看下面这张图：

[![API网关性能比较：NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 8]][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 8]![20200831144041264.gif][]

这里由于仅涉及到 API 网关的对比，因此我不逐一介绍其他工具了。

Spring Cloud 对 Zuul 进行了整合，但从 Zuul 来看，没有大变化，但是 Spring Cloud 整个框架经过了组件的集成，提供的功能远多于 Netflix Zuul，可能对比时会出现差异。

## 3.4 Service Mesh 之 Linkerd ##

我想 Turgay Celik 博士把 Linkerd 作为对比对象之一，可能是因为 Linkerd 为云原生应用提供弹性的 Service Mesh，而 Service Mesh 能够提供轻量级高性能网络代理，并且也提供微服务框架支撑。

从介绍来看，linkerd 是我们面向微服务的开源 RPC 代理，它直接立足于 Finagle（Twitter 的内部核心库，负责管理不同服务间之通信流程。事实上，Twitter 公司的每一项在线服务都立足于 Finagle 构建而成，而且其支持着每秒发生的成百上千万条 RPC 调用）构建而成，设计目标在于帮助用户简化微服务架构下的运维，它是专用于处理时间敏感的服务到服务的通信基础设施层。

和 Spring Cloud 类似，Linkerd 也提供了负载均衡、熔断机器、服务发现、动态请求路由、重试和离线、TLS、HTTP 网关集成、透明代理、gRPC、分布式跟踪、运维等诸多功能，功能是相当全了，为微服务框架的技术选型又增加了一个。由于没有接触过 Linkerd，所以暂时无法从架构层面进行分析，后续会补充这方面的内容，自己来做一次技术选型。

## 4 性能测试 ##

## 4.1 A性能测试场景 ##

Turgay Çelik 博士的那篇文章里使用了 Apache 的 HTTP 服务器性能评估工具 AB 作为测试工具。注意，由于他是基于亚马逊（AWS）公有云的进行的测试，可能和你实际物理机上的测试结果有出入。

实验中启动了客户端和服务端两台机器，分别安装多个待测试服务，客户端通过几种方式分别访问，尝试获取资源。测试方案如下图所示：

[![API网关性能比较：NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 9]][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 9]![20200831144041209.gif][]

Turgay Çelik 博士的这次测试选择了三个环境，分别是：

1.  单 CPU 核，1GB 内存：用于比较 Nginx 反向代理和 Zuul（去除第一次运行后的平均结果）；
2.  双 CPU 核，8GB 内存：用于比较 Nginx 反向代理和 Zuul（去除第一次运行后的平均结果）;
3.  8 个核 CPU，32GB 内存：用于比较 Nginx 反向代理、Zuul（去除第一次运行后的平均结果）、Spring Cloud Zuul、Linkerd。

测试过程均采用 200 个并行线程发送总共 1 万次请求，命令模板如下所示：

> ab -n 10000 -c 200 HTTP://`<server-address>`/`<path to resource>`

**注意：由于 Turgay Çelik 博士的测试过程中是基于 Zuul 1 进行的测试，所以性能上较差，不能真实反映当前 Zuul 版本的性能状况，后续文章我会自己做实验并发布结果。**

**[![API网关性能比较：NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 10]][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 10]**

**[![API网关性能比较：NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 11]][API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 11]**![20200831144041269.gif][]

从上面的结果来看，单核环境下，Zuul 的性能最差（950.57 次 /s），直接访问方式性能最好（6519.68 次 /s），采用 Nginx 反向代理方式较直接访问方式损失 26% 的性能（4888.24 次 /s）。在双核环境下，Nginx 的性能较 Zuul 性能强接近 3 倍（分别是 6187.14 次 /s 和 2099.93 次 /s）。**在较强的测试环境下（8 核），直接访问、Nginx、Zuul 差距不大**，但是 Spring Cloud Zuul 可能由于内部整体消耗，导致每秒的请求数只有 873.14。

### 4.1.1 小结 ###

从产品思维来看，API 网关负责服务请求路由、组合及协议转换。客户端的所有请求都首先经过 API 网关，然后由它将请求路由到合适的微服务。API 网关经常会通过调用多个微服务并合并结果来处理一个请求，它可以在 Web 协议（如 HTTP 与 WebSocket）与内部使用的非 Web 友好协议之间转换，所以说作用还是很大的，因此技术方案选型对于整个系统来说也有一定重要性。

从我所理解的这四款组件的设计原理来看，**Zuul1 的设计模式和 Nigix 较像，每次 I/O 操作都是从工作线程中选择一个执行，请求线程被阻塞直到工作线程完成**，但是差别是 Nginx 用 C++ 实现，Zuul 用 Java 实现，而 JVM 本身有第一次加载较慢的情况。**Zuul2 的性能肯定会较 Zuul1 有较大的提升**，此外，Zuul 的第一次测试性能较差，但是从第二次开始就好了很多，可能是由于 JIT（Just In Time）优化造成的吧。

而对于 Linkerd，它本身是对于资源比较敏感的一种网关设计，所以在通用环境下拿它和其他网关实现相比较，可能会出现不准确的结果。

英文原文链接如下：[ https://engineering.opsgenie.com/comparing-api-gateway-performances-nginx-vs-zuul-vs-spring-cloud-gateway-vs-linkerd-b2cc59c65369][https_engineering.opsgenie.com_comparing-api-gateway-performances-nginx-vs-zuul-vs-spring-cloud-gateway-vs-linkerd-b2cc59c65369]

## 4.2 B性能测试场景 ##

原文：[https://zhuanlan.zhihu.com/p/91636902][https_zhuanlan.zhihu.com_p_91636902]

**对A测试存在反驳意见**

A性能测试场景使用 Apache Benchmark 进行压力测试，得出的结论和预期的大相径庭，基于 rxNetty 的 Spring Cloud Gateway 比 Zuul 表现还差一大截，而且在进行长连接测试的时候 Spring Cloud Gateway 直接卡死。

这个问题在 github 的 spring-cloud-gateway 的 Issues 区早有提及： [Throughput problems when compared with Netflix Zuul and Nginx][]

Issue 被提出是因为有人提出用 Apache Benchmark 对 Spring Cloud Gateway, Netflix Zuul 和 Nginx 进行压测，发现结果如下：

![format_png][]

通过 Issue 的回复区的: [Add support for HTTP 1.0][] 关联问题，我们可以找到很多关于 rxNetty 不支持 HTTP1.0 的 Issues，这里列出来几个，有兴趣的读者可以点进去看看：

*  [Add HTTP 1.0 support][]
 *  [Buffering of output in Spring Web Reactive with Netty too aggressive][]
 *  [Add HTTP 1.0 support on Reactor Netty][]

至此，**得出 Apache Benchmark 并不能很好地测试出网关的性能，转而使用 wrk 进行测试**（Spring Cloud Gateway 官方使用的性能测试工具也是这个，后文会有提及）。wrk 默认工作于长连接模式，有效地减少了断连建连的损耗，可以比较真实地反映出网关的性能。

**对原始服务进行测试：**

1.  运行命令: wrk -t12 -c100 -d300s [http://192.168.0.5:8080/checked-out][http_192.168.0.5_8080_checked-out]
2.  得到结果如下：

Running 5m test @ http://192.168.0.5:8080/checked-out
     12 threads and 100 connections
     Thread Stats Avg Stdev Max +/- Stdev
     Latency 2.94ms 1.18ms 56.41ms 81.59%
     Req/Sec 2.76k 228.24 3.76k 72.32%
     9906220 requests in 5.00m, 1.25GB read
    Requests/sec: 33014.70
    Transfer/sec: 4.26MB

1.  根据测试结果，可以得到延时服务的 RPS 和平均延时为：

*  RPS：33014.70 请求/秒
 *  Average Latency: 2.94ms

### **4.2.1 Netflix Zuul** ###

1.运行命令: wrk -t12 -c100 -d300s [http://192.168.0.5:8081/checked-out][http_192.168.0.5_8081_checked-out]

2.得到结果如下：

Running 5m test @ http://192.168.0.152:8081/checked-out
     12 threads and 100 connections
     Thread Stats Avg Stdev Max +/- Stdev
     Latency 12.39ms 21.27ms 1.15s 91.90%
     Req/Sec 1.10k 264.62 2.09k 72.43%
     3953807 requests in 5.00m, 735.99MB read
    Requests/sec: 13175.21
    Transfer/sec: 2.45MB

3.根据测试结果，可以得到 Netflix Zuul 的 RPS 和平均延时为：

*   *  RPS：13175.21 请求/秒
     *  Average Latency: 12.39ms

4.在性能测试的过程中使用 top 看一下 CPU 使用情况，基本满负载运行：

![format_png 1][]

### **4.2.2 Spring Cloud Gateway** ###

1.运行命令: wrk -t12 -c100 -d300s [http://192.168.0.152:8082/checked-out][http_192.168.0.152_8082_checked-out]

2.得到结果如下：

Running 5m test @ http://192.168.0.152:8082/checked-out
     12 threads and 100 connections
     Thread Stats Avg Stdev Max +/- Stdev
     Latency 4.95ms 9.96ms 539.29ms 98.96%
     Req/Sec 1.82k 222.74 2.39k 91.81%
     6507221 requests in 5.00m, 850.19MB read
    Requests/sec: 21685.14
    Transfer/sec: 2.83MB

3.根据测试结果，可以得到 Spring Cloud Gateway 的 RPS 和平均延时为：

*   *  RPS：21685.14 请求/秒
     *  Average Latency: 4.95ms

4.在性能测试的过程中使用 top 看一下 CPU 使用情况，基本满负载运行：

![format_png 2][]

### **4.2.3 ServiceComb EdgeService** ###

1.运行命令: wrk -t12 -c100 -d300s [http://192.168.0.152:8083/rest/thirdPartyService/checked-out][http_192.168.0.152_8083_rest_thirdPartyService_checked-out]

2.得到结果如下：

Running 5m test @ http://192.168.0.152:8083/rest/thirdPartyService/checked-out
     12 threads and 100 connections
     Thread Stats Avg Stdev Max +/- Stdev
     Latency 3.80ms 4.67ms 300.59ms 97.98%
     Req/Sec 2.27k 309.82 3.10k 86.53%
     8144028 requests in 5.00m, 1.03GB read
    Requests/sec: 27139.19
    Transfer/sec: 3.52MB

3.提取 RPS 数据，可以得到 EdgeService 的测试 RPS 为：27139.19 请求/秒

4.在性能测试的过程中使用 top 看一下 CPU 使用情况，基本满负载运行：

![format_png 2][]

### **4.2.4 测试结果：** ###

对测试的数据进行表格分析对比，分别给出平均时延、RPS 和性能损失（（原服务的 RPS - 网关的 RPS） / 原服务的 RPS）表格如下图所示：

![format_png 3][]

可以看出，在硬件环境完全相同，并且 CPU消耗基本一致的情况下，以 RPS 为性能指标（以性能损失为性能指标的话，差异更大，这里参考业界做法，以 RPS 为指标），Spring Cloud Gateway 的性能比 Netflix Zuul 好将近一倍，而 Edge Service是 Spring Cloud Gateway 的 1.25 倍多，这还是在 EdgeService 的链接数劣于 Spring Cloud Gateway 20% 左右的情况下的数据，如果将 EdgeService 的链接数设置和 Spring Cloud Gateway 一致，性能会相差更大，有兴趣的读者可以自己尝试一下。

### **4.2.5. 小结：** ###

Spring Cloud Gateway 的性能比 Zuul 好基本上已经是业界公认的了，实际上，Spring Cloud Gateway 官方也发布过一个性能测试，这里节选如下数据：

![format_png 4][]

*\*该表格数据来自于* *[spring-cloud-gateway-bench][]*

因为我们的测试机器部署在同一个局域网，所以性能损失均要低于 spring-cloud-gateway-bench 官方的测试数据，但是从测试结果看来基本一致。网关的性能和其实现方式也有很大的关系：

*  Netflix Zuul：测试版本为 1.x，基于阻塞 io。**2.\*版本异步IO，性能可能有所提高**
 *  Spring Cloud Gateway：前面已经提到过，基于 RxNetty，异步非阻塞
 *  ServiceComb EdgeService：为 ServiceComb 的子项目，基于 vert.x，也是异步非阻塞

同样基于异步非阻塞，EdgeService 的性能明显优于 Spring Cloud Gateway，可以看出网关的性能不仅和底层实现有关，和内部实现方式和优化也有很大的关系。参考 ServiceComb 的[官方文档][Link 1]，可以发现 EdgeService 还支持接入 rest 自动变成 highway 转调，性能更高。这里因为协议层面不一样，就不放出来做对比了，对性能有极致要求的可以采用这种模式。

**在 2018 年终于发布了 Zuul 2.x 之后，Netflix 给出了一个比较模糊的数据，大致 Zuul2 的性能比 Zuul1 好 20% 左右**。然而从测试数据看来即使性能提升一半也完全比不上 Spring Cloud Gateway 的，更不用说 EdgeService 了。看来 Zuul 2.x 并没有把异步非阻塞的性能发挥出来。

竞争是发展的催化剂。在这个网关服务层出不穷的年代，各公司都铆足力气打造自己的网关产品，尽量让自己的产品成为用户的第一选择。而广大开发者也在享受这样的红利，使用高性能的网关来开发自己的应用。作为广大开发者的一员，我们欣然接受这样良性竞争的出现，并且也乐于尝试市面上出现的任何新产品，谁也说不准某一个产品以后就会成为优选的代名词。虽然从现在网关的性能差距看来，后发优势明显，但在可预见的将来，各网关迟早会到达性能瓶颈，在性能差距不大并且产品稳定之后，就会有各种差异化特性出现。而等到网关产品进入百舸争流的时代之后，用户就可以不再根据性能，而是根据自己的需求选择适合的网关服务了。

# 5 总结 #

**开源项目都在不断更新，上面的测试结果只是针对当时版本进行测试，所以只能提供参考。**

**当你需要进行选型时，最好亲自测试最近版本获取最新对比数据。**

# 参考： #

[https://engineering.opsgenie.com/comparing-api-gateway-performances-nginx-vs-zuul-vs-spring-cloud-gateway-vs-linkerd-b2cc59c65369][https_engineering.opsgenie.com_comparing-api-gateway-performances-nginx-vs-zuul-vs-spring-cloud-gateway-vs-linkerd-b2cc59c65369]

[https://zhuanlan.zhihu.com/p/91636902][https_zhuanlan.zhihu.com_p_91636902]

[https://www.infoq.cn/article/comparing-api-gateway-performances][https_www.infoq.cn_article_comparing-api-gateway-performances]

[https_www.infoq.cn_article_comparing-api-gateway-performances]: https://www.infoq.cn/article/comparing-api-gateway-performances
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zdGF0aWMwMDEuaW5mb3EuY24vcmVzb3VyY2UvaW1hZ2UvYjcvMDAvYjdjYjVmNDdhODBlMDkxMGRjMWMzM2Q2MjA4MGVhMDAucG5n?x-oss-process=image/format,png
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd]: https://s3.amazonaws.com/infoq.content.live.0/articles/comparing-api-gateway-performances/zh/resources/5081-1523696432553.png
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zdGF0aWMwMDEuaW5mb3EuY24vcmVzb3VyY2UvaW1hZ2UvZmUvNWEvZmU4NjYzYTMwNDg1ZGY1NGRiNTkwM2ZmZTM1MDI3NWEucG5n?x-oss-process=image/format,png
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 1]: https://s3.amazonaws.com/infoq.content.live.0/articles/comparing-api-gateway-performances/zh/resources/3952-1523696431067.png
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zdGF0aWMwMDEuaW5mb3EuY24vcmVzb3VyY2UvaW1hZ2UvZjcvYzQvZjc5MjllNWVkZmYwYjIwMTI2YzkxN2FiZWNhM2RmYzQucG5n?x-oss-process=image/format,png
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 2]: https://s3.amazonaws.com/infoq.content.live.0/articles/comparing-api-gateway-performances/zh/resources/3193-1523696431301.png
[20200831144041215.gif]: /images/20221123/478760b0f34a4c82b24bb12e5edce1e7.png
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 3]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zdGF0aWMwMDEuaW5mb3EuY24vcmVzb3VyY2UvaW1hZ2UvOTMvM2YvOTNlYTg5MWQwNTJhNzk3NGUwYjAzN2Q4Y2MwZWM0M2YucG5n?x-oss-process=image/format,png
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 3]: https://s3.amazonaws.com/infoq.content.live.0/articles/comparing-api-gateway-performances/zh/resources/2794-1523696431461.png
[20200831144041267.gif]: /images/20221123/84174e767e3d4b10b8792f7a582015ee.png
[20200831144041300.gif]: https://img-blog.csdnimg.cn/20200831144041300.gif
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 4]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zdGF0aWMwMDEuaW5mb3EuY24vcmVzb3VyY2UvaW1hZ2UvYzgvYWMvYzgzZjI4NmY5ZmY2NDM2NmM1MWQwMzU0NTUyYjI2YWMucG5n?x-oss-process=image/format,png
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 4]: https://s3.amazonaws.com/infoq.content.live.0/articles/comparing-api-gateway-performances/zh/resources/2355-1523696431663.png
[20200831144041292.gif]: https://img-blog.csdnimg.cn/20200831144041292.gif
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 5]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zdGF0aWMwMDEuaW5mb3EuY24vcmVzb3VyY2UvaW1hZ2UvNmEvMTAvNmFiMTg3ZWVmOTAxNDBjYmNiN2Y2ZjcxOWE0MzBiMTAucG5n?x-oss-process=image/format,png
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 5]: https://s3.amazonaws.com/infoq.content.live.0/articles/comparing-api-gateway-performances/zh/resources/2176-1523696432946.png
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 6]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zdGF0aWMwMDEuaW5mb3EuY24vcmVzb3VyY2UvaW1hZ2UvZjIvNzQvZjJmNTQxMzlkYmQ4NTBlZWU2ZWI4YWVmOTI5MjU5NzQucG5n?x-oss-process=image/format,png
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 6]: https://s3.amazonaws.com/infoq.content.live.0/articles/comparing-api-gateway-performances/zh/resources/1707-1523696433087.png
[20200831144041296.gif]: /images/20221123/628bd4f09a854db2bd751330d6a33107.png
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 7]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zdGF0aWMwMDEuaW5mb3EuY24vcmVzb3VyY2UvaW1hZ2UvMDYvOWQvMDY5YzRjMjlhNDk4NmFlYTIxOTg5OGNmZmJlOGZkOWQucG5n?x-oss-process=image/format,png
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 7]: https://s3.amazonaws.com/infoq.content.live.0/articles/comparing-api-gateway-performances/zh/resources/1458-1523696433214.png
[20200831144041270.gif]: /images/20221123/29106ae7d38c41979d5bfda750d8616d.png
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 8]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zdGF0aWMwMDEuaW5mb3EuY24vcmVzb3VyY2UvaW1hZ2UvOTkvYjEvOTlmNTY4YTk3NjgwZTQ5MTc2ODg4MWY1MThhNzU4YjEucG5n?x-oss-process=image/format,png
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 8]: https://s3.amazonaws.com/infoq.content.live.0/articles/comparing-api-gateway-performances/zh/resources/1269-1523696433477.png
[20200831144041264.gif]: /images/20221123/7304f2c422f2499485c79cd1fddfe07a.png
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 9]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zdGF0aWMwMDEuaW5mb3EuY24vcmVzb3VyY2UvaW1hZ2UvMmEvZDAvMmFmMjBjYWM3Zjc2N2UzNGM2NjczOTg5MTE4OTVjZDAucG5n?x-oss-process=image/format,png
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 9]: https://s3.amazonaws.com/infoq.content.live.0/articles/comparing-api-gateway-performances/zh/resources/8810-1523696432702.png
[20200831144041209.gif]: /images/20221123/b8270f263c1645b9854fec74a0c93828.png
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 10]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zdGF0aWMwMDEuaW5mb3EuY24vcmVzb3VyY2UvaW1hZ2UvYmMvNGEvYmNlNjQ3OWI1MjUyMzgzOGM3MzAwZjViNjkxODlmNGEucG5n?x-oss-process=image/format,png
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 10]: https://s3.amazonaws.com/infoq.content.live.0/articles/comparing-api-gateway-performances/zh/resources/8011-1523696433342.png
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 11]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zdGF0aWMwMDEuaW5mb3EuY24vcmVzb3VyY2UvaW1hZ2UvNTUvYTcvNTU3MTFlNGFkN2FmODNmY2FiMjNjZTQwM2MzOTJkYTcucG5n?x-oss-process=image/format,png
[API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd_API_NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 11]: https://s3.amazonaws.com/infoq.content.live.0/articles/comparing-api-gateway-performances/zh/resources/8112-1523696433650.png
[20200831144041269.gif]: /images/20221123/b4f2804a945442c09fa518fc8bc8a89f.png
[https_engineering.opsgenie.com_comparing-api-gateway-performances-nginx-vs-zuul-vs-spring-cloud-gateway-vs-linkerd-b2cc59c65369]: https://engineering.opsgenie.com/comparing-api-gateway-performances-nginx-vs-zuul-vs-spring-cloud-gateway-vs-linkerd-b2cc59c65369
[https_zhuanlan.zhihu.com_p_91636902]: https://zhuanlan.zhihu.com/p/91636902
[Throughput problems when compared with Netflix Zuul and Nginx]: https://link.zhihu.com/?target=https%3A//github.com/spring-cloud/spring-cloud-gateway/issues/124
[format_png]: /images/20221123/4adf75e13ef942bf9601758dc3f8a517.png
[Add support for HTTP 1.0]: https://link.zhihu.com/?target=https%3A//github.com/reactor/reactor-netty/issues/21
[Add HTTP 1.0 support]: https://link.zhihu.com/?target=https%3A//github.com/ReactiveX/RxNetty/issues/575
[Buffering of output in Spring Web Reactive with Netty too aggressive]: https://link.zhihu.com/?target=https%3A//github.com/spring-projects/spring-framework/issues/19510
[Add HTTP 1.0 support on Reactor Netty]: https://link.zhihu.com/?target=https%3A//github.com/spring-projects/spring-framework/issues/19531
[http_192.168.0.5_8080_checked-out]: https://link.zhihu.com/?target=http%3A//192.168.0.5%3A8080/checked-out
[http_192.168.0.5_8081_checked-out]: https://link.zhihu.com/?target=http%3A//192.168.0.5%3A8081/checked-out
[format_png 1]: /images/20221123/8665697044884426a0fa6d8be920669d.png
[http_192.168.0.152_8082_checked-out]: https://link.zhihu.com/?target=http%3A//192.168.0.152%3A8082/checked-out
[format_png 2]: /images/20221123/c5f852e1c1554f17ab0da1954f3a72d2.png
[http_192.168.0.152_8083_rest_thirdPartyService_checked-out]: https://link.zhihu.com/?target=http%3A//192.168.0.152%3A8083/rest/thirdPartyService/checked-out
[format_png 3]: /images/20221123/b25ac93ec26a440e9972aa91868fca8d.png
[format_png 4]: /images/20221123/5a8d5a9e6fb749a483d0798ab5e033ca.png
[spring-cloud-gateway-bench]: https://link.zhihu.com/?target=https%3A//github.com/spencergibb/spring-cloud-gateway-bench
[Link 1]: https://link.zhihu.com/?target=https%3A//docs.servicecomb.io/java-chassis/zh_CN