1. 从Kong的统治时代说起APISIX为什么会出现如果你在2015年到2019年之间接触过微服务架构大概率绕不开Kong。那时候API网关的选型基本没有什么悬念想用开源方案Kong几乎就是唯一的选择它踩在OpenResty和Nginx的肩膀上把流量入口、鉴权、限流、日志这些基础设施做成了插件体系漫长的微服务化过程中Kong是那个时代最亮眼的网关方案。但用过Kong的人心里多多少少都埋着几个痛点。最典型的两个一是配置存储依赖PostgreSQL每次变更都需要走一次数据库同步加上Kong自身的缓存失效机制很多团队在网关配置量上了规模之后都能明显感知到改了配置怎么半天不生效的延迟二是它的路由匹配用的是基于正则和查找表的方案规则一多性能衰减就变得非常明显。这些痛点如果只是体感还好但放到大流量场景里就是实打实的成本和事故风险。APISIX就是在这个背景下出现的。2019年它作为一个开源项目对外发布核心团队来自当时的支流科技。2020年APISIX捐献给了Apache软件基金会随后快速从孵化器毕业成为Apache顶级项目。它的瞄准目标很直接Kong能做到的它要做Kong做得不够好的它要换一种方式做。特别是配置分发这块APISIX早期就选择了etcd作为配置中心利用etcd的watch机制实现配置秒级下发彻底绕开了业务配置变更靠数据库轮询或手动刷新的老路。这个选择后来被证明是APISIX整个技术路线的关键分岔口。etcd的watch机制天然适合控制面和数据面分离的架构也让APISIX在往云原生和Kubernetes生态靠拢的时候几乎没有额外负担。反观Kong一直到3.x版本才在声明式配置和DB-less模式上做了大量补强但从架构演进的历史包袱来看Kong是在传统模式之上叠加新能力而APISIX是从第一天起就是为动态化、高性能、云原生这三件事设计的。所以那几年经常能看到一种很有意思的技术社区讨论Kong还有没有必要学APISIX是不是Kong的替代品我的结论是二者在功能层面高度重叠但在设计哲学上是两代产品。APISIX的出现本质上是API网关进入云原生时代的必然产物Kong解决的是微服务初期网关从无到有的问题APISIX解决的是网关本身如何跟上基础设施演进的问题。后面的AI网关浪潮其实也延续了同样的逻辑——当上游流量的核心形态从服务间调用变成LLM API调用时网关这一层又需要一次能力重构而APISIX又一次站在了比较靠前的位置。2. 架构层面的正面交锋APISIX对比Kong的核心差异评价API网关绕不开三个维度路由性能、配置分发、插件体系。这三件事APISIX和Kong的做法都截然不同从结果上拉开了体验差距。2.1 路由匹配radixtree对比Kong的传统路由Kong在默认情况下使用基于正则表达式和查找表的路由匹配当路由规则数量增多、Service和Route之间关系复杂化之后匹配的开销会明显上升。而APISIX在路由层面直接拥抱了radixtree前缀基数树配合lua-resty-radixtree这个库实现路由匹配的时间复杂度跟规则的绝对数量关系不大更多取决于URI本身的长度和结构。这意味着什么在实践中我把几千条路由配置同时压到APISIX和Kong上做过对比测试同机型、同压测工具、同等规则数量APISIX在QPS上的领先非常稳定尤其在规则数量上千之后差距进一步拉大。APISIX社区早年公布的benchmark数据显示单核CPU下APISIX就能跑到几万甚至几十万的QPS量级远高于Kong在同样硬件条件下的表现。虽然不同人测出来的绝对值有差异但相对优劣的方向一直没有变过。2.2 配置分发etcd watch对比数据库轮询这一条是架构层面的根本分歧。Kong传统模式把配置存在PostgreSQL里数据面节点需要定期或者通过事件机制感知配置变更流程长、中间环节多。DB-less模式虽然绕过了数据库但配置文件本身是静态的动态更新又绕了回来。APISIX则从内核上支持控制面/数据面分离。控制面负责与etcd同步配置数据面只和etcd通信通过watch机制实时感知变更。任何一个路由、上游、插件的增删改都能在极短时间内生效到全集群所有数据面节点。我在生产环境里验证过通过Admin API修改一个上游节点的权重观察灰度流量曲线几乎在秒级就能看到变化。这对于做金丝雀发布、故障摘除这类操作来说差别是质的。另外APISIX在配置模型上做了分层设计全局配置比如SSL证书、插件元数据和业务配置Route、Upstream、Consumer分开管理日常变更集中在一小部分高频率对象上watch的效率和稳定性都更有保障。这些细节平时不显眼但大集群、频繁变更的时候优势就会放大成稳定性差异。2.3 插件体系成熟度与开发成本的权衡Kong的插件生态比APISIX起步早插件数量多、文档完善社区沉淀了大量经过生产环境验证的插件特别是企业版里那些面向企业的治理能力确实很成熟。如果你公司里已经积累了基于Kong插件体系的运维规范和代码资产迁移成本是真实存在的。APISIX则走了另一条路插件机制更轻量、更开放。它支持用Lua编写插件同时提供了Serverless模式——你可以用任意语言写一个HTTP接口通过serverless-pre-function或serverless-post-function插件在请求链路中动态调用。这个设计非常取巧它让那些不熟悉OpenResty生态的后端团队也可以用自己熟悉的语言快速扩展网关能力而不需要深入Lua和Nginx的实现细节。我在实际工作中更喜欢APISIX的另一个原因是插件的热加载体验。Kong在修改插件配置后同样能动态生效但APISIX对整个插件生命周期的管理更加精细插件可以按Route、按Service、按Consumer分别绑定还可以配置优先级。因为插件之间执行顺序可控很多复杂的流量治理逻辑可以通过组合几个基础插件来实现而不是非得自己写一个定制插件。这种组合优于定制的思路让日常运维压力小很多。下面用一张表总结几个关键维度的差异方便你对照评估对比维度APISIXKong配置存储etcdwatch机制实时同步PostgreSQL/Cassandra或声明式文件路由匹配radixtree高规则量下性能稳定正则查找表规则多时衰减明显配置生效速度秒级动态生效传统模式延迟较高DB-less模式更新受限插件扩展Lua Serverless任意语言HTTP调用Lua为主企业插件丰富云原生基因原生支持K8s、服务发现、控制面/数据面分离3.x逐步补齐历史包袱较重开源治理Apache顶级项目社区活跃度高核心开源企业版闭源组件多3. 健康检查配置对比从Kong Manager到APISIX的实操差异健康检查这个能力听起来是所有网关的标配但真正用好的团队不多。搜索kong manager 节点主动健康检查配置的人很多说明大家在配Kong的健康检查时遇到的实际问题不少。我正好在两个网关上都做过完整的健康检查方案把关键配置和踩过的坑一起记录下来。3.1 Kong Manager里配置主动健康检查的完整路径Kong Manager的可视化界面做得确实不错主动健康检查的配置入口也不难找。登录Kong Manager后菜单路径是Gateway Services → 选择目标Service → 进入Health Checks标签页 → 勾选Enable Active Health Checks。这里有几个核心参数配置时必须理解它们各自的作用Type健康检查的探测协议最常用的是HTTP和HTTPS。要注意Type选择HTTPS时如果上游证书不是公共信任的CA签发的默认探测会失败需要额外为健康检查配置CA证书或者SSL选项。HTTP Path健康检查的探测路径。不要默认用根路径/很多服务的根路径可能压根没有接口或者返回的是登录重定向尽量选择一个明确的、返回快的健康检查接口比如/health/live或/actuator/health这种。Interval和Timeout分别是探测间隔和超时时间。Interval设得太小会对上游造成不必要的压力我见过有人把Interval设置成1秒结果上游同一时刻收到大量网关节点的探测请求反而拖垮了业务健康接口。Healthy/Unhealthy阈值Kong里的标识比较直观Healthy条件里的Successes代表连续成功几次判定为健康Unhealthy里的Failures代表连续失败几次判定为不健康。这两个值直接决定了健康状态切换的灵敏度建议根据业务容忍度谨慎调整。用假配置给你一个直观的参考http_path: /health/live timeout: 2s interval: 5s healthy: - interval: 5s successes: 2 http_statuses: - 200 - 302 unhealthy: - interval: 3s failures: 3 http_statuses: - 404 - 429 - 500 - 501 - 502 - 503需要注意Kong Manager里的健康检查配置默认是针对Upstream级别的Target生效的如果某个Service的host不是通过Upstream管理的界面上的Health Checks相关的选项可能不可用。很多人在这块绕了半天问题其实在于该配的地方是Upstream而不是Service。3.2 APISIX健康检查的配置方式APISIX的健康检查配置全部落在Upstream对象上通过Admin API或者配置文件声明。它的设计比Kong更收敛字段组织和含义都很直白格式大致是这样{ upstream: { nodes: { 10.0.0.1:8080: 1, 10.0.0.2:8080: 1, 10.0.0.3:8080: 1 }, health_check: { active: { type: http, http_path: /health/live, timeout: 2, interval: 2, healthy: { interval: 2, successes: 2, http_statuses: [200, 302] }, unhealthy: { interval: 1, failures: 3, http_statuses: [404, 429, 500, 501, 502, 503] } }, passive: { type: http, http_statuses: [500, 502, 503], healthy: { successes: 3 }, unhealthy: { http_statuses: [500, 502, 503], failures: 3 } } }, keepalive_timeout: 60 } }这套配置的核心含义是主动探测每2秒向/health/live发一次请求连续成功2次标记节点为健康连续失败3次标记为不健康被动健康检查则是在真实请求流量中统计当上游连续返回多个5xx错误时直接把节点摘掉等主动探测恢复后再放回流量池。我把健康检查分成主动和被动两个维度是APISIX比Kong做得更精细的地方。主动检查解决的是无声故障——节点活着但服务不可用被动检查解决的是瞬时故障——流量进来后发现上游已经开始报错直接快速摘除而不是干等下一次主动探测。两者配合使用才能真正把网关对上游故障的感知时间压到最短。3.3 生产环境健康检查的踩坑记录健康检查配好不难配好之后能稳定跑才是真功夫。我把自己在生产环境里踩过的坑挑几个重点说说。第一个坑探测路径和业务接口耦合太深。有一次我把健康检查的探测路径设置成一个耗时的业务查询接口接口偶尔会超过2秒导致健康状态在健康和故障之间反复横跳。这个问题的本质是健康检查路径本身不具备快速返回的能力它应该在最短时间内给出一个确定性的状态信号而不是去执行业务逻辑。给上游团队定规矩的时候一定要明确健康检查路径里不允许有任何数据库或远程调用。第二个坑健康检查状态与真实流量恢复不同步。APISIX的被动健康检查在看门狗逻辑上做得比较细但如果上游网络分区抖动被动检查会误伤正常节点。我的做法是合理设置unhealthy的failures阈值不要因为一次两次失败就摘除节点配合主动检查的恢复机制让节点摘除和恢复都有一段确认期。我把这个叫做容忍抖动快速恢复——故障摘除要快但判断要稳。第三个坑多网关节点并发探测产生放大效应。你有3个APISIX节点每个节点都会对同一个上游做主动健康检查等于上游每2秒要承受3次探测请求。上游节点多的时候无所谓但如果上游是单实例或者资源紧张的服务这种常规的探测频率可能就成了压垮骆驼的稻草。这时候可以把探测interval适当调大到5秒或10秒或者利用APISIX同一个Upstream下所有节点共享探测结果的特点避免同一时刻多个数据面节点重复探测。这个细节Kong和APISIX都存在只是配置入口不同处理思路一样。4. 云原生路线图APISIX的演进路径从技术演进的角度看APISIX真正拉开和传统网关代差的地方在于它几乎完整地踩中了云原生基础设施变革的每一个节点。4.1 控制面与数据面分离带来的集群扩展优势传统Nginx系网关的启动、配置加载模型决定了它在多节点横向扩展时天然存在效率瓶颈。每个网关节点的配置都必须在本地生效配置来源和同步机制五花八门。APISIX则把控制面和数据面的职责在架构层面彻底分开控制面是Admin API加etcd数据面是Nginx worker进程加etcd watch客户端。新增一个数据面节点它启动后只需要连上etcd自动拉取全量配置并开始监听变更不需要人工干预也不会因为节点数量增加而放大控制面的压力。这个架构对Kubernetes环境尤其友好。我司把APISIX部署在K8s里作为南北向流量的入口网关Pod自动扩缩容的时候新拉起的APISIX节点能够在几秒内完成配置同步并开始接收流量。整个过程中不需要运维人员去处理任何把A节点的配置同步到B节点这类手工操作这是DB-less模式的Kong很难做到的流畅体验。4.2 Ingress Controller与CRD驱动的配置管理APISIX的Kubernetes集成方案是apache/apisix-ingress-controller它支持以CRD方式管理网关配置也支持直接从Ingress资源自动生成网关路由。我在K8s集群里用的比较多的方式是通过ApisixRoute这个CRD来管理路由规则它比原生Ingress的表达能力强很多可以精确控制路由优先级、服务发现类型、TLS配置、转发改写规则等。用CRD管理网关配置带来的另外一个好处是GitOps落地变得顺理成章。网关配置可以像应用代码一样走代码评审、CI流水线、自动发布所有变更都有历史版本可回溯。我曾经在裸机时代用脚本管理Kong配置出了问题只能靠日志和记忆排查切到APISIX的CRD模式之后任何一个变更都能精确定位到具体的Commit和作者这个体验上的提升对团队协作来说是决定性的。4.3 服务发现与微服务治理的深度融合APISIX内置了对Consul、Nacos、Eureka等注册中心的服务发现支持上游节点可以不写死IP列表而是根据服务名动态获取实例列表。在实际的微服务架构里这个能力意味着网关对上游实例的变化感知是自动的服务缩容、扩容、故障摘除网关侧都不需要人工干预。我所在团队的后端服务大量使用Nacos注册中心APISIX通过服务发现插件直接在Nacos里拉取实例列表同时配合健康检查实现双保险。Kong虽然也支持一些服务发现机制但整体上要么依赖DNS解析要么需要额外的服务发现模块配置复杂度和可维护性都不如APISIX的自然。服务发现、健康检查、负载均衡这三件事放在一起才是网关管理上游流量的完整闭环。APISIX把这三件事全部做成了配置驱动、动态生效的能力这恰好是云原生基础设施最需要的样子——系统尽可能自己感知、自己调整而不是靠人去填坑。5. AI网关API网关的下一个战场如果说过去五年Microservices Gateway是网关的统治性叙事那2023年之后AI Gateway正在成为新的叙事中心。这个大背景下APISIX的路线图迅速向AI方向倾斜并形成了非常清晰的落地产品能力。5.1 AI网关到底解决什么问题很多人第一次听到AI网关这个说法会有点模糊它和传统API网关的区别到底是什么我建议用一个简单的对比来看传统网关治理的是API请求在服务之间的流转AI网关治理的是业务系统与LLM之间的交互。这里面的核心差异化需求有四块API Key的安全管理把大模型提供商的API Key从业务代码里剥离出来由网关统一保管和注入避免前端或下游服务直接接触到Key。Token级别的流量控制传统限流单位是QPS但大模型计费和限流往往看Token数。QPS相同但Token消耗差异巨大的情况下必须做Token粒度的计量和限流。多模型编排与成本优化同一个业务请求可以根据场景路由到不同模型比如简单问答走小模型、复杂推理走大模型或者在不同供应商之间做故障转移。语义级安全与流量治理不仅是这个请求来自谁还要关注这个请求想干什么对Prompt内容进行审核和防护。这四件事传统API网关基本管不了或者管得很粗AI网关的价值正在于此。5.2 APISIX在AI网关方向的能力拆解APISIX在AI方向的落地核心是围绕一批AI专用插件展开的。我重点讲几个实际用得上的。ai-proxy插件是最基础也最重要的一个。它做的事情很纯粹让APISIX成为LLM API的统一出口。业务系统不再直接请求OpenAI、Anthropic、Azure OpenAI或者其他兼容OpenAI协议的模型服务而是统一请求到APISIX的某个Route上由ai-proxy识别上游供应商并完成请求格式的转换。这样上游模型供应商的API地址、认证方式和可能发生的接口变更都被APISIX这一层完全屏蔽掉了。给一个最简单的配置示例对接OpenAI{ uri: /v1/chat/completions, plugins: { ai-proxy: { provider: openai, api_key: sk-xxxx, timeout: 30 } }, upstream: { type: roundrobin, nodes: { api.openai.com:443: 1 }, scheme: https } }ai-prompt-guard插件则是做语义安全用的。可以针对Prompt内容做敏感信息检测比如手机号、身份证号、地址等实体信息的识别和脱敏也可以在检测到高风险指令时直接阻断请求。这个能力对于内部大模型应用来说几乎是刚需——你不想让员工跟LLM交互时把客户资料或内部战略文档原样传出去。ai-proxy还带一个很实用的能力叫模型编排APISIX可以提供基于权重模型路由比如两个模型副本分别绑定不同权重实现模型供应商之间的流量切换和灰度验证。我在落地大模型服务时就是用这个方式把少量流量切到新模型供应商观察返回质量和错误率稳定后再逐步调高权重整个过程中的客户端代码一行没动。下面的表格把APISIX目前的AI插件能力和用法整理了一份常用索引插件名称核心能力典型使用场景ai-proxy统一接入大模型API、多供应商切换、模型编排业务系统统一走后端网关调用LLMai-prompt-guardPrompt内容安全检测、敏感数据识别防止数据泄露、拦截恶意提示词注入ai-prompt-templatePrompt模板管理与变量注入标准化提示词格式方便审计ai-prompt-decorator在请求上下文中补充Prompt片段统一注入系统角色设定、知识库上下文ai-rate-limitingToken维度限流按用户或按应用维度控制Token消耗5.3 AI网关实践中的几个关键建议AI网关的落地我倾向于先解决API Key管理再做Token限流最后做语义安全和模型编排这种渐进路径。原因很简单API Key管理是纯技术问题收益立竿见影Token限流牵涉到计量和配额设计需要和业务方对齐语义安全则涉及误判率、隐私合规等更多复杂问题。这里特别要提一句Token限流的实现细节。APISIX的ai-rate-limiting插件需要配置一个token容量和刷新速率它会在网关层面维护一个小型令牌桶。但很多大模型API是按Prompt和Completion分别计费的响应Token数在请求发出前无法精确预估。所以我在配置时通常会留出安全余量把限流阈值设置为实际预算的70%左右避免响应Token消耗导致预算超支。另一个容易忽略的点是超时设置。LLM接口的响应时间波动很大简单的请求一两秒就返回了复杂推理可能要几十秒甚至更久。APISIX的ai-proxy插件里必须单独配置大模型接口的超时时间不要沿用普通API网关默认的几秒超时。我建议至少配置到30秒以上同时为这类Route单独配置一个更大的proxy_read_timeout否则业务方经常会反馈网关超时了但大模型那边其实已经生成了结果这类问题排查起来非常痛苦。6. 如何选择给团队的实际建议写到这里已经有不少读者会自然产生一个疑问那我们团队到底应该用APISIX还是Kong我分享一下纯个人向的判断标准仅供参考。6.1 我推荐选APISIX的场景如果你的团队正在做云原生改造K8s是主要基础设施未来大概率会有频繁的路由变更和流量治理需求APISIX是明显更适合的选择。它跟K8s生态的集成深度、配置动态生效的体验、以及高性能下稳定的表现都是Kong在同等开源条件下比较难追的。另外一个重要指标是社区活跃度。APISIX现在是Apache顶级项目社区活跃度、Issue响应速度、新功能迭代节奏目前都很快。你如果在GitHub上对比两个项目最近一年的Commit数、Release频率和贡献者数量APISIX的活力一目了然。这意味着你在遇到问题的时候找到答案、找到修复方案、甚至让官方快速修复的可能性都更高。6.2 继续留在Kong的合理理由如果你的团队已经在Kong上积累了深度的插件定制经验或者你的业务量级不大、对配置动态生效速度没有硬性要求留在Kong也完全合理。Kong企业版的成熟管理界面、丰富的企业级插件、以及大量的第三方技术集成在处理企业治理类需求时依然很有价值。技术选型永远要考虑迁移成本和历史投资Kong并不因为APISIX的崛起就变成一个不能用的方案只是它不再像五六年前那样具有压倒性的推荐理由。6.3 最容易被忽视的选型维度很多人选网关只看功能列表和benchmark跑分但我的建议是优先看配置管理体验。网关是基础设施里变更最频繁的组件之一今天加个路由明天调个健康检查阈值后天切个流量权重——这些日常操作是否顺畅、是否可自动化、是否可回滚才真正决定了你和团队在这套系统上长期的幸福感。这也是我从Kong迁移到APISIX之后体会最深的一点功能对比往往在PPT上就能完成但日常使用的顺畅感只有真实在长周期运维中才能感受到。如果你现在正处在网关选型的十字路口我建议你抽出一天时间在测试环境把同一个业务场景分别在两个网关上部署一遍尤其重点做三件事改一条路由看生效速度、把一个上游节点摘掉看健康检查流量变化、写一个自定义插件试试开发体验。做完这三件事答案大概率已经在你心里了。