Nginx，Zuul ，Spring Cloud 和 Linkerd 网关

在OPSGENIE，我们在头部和产品特征方面积极地发展。为了给你一些想法，我们的工程团队去年只增长了15到50。为了扩大开发团队，我们通过遵守两个披萨团队规则，将工程权力分为八人队。

正如您所期望的那样，我们目前的产品有点单体架构。开发和运营它在团队的平行开发工作方面挑战，CI / CD（持续整合/连续交付）过程等。我们正在遵循当前的趋势，并致力于从整体到微服务架构的转换。您可以了解有关Martimices架构的更多信息，以及Martin Fowler本文的优势。

有一些推荐的架构模式用于应用微服务概念。其中一个模式是API网关。API Gateway是所有客户端的单个入口点。API网关以两种方式之一处理请求。某些请求只是将/路由到适当的服务。它通过扇动到多个服务来处理其他请求。

API Gateway模式是MicroService架构的良好起点，因为它使得能够将特定的请求路由到从单体中分离的不同服务。实际上API Gateway不是我们的新概念。直到到目前为止，我们一直在使用Nginx作为前面的API网关，但我们希望在微服务过渡的背景下重新评估我们的决定。我们关心性能，便于可扩展性和额外的能力，例如速率限制。第一步是评估重载下替代品的性能，以确保它们将足够扩展以满足我们的需求。

在本博客文章中，我们解释了我们如何设置测试环境，并比较替代API网关的性能：Zuul 1，Nginx，Spring云网关和Linkerd。事实上，我们有其他替代品，如Lyft的特使和承诺。我们将与这些工具进行类似的测试，并在将来的博客帖子中分享结果。

Zuul 1似乎对我们很有前途，因为它与Java开发并具有弹簧框架的强大支持。已经有一些博客帖子比较Zuul与Nginx，但我们还希望评估Spring云网关和链接器的性能。此外，我们计划执行进一步的负载测试，因此我们决定设置自己的测试工作台。

为了评估API网关的性能，我们创建了独立于OPSGENIE产品的隔离测试环境。我们使用Apache HTTP服务器基准测试工具 - 用于基准。

我们首先将nginx安装到AWS EC2 T2.MICro实例根据官方nginx文档。此环境是我们的初始测试环境，我们为此环境添加了Zuul和Spring Cloud Gateway安装。Nginx Web服务器驻留静态资源，我们将反向代理定义为NGINX，Zuul和Spring云网关的Web服务器。我们还启动了另一个T2.Micro EC2来执行请求（客户端EC2）。

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

• 直接访问
• 通过nginx反向代理访问
• 通过Zuul访问
• 通过Spring Cloud 网关访问
• 通过Linkerd访问

我们知道您对看到结果不耐烦，因此让我们先给出结果，并稍后详细说明。

性能基准摘要

测试策略

我们使用Apache HTTP Server基准测试工具。我们在每次测试运行时使用200个并发线程提供了10,000个总申请。

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

我们对三个不同AWS EC2服务器配置进行了测试。我们在每一步都缩小了测试用例，以进一步澄清：

• 我们在只需第一步即可看到代理的开销即可进行额外的直接访问测试，但由于我们无法为我们提供直接访问，因此我们没有对以下步骤执行此测试。
• 由于Spring Cloud网关仍未正式发布，我们在最后一步中评估它。
• Zuul在第一个通信后的后续通信的表现更好。我们认为这可能导致JIT（正常）在第一个呼叫上执行优化，因此我们称之为Zuul的第一个作为“hormup”。下面的摘要表中显示的值在预热性能之后。
• 我们知道Linkerd是一个资源密集型代理，因此我们将其与最高资源配置的最后一步进行比较。

测试配置

T2.Micro - 单核CPU，1GB内存：我们运行直接访问的测试，Nginx反向代理和Zuul（热身后）。

M4.LARGE - 双核CPU，8GB内存：我们比较了Nginx反向代理和Zuul的性能（预热后）。

M4.2xlarge - 8核心CPU，32GB内存：我们比较了Nginx反向代理，Zuul（在Harmup之后），Spring云网关和Linkerd的性能。

试验结果

性能基准摘要如下：

测试细节

直接访问请求

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

通过nginx反向代理访问

在我们的第二个测试中，我们通过Nginx反向代理访问了资源。每个请求的平均时间为40毫秒。我们可以说，与前一节中解释的直接访问相比，nginx反向代理平均增加了％33开销。

通过Zuul反向代理访问

之后，我们使用主要方法创建了一个Spring启动应用程序：

这是我们的application.yml文件：

初始Zuul测试的结果如下：

对于直接访问和NGINX反向代理，每个对NGINX的每个请求的时间分别为30ms和40毫秒。首次运行的每个请求的时间是388ms。如其他博客帖子所述，JVM warmup可能有所帮助。当我们重新开始测试时，我们得到以下结果：

预热后Zuul代理更好地执行（每个请求的时间为200ms），但与Nginx反向代理相比，仍然没有那么好，得分为40ms。

如果我们将服务器升级到m4.large，该怎么办？

如图1所示，服务器是T2.micro EC2，其具有单核和1GB的内存。nginx是一个本机C ++应用程序，Zuul是基于Java的。我们知道Java应用程序对于资源有点 :) 更苛刻。因此，我们将服务器更改为m4.large实例，其中包含两个CPU内存和8GB内存。

我们再次运行nginx和Zuul反向代理测试，结果如下：

如上图所示，对于Nginx和Zuul，每秒值的请求分别为32ms和95ms。这些结果比T2.MICRO的测试结果更好，这些结果为40ms和200ms。

有效的批评是我们通过Spring Boot应用程序使用Zuul来引入额外的开销。如果我们将Zuul作为独立应用程序运行Zuul，大多数可能会更好。

如果我们将服务器升级到M4.2xlarge，该怎么办？

我们还评估有八个核心和32GB内存的M4.2xlarge服务器。NGNIX和ZUUL的结果在下面的附图中给出：

Zuul在M4.2xlarge服务器上表现出比NGNIX更好。我们执行了一些研究，以了解NetFlix使用哪种类型的EC2实例用于主机Zuul实例，但我们找不到有关它的任何信息。在一些博客帖子中，人们抱怨Zuul的表现，并询问Netflix如何衡量它;我们认为这是答案;正如所说，Zuul是CPU密集型应用。

Linkerd的基准

Linkerd是一个CNCF云本机计算基础成员项目。它是Scala中开发的服务网格应用程序。除了服务网格功能之外，它还提供反向代理功能，例如服务发现。我们评估了LinkerD的性能，结果如下所示。Linkerd的性能与Zuul非常接近。

Spring Cloud 网关的基准

Spring Cloud 也在开发网关模块。虽然它仍然没有正式发布，但我们认为值得与其他替代方案进行比较。因此，我们根据我们的测试环境修改了网关应用的样本应用。

我们使用Apache HTTP服务器基准测试工具运行相同的性能测试，该工具发送10,000个请求，其中包含200个并发线程。结果如下图所示：

如图所示，Spring Cloud 网关可以处理每秒873个请求，并且每个请求的平均时间为229ms。根据我们的测试，Spring网关的性能无法达到Zuul，linkerd和nginx的水平，至少是GitHub上当前代码库的情况。上面给出了Nginx，Zuul，Linkerd和Spring云网关的比较，在基准摘要部分结束时提供。

下一步是什么？

在此博客文章中，我们将Zuul，Nginx，Linkerd和Spring云网关的性能进行了比较了Apache HTTP Server基准工具AB。我们计划遵循的后续步骤是：

• 我们要评估细节。实际上，Envoy不仅仅是一个API网关;它是一个服务网格，但它还提供了一个API网关，可以在应用程序的前侧使用。
• Undertow也具有反向代理功能，因此我们也将评估它。
• Netflix将Zuul重新设计为基于Netty的非阻塞应用程序。这个新版本称为“Zuul 2”。我们将在正式发布的情况下，执行新Zuul的基准并分享新Zuul的结果。
• Spring Cloud网关仍在开发中。它是一个基于Netty的非阻塞网关，用Java开发，所以这是我们的好候选人。我们将评估其官方发布的表现。
• 一些API网关（Zuul 1，Ngnix）是阻塞的，其他API网关（Zuul 2，Linkerd，Envoy）是非阻塞的。阻塞架构对于简单的开发和追踪请求是好的，但阻塞性质可能导致可扩展性问题。在开发和可追溯性方面，非阻塞架构更复杂，但它们在可扩展性和弹性方面更好。我们将决定是否稍后使用阻塞或非阻塞体系结构。
• 我们将以Gatling进行测试。我们将在我们的下一个博客文章中分享结果。

(本文由闻数起舞翻译自Muhammed DEM?RBA?的文章《Comparing API Gateway Performances: NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd》，转载请注明出处，原文链接：https://engineering.opsgenie.com/comparing-api-gateway-performances-nginx-vs-zuul-vs-spring-cloud-gateway-vs-linkerd-b2cc59c65369)