网关性能大 PK，Spring Cloud Gateway 让人大失所望！，java 教程 pdf 百度云下载

在这篇博客文章中，我们将解释如何设置测试环境并比较下面 API 网关的性能：

Zuul，Nginx，SpringCloud Gateway 和 Linkerd.

事实上，我们还有其他选择，比如[Envoy 和[UnderTow..我们将使用这些工具进行类似的测试，并在的博客文章中分享结果

Zuul 视乎还是挺好的，因为它是用 Java 开发的，并且有 Spring 框架的强大支持。已经有一些博客文章比较 ZUUL 和 NGIXX，但我们也想评估 Spring cloud gateway 和 Linkerd 的性能。此外，我们计划进行进一步的负载测试，所以我们决定设置自己的测试任务。

我们首先安装 NGIX 到 AWS EC2 T2 微实例，根据官方的 NGNX 文档。这个环境是我们的初始测试环境，并且我们将 ZUUL 和 Spring cloud Gateway 安装添加到这个环境中。NGNIX Web 服务器托管静态资源，并为 NGIX、ZUUL 和 cloud Gateway 定义了反向代理。我们还启动了另一个 T2 微服务 EC2 来执行请求（客户端 EC2）。


图中的虚线箭头是我们的测试路径。其中有四个：

l 直接存取

l 通过 NGIX 反向代理访问

l 通过 ZUL 访问

l 通过 Spring 云网关访问

l 通过 Linkerd 访问

我们知道你不耐烦地看到结果，所以让我们先给出结果，然后再详细说明。

1.1. 性能基准总结

1.1.1. 测试策略

我们使用 Apache HTTP 服务器基准工具。在每次测试运行中，我们用 200 个并发线程完成了 10000 个总请求。

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

我们在三个不同的 AWS EC2 服务器配置上进行了测试。我们在每一步缩小测试用例以获得最终的结果

1、我们在第一步中执行了额外的直接访问测试来查看代理的开销，但是由于直接访问不是我们的选择，所以我们没有在下面的步骤中执行这个测试。

2、由于 Spring Cloud G

【一线大厂Java面试题解析+核心总结学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

ateway 使用部是特别多，再最后一步再进行测试。

3、ZUUL 的性能在第一次调用后的后续调用更好。我们认为这可能是由于 JIT（准时）优化在第一次调用上进行的，所以我们称 ZUUL 运行的第一个为“热身”所以下面的汇总表中显示的值是在预热性能之后。

4、我们知道 Linkerd 是一个资源密集型的代理，所以我们在最后一个步骤与最高的资源配置进行了比较。

1.2. 测试配置

**T2、**Micro 单核 CPU、1GB 内存：我们运行直接访问、NGNIX 反向代理和 ZUUL（热身后）的测试。

M4.Large? 双核 CPU，8GB 的内存：我们比较了 NGIX 反向代理和 ZUUL（热身后）的性能。

M4.2xLarge 8 内核 CPU，32GB 内存：我们比较了 NGIX 反向代理、ZUUL（热身后）、Spring cloud gateway 和 Linkerd 的性能。

1.3. 测试结果

性能测试的结果如下


第一张图显示每一秒不同的网关处理的请求数，可见在硬件都很糟糕的情况下 nginx 是不错的选择，如果硬件性能都提升的情况下，Zuul 和 Linkerd 性能能反超 nginx

但是 SpringCloud Gateway 的性能有点让人失望


这个图也是同样，测试的是每次请求的平均时间，单位是毫秒，在单核 cpu 的情况下 zuul 表现确实差强人意，但一旦到了服务器的硬件条件下，zuul 的性能确是 4 个中最好的

但是不管从哪个层面来看 geteway 的性能都不能让人满意

1.4. 测试详细

1.4.1. 直接访问

首先，我们在没有任何代理的情况下直接访问静态资源。结果如下。平均每次请求时间为 30 毫秒。


1.4.2. 通过 nginx 反向代理访问的情况

在第二个测试中，我们通过 NGNX 反向代理访问资源。每次请求的平均时间是 40 毫秒。我们可以说，与上一部分中所解释的直接访问相比，nginx 的性能增加了部分开销


1.4.3. 使用 Zuul 来做代理的情况


在配置文件里面仅仅做些简单的路由配置，其中的 yml 文件如下：