对 NGINX、Kong 和 Amazon 的 API 管理解决方案进行基准测试：它们能否交付实时API？

速度 — 这在当今数字环境中尤为重要，如果您的应用性能太慢，消费者会毫不犹豫地选择您的竞争对手。应用速度最终取决于 API 的响应能力、运行状况和适应性，而影响 API 响应能力的关键因素之一就是 API 网关引入的延迟。但是，并非所有 API 网关的性能都是相同水平。

这点让我想起去年秋天，一位 NGINX 客户（消费信贷行业的一家知名公司）告诉我们，随着越来越多的应用和其他组件需要彼此通信以提供用户期望的数字体验，“实时” API 性能的重要性正日益提高。我们很高兴得知 NGINX Plus 是唯一能实现客户所需的超短 API 延迟（低至 10 毫秒）的 API 网关。其他许多客户，例如 Capital One，也与我们分享了如何通过使用 NGINX 开源版或 NGINX Plus 作为 API 网关来缩短延迟和提高吞吐量。

我们决定对 API 生态系统进行更深入的研究，并尝试弄清 API “实时”意味着什么。基于大量的考虑因素，我们最终确定了实时 API 处理端到端 API 调用的时间，前 99 百分位必须在 30 毫秒内（这意味着平均只有百分之一的调用用时超过 30 毫秒）。

 

比较 API 管理解决方案

我们的内部测试一致表明，当您定义、发布 API 并进行全生命周期管理和监控时，通过我们的 API 管理解决方案可以轻松实现实时 API 性能，该解决方案将 NGINX Plus 用作处理 API 调用的 API 网关，并使用 NGINX Controller API 管理模块（现已并入 NGINX Management Suite）来管理两个 NGINX Plus 实例以及您的 API。

但是我们知道，仅凭我们的一面之词，可能很难取信于您。因此，我们委托独立技术研究和分析公司 GigaOm 对我们的 API 管理解决方案和市场上的其他流行解决方案进行了客观透明的基准测试，这包括两款类似 NGINX 的可部署在本地或云中的解决方案 Apigee 和 Kong Enterprise，以及两款完全托管的云产品 Amazon API Gateway 和 Kong Cloud。

在本文中，我们概述了 GigaOm 的测试结果（最佳表现者：NGINX Plus 在每种测试条件下均能实时提供 API，而其他解决方案则不能）。有关解决方案、测试方法和结果的全部详情，请联系我们的团队成员。

注：Apigee 最终用户许可协议 (EULA) 禁止未经 Google 明确许可发布测试结果，因此很遗憾，该报告和本文中均未包含有关 Apigee 的信息。

 

基准测试概述

GigaOm 使用 Vegeta HTTP 负载测试工具生成请求（API 调用），并测量了在各种吞吐率 (RPS) 下 API 网关引入的延迟，即将响应返回给 API 调用所花费的时间。GigaOm 将 RPS 称为“攻击速率”。GigaOm 在从 1,000 到 5,000、10,000、20,000 及更高 RPS 的攻击速率下，不断运行测试，直到 Vegeta 报告错误状态代码为止。每次测试持续 60 秒，并重复 3 次。如下图所示，GigaOm 捕获了在 50、90、95、99、99.9 和 99.99 百分位下的延迟，并且还记录了在测试运行期间观察到的最长延迟（即图中的最大）。

 

结果：NGINX 与 Kong Enterprise

GigaOm 进行了两次基准测试，对 NGINX Plus（使用 NGINX Controller 部署）和 Kong Node（使用 Kong Enterprise 部署）进行了比较。在第一次基准测试中，只有一个工作节点（一个 NGINX Plus 或 Kong Node 实例）。在第二次基准测试中，3 个工作节点由 NGINX 开源版通过轮询调度算法进行负载均衡。（GigaOm 强调，使用 NGINX 开源版作为负载均衡器并不会给 NGINX Plus 带来优势，甚至 Kong 建议将其用作集群 Kong 实例的负载均衡器。）

如下图所示，在第 99 百分位之前，NGINX 和 Kong 之间的延迟差异可以忽略不计，但之后 Kong 的延迟开始呈指数增长。在两次基准测试中，在第 99.99 百分位下，Kong 的延迟均为 NGINX 的两倍或三倍。

API 在每个百分位下，直到第 99 百分位为止都能保持低延迟才能被定义为实时，但 GigaOm 指出，在实际部署中，在更高的百分位（如第 99.9 和 99.99）下保持低延迟“极其重要”。该报告说明：

延迟结果随时间的推移趋向于多模式，陡变的顶端代表响应时间中的“停顿”。

这些停顿关系重大。如果响应时间或延迟的中位数小于 30 毫秒，但存在 1 秒或更长时间延迟的停顿，则实际上会对后续用户体验产生累积影响。例如，如果您开车去一家快餐店，平均等餐时间为 1 分钟，您可能会认为这还是一种不错的客户体验。但是，如果您前面的客户订单出现问题，需要 10 分钟才能解决，那会怎样？这意味着您的等餐时间实际上是 11 分钟。由于您的请求是出现停顿之后，因此第 99.99 百分位的延迟也可能会成为您的延迟。

在高百分位下，超长延迟带来的负面影响在分布式应用中会变得更加明显，因为在此类应用中，单个客户端请求实际上可能会产生多个下游 API 调用。例如，假设 1 个客户端请求创建了对子系统的 10 个 API 调用，发生缓慢响应的概率为 1%。缓慢响应影响 1 个客户端请求的概率在 10% 左右，这点从数学上可以证明。有关详细信息，请参阅《谁动了我第 99 百分位的延迟？》。

图 1 描述了在单个工作节点和 30,000 RPS 攻击速率下的结果。在第 99.99 百分位，Kong 的延迟是 NGINX 的 3 倍以上，并且超过了实时 API 30 毫秒的阈值。相比之下，NGINX Plus 在每个百分位下均实现了实时延迟，其最高记录的（最大）延迟仅有 13 毫秒，还不到实时阈值的一半。

图 2 显示了在三个工作节点下，同样也是在 30,000 RPS 攻击速率下的基准测试结果。有趣的是，在第 99 百分位和第 99.9 百分位下，Kong 表现优于 NGINX，但到第 99.99 百分位再次经历了延迟飙升，这时的延迟大约是 NGINX 的两倍。与第一个基准测试一样，NGINX 在所有百分位均保持小于 30 毫秒的实时阈值。

衡量 API 网关性能的另一种方法是，利用单节点和三节点配置，确定在百分百成功（无 5xx 或 429 [Too Many Requests] 错误）并且在所有百分位延迟都小于 30 毫秒的情况下，它可以处理的最大 RPS。图 3 显示了根据此测量方法，NGINX 支持比 Kong 高出 50% 的 RPS：30,000 VS. 20,000。

 

结果：NGINX 与 Kong Cloud 和 Amazon API Gateway

在第三组基准测试中，GigaOm 将 NGINX Plus 同 Kong Cloud 和 Amazon API Gateway 进行了比较。GigaOm 强调，直接比较存在很大问题，因为 Kong Cloud 和 Amazon API Gateway 是完全托管的 SaaS 产品，而 NGINX Controller（现已并入 NGINX Management Suite）是 PaaS 产品，目前不作为 SaaS 提供。特别是，这两种 SaaS 产品都无法揭示其使用的实例类型、运算能力、内存或网络功能。因此，GigaOm 必须就与 NGINX Plus 相当的设置做出最佳猜测。

实际上，即使不与 NGINX Plus 进行比较，也能轻松发现，SaaS 产品在任何测试百分位下均无法实时提供 API，即便在图 4 所示的第二低攻击速率（5,000 RPS）下也是如此。在第 50 百分位下，SaaS 产品的延迟就已超过 30 毫秒阈值的 7 倍；而在第 99.99 百分位下，它比该阈值高出 8000% 以上。显而易见，在任何情况下，Kong Cloud 或 Amazon API Gateway 都无法百分百保证小于 30 毫秒的延迟。

 

验证 NGINX 是唯一的实时 API 解决方案

总而言之，NGINX 是业经 GigaOm 测试的唯一符合实时 API 处理标准的解决方案，在每个百分位下的延迟均小于 30 毫秒。Kong Enterprise 在第 99 百分位获得了实时性能，但在较高的百分位下，其延迟急剧上升。因此，它不适合即便是只需适量实时 API 处理的生产环境。测试中的 SaaS 解决方案均不能被归类为实时。

GigaOm 报告证实了我们以前的基准测试结果以及客户向我们提供的反馈。NGINX Plus 是市场上最快的 API 网关，并且是唯一能够在所有百分位下都保持小于 30 毫秒延迟的 API 解决方案。而且，如果将其与 NGINX Controller （现已并入 NGINX Management Suite）搭配使用，您将可以获得具有独特架构的 API 管理解决方案。通过精心的解耦设计，API 管理控制平面 (NGINX Controller，现已并入 NGINX Management Suite) 不会对 API 网关数据平面 (NGINX Plus) 的性能产生任何影响。

您可以使用我们的 rtapi 延迟测量工具测试您自己的 API 性能。请联系我们，探讨我们可如何帮助您实现实时 API。