一文看懂Zuul, Nginx, Spring Cloud, Linkerd性能差异

原创： Turgay ?elik

导语：API Gateway是实现微服务重要的组件之一。面对诸多的开源API Gateway，如何进行选择也是架构师需要关注的焦点。本文作者对几个较大的开源API Gateway进行了压力测试，对于架构师来说，相信可以提供不少帮助。

在这篇文章中，我们讲解如何设置我们的测试环境，并且对比这些网关的性能： Zuul 1[5], Nginx[6], Spring Cloud Gateway[7], Linkerd[8]。事实上，我们还有另外两个选择Envoy[9]和 UnderTow[10]。我们将会对这些工具做相同的测试，并且在后面的博客中公布测试结果。

Zuul 1由于使用Java开发，并且对Spring框架有很强的支持，对我们来说似乎很合适。尽管有很多文章对比过Zuul和Nginx，但是我们还想跟Spring Cloud Gateway和Linkerd一起评估。此外，我们计划做高负载的测试，所以我们决定设置我们自己的测试环境。

为了评估API网关各自的性能，我们为OpsGenie产品创建了一个隔离的独立测试环境。我们使用Apache的ab作为压测工具。

首先，我们参照Nginx文档在一个单核1G内存的AWS EC2实例上安装了一个Nginx。这个环境是我们的初始测试环境，然后我们安装Zuul和Spring Cloud Gateway到这个环境中。Nginx为静态资源提供web服务，我们通过Nginx、Zuul和Spring Cloud Gateway定义反向代理到这个web服务。我们同样启动了另外一个单核1G内存的EC2实例发起压测请求。

图片中的箭头是我们的测试路径。这里有4中情况：

• 直接访问
• Nginx反向代理访问
• Zuul访问
• Spring Cloud Gateway访问
• Linkerd访问

我们知道大家急于想看测试结果，所以，我们先给测试结果，然后再做详细说明。

性能压测总结

测试策略

我们使用Apache的ab做压测工具。我们发起总共10000个请求、使用200个并发线程分别进行压测。

我们将在3种不同配置的AWS EC2服务器上进行测试。我们会缩小每一步的测试用例的范围：

• 尽管我们不选择直接访问，但是我们在第一步额外做了直接访问的测试，用于衡量代理的理想值，这个测试我们不会在后面的步骤中进行。
• 尽管Spring Cloud Gateway依然没有官方稳定版，我们会在最后那步评估它。
• Zuul随后的性能比第一次压测的性能更好。我们估计出现这种情况的原因是第一次压测进行了JIT优化，所以我们把针对Zuul的第一次压测当成“预热”。在总结表中的值是预热之后的性能。
• 我们知道Linkerd是资源密集型代理，所以我们只在高资源配置的最后一步对比。

测试配置

T2.Micro——单核1G内存：我们对比测试直接访问、Nginx反向代理和Zuul（预热之后）。

M4.Micro?——双核8G内存：我们对比测试Nginx反向代理和Zuul（预热之后）。

M4.2xLarge——8核32G内存：我们对比测试Nginx反向代理、Zuul（预热之后）、Spring Cloud Gateway和Linkerd。

测试结果

性能压测结果如下

测试详情

直接访问

首先，我们不使用代理，直接访问静态资源。结果如下，单个请求平均30ms。

Nginx反向代理

我们的第2个测试，通过Nginx反向代理访问资源。单次请求平均耗时40ms。可以说，Nginx代理对比直接访问，平均增加了33%的耗时。

Zuul反向代理

接下来，我们创建了一个Spring Boot应用：

这是我们的application.yml文件：

Zuul第1次测试结果如下：

直接访问Nginx单次请求是30ms，通过Nginx反向代理访问是40ms。Zuul首次访问单次请求在388ms。如在另外一篇博客[12]中提到的，JVM预热会有作用。我们重新压测，结果如下：

预热后Zuul代理的性能更好（单次请求是200ms），但是跟Nginx反向代理的40ms对比，仍然不好。

服务器升级到双核8G内存会怎么样呢？

前面的测试服务器配置是单核1G内存。Nginx是C++应用，Zuul是基于Java的。我们知道，Java应用对环境要求更苛刻。所以我们将服务器配置换成双核8G内存实例。

我们重新对Nginx和Zuul做压测，结果如下

由上面图片可见，Nginx反向代理和Zuul代理单次请求花费时间分别是32ms和95ms。这次压测结果比单核1G内存的40ms和200ms更好。

由此可见，使用Spring Boot部署的Zuul有额外的消耗。很可能Zuul的独立应用会有更好的性能。

服务器升级到8核32G内存会怎么样呢？

我们继续评估8核32G内存的服务器配置。Nginx和Zuul的压测结果如下

在8核32G的配置上，Zuul跑赢了Nginx。我们想找到Netflix的Zuul实例部署在哪种类型的ec2服务器上，但是我们没有找到任何信息。一些博客中，有人说了Zuul的性能，并且询问Netflix如何处理的。我们认为这可能是答案，Zuul使用CPU绑定。

Linkerd压测

Linkerd是CNCF的项目，是Scala开发的service mesh应用。他提供反向代理能力用于扩展service mesh能力，例如服务发现。我们评估Linkerd性能并且给出如下结果。Linkerd跟Zuul的性能很接近。

Spring Cloud Gateway性能测试

Spring Cloud组织也开发了一个Gateway模块。尽管官方还没有正式版本，我们觉得还是有必要跟其他选择进行对比。但是，我们按照我们的测试环境修改了Gateway的例子。

我们用Apache的ab使用了20个线程、发了总共10000个请求做了同样的压测。测试结果在下面这张图中：

由上图可见，Spring Cloud Gateway每秒能处理873个请求，单次请求平均耗时229ms。根据我们的测试结果，Spring Cloud Gateway不能达到Zuul、Linkerd、Nginx的性能水平，这是他们目前最新版本测试的结果。Nginx、Zuul、Linkerd和Spring Cloud Gateway的最后一次测试结果上面已经给出。

最后，我自己是一名从事了多年开发的Java老程序员，辞职目前在做自己的Java私人定制课程，今年年初我花了一个月整理了一份最适合2019年学习的Java学习干货，可以送给每一位喜欢Java的小伙伴，想要获取的可以关注我的头条号并在后台私信我：01，即可免费获取。