3、API网关选型：Kong、APISIX、Envoy的延迟对比

在额度定价决策链路中，API网关是请求进入系统的第一道关卡，其延迟直接决定了整个链路的响应速度。本章从延迟维度对Kong、APISIX、Envoy三大主流网关进行对比分析，帮助你在架构选型时做出数据驱动的决策。

3.1 三大网关架构概览

延迟差异根源于架构设计。下表从核心代理模型、路由引擎、插件机制三个维度梳理三者的架构特征：

3.2 延迟基准测试结果

以下数据基于标准测试环境（4C8G 云服务器，HTTP/1.1 直连，无 TLS，单节点部署，100并发连接，1000次请求取P99延迟）。测试场景覆盖空路由、单插件、多插件三种典型负载：

3.3 延迟关键影响因素分析

延迟差异并非偶然，以下三个因素决定了网关的响应速度：

• 路由查找算法： Kong 使用 Lua 正则匹配，复杂度 O(n)；APISIX 和 Envoy 使用 Radixtree，复杂度 O(log n)。在 1000+ 路由规则下，Radixtree 的查找时间仅为正则的 1/5~1/3。
• 插件执行模型： Kong 的插件在 Lua 协程中串行执行，每个插件完成后再进入下一个；APISIX 将插件拆分为多个阶段（rewrite、access、header_filter、body_filter），允许部分阶段并行；Envoy 的 C++ Filter 链直接在事件循环中执行，无协程切换开销。
• 配置更新机制： Kong 依赖数据库轮询（默认 5 秒），更新后需 reload Worker 进程，期间产生毫秒级中断；APISIX 通过 etcd watch 实时推送，配置变更在 10ms 内生效；Envoy 通过 xDS 协议流式推送，变更延迟在 1ms 以内。

3.4 延迟对比架构图

下图从请求处理流程角度，展示三大网关在路由查找、插件执行、配置更新三个环节的延迟构成差异：

3.5 额度定价场景选型建议

结合额度定价决策链路的实际需求，给出以下选型建议：

• 低延迟优先（P99 < 5ms）： 选择 Envoy。其 C++ 原生性能和 xDS 配置推送机制能保证在 3~5 个插件场景下延迟控制在 3ms 以内。适合高频交易、实时计费等场景。
• 平衡型（P99 < 10ms）： 选择 APISIX。Radixtree 路由 + 阶段化插件执行 + etcd 实时配置，在 1000 路由、5 插件场景下延迟约 4ms。适合大多数企业级额度定价系统。
• 快速迭代型： 如果团队 Lua 开发能力强，且路由规则较少（< 200 条），Kong 的生态成熟度最高，插件市场丰富，可快速实现额度定价逻辑。

3.6 延迟优化最佳实践

无论选择哪款网关，以下优化手段均可降低延迟：

1. 路由规则合并： 将额度定价相关的路由按前缀或域名合并，减少路由表条目数。例如将 /v1/quota/* 和 /v1/price/* 合并为 /v1/*，在插件内部再做二次分发。
2. 插件链精简： 将多个轻量插件合并为一个插件，减少协程切换和上下文传递开销。例如将额度校验和定价计算合并为一个自定义插件。
3. 缓存热点数据： 在网关层使用 lru-cache 缓存用户额度信息，避免每次请求都穿透到后端服务。APISIX 和 Kong 均支持共享字典缓存。
4. 连接池复用： 配置 keepalive 连接池，减少与后端服务的 TCP 握手延迟。Envoy 默认支持连接池，Kong 和 APISIX 需在 upstream 配置中显式开启。

# APISIX 路由合并示例：将额度与定价路由合并
curl http://127.0.0.1:9180/apisix/admin/routes/1 -X PUT -d '
{
  "uri": "/v1/*",
  "plugins": {
    "limit-count": {
      "count": 1000,
      "time_window": 60,
      "rejected_code": 429
    },
    "serverless-pre-function": {
      "phase": "access",
      "functions": ["return require(\"quota_price\").handle()"]
    }
  },
  "upstream": {
    "type": "roundrobin",
    "nodes": {
      "backend:8080": 1
    }
  }
}'