API管理（APIM）市场竞争激烈。最新的Gartner全生命周期API管理魔力象限对22家供应商进行了排名，其中7家位于领导者象限。在现有市场中竞争，需要确立鲜明定位，以实现差异化并从竞争中脱颖而出。那么，NGINX的API管理解决方案有何不同？
NGINX致力于打造轻量级、高性能的软件。NGINX Open Source已成为全球众多高流量网站广泛采用的Web服务器，因为其事件驱动型架构比为每个连接创建进程或线程的Web服务器更具扩展性。NGINX Open Source也是业内广泛使用的API网关，可作为基础设施组件处理APIM解决方案中的API流量，例如Apigee、Axway、IBM DataPower、Kong、Red Hat 3scale和Torry Harris提供的解决方案。
The NGINX Controller API Management Module是一款高性能APIM解决方案。本博客将对比该模块与以高性能著称的竞品Kong。Kong基于NGINX构建，并使用Lua实现其API功能；而API Management Module则完全依托以NGINX Plus模块形式实现的原生高性能功能。NGINX的API管理解决方案采用创新架构，将数据平面与控制平面解耦。所有API调用均由充当API网关（数据平面）的NGINX Plus直接处理，无需与控制平面进行任何交互。因此，无论是南北向流量还是东西向流量，都能实现高性能的API流量中介处理。
先睹为快：NGINX Controller API Management Module 的性能是 Kong 的 2 倍。
特别感谢Intel为本次测试提供硬件和实验室场地。完整的测试和硬件详情请参阅附录。
单个请求增加的延迟
在此测试中，我们针对大小为0 KB和1 KB的文件，比较了API管理器为单个请求增加的延迟。我们使用curl发送单个HTTP请求（详情）。
与API Management Module相比，Kong会增加延迟：对于0 KB文件，延迟增加44%；对于1 KB文件，延迟增加24%。
每秒API调用次数
衡量HTTP可扩展性的标准指标是每秒请求数（RPS）。在APIM场景中，对应的指标是每秒API调用数。我们使用wrk，通过300个连接持续发送针对0 KB或1 KB文件的请求，测试时长为3分钟（详情）。
对于1 KB响应，API Management Module每秒处理的API调用量是Kong的2.6倍，性能更胜一筹。
CPU 使用率
API Management Module的CPU利用效率更高，因此与Kong相比，延迟更低，每秒可处理更多API调用。我们测量了每秒API调用次数逐步增加时的CPU使用率。本次测试使用单核，因此每秒API调用次数的绝对值远低于此前使用22核的测试（详情）。
Kong的实际处理上限为每秒5,000次API调用。调用量超过这一水平时，延迟会明显激增，表明系统已满负载运行。在每秒5,000次调用时，CPU使用率为93%，比API Management Module高73%。
使用JWT时的每秒API调用次数
最后一项测试衡量各API网关验证JSON Web Token（JWT）的能力。JWT是API请求身份验证的首选方法。最重要的API端点通常需要进行身份验证，因此这项测试更接近实际配置。
我们对两个网关使用了同一个由HS256签名的JWT（详情）。
API Management Module每秒处理的JWT身份验证API调用量是Kong的2倍以上。
NGINX Controller 的工作原理
NGINX Controller是一种用于管理NGINX Plus数据平面的控制平面解决方案。借助NGINX Controller，可以管理NGINX Plus作为负载均衡器、API网关或服务网格环境中的代理时的整个生命周期。通过NGINX Controller的API Management Module，可以定义、发布、保护、监控和分析API。
在后台，NGINX Controller 会生成 NGINX Plus 配置，并将其发布到底层 NGINX Plus 数据平面。核心配置加载器采用高效的内存配置存储机制，使 API Management Module 能够为 API 提供高性能。
结论
许多公司已使用NGINX Open Source作为API网关。Capital One已能够扩展至每天处理超过120亿次API调用，所使用的正是NGINX Open Source。事实上，包括Kong在内的许多竞争对手也在其APIM解决方案的底层使用NGINX Open Source。我们的轻量级设计基于原生高性能NGINX配置和NGINX Plus模块，使API Management Module相比基于NGINX衍生开发的竞品具备更强的扩展能力。
延迟是衡量最终用户体验的重要指标之一。高延迟会降低应用响应速度，令用户感到不满。与Kong相比，API Management Module为用户请求增加的延迟低20%至30%。它还能更高效地利用系统资源，在相同工作负载下，CPU使用量比Kong低40%。
附录
拓扑
所有测试均使用3台独立计算机完成。这些计算机通过10 GbE链路连接在一个简单的扁平化第2层网络中。
所用硬件
测试使用了以下硬件。3台机器的配置完全相同。测试未启用超线程。在之前的测试中，我们未观察到超线程对性能有显著影响。
| CPU | 网络 | 内存 |
|---|---|---|
| Intel® Xeon(R) CPU E5‑2699 v4 @ 2.20GHz， 22 核 | Intel Ethernet Controller 10‑Gigabit X540‑AT2 | 128 GB |
所用软件
测试使用了以下软件：
- NGINX Controller API Management Module版本 2。
- Kong Open Source 1.0.0 版。我们未测试 Kong Enterprise，但其附加功能均与我们的测试无关（例如，Kong Open Source 和 Kong Enterprise 使用相同的 JWT 插件）。
curl版本 7.61.0。- Docker版本18.09.1。为简化管理，我们在Docker容器中运行Kong和API Management Module。我们发现Docker会使性能降低约30%，但由于比较的是相对性能，使用Docker带来的便利超过了性能损失。
mpstat，来自systat软件包的12.0.1版本。wrk4.1.0版，按照这些说明安装。
NGINX配置
测试使用了以下NGINX配置。
upstream my_upstream { keepalive 60; server API-server:80; keepalive_requests 3000000; keepalive_timeout 300;}server { listen 8000; access_log off; keepalive_requests 3000000; keepalive_timeout 300; tcp_nodelay on; location /test { set $apimgmt_environment 4; set $apimgmt_definition 3; set $upstream my_upstream; set $upstream_protocol http; rewrite ^ /_devel_4 last; } location = /_devel_4 { internal; set $apimgmt_definition_name my_api; set $apimgmt_environment_name devel; proxy_intercept_errors on; proxy_http_version 1.1; proxy_set_header Connection ""; proxy_pass $upstream_protocol://$upstream/0kb; # 0-KB file #proxy_pass $upstream_protocol://$upstream/1kb.bin; # 1-KB file }}为尽可能提升性能，我们进行了以下设置。如下一节所述，我们在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=3000000nginx_http_keepalive_timeout=300proxy_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", "created_at": 1556770191, "connect_timeout": 60000, "id": "f4629d56-550b-4b37-aa59-66d931aa6f37", "protocol": "http", "name": "test", "read_timeout": 60000, "port": 80, "path": "/0kb", "updated_at": 1556770191, "retries": 5, "write_timeout": 60000 } ]}$ curl localhost:8001/services/test/routes | jq '.'{ "next": null, "data": [ { "created_at": 1556770191, "methods": null, "id": "a7b417af-ccd4-48f7-b787-ae19490194dc", "service": { "id": "f4629d56-550b-4b37-aa59-66d931aa6f37" }, "name": null, "hosts": null, "updated_at": 1556770191, "preserve_host": false, "regex_priority": 0, "paths": [ "/test" ], "sources": null, "destinations": null, "snis": null, "protocols": [ "http", "https" ], "strip_path": true } ]}测试方法
单个请求增加的延迟
我们使用curl进行单次请求延迟测试。为设定基准，我们首先直接向API服务器发送请求，不经过API网关。然后，我们分别通过各API网关向API服务器发送相同请求，以测量每个网关引入的延迟。
$ curl -w "@curl-latency.txt" -o /dev/null -s http://target-server以下是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 time_connect: 0.000364 time_appconnect: 0.000000 time_pretransfer: 0.000401 time_redirect: 0.000000 time_starttransfer: 0.001701 ---------- time_total: 0.001727每秒API调用次数
我们使用wrk测试了每秒API调用次数。wrk是我们经常使用的一款可扩展基准测试工具。我们尝试了多种参数组合，以下组合可使API Management Module和Kong均达到较高性能：
$ wrk -t 22 -c 300 -d 180 http://target-server该命令会创建22个wrk线程（每个核心1个），并在这些线程中共建立300个连接。-d参数用于指定测试时长，本例中为180秒（3分钟）。输出示例：
$ wrk -t 22 -c 300 -d 180 http://192.0.2.1/api-endpointRunning 3m test @ http://192.0.2.1/api-endpoint 22 threads and 300 connections Thread Stats Avg Stdev Max +/- Stdev Latency 13.96ms 7.84ms 279.85ms 77.37% Req/Sec 0.96k 298.23 1.88k 68.55% 3769861 requests in 3.00m, 36.25GB readRequests/sec: 20934.34Transfer/sec: 206.16MBCPU 使用率
我们在运行mpstat（用于测试CPU使用率的标准Linux工具）的同时，执行wrk命令来测试每秒API调用次数。以下是示例输出（为便于阅读，分为两行显示）：
$ mpstatLinux 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 PM all 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命令测试了JWT在每秒API调用场景下的性能，并添加-H参数，将JWT插入Authorization: Bearer HTTP标头。我们按照这篇博客文章中的说明生成了JWT和JSON Web密钥（JWK），并将JWT存储在名为test.jwt的文件中。
$ wrk -t 22 -c 300 -d 180 -H "Authorization: Bearer `cat test.jwt`" http://target-server关于作者
相关博客文章
NGINX Plus R26 正式发布
NGINX Plus R26通过缓存JSON Web密钥集加快JWT验证，并强化TLS握手，从而提升安全性。NGINX JavaScript的新功能包括增强对异步函数的支持，以及实现WebCrypto API。
使用NGINX App Protect DoS保护gRPC应用，抵御严重的DoS攻击
gRPC具备开发人员设计和部署现代应用所需的速度与灵活性，但其开放性也使其极易受到第7层DoS攻击。NGINX App Protect DoS可保护gRPC应用免受此类破坏性攻击。
Ingress Controller 选型指南（第 2 部分）：风险与面向未来的规划
了解选择错误的Ingress控制器可能带来的风险，以及如何从关键方面着手，让您的选择更好地适应未来需求。
NGINX Plus R19 正式发布
NGINX Plus R19扩展了监控功能，不仅提供更多指标，还新增了指标分析方式；增加试运行模式，用于测试限速效果；增强键值存储，以支持IP地址范围；并使限速更加动态。
NGINX现已正式加入F5
NGINX现已正式成为F5的一部分。Gus Robertson现任F5 NGINX业务部门负责人。他阐述了两家公司在人才、文化和愿景方面融合的价值，以及双方将如何携手增强NGINX的开源产品和商业产品。
