★ FEATURED ARTICLE 干API网关这行做久了脑子里存着一堆深夜救火的画面。四年前我负责的平台还跑在Kong上那天凌晨核心业务抖动Kong依赖的PostgreSQL慢查询日志和Nginx错误日志来回翻配个路由动辄要同步缓存从那一刻起我开始盯上Apache APISIX。这篇不打算做菜市场级别的对比而是想聊聊APISIX的演进逻辑它怎么从当年被视为Kong的挑战者一步步变成如今AI网关赛道上的热门选择。技术路线背后的思路变化远比表面上的Benchmark更有意思。如果你正在做网关选型或者在Kong、APISIX之间犹豫又或者只是好奇“AI网关”到底和普通API网关有什么不同这篇值得看完。我会尽量用实际踩坑的经历来讲不堆概念。1. 先交代背景APISIX为什么出现在那个时间点1.1 网关解决的本质问题很多人一提到API网关第一反应是“反向代理”。这话对但太粗了。网关站在流量的最前面干的活本质上是四件事统一接入、安全防护、流量治理、可观测。统一接入好理解就是所有客户端别直接面对一堆散落的微服务统一走一个口子进来。安全防护是在这个口子上做认证、鉴权、防注入、限流。流量治理是灰度发布、权重调整、熔断降级、流量镜像这类高级操作。可观测则是记录日志、链路追踪、指标采集。打个比方网关就是一个园区门口的保安加前台。来访者先在前台登记保安核实身份然后按访客单引导到指定房间。如果某个楼要搞消防演练前台发出一部分人去B栋一部分人去C栋这就是灰度。听起来很简单但在分布式系统里这些操作的性能开销、配置管理难度、扩展性都会成为巨大的坑。1.2 Kong当年是怎么解决这些问题的Kong在API网关领域确实是里程碑式的存在。2015年前后开源基于OpenResty和Nginx用插件化方式把鉴权、限流、日志这些功能拆成一个一个可以插拔的模块。它把控制面和数据面分离数据面是Nginx worker处理请求控制面通过Admin API来管理配置配置持久化到PostgreSQL甚至早期的Cassandra里。这套设计在当年非常先进。在它之前很多人写网关逻辑就是直接改Nginx配置改完reload出了问题回滚都难。Kong让“动态管理路由、动态挂插件”变成了现实。很长一段时间里它都是开源API网关的默认答案社区生态也大企业版卖得也很稳。但放在今天的视角往回看Kong的架构里藏着一个隐患配置中心是数据库。数据库擅长的是持久化事务性数据但对于“配置变更需要快速广播到所有数据面节点”这个场景它并不是最优解。尤其是在路由规模上千、多可用区部署的时候配置变更的同步链路会变得很重。我自己当年的体会是在Kong上改一个插件参数有时候像发了一次生产版本。不是Kong不好而是那个时代的架构基因决定了它的行为模式。1.3 一个新的解题思路出现了APISIX诞生的时候云原生和Kubernetes正在快速普及。它从第一天起就走了一条不同的技术路线配置中心用etcd控制面和数据面之间通过etcd的watch机制做实时推送。这个改变带来的直观结果是你改一个路由规则不用reload Nginx不用等数据库同步配置变更在极短时间内就能推送到所有网关节点。路由匹配用radixtree基数树大量路由规则下依旧能保持稳定高效的匹配性能。APISIX后来捐赠给Apache基金会成为Apache顶级项目这本身也说明它的社区治理和技术方向得到了认可。从我的角度看它在那个时间点出现正好抓住了两个趋势一是业务系统全面容器化二是网关本身需要从“配置发版模式”走向“声明式实时生效模式”。2. 与Kong的路线差异不是跑分胜负而是架构理念更符合云原生2.1 存储层选型PostgreSQL与etcd背后是两种世界观Kong和APISIX最核心的分歧不在于谁的代码写得更好而在于配置应该放在哪里。维度KongAPISIX典型配置存储PostgreSQL早期也支持Cassandraetcd也可用Standalone本地文件模式配置变更机制通过Admin API写库数据面需要轮询或事件机制感知变更etcd watch机制变更实时推送扩展性思路数据库为中心适合传统部署分布式一致性和Kubernetes生态天然贴近运维复杂度需要额外维护数据库高可用需要维护etcd集群但对云原生团队来说很熟悉为什么etcd更贴合云原生因为Kubernetes本身就是用etcd存所有集群状态它天然支持分布式一致、范围查询、watch监听。网关配置本质上也是“需要所有节点保持一致状态的数据”所以用etcd而不是数据库在理论层面更顺。不过要注意etcd并不适合当业务数据库去存大量历史数据。网关配置最多几千几万条这个量级对etcd来说毫无压力。但如果你硬要把日志、审计记录都塞进etcd那肯定出事。APISIX社区一直强调etcd只放配置数据面产生的日志、指标走另外的管道这个边界一定要守住。2.2 路由匹配与热加载的工程细节再往下说一点工程实现。Kong和APISIX都是基于Nginx/OpenResty的但路由匹配算法的取舍不一样。Kong的路由匹配在某些场景下用基于正则和优先级的方式路由规则数量暴涨的时候匹配开销和规则排序复杂度都会上升。APISIX用的是radixtree这种数据结构对前缀匹配和通配符匹配非常友好而且支持运行时动态插入删除规则。实际体验中我迁移过一次路由规模比较大的服务几百条路由里混着正则、前缀、Host匹配、Header匹配APISIX的匹配结果依然稳定。而且插件热加载体验是真的好启用一个新插件修改配置后立即生效不用像老一代方案那样担心“reload瞬间连接中断”。注意Nginx reload不是洪水猛兽但高并发下reload确实会造成短暂的worker重启和连接波动。一个网关系统如果每次配置变更都要reload就等于把“动态”这两个字打了一半折扣。APISIX这种热加载能力在频繁调整灰度策略的时候非常爽。2.3 我的迁移实测从Kong到APISIX当时我们迁一个订单查询服务场景不算复杂几百个路由、统一JWT鉴权、按用户限流、日志采集、部分接口要做流量镜像。迁移步骤简单说是这样先从Kong Admin API把所有routes/services/upstreams的配置导出成JSON。写个脚本做字段映射把Kong的路由规则转换成APISIX的route资源。在测试环境用APISIX Admin API批量导入逐个核对路由匹配结果。灰度切流量先用小流量验证鉴权、限流、日志链路。观察客户端报错率和延迟确认稳定后再全量切换。用一个例子说明创建路由的配置格式。比如我要创建一个路径为/api/orders的路由走JWT鉴权限流每秒钟每个用户最多10次请求转发到上游服务routes: - uri: /api/orders name: order-service methods: [GET, POST] plugins: jwt-auth: {} limit-count: count: 10 time_window: 60 key_type: var key: consumer_name rejected_code: 429 upstream: type: roundrobin nodes: 10.0.1.23:8080: 1这段配置里uri就是路径匹配plugins按顺序生效upstream定义了转发目标。APISIX的配置哲学是一个资源就是一个JSON/YAML对象可以通过Admin API动态创建也可以写成声明式文件同步到etcd。当时踩过最大的坑是路由优先级。Kong里路由规则有regex_priorityAPISIX里有更细粒度的priority字段如果你同时存在/api/orders和/api/orders/:id这种规则没有显式设置优先级时匹配结果可能和预期不一致。我的建议是任何可能重叠的路由都显式设置priority别靠默认行为。3. 云原生阶段APISIX做对了什么3.1 与Kubernetes的配合几乎是天生一对APISIX在Kubernetes环境里的价值远比在传统虚机上明显。官方维护的APISIX Ingress Controller可以直接用Kubernetes的Ingress资源来驱动APISIX配置也提供了更细粒度的CRD比如APISIXRoute、APISIXUpstream、APISIXConsumer这些自定义资源。有了CRD之后网关配置就可以纳入GitOps流程。你不需要SSH到某台机器上去调配置而是提交一个YAML到代码仓库再由CI/CD工具把这份声明同步到集群。配置有review记录有版本历史出问题可以回滚。这种体验对从传统运维转过来的人来说简直是从手工记账切换到ERP系统。如果你已经用了KubernetesAPISIX Ingress Controller还有一个很实际的好处服务发现可以直接对接Kubernetes Service上下游节点变更不用手动维护upstream列表。Pod重建、扩缩容之后网关自动感知。3.2 多语言插件体系把扩展门槛降下来早期网关插件几乎都是Lua写的。Lua本身不难但真正能写好Lua插件、又理解Nginx异步模型的工程师数量确实有限。APISIX很早就设计了一套Plugin Runner机制支持Java、Go、Python、WASM等语言跑外部插件。这个设计理解起来其实很简单。把APISIX想象成一个插座板Lua插件是原生插头而Plugin Runner是一个转接头让不同语言的插头也能插进来。APISIX主进程和外部插件进程之间通过Unix Socket通信把请求阶段的数据交给外部插件处理拿回结果后再继续往下走。我团队里有个业务逻辑特别复杂的限流需求要用到公司内部的风控模型用Go写插件比用Lua顺手太多。生产实践下来外部插件的性能损耗是有一定代价的但换来的是“不用等Lua专家业务团队自己就能扩展网关能力”。这个权衡我觉得很值。3.3 顺带聊一个容易混淆的“Apache”话题这几天看到搜索热词里有人问“apache spark与databricks的区别”还有人搜“apache tomcat启动失败”。每次看到这种词条我都想说一句Apache是一个庞大的开源生态Spark是大数据计算引擎Tomcat是Java应用服务器而APISIX是云原生API网关。这四样东西唯一的共同点就是都属于Apache基金会应用场景完全八竿子打不着。很多人听到“Apache APISIX”第一反应是“跟Apache HTTP Server有关系”第二反应是“是不是那个老古董”。其实APISIX是很新派的云原生基础设施跟传统的Apache HTTP Server之间的距离就像智能手机和大哥大一样。搞清楚这一点选型时才不会先入为主。4. AI网关时代APISIX凭什么站在最前面4.1 传统API网关为什么接不住AI应用如果说过去几年网关主要接的是REST API和WebSocket那现在越来越多请求是发给大模型服务的。这类请求有几个特殊点第一上游供应商五花八门OpenAI、Anthropic、各类国内模型服务接口规范不统一有的兼容OpenAI协议有的有自己的签名流程。业务方接每一家都要单独适配。第二API Key管理是个大问题。你不能把厂商密钥直接放到前端或业务后端里密钥泄露就是钱的问题。而多业务线共享密钥又没法统计谁用了多少、谁触发限额。第三Prompt本身是敏感信息和核心资产。用户可能往Prompt里粘贴内部代码、客户资料网关如果不做脱敏和审计合规风险极高。第四流式响应让传统日志和监控全部失灵。普通HTTP请求返回一次就结束了LLM的流式输出是持续不断的内部还要关心首字延迟、token吞吐量、上下文长度这些新指标。第五成本控制。每个模型价格不一样同一个模型不同时段价格也可能不一样传统网关的限流配额是基于“请求次数”的而AI场景更关心“token数量”和“模型单价”。这一堆新问题传统的路由转发、鉴权限流能力只能覆盖其中一小部分。所以“AI网关”不是营销概念而是新场景倒逼出来的新品类。4.2 APISIX的AI原生能力是怎么设计的APISIX在近几个版本里已经沉淀出一套相对完整的AI网关插件体系。你可以把它理解成三块能力第一块是接入代理。ai-proxy这一系列插件可以把APISIX改造成一个对上游LLM服务的统一代理入口一个route对应一个模型供应商对外暴露统一的OpenAI兼容接口。业务方根本不用关心上游是OpenAI还是Anthropic还是别的什么只要请求网关的统一地址就行。替换供应商时网关层配置改一下业务代码完全不用动。第二块是模型路由与容灾。ai-llm这类插件可以配置多个大模型后端设置主备关系或按权重分发上游某个模型限流或故障时自动降级到可用模型上。这一条在AI场景里特别实用因为大模型服务的稳定性再大牌也会有波动。第三块是Prompt管理和语义缓存。ai-prompt-template可以在网关层给请求动态拼接系统提示词让业务方只需要传用户消息。语义缓存则是把常见问题的响应结果缓存起来命中缓存就直接返回大幅降低token消耗。AI插件还可以跟APISIX原有的通用能力天然组合。比如用key-auth做多租户鉴权用limit-count做按用户限流用prometheus插件做指标采集用request-logger记录每一次AI调用的请求和响应摘要形成完整的审计流水线。我实际体验下来这套体系已经不止是“能用”而是可以拿来做正式的AI应用接入基础层。有一个点我想特别提醒启用AI插件时路由层最好预留足够的超时时间。非流式的大模型接口经常要几十秒流式接口更是可能持续几分钟默认的60秒超时根本不够。需要针对AI路由单独配置read_timeout和send_timeout否则你会看到一堆莫名其妙中断的请求。4.3 一个真实场景把内部知识库包装成OpenAI兼容助手我们做过一个内部问答助手底层是RAG架构知识库向量化之后交给大模型生成回答。现在所有流量都走APISIX网关业务层不需要保存模型供应商密钥只需要在请求头带上内部统一身份凭证。网关上做的事情是按用户身份做鉴权和配额管理每个部门每个月多少token预算超了就限流财务月底拉账单。经ai-proxy统一转发到模型服务模型供应商密钥只存在于网关环境变量里。对入站Prompt做脱敏和拦截检测到手机号、身份证号等敏感信息直接打码。每个请求记录model、prompt长度、响应码、耗时的审计日志方便按业务线追溯。在主模型不可用的时候自动降级到备用模型用户无感知。这个方案做出来之后业务线的接入成本肉眼可见地下降了。以前新业务想接AI能力先要去申请密钥、自己处理限流、自己搞日志审计现在直接调网关接口就够了。这其实就是AI网关的核心价值把复杂度和风险集中收敛到一层对外提供简洁规范的能力。5. 从部署到排障我的实操笔记5.1 快速搭一套本地环境etcd加APISIX再加Dashboard如果你只是想跑起来看看最省事的方式是用Docker Compose。一个最小环境包含三个服务etcd、apisix、apisix-dashboard。# docker-compose.yml version: 3 services: etcd: image: bitnami/etcd:3.5 environment: - ALLOW_NONE_AUTHENTICATIONyes - ETCD_LISTEN_CLIENT_URLShttp://0.0.0.0:2379 - ETCD_ADVERTISE_CLIENT_URLShttp://etcd:2379 ports: - 2379:2379 apisix: image: apache/apisix:3.9.0 depends_on: - etcd ports: - 9180:9180 - 9443:9443 - 9080:9080 environment: - APISIX_STAND_ALONEfalse dashboard: image: apache/apisix-dashboard:3.0.0 depends_on: - apisix ports: - 9000:9000 volumes: - ./dashboard_conf/conf.yaml:/usr/local/apisix-dashboard/conf/conf.yaml启动后网关数据面端口是9080管理和API端口是9180控制台在9000。生产环境我不建议用这种方式但本地体验、跑通功能docker-compose是最快的路径。生产环境我的建议是用Helm部署在Kubernetes集群里etcd单独维护一个三节点集群APISIX实例至少两个副本控制台可以按需部署甚至可以不暴露公网。还有一点非常重要生产环境etcd的TLS必须开否则网关控制面数据裸奔在网络上隐患非常大。5.2 Dashboard里添加流复制的正确处理方式最近总有人搜“apisix dashboard添加流复制”我估计很多人在界面上找不到入口。先说结论Dashboard里不是每个插件的配置项都有漂亮的表单traffic-split插件一般要直接编辑JSON配置。流量复制也叫流量镜像的真实语义是把真实请求复制一份到另一个上游服务但客户端只拿到原上游的响应。这个东西常用于影子发布拿真实流量去压测新版本服务不影响线上用户。通过Admin API创建一个简单的流量复制配置如下curl http://127.0.0.1:9180/apisix/admin/routes/1 -X PUT -d { uri: /api/sample, plugins: { traffic-split: { rules: [ { weighted_upstreams: [ { upstream: { type: roundrobin, nodes: { 10.0.0.8:8080: 10 } } } ] } ] } }, upstream: { type: roundrobin, nodes: { 10.0.0.7:8080: 100 } } } 这段配置的含义是所有请求正常打到10.0.0.7的正式服务同时以10比100的权重也就是约9%的比例复制到10.0.0.8的影子服务。关键是影子服务的响应不会返回给客户端你只需要去影子服务查它的日志和指标就行。注意traffic-split复制的是请求但下游如果做了数据库写入操作影子环境会把真实数据写到测试库里。影子服务的数据库一定要隔离要么连测试库要么把写的操作全部mock掉否则你就等着被脏数据坑一晚上吧。5.3 常见故障清单与排查思路根据我自己的生产经验整理了一份网关故障速查表故障现象可能原因排查方向路由配置不生效配置了Standalone模式但又用Admin API写配置或者etcd连接失败先确认APISIX运行模式再看etcd到网关的网络连通性最后用curl /apisix/admin/routes确认配置是否真的写入请求全部401认证插件没有正确挂在route上或者consumer不存在检查插件是否启用、key和secret是否匹配、consumer是否创建成功流式接口中断、超时Nginx默认读取超时太短或者开启了缓冲单独给AI路由设置长read_timeout、send_timeout关掉proxy_buffering限流误伤大量用户limit-count的key选择不合理比如用了全局IPkey改成consumer_name或user_idIP这个维度在NAT环境下普遍不太靠谱插件配置格式报错插件字段名写错不同版本字段兼容性有变化去官方文档对照config字段测试环境先验证别直接怼生产配置回滚困难没有做etcd定期快照每次批量变更前用etcdctl snapshot save打快照便于快速恢复排查时我最常用的三板斧第一看APISIX错误日志默认在日志文件里Kubernetes环境用kubectl logs直接看第二用Admin API查询当前配置确认数据面看到的东西是不是和预期一致第三在测试环境用curl带不同header反复打路由逐步缩小范围。排查到怀疑插件顺序问题时可以把插件全部摘掉只留下转发先确认基础链路通。然后一个一个挂插件回来每挂一个就压一遍定位到是哪个环节引入问题。这种二分法看着笨但在生产环境反而最安全。最后分享一个我个人受用很久的小技巧如果你所在的公司后续需要把AI能力开放给多条业务线千万别一上来就让每个业务都直接拿模型厂商的Key。先在APISIX上把AI代理路由建好统一挂鉴权、限流、日志三个插件再让业务来注册接入。我这么干过之后省掉了大量“谁又把Key泄露到Git仓库”的头痛事也把每个月的模型账单控得明明白白。另外一个建议是APISIX的学习曲线没有想象中陡但你要先接受配置流这套思考方式。总拿它当普通静态Nginx用只会平白增加心智负担。等你看懂了etcd里那份配置结构等于打通了整个云原生网关的任督二脉。这个工具最后的边界是团队自身的运维体系而不是它本身的功能上限。
阅读完成 · 觉得有帮助？
