写这篇稿子之前我又翻了翻 APISIX 和 Kong 的 GitHub release 记录。这两年“AI 网关”的概念被炒得很热很多文章一上来就是“APISIX 颠覆 Kong”“Kong 已死”这类标题但真正在一线维护过网关的人都清楚所谓颠覆从来没有一夜之间发生的道理。Apache APISIX 从 2019 年开源到 2022 年从 CNCF 毕业再到今天把 AI 代理、Token 限流、语义缓存这些能力写进插件体系每一步都有清晰的技术路线和踩坑痕迹。这篇文章我想从从业者视角把这段演进史拆开讲讲Kong 当年赢在哪APISIX 又是靠哪些架构决策一步步追上并跑出自己的节奏最后再聊聊 AI 网关这个新赛道上APISIX 凭什么被推到了台前。适合读这篇文章的人应该是正在做网关选型或迁移评估的工程师也包括那些已经用着 Kong 但被控制台、性能、云原生适配等问题困扰的团队。我会把架构差异、健康检查配置、AI 插件玩法、生产环境避坑这些内容全部揉进去尽量给到可以“抄作业”的配置和思路。1. 网关江湖十年Kong 率先跑通APISIX 踩着 OpenResty 的肩膀逆袭1.1 2015-2019Kong 把 API 网关概念做成大众产品Kong 在 2015 年开源时市面上几乎没有像样的开源 API 网关。那时大家在微服务拆分过程中网关层面要么自己拿 Nginx 写 Lua要么用 Spring Cloud Gateway 硬顶再要么干脆用 F5、Nginx Plus 这类商业负载均衡器。Kong 出现后直接提供了一套“路由 服务 上游 插件”的标准化模型route 匹配请求service 绑定上游upstream 做负载均衡和健康检查插件体系覆盖认证、限流、日志、转换等场景。这套模型后来被太多产品模仿以至于行业里聊 API 网关绕不开 Kong 定义的那套抽象。Kong 的早期成功离不开 OpenResty。OpenResty 把 Nginx 和 LuaJIT 整合在一起让开发者能在 Nginx 的各个请求处理阶段里写逻辑。Kong 等于把微服务网关要做的鉴权、限流、转发、日志全变成了可安装的 Lua 插件。2017 年前后做技术选型Kong 几乎是唯一能满足“开箱即用 可编程”的开源方案社区活跃、文档齐全很多公司直接在它上面做二次开发。我印象最深的是那时候讨论网关大家默认有一个“Kong 模式”数据库管配置Admin API 管变更插件负责所有横切关注点。但问题也很快暴露。Kong 的控制面默认依赖 PostgreSQL企业版还能选 Cassandra所有配置都放在数据库里。数据面如果要感知配置变更要么靠轮询数据库要么靠 Admin API 触发 reload。请求量上来后reload Nginx 是有代价的连接会断、延迟会抖、长连接全部重连。Kong 后来做了声明式配置和 DB-less 模式试图绕开数据库但架构的影子还在——它本质上是“服务端配置数据库 旁路控制”的设计。对于一个面向高并发场景的网关来说这种设计注定要遇到天花板。1.2 2019-2023APISIX 的云原生化破局APISIX 在 2019 年由支流科技开源很快进入 CNCF并在 2022 年成为毕业项目。很多人问它凭什么崛起我认为核心就两件事etcd 驱动的动态配置以及从第一天就面向 Kubernetes 设计的姿势。这两点恰好是 Kong 当时最不舒服的地方。APISIX 的控制面不用关系型数据库而是直接拥抱 etcd。etcd 天生支持 watch 机制配置一变化所有数据面节点能毫秒级感知完全不需要 reload。这个特性在云原生环境里价值巨大Kubernetes 控制器把 Service、Ingress 的变化同步到 etcdAPISIX 的 worker 监听 etcd 增量事件在内存中热更新路由、上游、SSL 证书。对运维来说新增一个上游节点、改一个超时时间、加一条限流规则Admin API 调用一下或者 Dashboard 点一下实时生效。这种体验和 Kong 过去那套“改配置、跑迁移、reload Nginx”的流程相比完全不是一个时代的产物。APISIX 在性能上也下了不少功夫。路由匹配默认用 radixtree也就是基数树的工程实现对大量前缀路由、参数路由的匹配效率极高。Kong 早期很多版本用的是正则列表匹配路由条目一多CPU 开销直线上升。虽然后来 Kong 也引入 radixtree 思路但 APISIX 从开源起就把高性能当成核心卖点社区里大量压测对比哪怕和原生 Nginx 配置比APISIX 的额外损耗都压得很低。对技术决策者来说高性能是拍板最痛快的理由也直接帮 APISIX 拿下了第一批生产用户。更关键的一点是APISIX 的开源策略非常激进。Kong 的好多功能例如 Kong Manager 控制台、主动健康检查的高级可视化配置、多环境管理往往被划进企业版。而 APISIX 从开源第一天就把 Dashboard、Admin API、完整健康检查、高级路由、参数映射全部开放。想想一个场景团队在搜索“kong manager 节点主动健康检查配置”发现官方文档里对应界面是企业版功能社区版只能绕道 Admin API 写一长串字段另一边 APISIX 用户打开开源控制台直接点点点。这种差距对中小团队尤其致命也解释了为什么 APISIX 能在开源社区里快速建立口碑。1.3 演进史里的关键节点APISIX 的版本演进也能看出产品思路的转向。早期版本重点打基础把 etcd 集成、路由性能、核心插件做扎实中期开始做云原生集成比如 Ingress Controller、Service Mesh 适配到了 3.x 版本插件体系越来越完善跟 AI 相关的插件也开始出现。 Kong 的版本演进则更偏向企业功能叠加社区版与商业版的边界逐渐清晰。这背后是两种商业化路径的分野Kong 走的是“开源获客、企业版收费”的老路APISIX 则更依赖开源生态驱动。这样的路线差异直接影响了功能走向也为后来 AI 网关的赛跑埋下伏笔。2. 架构分水岭同样基于 OpenResty为什么 APISIX 能和 Kong 掰手腕2.1 控制面etcd 是配置总线PostgreSQL 是配置库老读者会有疑问APISIX 和 Kong 底层都是 OpenResty凭啥 APISIX 的架构更先进关键在于控制面和数据面的交互方式。用生活化类比解释PostgreSQL 存配置就像一个仓库Kong 的每个节点需要时不时派人去仓库看有没有新货有的话搬回来再 reload 应用。etcd 存配置像一条广播总线APISIX 节点订阅了 etcd 里的 key一有变化etcd 立刻推送新配置节点在内存里完成热更新不需要 reload。前者是“拉取 整体重载”后者是“订阅 增量热更新”高并发下的体验完全不一样。很多人忽略的是etcd 本身就是分布式强一致存储。生产环境部署三节点 etcd天然具备高可用能力不用像 PostgreSQL 那样额外搭主从复制。APISIX 的配置变更只要写进 etcd都会通过 raft 协议达成一致数据面各节点拿到的是同一个版本的配置。对比 Kong 在 DB-less 模式下用静态 YAML 文件、deck 工具同步的方式APISIX 在动态性和云端联动上明显更顺滑。不过这里必须提一个早期教训APISIX 早期对 etcd 的依赖非常强etcd 集群抖动会直接影响数据面。后来项目引入本地缓存与故障容错机制即便 etcd 短暂不可用已加载的配置还能继续服务请求只是变更无法下发。这个兜底能力很重要但它不等于让你绕开 etcd。生产部署时etcd 必须当一等公民看待单独集群、独立磁盘、定时备份、监控告警全部配齐。别以为 APISIX 的数据面是纯 Nginx 就很轻控制面一旦趴下你连加一条路由都做不到。2.2 路由与性能radixtree 带来数量级差异APISIX 的路由匹配基于 radixtree核心机制是公共前缀复用。比如你有几千条路由路径分别是 /api/users、/api/orders、/api/productsradixtree 会把 /api/ 这个公共前缀合并匹配时沿着树的子节点快速定位而不是拿请求路径挨个正则比对。这个数据结构对网关场景极其合适因为线上路由的 uri 大量存在公共前缀树形结构能显著减少无效比较。Kong 从 2.x 开始也往 radixtree 方向调优但很长一段时间里它的路由表达方式还是数组加正则路由数量一多CPU 占用立刻看得出来。社区的压测数据显示上万条路由场景下APISIX 的匹配耗时能做到比 Kong 的旧方案低一个量级。网关是流量入口单次匹配省下 0.1 毫秒乘上百万级 QPS就是很大的 CPU 成本差异。APISIX 的 radixtree 路由还支持不少高级玩法按 header、cookie、query 参数做条件路由配合 vars 表达式实现流量切分可以按权重把部分请求引到新版本服务可以做蓝绿发布和 A/B 测试。这些能力在微服务治理里非常实用。Kong 也能做类似事情但它通常需要额外插件或自定义逻辑配置复杂度更高。对团队来说够用的路由能力是底线玩得顺手才是加分项。2.3 插件体系从 Lua 一把抓到多语言插件 Runner插件生态是网关的灵魂这句老话到现在都成立。Kong 的插件市场沉淀多年认证、限流、转换、日志、WAF 都有成熟 Lua 插件这是它的存量优势。Kong 老用户常说“插件都写好了迁移成本太高”这个说法在 2020 年前很有说服力因为 APISIX 的插件数量确实在追赶。转折点出现在 APISIX 引入插件 runner 机制。它不再局限于 Lua而是支持独立进程跑 Java、Python、Go、Wasm 插件。这意味着 Java 团队可以不用学 Lua直接用熟悉的后端语言开发网关插件。比如内部要做一个复杂的加密插件Java 代码直接放进 runner业务逻辑几乎不需要为网关重写。这个能力把网关插件开发的门槛降了一大截对大型企业尤其有吸引力。插件机制的另一个关键点是热加载。APISIX 的插件配置修改后实时生效不需要 reload worker。Kong 的社区版里不少插件配置变更依然需要 reload这在生产环境是有感知的。试想一个场景线上流量高峰你需要把某个限流阈值从每秒 1000 调到 100APISIX 改一下配置请求立刻按新阈值执行Kong 老流程走到 reload连接闪断、流量抖动运维心态直接崩。虽然 Kong 现代版本在不断优化但底层机制决定了体验上限这也是很多团队在实际压力测试后选择 APISIX 的重要原因。3. 运维视角从 Kong Manager 到 APISIX Dashboard健康检查到底怎么配先回应最近频繁出现的一个搜索词“kong manager 节点主动健康检查配置”。Kong Manager 是 Kong 企业版里的图形化管理控制台支持在 Upstream 页面配置 Health Checks。健康检查分为主动和被动两类主动健康检查是网关定期主动发探测请求判断上游节点存活被动健康检查是在真实业务请求中根据成功率、失败率推测上游状态。生产环境一般优先配主动健康检查因为它不依赖真实流量故障感知更稳定。但问题在于Kong Manager 是商业版组件社区版用户根本看不到完整控制台界面。想配主动健康检查只能通过 Admin API 或 deck 声明式配置写一长串 JSON。Kong Gateway 官网文档虽然提供了健康检查示例但多是最简配置生产环境中要调的 timeout、interval、healthy、unhealthy 阈值都得自己摸索。这个信息差导致大量运维人员在配置健康检查时只配了被动检查或者参数设置不合理结果上游服务已经挂了网关还在继续转发。3.1 Kong Manager 的主动健康检查配置难在哪在 Kong Manager 里配置主动健康检查核心字段包括 check interval、timeout、healthy/unhealthy 阈值、探测路径等。界面逻辑看起来不复杂但有几个细节很容易踩坑第一主动探测路径必须是一个轻量接口很多人直接把首页或者业务接口写成探测路径导致探测请求本身消耗大量资源第二Kong 的健康检查状态不是全局一致的不同节点可能对同一上游服务有不同的健康判断尤其在多数据中心部署时更明显第三Kong 社区版的 deck/YAML 配置里字段层级很容易写错少一层或者多一层健康检查就直接失效。这些问题不是说 Kong 不能用而是它的可用性设计偏向企业版社区用户需要自己补齐很多细节。相比之下APISIX Dashboard 虽然是开源项目但健康检查的配置界面完整度很高。进入上游编辑页面打开健康检查开关主动检查、被动检查的参数全部可视化展示保存后即时生效。常规字段如探测协议、路径、间隔、失败次数以及高级字段如并发数、超时时间都能在 UI 里直接完成对运维非常友好。3.2 APISIX 的主动健康检查一段配置讲透APISIX 的 upstream 主动健康检查配置大概是这个样子{ type: roundrobin, nodes: { 10.10.0.10:8080: 1, 10.10.0.11:8080: 1 }, health_check: { active: { type: http, timeout: 2, concurrency: 2, http_path: /healthz, interval: 3, healthy: { interval: 2, successes: 2 }, unhealthy: { interval: 2, http_failures: 3 } } } }字段含义逐一说。type 是探测协议http 表示发 HTTP 请求tcp 表示做端口连通性探测。timeout 是单次探测超时时间超时就算失败。concurrency 是同时探测的节点数节点多时可以调大但小心把探活流量打成真实流量。http_path 是探测路径建议用专门为健康检查设计的轻量接口不要用业务接口。interval 是全局探测间隔healthy 和 unhealthy 下面的 interval 是节点进入对应状态后的探测频率successes 和 http_failures 则是连续成功或失败的次数判定阈值。配合被动健康检查可以在同一段配置里加 passive 字段。主动检查负责“无流量时也能发现故障”被动检查负责“故障发生时快速摘除”。两者配合才能覆盖完整的故障感知场景。比如某个节点假死主动检查每 3 秒探测一次失败 3 次才摘除最长可能需要 9 秒被动检查如果遇到真实流量连续 5xx可能在几次请求内就触发熔断时效性更好。生产建议二者都开但被动检查的阈值要结合业务合理设置太灵敏会导致上游稍微抖动就被摘掉。3.3 健康检查参数调优的三个坑第一个坑是 interval 太短。有人把主动检查间隔设成 1 秒上游几十个节点等于网关每秒发出几十个探活请求。如果探测接口还查了数据库那探活流量本身就成了压力源。生产环境建议主动探测间隔设置在 5-10 秒故障感知稍微晚一点可以接受探活流量爆炸不可接受。第二个坑是 unhealthy 阈值过大。默认连续失败 3 次才摘除可能导致故障节点持续被分配流量。如果上游节点资源有限或者服务恢复很慢建议把失败阈值调低到 2 次配合 fail_timeout 快速摘除。反过来healthy.successes 也不要设得太小否则服务刚恢复又被打下去节点会在健康和不健康之间来回震荡。第三个坑和负载均衡权重相关。APISIX 的 roundrobin 支持加权负载节点被标记为不健康后不会参与调度恢复后自动加回。这看起来很合理但要注意健康检查状态和真实可用状态之间可能存在的偏差。比如健康检查接口正常但业务接口因为某个依赖问题实际不可用主动健康检查就很难发现。这时候必须依赖被动健康检查和业务侧可观测性配合别把健康检查当成唯一救命的稻草。4. AI 网关时代APISIX 从 API 代理进化为 Token 流量管家4.1 为什么 AI 网关不能拿普通 API 网关硬改这两年大家都在谈 AI 网关普通 API 网关和 AI 网关到底差在哪我理解的核心差异在计费和流量模型。传统网关的限流按请求数或 QPS单位是请求次。AI 网关面对的是大模型推理流量计费单位是 token一个 Chat 请求可能持续几十秒流式返回几百上千个 token同时可能跨多个模型供应商。按请求数限流完全没有意义一次消耗一万 token 的请求和一次消耗一百 token 的请求对成本的冲击完全不同。另外大模型流式响应带来的可观测性问题也很麻烦。普通网关可以等完整响应回来再记录日志但 AI 场景里响应是持续流出的网关需要在流式过程中记录 token 消耗、首字延迟、总延迟等指标。传统网关插件做不了这些事需要全新的数据模型。APISIX 的做法是把 AI 流量当成一等公民在插件层面直接解析流式响应实时统计 token 用量而不是把整个响应缓冲完再计算。还有一个容易忽略的点是多模型路由的灵活性。企业接大模型通常不会只接一家OpenAI、Anthropic、通义、自建 vLLM 可能都会用到。应用如果直接写死某家协议后续切换 provider 成本极高。AI 网关的价值就体现在这里对上提供统一的 OpenAI 兼容接口对下可以把请求分发到不同 provider还能做模型的灰度、容灾和降级。这个逻辑和 API 网关的服务路由很像但协议转换从简单的 HTTP 转发变成了大模型 API 之间的语义转换复杂度不在一个量级。4.2 APISIX AI 插件族怎么用APISIX 对 AI 场景的回应不是停留在概念而是直接开源了一组 AI 插件。我用一张表概括它们的能力插件作用典型场景ai-proxy统一代理多种大模型 provider对接 OpenAI、Anthropic、自建服务ai-prompt-template管理 Prompt 模板多业务复用提示词统一维护ai-ratio-limiting按 token 消耗限流控制单用户或单应用成本ai-cache语义缓存重复问题降本提速ai-observability观测 token 消耗、延迟成本分析、用量报表这组插件单独看都不复杂组合起来价值很大。比如一个客服机器人项目用户经常问“退款流程是什么”和“怎么退钱”语义接近ai-cache 命中后直接返回缓存省掉一次大模型调用。ai-ratio-limiting 可以给每个用户设置 token 配额防止某个用户刷接口把预算耗尽。这些治理工作在网关层完成业务团队完全不用改代码。还需要提到的是APISIX 底层依然支持传统网关的全部能力。AI 流量和普通 API 流量可以混跑在同一套网关上不需要单独部署一套 AI 网关。你可以给 /v1/chat/completions 配置 AI 插件同时给 /api/orders 配置普通限流和鉴权插件这种融合能力在真实的业务架构里非常友好省掉了平行部署多套网关的运维成本。4.3 一个可落地的 AI 网关接入示例假设你在内网部署了一个 OpenAI 兼容的服务地址是 10.0.1.20:8000同时希望部分请求能路由到外部模型 provider统一走 APISIX 出口。第一步先创建 upstreamcurl -X PUT http://127.0.0.1:9180/apisix/admin/upstreams/1 -d { type: roundrobin, nodes: { 10.0.1.20:8000: 1 }, scheme: http }第二步创建 route绑定 /v1/chat/completions并配置 ai-proxy 和 ai-ratio-limitingcurl -X PUT http://127.0.0.1:9180/apisix/admin/routes/1 -d { uri: /v1/chat/completions, upstream_id: 1, plugins: { ai-proxy: { provider: openai, auth: { header: { Authorization: Bearer YOUR_KEY } } }, ai-ratio-limiting: { limit: 100000, time_window: 60, rejected_code: 429 } } }ai-proxy 的 provider 参数决定协议格式如果内网服务完整兼容 OpenAI 接口直接用 openai 即可。如果要对接 Anthropicprovider 改为 anthropicAPISIX 会自动完成协议转换。ai-ratio-limiting 的 limit 是 token 数time_window 是窗口秒数这个配置表示每分钟最多放行 10 万 token超了就拒绝。注意把管理端口 9180 限制在内网AI 网关入口如果裸奔在公网等于给攻击者留了一个按量付费的消费通道被刷爆账单时再后悔就晚了。再叠加一层 ai-cache。配置 Redis 作为缓存后端命中后直接返回缓存结果。实测在高频重复问题场景里语义缓存命中率可以达到 30%-50%。但缓存 key 和 prompt 稳定性强相关如果 prompt 里带了用户 ID、时间戳这类变量缓存命中率会大幅下降。这也是很多团队配置缓存后效果不佳的最常见原因。设计 prompt 时尽量把动态参数剥离出来让语义缓存能真正发挥作用。5. 选型与迁移心得别被“颠覆”冲昏头5.1 APISIX 生产环境的几个暗坑APISIX 的架构优势是实打实的但生产环境里也有几个必须提前了解的坑。第一个是 etcd 集群的运维要求。前面提到过etcd 是配置存储的核心它的稳定性直接决定控制面稳定性。单节点 etcd 一旦挂掉配置变更全部停摆。生产环境至少要三节点并且给 etcd 独立的磁盘和网络资源。不要把 etcd 和其他高负载应用混部在同一台机器上磁盘 IO 抖动会直接影响配置读写延迟。第二个是 worker 模型带来的共享内存问题。APISIX 的每个 worker 是独立的 Lua VM跨 worker 共享数据必须依赖 lua_shared_dict 或外部存储。如果你在自定义插件里用模块级变量存计数多 worker 下数据一定不一致。这个坑在开发自定义插件时几乎必踩一次。写插件前先想清楚数据要不要跨 worker 共享要共享就别偷懒直接用共享字典或 Redis。第三个是插件代码更新不走热更新。APISIX 的配置热更新很爽但插件 Lua 源码改了之后必须 reload worker 才能加载新代码。很多新手以为改了插件源码调一下 Admin API 就会生效折腾半天发现没变化其实是机制没搞清。发布自定义插件时要把 reload worker 纳进发布流程避免线上跑着旧逻辑还以为已生效。5.2 Kong 和 APISIX 到底怎么选我给一个务实的判断标准如果团队已经沉淀了大量 Kong 插件资产运维体系稳定业务对网关性能没有极致要求留在 Kong 完全合理升级时优先看官方企业版的商业支持。如果业务正在从单体拆微服务或者已经深度使用 KubernetesAPISIX 的云原生集成和动态配置体验会明显更顺手。预算敏感的开源用户APISIX 的开源功能完整度确实更有吸引力。AI 网关这个方向上两家都有布局。Kong 也推出了 AI Gateway 相关插件但 APISIX 的动作更早社区讨论更密集。我个人的判断是AI 网关的最终赢家不会是某个传统网关厂商的“新增功能模块”而是能把协议转换、成本治理、模型路由、可观测性快速落到云原生体系里的产品。APISIX 目前的牌面比较完整不过这个领域变化太快插件形态、配置方式可能半年就换一轮跟进时要务实别被厂商故事带偏。5.3 从 Kong 迁移到 APISIX 的实践路径如果下定决心迁移千万别搞一刀切。先做 side-by-side 灰度在 APISIX 里配置同一组上游和路由用小流量逐步切过来持续观察错误率、延迟和异常日志。重点核对三个差异点路由语义差异APISIX 的 uri 匹配和 Kong 的 paths 表达不完全等价插件行为差异比如认证插件的 header 名称、错误响应格式健康检查机制差异两边对不健康节点的判定和摘除时机不同。这三点对业务影响最大也最容易在迁移后引发线上事故。另一个经验是迁移期间把两边的访问日志同时留存对比同一条请求在两个网关上的转发结果。我见过不止一次迁移后某些客户端因为 TLS 指纹、SNI 行为或者 HTTP 版本协商差异而连接失败这种问题靠功能测试发现不了必须靠真实流量比对。迁移周期要留足别只看压测数字灰度观察至少跑一两个业务周期再考虑全量切换。最后分享一个实用小技巧利用 APISIX 的 control API 和 etcd 快照导出配置迁移前后做完整 diff确保两边路由、上游、插件配置的一致性。这个习惯帮我避开了很多配置遗漏的坑。另外迁移初期可以把 APISIX 的告警级别调高任何 5xx 比例上升、上游摘除事件增多都要第一时间介入。网关是流量咽喉迁移过程中出了问题影响的是全链路。我自己的体会是网关永远是那个“平时不显眼、出事背大锅”的组件。无论是 Kong 还是 APISIX选型时都不要被性能数字和厂商故事带偏要回到自己的流量模型、团队技术栈和运维能力。APISIX 能在这十年里从追赶者变成 AI 网关赛道的话题中心底层靠的是架构选择和工程细节的一点一滴积累。工具会迭代场景会变化但扎实的运维习惯和对原理的敬畏什么时候都不会过时。