NGINX 控制器 API 管理模块与 孔: 性能比较

API 管理（APIM）市场竞争激烈。 最新的Gartner 全生命周期 API 管理魔力象限对22 家供应商进行了排名，其中 7 家进入领导者象限。 在现有市场中竞争需要建立强大的地位，以在竞争中脱颖而出。 那么 NGINX 的API 管理解决方案有何不同？

在 NGINX 我们的目标是制作轻量级、高性能的软件。 NGINX 开源已经成为世界上最繁忙网站的首选 Web 服务器，因为其事件驱动架构比为每个连接生成一个进程或线程的 Web 服务器具有更好的扩展性。 NGINX Open Source 也是业界最普遍的 API 网关，它是一种基础设施组件，可处理 Apigee、Axway、IBM DataPower、Kong、 Red Hat 3scale和 Torry Harris 等 APIM 解决方案中的 API 流量。

NGINX 控制器 API 管理模块是一个高性能 APIM 解决方案。 在这篇博客中，我们将把它的性能与以高性能著称的竞争对手 Kong 进行比较。 Kong 基于 NGINX 构建，并使用 Lua 实现其 API 功能，而 API 管理模块完全依赖于作为 NGINX Plus 模块实现的本机、高性能功能。 NGINX 的 API 管理解决方案建立在数据平面和控制平面分离的创新架构上。 所有 API 调用均由充当 API 网关（数据平面）的 NGINX Plus 直接处理，而无需与控制平面进行任何交互。 这使得南北向和东西向流量的 API 流量调节性能更高。

结果预览：NGINX Controller API 管理模块的性能比 Kong 高出 2 倍。

特别感谢英特尔提供用于进行此次测试的硬件和实验室空间。 完整的测试和硬件详细信息可以在附录中找到。

单个请求的延迟

在此测试中，我们比较了 API 管理器对单个请求引入的额外延迟，针对大小为0 KB和 1 KB的文件。 我们使用curl发送单个 HTTP 请求（详细信息）。

与 API 管理模块相比，Kong 增加了延迟： 0 KB文件的延迟增加了 44%， 1 KB 文件的延迟增加了 24%。

每秒 API 调用次数

标准 HTTP 可扩展性指标是每秒请求数 (RPS)。 APIM 上下文中的等效指标是每秒的 API 调用次数。 我们使用wrk在 3 分钟内通过 300 个连接发送了针对0 KB或 1 KB文件的连续请求流（详细信息）。

API 管理模块的表现优于 Kong——每秒处理1 KB响应的 API 调用数量是 Kong 的 2.6 倍。

CPU 使用率

API 管理模块比 Kong 引入的延迟更少，并且每秒处理的 API 调用更多，因为它更有效地使用 CPU。 我们测量了每秒 API 调用次数增加时的 CPU 使用率。 我们使用了单核，因此每秒的绝对 API 调用次数比之前的测试（使用了 22 个核心（详细信息））要低得多。

Kong 的实际上限为每秒 5,000 次 API 调用——当调用量高于该上限时，延迟会明显增加，表明系统已满载。 每秒 5,000 次调用时，CPU 使用率为 93%，比 API 管理模块高 73%。

使用 JWT 的每秒 API 调用次数

最终测试衡量每个 API 网关验证 JSON Web Tokens (JWT) 的效果，JWT 是验证 API 请求的首选方法。 您最重要的 API 端点可能会经过身份验证，因此此测试更接近真实世界的配置。

我们对两个网关使用了相同的 JWT，并使用 HS256 签名（详细信息）。

API 管理模块每秒处理的 JWT 认证 API 调用数量是 Kong 的 2 倍多。

NGINX 控制器如何工作

NGINX Controller 是一个管理 NGINX Plus 数据平面的控制平面解决方案。 NGINX Controller 使您能够管理 NGINX Plus 的整个生命周期，作为负载均衡器、API 网关或服务网格环境中的代理。 使用 NGINX Controller 的 API 管理模块，您可以定义、发布、保护、监控和分析 API。

在底层，NGINX Controller 生成 NGINX Plus 配置，并发布到底层 NGINX Plus 数据平面。 核心配置加载器具有非常高效的将配置存储在内存中的机制，使得 API 管理模块能够为 API 提供高性能。

结论

许多公司已经使用 NGINX 开源作为其 API 网关。 使用 NGINX 开源，Capital One 已经能够扩展到每天超过 120 亿次 API 调用。 事实上，我们的许多竞争对手（包括 Kong）都在其 APIM 解决方案中使用 NGINX 开源。 我们的轻量级设计 - 基于本机、高性能 NGINX 配置以及 NGINX Plus 模块 - 使 API 管理模块比 NGINX 衍生竞争对手具有更好的扩展性。

延迟是最终用户体验最重要的指标之一。 高延迟会降低应用程序的响应能力，让用户感到沮丧。 与 Kong 相比，API 管理模块使用户请求的延迟减少了 20-30%。 它还能更高效地利用系统资源，在相同工作负载下，CPU 占用率比 Kong 低 40%。

附录

拓扑

所有测试均使用三台独立的机器在简单、扁平的第 2 层网络中通过 10 GbE 链路连接完成。

使用的硬件

以下硬件用于测试。 这三台机器完全相同。 没有使用超线程。 在之前的测试中，我们没有观察到超线程性能上的重大差异。

使用的软件

使用以下软件进行测试：

• NGINX 控制器 API 管理模块版本 2。
• Kong 开源版本 1.0.0。 我们没有测试 Kong Enterprise，但它的任何附加功能都与我们的测试无关（例如，Kong Open Source 和 Kong Enterprise 使用相同的 JWT 插件）。
• curl版本 7.61.0。
• Docker 版本 18.09.1。 为了简化管理，我们在 Docker 容器内运行 Kong 和 API 管理模块。 我们发现 Docker 降低了约 30% 的性能，但是因为我们比较的是相对性能，所以使用 Docker 的好处超过了性能损失。
• systat包中的 12.0.1 版本中的mpstat 。
• wrk版本 4.1.0，按照这些说明安装。

NGINX 配置

以下 NGINX 配置用于测试。

上游 my_upstream { keepalive 60; 服务器API 服务器：80; keepalive_requests 3000000; keepalive_timeout 300; } 服务器 { 监听 8000; access_log 关闭; keepalive_requests 3000000; keepalive_timeout 300; tcp_nodelay 开启；位置 /test { 设置 $apimgmt_environment 4; 设置 $apimgmt_definition 3; 设置 $upstream my_upstream; 设置 $upstream_protocol http; 重写 ^ /_devel_4 last; } 位置 = /_devel_4 { 内部；设置 $apimgmt_definition_name my_api; 设置 $apimgmt_environment_name devel; proxy_intercept_errors 开启；proxy_http_version 1.1; proxy_set_header 连接“”； proxy_pass $upstream_protocol://$upstream/0kb; # 0-KB 文件 #proxy_pass $upstream_protocol://$upstream/1kb.bin; # 1-KB 文件 } }

我们进行了以下设置以最大限度地提高性能。 如下一节所详述的，我们在 Kong 配置中做了类似的设置。

• keepalive_requests和keepalive_timeout被设置为较高的数字，以最大限度地减少建立 TCP 连接的开销。
• 启用了tcp_nodelay ，通过禁用 Nagle 算法稍微提高了性能。
• access_log已被禁用。 启用该功能会使性能降低约 10%。
• 我们使用两个proxy_pass指令来请求适当的文件大小。

Kong 配置

我们在kong.conf.default中添加了以下配置指令，与上一节讨论的 NGINX 配置中的设置相匹配。

nginx_http_tcp_nodelay=onnginx_http_keepalive_requests=3000000
nginx_http_keepalive_timeout=300
proxy_access_log=off

我们运行以下 Kong API 调用来创建到 API 服务器的路由。 第一个命令创建一个名为test的服务，第二个命令创建指向服务器的路由/test 。

$ curl -X POST http://localhost:8001/services/ \ --data 'name=test' \ --data 'url=http:// API-server :80/0kb' $ curl -X POST http://localhost:8001/services/test/routes \ --data 'paths[]=/test'

以下命令分别显示服务和路由的配置。 我们将输出传送到jq工具，以便更容易读取 JSON 输出。

$ curl localhost:8001/services/ | jq'.' {"next":null，"data":[{"host": “172.20.40.32”，“创建时间”： 1556770191，"连接超时"： 60000，“id”：“f4629d56-550b-4b37-aa59-66d931aa6f37”，“协议”：“http”，“名称”：“test”，“read_timeout”： 60000，"端口"： 80，“路径”：“/0kb”，“updated_at”： 1556770191，"重试"： 5，“write_timeout”： 60000 } ] } $ curl localhost:8001/services/test/routes | jq '.' { “next”: null, “data”: [ { “created_at”: 1556770191，"方法"：null，"id"："a7b417af-ccd4-48f7-b787-ae19490194dc"，"服务"：{"id"："f4629d56-550b-4b37-aa59-66d931aa6f37"}，"名称"：null，"主机"：null，"updated_at"： 1556770191，"preserve_host"：false，"regex_priority"： 0，“路径”：[“/test”]，“源”：null，“目的地”：null，“snis”：null，“协议”：[“http”，“https”]，“strip_path”：true } ] }

测试方法

单个请求的延迟

我们使用curl进行单一请求延迟测试。 为了设置基线，我们首先向没有 API 网关的 API 服务器发出请求。 然后，我们对 API 服务器前面的每个 API 网关发出相同的请求，以测量它们引入的延迟。

$ curl -w "@curl-latency.txt" -o /dev/null -s http://目标服务器

curl-latency.txt的内容：

    time_namelookup：%{time_namelookup}\n
time_connect：%{time_connect}\n
time_appconnect：%{time_appconnect}\n
time_pretransfer：%{time_pretransfer}\n
time_redirect：%{time_redirect}\n
time_starttransfer：%{time_starttransfer}\n
----------\n
time_total：%{time_total}\n

单个请求的延迟图表显示time_total ，以毫秒为单位。 以下是示例输出：

$ curl -w "@curl-latency.txt" -o /dev/null -s http://192.0.2.1/api-endpoint time_namelookup:  0.000035时间连接：  0.000364 time_appconnect：  0.000000 时间预传输：  0.000401时间重定向：  0.000000 time_starttransfer：  0.001701 ---------- 时间总计：  0.001727

每秒 API 调用次数

我们使用wrk （我们经常使用的可扩展基准测试工具）测试了每秒的 API 调用次数。 我们尝试了各种参数组合，这个组合最大程度地提高了 API 管理模块和 Kong 的性能：

$ wrk -t 22 -c 300 -d 180 http://目标服务器

该命令创建 22 个wrk线程（每个核心 1 个）以及跨线程的总共 300 个连接。 -d参数指定测试的持续时间，在我们的例子中为 180 秒（3 分钟）。 示例输出：

$ wrk -t 22 -c 300 -d 180 http://192.0.2.1/api-endpoint运行 3m 测试 @ http://192.0.2.1/api-endpoint 22 个线程和 300 个连接 线程统计 平均值 Stdev 最大值 +/- Stdev 延迟 13.96ms 7.84ms 279.85ms 77.37% 请求/秒 0.96k 298.23 1.88k 68.55% 3.00m 内有 3769861 个请求，36.25GB 读取请求/秒：  20934.34 传输/秒：    206.16MB

CPU 使用率

我们在运行wrk命令以每秒执行 API 调用数时，使用mpstat （用于此目的的标准 Linux 工具）测试了 CPU 使用率。 示例输出（为了易读，分为两行）：

$ mpstat Linux 4.18.0-13-generic (nbdw38) 04/29/2019 _x86_64_ (88 CPU) 03:34:50 PM CPU ％usr ％nice ％sys ％iowait ％irq ％soft ％steal ...
下午 03:34:50 全部 0.04 0.00 0.02 0.00 0.00 0.03 0.00 ... ... %guest %gnice %idle ...   0.00 0.00 99.91

使用 JWT 的每秒 API 调用次数

我们使用wrk命令测试了每秒 API 调用次数的 JWT 性能，并添加了-H参数将 JWT 插入到授权中： 承载HTTP 标头。 我们根据这篇博文中的说明生成了 JWT 和 JSON Web Keys (JWK)，并将 JWT 存储在名为test.jwt的文件中。

$ wrk -t 22 -c 300 -d 180 -H “授权： 承载者 `cat test.jwt`" \ http://目标服务器