【DevOps】4大API网关压力性能测试
作为DevOps服务的研发和服务提供者，我们经常会面对不同客户不同规模的需求，包括人员的激增，不同开发部署阶段的流量保证等等。
最最开始的时候，我们提供了一键安装 部署本地的单体式的SaaS软件服务，而随着时间技术的发展，我们研发和增加更多的客户需求的产品服务，使得我们的产品有点庞大而笨重。 在团队的并行开发工作、CI/CD（持续集成/持续交付）流程等方面，开发和运行都是一项挑战。因此我们遵循当前的趋势，努力过渡从单块架构转为微服务架构。
对于应用微服务概念，有一些建议的架构模式 。其中之一是API网关 。API网关是所有客户端的单一入口点。API网关有两种请求处理方式。一些请求仅仅被代理/路由到适当的服务上。它也会处理其他请求，通过将请求分发给多个服务。
API网关模式是微服务架构的一个很好的起点，因为它能够将特定的请求路由到我们从单块中拆分出来的不同服务。实际上，API网关对我们来说并不是一个新概念。到目前为止，我们一直在单块应用程序前使用Nginx 作为API网关，但我们希望在微服务过渡的背景下重新评估我们的决策。
我们关心性能、易扩展性以及其他能力，比如速率限制。 第一步便是评估备选方案的性能，以确保它们能够满足我们的需求。
在这篇博客文章中，我将解释我们如何设置测试环境，并比较替代API网关的性能：
事实上，我们还有其他备选方案，比如Lyft的**Envoy 和UnderTow **。我们将使用这些工具进行类似测试，并在未来的博客文章中分享结果。
Zuul对我们来说似乎很有前途，因为它是使用Java开发的，而且具有Spring框架的强大支持。已经有一些博客文章将Zuul与Nginx进行了比较，但我们也想评估Spring Cloud Gateway和Linkerd的性能。此外，我们计划进行更多的负载测试，因此我们决定建立自己的测试工作台。
为了独立评估API网关的性能，我们使用Apache Http服务器基准测试工具——ab 来进行基准测试。
我们首先根据官方Nginx文档将Nginx安装到AWS EC2 t2.micro实例。这个环境是我们的初始测试环境，我们在其中添加了Zuul和Spring Cloud Gateway的安装。
Nginx web服务器托管静态资源，并为Nginx、Zuul和Spring Cloud Gateway的web服务器定义了反向代理。
我们还启动了另一个t2.micro EC2来执行请求（客户端EC2）。
虚线代表我们的测试路径，其中有以下几种：
- Direct access - 直接访问
- Access via Nginx reverse proxy - 通过Nginx反向代理访问
- Access via Zuul - 通过zuul访问
- Access via
Spring Cloud Gateway- 通过SCG访问 - Access via Linkerd - 通过Linkerd访问
性能基准摘要
测试策略
我们使用了Apache HTTP服务器基准测试工具。每次测试运行中，我们进行了10,000次总请求，每次使用200个并发线程。
ab -n 10000 -c 200 HTTP://<服务器地址>/<资源路径>
我们对三种不同的AWS EC2服务器配置进行了测试。我们在每个步骤缩小了测试案例，以便进一步验证：
- 我们在第一步仅进行了额外的直接访问测试，以查看代理的开销，但由于直接访问对我们不可行，因此我们没有在随后的步骤中进行这项测试。
- Spring Cloud Gateway 我们在最后对其进行了评估。
- Zuul在第一次调用后的后续调用性能更好。我们认为这可能是因为在第一次调用时执行了JIT（即时编译）优化，因此我们将Zuul运行的第一次称为“预热”。下表中显示的值是预热性能后的结果。
- 我们知道Linkerd是一种资源密集型代理，所以我们仅在具有最高资源配置的最后一步中进行了比较。
测试配置
T2.Micro — 单核CPU，1GB内存：我们对直接访问、Nginx反向代理和Zuul（预热后）进行了测试。
M4.Large — 双核CPU，8GB内存：我们比较了Nginx反向代理和Zuul（预热后）的性能。
M4.2xLarge — 8核CPU，32GB内存：我们比较了Nginx反向代理、Zuul（预热后）、Spring Cloud Gateway和Linkerd的性能。
测试结果
性能基准摘要如下：
测试细节
直接访问请求
首先，我们直接访问了一个静态资源，没有任何代理。结果如下：每个请求的平均时间为30毫秒。
通过Nginx反向代理
在我们的第二次测试中，我们通过Nginx反向代理访问了一个资源。每个请求的平均时间为40毫秒。与前一节中提到的直接访问相比，我们可以说Nginx反向代理平均增加了33%的开销。
通过 Zuul 访问
之后我们创建了一个 Spring Boot Application :
application.yml:
测试结果如下：
Nginx的请求时间分别为30毫秒和40毫秒，直接访问和Nginx反向代理。Zuul的每个请求时间在第一次运行时为388毫秒。 进行JVM预热可能会有所帮助。当我们重新运行测试时，我们得到了以下结果：
Zuul代理在预热后表现更好（每个请求的时间为200毫秒），但与Nginx反向代理相比仍然不算太好，后者的得分为40毫秒。
将服务器升级到m4.large
如图1所示，服务器是一个t2.micro ec2，有一个核心和1GB内存。Nginx是一个原生的C++应用程序，而Zuul是基于Java的。我们知道Java应用程序有点更加要求高。因此，我们将服务器改为一个有两个CPU核心和8GB内存的m4.large实例。
我们再次运行了Nginx和Zuul反向代理测试，结果如下：
m4.large上的Zuul反向代理（预热后）
如上图所示，Nginx和Zuul的每秒请求值分别为32ms和95ms。这些结果比在t2.micro上测试的40ms和200ms要好得多。
值得注意的是，通过使用Spring Boot应用程序使用Zuul会引入额外的开销。我们认为如果我们将Zuul作为一个独立的应用程序运行，性能可能会更好。
将服务器升级到m4.2xlarge
我们还评估了具有八个核心和32GB内存的m4.2xlarge服务器。
Nginx和Zuul的结果如下：
m4.2xlarge服务器的Nginx反向代理：
m4.2xlarge服务器的Zuul反向代理：
在m4.2xlarge服务器上，Zuul的表现优于Nginx。我们进行了一些研究，以找出Netflix用来托管Zuul实例的ec2实例类型，但我们无法找到任何相关信息。在一些博客文章中，人们抱怨Zuul的性能，并询问Netflix是如何扩展它的；我们认为这就是答案；正如所说，Zuul受CPU限制：)
Linkerd的基准测试
Linkerd是云原生计算基金会会员项目。它是一个用Scala开发的服务网格应用程序。除了提供服务网格功能外，它还提供了反向代理功能，如服务发现。我们评估了Linkerd的性能，结果如下。Linkerd的性能与Zuul非常接近。
m4.2xlarge服务器上的Linkerd反向代理
Spring Cloud Gateway的基准测试
我们使用Apache Http服务器基准测试工具进行了相同的性能测试，发送了10,000个请求，使用200个并发线程。结果如下图所示：
如图所示，Spring Cloud Gateway可以处理873个每秒的请求，每个请求的平均时间为229ms。根据我们的测试，Spring Cloud Gateway的性能无法达到Zuul、Linkerd和Nginx的水平
总结
在这篇博客文章中，我们使用了 Apache Http Server 基准测试工具 ab，对 Zuul、Nginx、Linkerd 和 Spring Cloud Gateway 的性能进行了比较。 我们接下来计划要进行的包括：
- 我们将评估 Envoy。实际上，Envoy 不仅仅是一个 API 网关；它是一个服务网格，但它也提供了一个可以用在应用程序前端的 API 网关。
- Undertow 也具有反向代理的功能，所以我们也将对其进行评估。
- 一些 API 网关（Zuul 1、Nginx）是阻塞的，而其他一些（Zuul 2、Linkerd、Envoy）是非阻塞的。阻塞架构适合简单的开发和请求跟踪，但阻塞的特性会导致可伸缩性问题。非阻塞架构在开发和可追踪性方面更复杂，但在可伸缩性和弹性方面更好。我们将稍后决定是否使用阻塞或非阻塞架构。
- 我们将使用 Gatling 进行测试。我们将在接下来的博客文章中分享结果。
我将在接下来的博客文章中逐步分享每个步骤的结果，敬请关注！