作为OpsGenie，我们在员工人数和产品功能方面都在积极发展。为了给您一些想法，我们的工程团队从去年的15人增加到了50人。为了扩大开发团队，我们遵循两个比萨饼团队规则将工程能力划分为八人团队。

如您所料，我们当前的产品有些单片。在团队的并行开发工作，CI / CD（连续集成/连续交付）流程等方面，开发和操作它具有挑战性。我们正在顺应当前的趋势，并致力于从整体式架构过渡到微服务架构。你可以阅读更多关于微服务架构和Martin Fowler的它的好处此文章。

有一些建议的体系结构模式可用于应用微服务概念。这些模式之一是API网关。API网关是所有客户端的单个入口点。API网关以两种方式之一处理请求。一些请求仅被代理/路由到适当的服务。它通过扇出多个服务来处理其他请求。

API网关模式是微服务体系结构的一个很好的起点，因为它可以将特定的请求路由到我们从整体中分离的不同服务。实际上，API网关对我们来说不是一个新概念。到目前为止，我们一直在整体应用程序之前使用Nginx作为API网关，但是我们想在微服务转换的背景下重新评估我们的决定。我们关心性能，易扩展性和速率限制等附加功能。第一步是评估替代方案在重负荷下的性能，以确保它们的规模足以满足我们的需求。

在此博客文章中，我们解释了如何设置测试环境并比较替代API网关的性能：Zuul 1，Nginx，Spring Cloud Gateway和Linkerd。实际上，我们还有其他选择，例如Lyft的Envoy和UnderTow。我们将使用这些工具执行类似的测试，并在以后的博客文章中分享结果。

Zuul 1对我们来说似乎很有希望，因为它是用Java开发的，并得到Spring框架的大力支持。已经有一些博客文章将Zuul与Nginx进行了比较，但是我们还想评估Spring Cloud Gateway和Linkerd的性能。此外，我们计划执行进一步的负载测试，因此我们决定设置自己的测试工作台。

为了独立评估API网关的性能，我们创建了独立于OpsGenie产品的隔离测试环境。我们使用了Apache Http Server基准测试工具-ab作为基准测试。

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

初始测试环境

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

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

我们知道您不耐烦看到结果，因此让我们先给出结果，然后再给出详细信息。

绩效基准摘要测试策略

我们使用了Apache HTTP Server基准测试工具。每次测试运行时，我们使用200个并发线程发出10,000个请求。

ab -n 10000 -c 200 HTTP：// <服务器地址> / <资源路径>

我们对三种不同的AWS EC2服务器配置进行了测试。我们在每个步骤中缩小了测试用例，以进一步阐明：

我们仅在第一步中执行了其他直接访问测试，以查看代理的开销，但是由于直接访问不是我们的选择，因此我们没有在后续步骤中执行此测试。由于Spring Cloud Gateway仍未正式发布，因此我们仅在最后一步对其进行了评估。在第一次通话后的后续通话中，Zuul的表现更好。我们认为这可能是由于在第一次调用时执行了JIT（及时）优化，因此我们将Zuul运行的第一个调用称为“预热”。下表汇总表中显示的值是预热性能之后的值。我们知道Linkerd是一个资源密集型代理，因此我们仅在最后一步将它与最高资源配置进行了比较。

测试配置

T2.Micro —单核CPU，1GB内存：我们进行了直接访问，Ngnix反向代理和Zuul（预热后）的测试。

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

M4.2xLarge — 8核心CPU，32GB内存：我们比较了Nginx反向代理，Zuul（预热后），Spring Cloud Gateway和Linkerd的性能。

试验结果

性能基准摘要如下：

测试细节

直接访问请求

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

直接访问静态资源

通过Nginx反向代理访问

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

Ngnix反向代理的性能

通过Zuul反向代理访问

之后，我们使用主方法创建了一个Spring Boot Application：

这是我们的application.yml文件：

初始Zuul测试的结果如下：

Zuul反向代理首次运行性能

对于直接访问和Nginx反向代理，每个Nginx请求的时间分别为30ms和40ms。每次运行Zuul的每次请求时间为388ms。如其他博客文章所述，JVM预热可能会有所帮助。当我们重新运行测试时，我们得到以下结果：

预热后的Zuul反向代理

预热后，Zuul代理的性能更好（每个请求的时间为200毫秒），但与得分为40毫秒的Nginx反向代理相比，效果仍然不佳。

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

如图1所示，服务器是t2.micro ec2，它具有单个内核和1GB内存。Nginx是本机C ++应用程序，而Zuul是基于Java的。我们知道Java应用程序有点:)要求更高。因此，我们将服务器更改为具有两个CPU核心和8GB内存的m4.large实例。

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

M4.large上的Nginx反向代理

m4.large上的Zuul反向代理（预热后）

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

一个有效的批评是，我们通过Spring Boot应用程序使用Zuul引入了额外的开销。如果我们将Zuul作为独立的应用程序运行，则很有可能会更好地执行。

如果将服务器升级到m4.2xlarge怎么办？

我们还评估了具有八个内核和32GB内存的m4.2xlarge服务器。下图给出了Ngnix和Zuul的结果：

M4.2xlarge服务器上的Nginx反向代理

M4.2xlarge服务器上的Zuul反向代理

Zuul在m4.2xlarge服务器上的性能优于Ngnix。我们进行了一些研究，以找出Netflix用于托管Zuul实例的ec2实例类型，但找不到任何有关它的信息。在一些博客文章中，人们抱怨Zuul的性能，并询问Netflix如何扩展它。我们认为这就是答案；据说，Zuul受CPU限制:)

Linkerd的基准

Linkerd是Cloud Native Computing Foundation的成员项目。它是在Scala中开发的服务网格应用程序。除了服务网格功能（例如服务发现）以外，它还提供反向代理功能。我们评估了Linkerd的性能，并在下面给出结果。Linkerd的表现与Zuul非常接近。

m4.2xlarge服务器上的Linkerd反向代理

Spring Cloud Gateway基准

Spring Cloud社区也在开发网关模块。尽管尚未正式发布，但我们认为值得将其与其他替代产品进行比较。因此，我们根据测试环境修改了网关应用程序的示例应用程序。

我们使用Apache Http Server Benchmarking Tool进行了相同的性能测试，该工具使用200个并发线程发送10,000个请求。结果如下图所示：

m4.2xlarge服务器上的Spring Cloud Gateway

如图所示，Spring Cloud Gateway每秒可以处理873个请求，每个请求的平均时间为229ms。根据我们的测试，Spring Cloud Gateway的性能无法达到Zuul，Linkerd和Nginx的水平，至少在当前基于Github的代码库中是如此。Nginx，Zuul，Linkerd和Spring Cloud Gateway的比较已在“基准摘要”部分末尾给出。