4. 容量压测作业平台API网关选型
API网关是容量压测作业平台的流量入口与安全边界。选型不当会导致压测流量转发延迟高、鉴权成为瓶颈、扩展性受限。本章从性能、可扩展性、社区活跃度三个核心维度展开对比，并给出基于Kong与APISIX的具体选型方案。
4.1 选型考量因素
在压测场景下，API网关需承载突发性高并发流量，同时集成细粒度的权限校验。以下三个因素构成选型决策的基石：
| 考量维度 | 关键指标 | 压测场景要求 |
|---|---|---|
| 性能 | QPS、P99延迟、内存占用 | 单节点≥10万QPS，P99延迟<5ms，内存稳定不泄漏 |
| 可扩展性 | 插件机制、自定义路由、多语言支持 | 支持热加载插件、自定义鉴权逻辑、与压测任务编排系统集成 |
| 社区活跃度 | GitHub Star、贡献者数量、版本迭代频率 | 社区响应快、安全漏洞修复及时、文档完善 |
选型原则： 压测平台网关不追求功能大而全，而应聚焦于低延迟转发与可编程鉴权两个核心能力。避免引入重量级网关导致压测流量失真。
4.2 基于Kong的选型方案
Kong基于OpenResty（Nginx + LuaJIT）构建，在API网关领域拥有最成熟的生态。其选型方案如下：
- 核心组件： Kong Gateway（数据面）+ Kong Manager（控制面）+ PostgreSQL/Cassandra（数据存储）。
- 性能表现： 单节点裸转发约8-12万QPS；启用RBAC与Key-Auth插件后约6-8万QPS，P99延迟在5-10ms区间。
- 权限集成方式： 通过自定义Lua插件或Kong Plugin Hub中的OAuth2/JWT插件实现压测任务的校验与资源级授权。
- 扩展性： 支持声明式配置（decK）、Kubernetes Ingress Controller、以及丰富的第三方插件市场。
- 社区活跃度： GitHub Star 39k+，企业版与开源版双轨并行，版本更新频率约每月1次。
适用场景： 团队已有Kong运维经验、需要成熟插件生态（如限流、日志、监控）、压测规模在10万QPS以内的场景。Kong的PostgreSQL依赖在极端高并发下可能成为瓶颈，建议启用连接池与读写分离。
4.3 基于APISIX的选型方案
APISIX同样是基于OpenResty的高性能网关，但在架构设计与性能优化上更激进。其选型方案如下：
- 核心组件： APISIX数据面 + etcd（配置中心）+ Admin API / Dashboard（控制面）。
- 性能表现： 单节点裸转发可达14-18万QPS；启用鉴权插件后约10-12万QPS，P99延迟稳定在3-5ms。
- 权限集成方式： 原生支持consumer-restriction、jwt-auth、hmac-auth等插件；支持通过自定义Lua或Wasm插件实现压测平台的动态权限策略。
- 扩展性： 路由匹配基于Radix Tree，性能优于Kong的DB-less模式；支持Wasm扩展，可运行Go/Rust编写的插件。
- 社区活跃度： GitHub Star 14k+，Apache顶级项目，版本迭代约每2周1次，社区响应速度快。
注意事项： APISIX强依赖etcd作为配置中心，etcd集群的稳定性直接影响网关控制面。在压测平台部署时，建议etcd与网关数据面分离部署，避免配置变更影响压测流量。
4.4 选型对比总结
以下SVG图从性能、扩展性、社区三个维度对Kong与APISIX进行雷达对比，帮助团队根据自身压测规模与技术栈做出决策：
从雷达图可以看出：APISIX在裸转发性能与可扩展性上略占优势，适合对延迟敏感的大规模压测场景；Kong在插件生态与社区成熟度上更胜一筹，适合需要快速集成第三方服务的团队。
4.5 最终选型建议
| 压测规模 | 推荐网关 | 核心理由 |
|---|---|---|
| 单集群 < 5万QPS | Kong | 生态成熟、运维文档丰富、团队上手快 |
| 单集群 5-20万QPS | APISIX | 低延迟、高性能、etcd配置中心更轻量 |
| 多集群 > 20万QPS | APISIX + 自定义Wasm插件 | Wasm扩展避免Lua性能瓶颈，支持多语言 |
| 已有Kubernetes基础设施 | APISIX Ingress | 原生K8s集成、声明式路由、自动服务发现 |
平台工程视角： 选型不是终点，而是起点。无论选择Kong还是APISIX，都需要在压测平台中封装一层网关抽象层，将路由配置、鉴权策略、限流规则以声明式API暴露给压测任务编排系统，避免业务团队直接操作网关原生API。这层抽象是平台工程“降低认知负载”理念的具体实践。