网关性能大 PK，Spring Cloud Gateway 让人大失所望！
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 Gateway 使用部是特别多，再最后一步再进行测试。
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 文件如下：
最后 zuul 的测试结果如下：
直接访问和用 nginx 反向代理访问的时间为 30ms 和 40ms，第一次使用 zuul 的请求时间是 388ms,效果非常不理想，当然可以使用 JVM 预热，会对 zuul 的性能有所提升，下面是进一步测试的情况。
ZUUL 代理在预热（每个请求的时间为 200 毫秒）后表现更好，但与 40ms 的 NGIX 反向代理相比，它仍然不太好。
上面做的测试是使用单核 CPU 和 1G 内存的服务器，Nginx 是一个本地的 C++应用测试，而 ZUUL 是 JAVA 开发的，我们知道 Java 应用程序有点：要求更高。因此，我们将服务器更改为具有两个 CPU 内核和 8GB 内存的 M4 大型实例。
我们再次运行了 NGIX 和 ZUUL 反向代理测试，结果如下：
如上述图所示，对于 NGIX 和 ZUUL，每秒请求值分别为 32 毫秒和 95ms。这些结果比 T2 微测试的结果要好得多，分别为 40ms 和 200 ms。
一个有效的批评是，我们通过使用 ZULL 通过 Spring 启动应用程序引入额外的开销。如果我们将 ZUUL 作为独立的应用程序运行，它可能会运行得更好。
我们还评估了具有八个核心和 32GB 内存的 M4.2X 大型服务器。NGNIX 和 ZUUL 的结果在下面的数字中给出：
如你所视，这个时候 zuul 的性能已经反超 nginx 了，很多人在抱怨 zuul 的性能太差，远远没有 nginx 的性能好，其实这样的看法其实还是太片面了，在真实的项目服务器情况下 zuul 的性能不会太差。
1.4.4. Linkerd 的测试情况
这也是使用大型八个核心和 32GB 内存的 M4.2X 大型服务器，测试出的结果和 zuul 非常相近
评论