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

NGINX | 2020年7月14日

速度在当今的数字环境中至关重要。如果应用性能太慢，消费者很容易转向竞争对手。应用速度最终取决于响应迅速、运行状况良好且适应性强的API，而API网关引入的延迟是影响API响应能力的关键因素之一。但并非所有API网关都能达到相同的性能水平。

去年秋天，一位来自消费信贷行业主要企业的NGINX客户向我们讲述了“实时”API性能日益提升的重要性。随着越来越多的应用和其他组件需要相互通信，才能提供用户期望的数字体验，这一点让我们有了更深刻的认识。得知NGINX Plus是唯一能实现该客户所需超低API延迟（最低可达10毫秒（ms））的API网关，我们深感欣慰。许多其他客户，例如Capital One，也向我们分享了如何使用NGINX Open Source或NGINX Plus作为API网关来降低延迟并提高吞吐量。

我们决定深入研究API生态系统，尝试弄清API具备哪些特征才能称为“实时”API。综合多项因素，我们认为，实时API必须在30 ms内完成API调用的端到端处理，并且从各百分位数到第99百分位数均须达到这一标准（即平均每100次调用中，只有1次耗时超过30 ms）。

比较API管理解决方案

我们的测试始终表明，借助我们的API管理解决方案，可以轻松实现实时API性能。该解决方案将NGINX Plus用作处理API调用的API网关，并通过NGINX Controller API Management Module管理NGINX Plus实例和API，支持在API的整个生命周期中进行定义、发布、管理和监控。

但我们理解，您可能不想只听信我们的一面之词。因此，我们委托了GigaOm这家独立的技术研究与分析公司，对我们的API管理解决方案和市场上其他广受欢迎的解决方案进行客观、透明的基准测试，其中包括两种与NGINX一样可部署在本地或云端的解决方案：Apigee和Kong Enterprise；以及两种完全托管的云服务：Amazon API Gateway和Kong Cloud。

本博客总结了GigaOm的测试结果（先透露一下：在所有测试条件下，NGINX Plus均能实时交付API，而其他解决方案未能做到）。如需全面了解各解决方案、测试方法和测试结果，请联系我们的团队成员。

注意：Apigee最终用户许可协议（EULA）禁止在未获得Google明确许可的情况下发布测试结果，因此很遗憾，本报告和本博客均未包含有关Apigee的信息。

基准测试概述

GigaOm使用Vegeta HTTP负载测试工具生成请求（API调用），并测量API网关在不同每秒请求数（RPS）下引入的延迟，即返回API调用响应所需的时间。GigaOm将每秒请求数称为“攻击速率”。GigaOm开展了多轮测试，攻击速率从1,000 RPS开始，逐步提高至5,000、10,000、20,000 RPS，以此类推，直至Vegeta报告错误状态码。每轮测试持续60秒，并重复3次。如下图所示，GigaOm采集了第50、90、95、99、99.9和99.99百分位的延迟，并记录了测试期间观察到的最长延迟（图中的最大值）。

结果：NGINX 与 Kong Enterprise 对比

GigaOm开展了两项基准测试，对使用NGINX Controller部署的NGINX Plus与使用Kong Enterprise部署的Kong Node进行了比较。第一项基准测试使用单个工作节点（一个NGINX Plus或Kong Node实例）。第二项测试使用三个工作节点，并由采用轮询模式的NGINX Open Source进行负载均衡。（GigaOm强调，使用NGINX Open Source作为负载均衡器并未给NGINX Plus带来优势；Kong甚至也建议将其用作Kong Node集群实例的负载均衡器。）

如下图所示，在第99百分位之前，NGINX与Kong之间的延迟差异可以忽略不计；从第99百分位开始，Kong的延迟呈指数级增长。在两项基准测试中，第99.99百分位的Kong延迟分别是NGINX的3倍和2倍。

第99百分位数可作为定义实时API的合理最低标准，但GigaOm指出，在实际部署中，将第99.9和第99.99等更高百分位数的延迟保持在较低水平“极其重要”。报告解释道：

延迟结果往往会随时间呈现多峰分布，其中峰值顶部表示响应时间出现“短暂异常”。

这些短暂卡顿不容忽视。如果响应时间或延迟的中位数低于 30 ms，但偶尔出现 1 秒或更长的延迟，就会对后续用户体验产生累积影响。例如，在快餐店的汽车餐厅，如果取餐等待时间的中位数为 1 分钟，您可能会认为这样的顾客体验不错。但如果前面的顾客遇到订单问题，需要 10 分钟才能解决，会怎样？您的实际等待时间将达到 11 分钟。由于您的请求排在这次卡顿之后，第 99.99 百分位的延迟也可能成为您所经历的延迟。

在分布式应用中，单个客户端请求可能会触发多个下游API调用，因此高百分位下异常高延迟造成的负面影响会更加显著。例如，假设1个客户端请求会向某个子系统发起10次API调用，而该子系统出现响应缓慢的概率为1%。通过数学计算可以证明，这会导致该客户端请求受慢响应影响的概率接近10%。有关具体计算方法，请参阅谁动了我的第99百分位延迟？

图1显示了使用单个工作节点时，攻击速率为30,000 RPS的测试结果。在第99.99百分位，Kong的延迟是NGINX的3倍以上，并超过实时API的30 ms阈值。相比之下，NGINX Plus在所有百分位均达到实时延迟要求；即使其记录的最高（最大）延迟为13 ms，也不到实时延迟阈值的一半。

图1. NGINX Controller和Kong Enterprise在1个节点上以30,000 RPS运行

图2显示，在同样采用30,000 RPS攻击速率的情况下，使用3个工作节点的基准测试结果非常相似。值得注意的是，Kong在第99和99.9百分位的表现优于NGINX，但在第99.99百分位再次出现大幅延迟飙升，此时的延迟约为NGINX的两倍。与第一次基准测试一样，NGINX在所有百分位的延迟均低于30 ms实时阈值。

图2. NGINX Controller和Kong Enterprise在3个节点下以30,000 RPS运行

衡量API网关性能的另一种方法是，分别在单节点和三节点配置下，确定其在请求成功率达到100%（无5xx或429 [Too Many Requests]错误）且所有百分位延迟均低于30 ms时可处理的最大RPS。图3显示，按此指标衡量，NGINX可持续处理的RPS比Kong高50%，分别为30,000和20,000。

图3. 无错误情况下实现的最大吞吐量

结果：NGINX与Kong Cloud和Amazon API Gateway的对比

在第三组基准测试中，GigaOm对NGINX Plus、Kong Cloud和Amazon API Gateway进行了比较。GigaOm强调，直接比较这些产品存在很大问题，因为Kong Cloud和Amazon API Gateway是完全托管的SaaS产品，而NGINX Controller是PaaS产品，目前尚未以SaaS形式提供。尤其是，这两款SaaS产品均未披露其使用的实例类型、计算能力、内存或网络功能。因此，GigaOm只能尽可能合理地估算NGINX Plus的可比配置。

即使不与NGINX Plus比较，也可以清楚地看出，在图4所示的第二低攻击速率（5,000 RPS）下，这些SaaS产品在所有受测百分位上都无法实时交付API。在第50百分位，SaaS产品的延迟已超过30 ms阈值的7倍；在第99.99百分位，延迟超出该阈值8,000%以上。这显然意味着，Kong Cloud或Amazon API Gateway在任何条件下都无法实现延迟低于30 ms且成功率达到100%。

图4. NGINX Controller、Amazon API Gateway和Kong Cloud在1个节点、5,000 RPS条件下的表现

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

总而言之，在GigaOm测试的解决方案中，只有NGINX达到了实时API处理标准，在所有百分位上的延迟均低于30 ms。Kong Enterprise在第99百分位可实现实时性能，但在更高百分位上，其延迟会显著飙升，因此不太适合需要处理中等规模实时API请求的生产环境。接受测试的两种SaaS解决方案均不能归类为实时解决方案。

GigaOm报告印证了我们此前的基准测试结果，也与客户反馈一致。NGINX Plus是一款性能出色的API网关，也是经测试能够在所有百分位下将延迟持续保持在30 ms以内的API解决方案。将其与NGINX Controller搭配使用，即可获得采用独特架构的API管理解决方案。通过精心解耦，API管理控制平面（NGINX Controller）不会影响API网关数据平面（NGINX Plus）的性能。

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