作为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 Benchmarking工具。每次测试运行时，我们使用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：
Zuul的Spring Boot主要应用
这是我们的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的比较已在“基准摘要”部分末尾给出。
下一步是什么？
在此博客文章中，我们将Zuul，Nginx，Linkerd和Spring Cloud Gateway与Apache Http Server Benchmarking工具 ab的性能进行了比较。我们计划要遵循的下一步是：
- 我们将评估特使。实际上，Envoy不仅仅是一个API网关；它是一个服务网格，但它也提供了可以在应用程序前端使用的API网关。
- Undertow还具有反向代理功能，因此我们也将对其进行评估。
- Netflix将Zuul重新设计为基于Netty的非阻塞应用程序。这个新版本称为“ Zuul 2”。每当正式发布新Zuul的开源版本时，我们将进行基准测试并分享结果。
- Spring Cloud Gateway仍在开发中。它是用Java开发的基于Netty的非阻塞网关，因此对我们来说是一个不错的选择。我们将评估其正式版本的性能。
- 一些API网关（Zuul 1，Ngnix）处于阻塞状态，而其他（Zuul 2，Linkerd，Envoy）处于非阻塞状态。阻塞体系结构有利于简单的开发和跟踪请求，但是阻塞性质会导致可伸缩性问题。非阻塞架构在开发和可跟踪性方面更为复杂，但在可伸缩性和弹性方面则更好。我们将决定稍后将使用阻塞还是非阻塞架构。
- 我们将使用Gatling执行测试。我们将在下一篇博客文章中分享结果。
我们将在后续的博客文章中分享每一步的结果，敬请期待！
