Traefik、Kong 与 APISIX：可复现的 API 网关跑分方法

公平比较 Traefik、Kong 和 Apache APISIX，不能从一张每秒请求数图表开始，而应先确定实验契约：准确版本、等价流量路径、相同资源限制、受控上游、明确的策略场景、负载模型、无效运行判定标准，以及可供他人复现的原始结果。

本文有意只提供方法，不宣布赢家。一个只转发 HTTP/1.1 的空代理测试，只能衡量非常有限的数据面路径；它无法回答哪种网关更适合 Kubernetes 平台、重安全策略场景或多区域运维模型。

核心要点

测试与决策相关的工作负载，而不是没有定义的“默认配置”。
保持硬件、部署位置、协议、TLS、上游、连接复用和策略等价。
同时报告延迟分位数、错误、目标负载与实际负载、资源饱和度。
同时执行容量搜索和固定速率测试，暴露过载行为。
发布 Manifest、命令、原始输出、排除项与环境数据，使结论可复现。

先写跑分契约

安装网关前，先记录这些字段：

维度	必须公开的内容
产品	镜像 Digest、网关版本、版本形态、构建参数、插件版本
平台	CPU 型号、核心数、内存、操作系统、内核、容器运行时、CPU 绑定与限制
拓扑	压测端、网关、上游、控制面与网络跳数
协议	HTTP 版本、TLS 版本、Cipher、Keep-Alive、连接数、载荷大小
路由	匹配规则、改写行为、上游算法、健康检查
策略	认证、限流、日志、追踪，或明确说明全部关闭
负载	开环或闭环模型、预热、持续时间、速率、并发与重复次数
有效性	压测端最高 CPU、允许错误、上游基线、时钟和遥测检查

RFC 9411要求跑分报告注明所测层级，并为 HTTP/HTTPS 事务定义了首字节与末字节时间等度量。API 网关的能力范围虽超出该 RFC 面向的网络安全设备，但它对信息披露的要求值得采用：没有测试拓扑和延迟信息的吞吐量数字不具备可比性。

构建等价测试环境

让压测端和上游使用独立且稳定的资源，使网关成为预期的被测系统。首先通过同一网络测量直接访问上游的基线。如果上游先于网关饱和，或者压测端无法维持目标速率，该次网关测试应判为无效。

为每种网关提供相同的 CPU 配额、内存、副本数、监听协议、TLS 终止点、上游、路由数量与日志策略。只有在所有候选中都关闭访问日志和遥测时才可关闭，并把结果明确标记为精简代理场景。

还必须注明部署拓扑。APISIX 支持传统、控制面与数据面分离和 Standalone 模式。Kong 记录了传统、Hybrid、DB-less 和托管拓扑。Traefik 的安装选项见其官方安装指南。控制面组件可能不在请求路径上，但仍会影响变更传播、内存、恢复与运维成本；应单独测量，而不是隐藏它们。

定义三个工作负载场景

1. 纯代理基线

一个精确路径和一个上游；
固定的小响应；
启用 Keep-Alive；
不启用认证、限流、追踪或正文检查；
如果两者都与决策有关，分别测试明文和 TLS。

这个场景隔离转发开销，但不能代表生产排名。

2. 通用策略场景

选择所有候选都能等价实现的行为，例如一次 JWT 验证、一项本地限流策略、有边界的访问日志和相同的 Trace 采样率。在测量前验证策略正确性。如果实现使用不同算法或共享存储，应把它们作为不同实验报告，不能假装等价。

3. 贴近生产的场景

使用脱敏后的路由数量、方法、请求与响应大小、上游延迟、连接复用、TLS 和策略比例分布。加入少量无效凭证、拒绝请求、上游错误与慢响应，并记录相对真实生产环境的每一项简化。

有意识地选择负载模型

官方 wrk README记录了线程、连接、持续时间、超时、请求头、脚本与延迟输出。下面的命令只是冒烟测试，不是完整跑分：

1wrk --threads 4 \
2  --connections 128 \
3  --duration 60s \
4  --timeout 2s \
5  --latency \
6  http://gateway.example.test/benchmark

它采用闭环负载：每个连接通常要等到收到响应后才发送下一项工作。延迟升高时，实际施加的负载可能下降，从而掩盖部分过载现象。wrk2增加了恒定吞吐模式，并讨论了协调遗漏（coordinated omission）问题。固定目标速率测试应使用开环或恒定速率工具，同时确认压测端本身没有饱和。

两类测试都要执行：

**容量搜索：**逐级提高目标负载，直到服务等级目标或错误阈值失败。
**固定速率稳定性：**在容量边界以下及附近选择多个速率，持续足够长时间，观察队列、内存、垃圾回收与恢复。

在可行时随机安排候选测试顺序，以相同方式预热并重复运行。报告中位结果和不同运行之间的波动，不要只选择最好的一次。

测量完整结果

至少采集：

目标每秒请求数和成功响应数；
p50、p90、p95、p99 与最大延迟，并注明测量位置；
HTTP 状态分布、连接错误、超时和无效响应；
网关 CPU、常驻内存、网络字节、文件描述符与重启次数；
上游 CPU、延迟与错误；
压测端 CPU、端口、Socket 与实际发送速率；
作为独立实验的配置收敛时间和控制面故障行为。

在看到结果前就定义容量边界。例如：p99 低于目标、非策略性 5xx 和超时不超过错误预算，且没有组件超过持续资源上限时的最高目标速率。这样可以防止某个网关通过快速返回错误而“获胜”。

增加过载与恢复测试

稳定状态只能回答一半问题，还应测试：

从正常负载突然升到过载，再恢复正常；
上游变慢或不可用；
连接频繁创建与 TLS 握手；
大请求头和有上限的请求正文；
流量期间更新配置；
一个网关副本退出；
策略依赖超时；
恢复时间，以及队列中的工作是否引发第二次峰值。

主动拒绝和处理失败应分开统计。按策略返回的 429 或负载卸载响应可能保护了上游，但仍表示请求没有成功处理，而且必须符合预先配置的策略。

避免常见跑分错误

**路由不同：**正则与前缀匹配，或不同路由数量，会改变测试问题。
**TLS 路径不同：**只让一个网关终止 TLS 会使比较失效。
**镜像未固定：**使用 latest 会让后续复现失去基础。
**隐藏默认值：**Worker 数、连接池、访问日志、Dashboard 与遥测设置都会影响结果。
**压测端饱和：**平坦曲线可能描述的是客户端，而不是网关。
**缺少正确性检查：**绕过插件的快速路由不是有效结果。
**只报告平均值：**平均值会掩盖尾延迟与过载崩溃。
**复用宣传结果：**其他硬件和负载上的数字只能作为背景，不能证明你的环境。

可复现交付包

应发布：

1benchmark/
2  README.md                 # 决策目标、范围、运行顺序、无效运行规则
3  environment.txt           # 硬件、操作系统、内核、运行时
4  manifests/                # 固定版本的网关与上游定义
5  config/                   # 等价路由与策略
6  load/                     # 脚本与载荷 Fixture
7  raw/                      # 未修改的工具与遥测输出
8  analysis/                 # 解析代码与生成的表格
9  checksums.txt              # 产物完整性

README 应说明执行者、时间、使用的提交，以及哪些结果为何被排除。交付包中不能包含凭证，生产数据也应替换为合成 Fixture。

决策检查清单

工作负载是否代表计划中的网关职责？
版本、版本形态、资源、拓扑和配置是否固定？
施加负载前是否已证明策略行为等价？
上游基线是否明显高于测试范围？
是否同时报告目标负载、尾延迟、错误与利用率？
重复运行与过载恢复是否得出一致趋势？
其他工程师能否从公开产物复现结果？

总结

足以支持决策的网关跑分是一项受控实验，而不是争夺最高每秒请求数。应统一请求路径，区分纯代理与策略场景，测量正确性和尾延迟，暴露饱和点，并发布复现工作所需的全部信息。只有这样，Traefik、Kong 和 APISIX 的测试结果才能支撑具体团队的选择。

常见问题

哪种网关最快？

如果没有版本、拓扑、协议、策略、硬件和成功标准，这个问题就不完整。本文方法要回答的是与你的工作负载相关的更具体问题。

只使用 `wrk` 是否足够？

它适合 HTTP/1.1 冒烟和容量测试，但完整研究还可能需要固定速率生成器、协议专用工具、系统遥测、正确性检查与故障注入。

控制面是否应该算入数据面性能？

应把请求路径延迟与控制面行为作为不同指标，但运维决策和成本模型必须同时包含两者。

后续步骤

把这套方法应用于 Apache APISIX 与 Kong 的候选拓扑，设置网关并发容量预算，并建立 TLS 性能测量方案。