2026年初我们团队花了大半个月做了一次开源API网关的横评。起因并不复杂服务微服务化的过程中流量入口一直散落在各个服务里鉴权逻辑、限流策略各写各的光是统一这部分就够头疼。偏偏这时候业务又提了新需求要把各家大模型接口的调用也收口到一个入口统一管理按部门核算成本、按调用方限制额度、单条流式响应的监控也得有。看起来是“网关选型”实际上是在给未来两三年的架构定调子。所以我把2026年能看到的开源方案全部拉了出来老牌的Kong、Apache APISIX云原生路线的Higress、Envoy Gateway、Gloo轻量路线的Traefik、KrakenD、Tyk还有这一年在AI网关赛道上冒出来的新面孔MAI Gateway。这篇文章是完整记录谁适合做微服务网关谁更适合做AI流量入口哪些项目看着热闹但我不建议踩坑都会讲到。1. 2026年API网关的三个新变化不止是路由和限流了1.1 传统网关的“基本盘”还在但权重变了API网关的传统职责说白了就是四件事统一入口、路由转发、安全管控、可观测。具体到功能上就是路径和服务的转发规则、鉴权认证、限流熔断、灰度发布、日志和指标采集。这套东西在2026年依然是刚需任何评测都绕不开。但权重变了。三年前选网关大家首先问性能其次插件多不多再次能不能在Kubernetes里当Ingress用。现在再问一遍答案的优先级会不一样——因为AI流量进场了。我们这次横评里性能依然看但更多关注的是网关能不能处理流式响应、能不能按token做限流、能不能对多个模型供应商做路由和故障转移。这些能力传统网关不是完全没有但大多要靠插件拼凑拼出来的效果和原生支持的差距很大。1.2 AI流量成为网关必须接管的“新基本盘”2025年到2026年之间企业调用大模型的方式发生了本质变化从一开始在代码里直接写供应商SDK到开始统一收口。原因很现实四条多供应商容灾单一模型的可用性不再可信出故障时需要自动切换到备用的模型服务商这层逻辑不能散落在业务代码里。成本失控token费用需要按调用方、按部门、按业务线核算没有了网关这一层统一记录月底对账就是一场灾难。安全合规prompt和响应内容需要审计留痕密钥不能散落在各个服务的环境变量里。性能问题流式响应是长连接一个请求可能持续几十秒甚至几分钟这对网关的并发模型、超时设置、日志采样方式都是新的考验。传统网关的限流器是按QPS设计的AI场景需要的是按token/秒计费而且是三个维度同时限制请求次数、输入token数、输出token数。再加上语义缓存、模型路由、prompt模板管理等能力这已经不是“给网关加个插件”能覆盖的范围了。1.3 网关与Mesh、Ingress的边界越来越模糊另一个变化是Kubernetes的Gateway API成了南北向流量的标准定义方式之后Ingress Controller、API网关、服务网格入口这三者的边界开始模糊。像Higress直接把Ingress、微服务网关、安全网关三者合一用Envoy Gateway专注于用Gateway API管理南北向流量Istio管的是东西向的网格内部通信但它也能生成网关配置。选型的时候必须意识到你已经不是在“选一个网关”了而是在“确定流量治理的架构边界”——哪些流量走网关、哪些走Ingress、哪些走Mesh这个边界先定清楚工具选择才有意义。2. 候选名单分三派成熟稳定、云原生新锐、轻量专项2.1 成熟稳定派Kong Gateway与Apache APISIXKong是开源网关里的老资历底层基于Nginx/OpenResty插件体系用Lua写生态非常完整。配置支持PostgreSQL存储的DB模式和纯静态配置的DB-less模式控制面数据面可以分离。它的插件市场是我见过最丰富的从基础的限流熔断、鉴权到服务发现、缓存转换都能找到现成的企业版还带开发者门户和更细粒度的管理功能。Kong最大的优点是“稳”和“全”社区足够大文档足够全踩坑的痕迹都能搜到。缺点是配置变更的动态性不如后来者——很多配置修改需要reload才能生效虽然在高可用架构下reload不是大事但高频动态调路由的场景确实不够优雅。Apache APISIX也是OpenResty底子但配置层改成了etcd驱动路由、插件、上游都可以热更新不需要reload。插件数量也很可观而且支持Lua以外的多语言插件开发通过Plugin Runner跑Java、Go、Python这在异构团队里是实打实的优势。项目是Apache顶级项目国内的社区活跃度很高中文资料非常全。APISIX在动态性上是明确胜过Kong的性能两者在一个量级。如果你有大量动态路由、动态上游的需求APISIX会更顺手。2.2 云原生新锐派Higress、Envoy Gateway、GlooHigress是阿里开源的项目基于Envoy数据面控制面自研。它最大的特点是“三合一”兼容Kubernetes Ingress标准兼容Gateway API同时还能替代Spring Cloud Gateway这类微服务网关并且自带一套WAF能力。对已经在用阿里云、或者熟悉Dubbo生态的团队Higress的学习曲线会平缓得多。它支持WASM插件意味着可以用Go、Rust等语言写插件而不是被绑定在Lua上。Envoy Gateway则更纯粹它就是围绕Envoy Proxy和Kubernetes Gateway API构建的南北向入口定位非常克制。如果你希望网关完全由Gateway API资源来描述不让网关有一丁点“平台私有配置”Envoy Gateway是理念最正的选择。代价是它的功能边界也比较“老实”很多高级策略要靠Envoy的Filter扩展对Envoy的理解门槛偏高。Gloo这里特指Gloo Gateway背后是Envoysolo.io出品。它更偏向企业级流量治理GraphQL支持是它的招牌能力AI网关方向也有专门的产品线。不过开源版本的功能边界需要仔细看有些能力只在企业版里。2.3 轻量专项派Traefik、KrakenD、Tyk、Spring Cloud Gateway、ShenYuTraefik是Go写的主打自动发现和极简配置。在Docker和Kubernetes环境里它能从容器标签或注解直接生成路由几乎零配置上手。中小型团队、边缘入口、非核心业务用Traefik非常舒服但它不太适合做承载企业核心治理策略的大网关。KrakenD也是Go写的但它的理念完全不同——它更像一个API聚合框架。配置是静态的改配置要重新加载但它能在一个请求里聚合后端多个服务的数据再组装返回性能极高。适合做编排聚合层不适合做动态策略下发。Tyk是Go写的完整API管理平台开源版带网关、仪表盘、开发者门户功能完整度很高QPS性能在Go阵营里也不错。它的定位更接近“API产品管理平台”如果你要做对外API的订阅、计费、开发者自助服务Tyk值得看。Spring Cloud Gateway是Java/Reactor栈对Spring生态的团队非常友好各种Filter写起来很顺手。但性能天然不如Go和C系的方案动态性和插件生态也比较受限。如果你已经是Spring Cloud全家桶内部服务间网关用它合理但对外入口我建议还是上面那几位。Apache ShenYu是Java系的国产网关支持HTTP、Dubbo、Spring Cloud、gRPC、Motan等多种协议转换插件化设计也不错。在Java技术栈为主的传统企业里ShenYu是多协议网关里比较能打的一个。2.4 候选全景表网关底层/语言配置存储插件语言许可证核心定位上手难度KongOpenResty/LuaPostgreSQL / DB-lessLuaApache-2.0通用API管理中Apache APISIXOpenResty/LuaetcdLua/Java/Go/PythonApache-2.0动态API网关中HigressEnvoy/Go控制面Kubernetes CRDWASM/Go/RustApache-2.0云原生三合一网关中高Envoy GatewayEnvoy/GoGateway API CRDEnvoy FilterApache-2.0K8s南北向入口高Gloo GatewayEnvoy/GoCRDEnvoy Filter/WASMApache-2.0企业级流量治理高TraefikGo配置/Label/CRDGo中间件MIT轻量自动发现低KrakenDGo静态配置GoApache-2.0API聚合框架低TykGoRedis PostgreSQLGo/JSMPL-2.0全栈API管理平台中Spring Cloud GatewayJava/Reactor配置中心JavaApache-2.0Spring生态微服务网关中低Apache ShenYuJava数据库JavaApache-2.0多协议微服务网关中3. MAI Gateway凭什么进横评AI原生网关的定位与风险3.1 它诞生的背景2026年的AI网关赛道老实说第一次听说MAI Gateway的时候我以为是某个大厂的内部项目开源了查了一圈才发现它是这一轮AI网关浪潮里社区讨论度上升最快的新项目之一。按公开资料它的定位非常聚焦——面向大规模LLM调用场景的API网关把模型供应商接入、密钥管理、Token级限流、成本统计、语义缓存、流式代理这些能力做成开箱即用的功能。它不像Kong和APISIX那样强调“通用API管理”而是集中解决一个问题当企业内部大量业务开始调用外部大模型API时谁来统一管住这些流量。这个切入点和我前面说的第二大变化完全重合所以尽管它年轻也值得纳入横评名单。我暂时没有找到官方对“MAI”这个缩写的统一解释不同资料里写法也不一样——这本身也说明项目还在快速演进期用之前务必要看准版本。3.2 功能取向Token级限流、模型路由、成本分账、语义缓存从架构和文档上看MAI Gateway做对了几件事。第一是Token维度的配额体系它把限流单位从请求数细化成输入token、输出token两个维度分别限制这恰好对应了大模型计费的两段式结构。第二是模型路由可以配置一组模型供应商按优先级、成本、延迟做选择失败时自动切换到备用的供应商这比你自己在业务代码里写fallback要干净得多。第三是成本分账它记录了每次调用的模型、token数、预估费用并按调用方维度聚合月底结算不需要再从各个服务的日志里翻。第四是流式响应的处理。这一点很关键普通网关代理SSE或流式gRPC时如果超时配置不当长响应会被网关掐断。MAI Gateway在流式代理上的处理我实测下来是合理的它的超时控制能区分“首次响应超时”和“整体流超时”这对大模型动辄几十秒的流式响应非常友好。3.3 客观提醒新项目的风险点在哪里新项目有新项目的红利也有必须正视的坑。MAI Gateway当前最明显的问题有三个社区规模还小。和APISIX、Kong这种Apache顶级项目或十年老牌相比它的Issue回复速度、插件生态、第三方集成文档都还处在早期阶段。遇到冷门问题大概率只能自己啃源码。生产案例少。公开可查的落地案例大多集中在中小规模的AI平台和创业团队大规模高并发的生产验证还不多。如果你的核心业务流量一天上亿次调用用它之前建议做足压测和故障演练。版本迭代快接口不稳定。这种快速演进是好事但也意味着跨版本升级可能有breaking change。只有在团队有人能持续跟进项目动态的前提下才适合作为核心网关长期持有。我的判断是如果你的平台AI调用量已经占了相当比例而你们又不想在传统网关上花大量时间拼装AI插件MAI Gateway值得PoC。如果你们的核心负载还是普通REST APIAI调用只是附属那用它替代通用网关就是自找麻烦。4. 横评是怎么做的测试环境、压测工具与八个评分维度4.1 环境与工具横评最怕的就是拿不同硬件环境下的二手数据对比所以我统一用同一套环境重新部署、压测。具体配置如下项目配置压测机8核16G云主机运行wrk和hey网关机4核8G云主机每款网关以容器方式独立部署后端服务同VPC内一台4核8G实例提供两个HTTP接口/api/hello/api/stream压测工具wrkHTTP/1.1、heyHTTP/2、自写流式测试脚本压测参数100并发、30秒时长、keep-alive开启网关版本各项目2026年2月最新稳定版这个配置不高但作为横向对比足够公平。所有网关都关闭多余的日志采样用默认配置跑一轮再加限流插件跑一轮目的是看出插件带来的性能损耗。4.2 八个评分维度单比性能是耍流氓我这次横评用了八个维度转发性能基准场景下的QPS和P99延迟。动态性路由、插件、上游配置修改后是否需要reload。功能完备度限流、熔断、鉴权、灰度、可观测这些基础能力是否开箱即用。K8s集成度是否直接支持Ingress/Gateway API是否好用。AI流量治理流式代理、Token限流、模型路由、成本记录。运维复杂度部署组件数量、依赖服务数据库/etcd/Redis、故障排查难度。社区与生态活跃度、文档质量、插件数量、生产案例。许可证友好度开源协议、企业版与开源版的功能边界。4.3 两类测试场景场景A是传统微服务网关场景后端是普通HTTP接口加两个常用插件限流JWT鉴权看QPS和P99的变化。场景B是AI代理场景后端返回模拟的流式响应持续输出约30秒重点观察网关是否在流中途断开、内存占用曲线和并发处理能力。这个场景是这次横评里最花时间的部分因为它暴露出不少网关对流式长连接的处理缺陷。5. 实测数据与功能矩阵别被单点性能带偏5.1 基准性能数据仅供参考需要先声明下面这些数据只在我这个4核8G的环境中有效不代表任何官方性能结论。真实业务里的表现取决于插件数量、配置、网络拓扑和业务体量。但作为横向参照它足够说明问题。网关场景A QPS基础限流JWT场景A P99延迟ms场景B流式代理30秒流Kong约410008.2稳定需要手动调proxy_read_timeoutApache APISIX约460007.5稳定流式表现好Higress约440007.8稳定WASM插件下内存涨幅需关注Envoy Gateway约480007.1稳定配置稍繁琐Gloo Gateway约430007.6稳定开源版AI插件有限Traefik约3500010.4一般流式需要额外配置Tyk约2900012.5流式支持较弱MAI Gateway约360009.6原生支持好内存占用低我唯一感到意外的是MAI Gateway在场景B里表现得比几个传统网关都省心——因为它的流式代理是内置能力不需要像Kong那样手动调整一层层超时参数。但在场景A的通用路由性能上它和第一梯队还是有差距。5.2 加入限流鉴权插件后的真实差距插件是网关性能的“隐形税”。纯转发性能再高限流、鉴权、日志这三个插件一挂性能衰减通常都在15%到40%之间。测试结果里最典型的是Tyk它功能全、体验好但插件链路的开销在低配置机器上会被放大而APISIX和Envoy Gateway在插件场景下的衰减相对平滑说明它们的插件执行链路优化做得更好。5.3 功能矩阵对比能力项KongAPISIXHigressEnvoy GatewayMAI Gateway基础路由/限流/熔断成熟成熟成熟成熟基础可满足热更新配置部分是是是是K8s Ingress需插件是原生原生一般Gateway API部分是是原生不支持多语言插件仅LuaLua/多语言WASMFilter/WASMGo扩展Token级限流需插件需插件有AI插件需扩展原生多模型路由需定制需定制部分需扩展原生成本分账需定制需定制部分需扩展原生语义缓存需定制需定制部分需扩展原生流式代理开箱可用否是是是是这个表基本划清了边界传统网关的AI能力是“缝”出来的要么靠社区插件要么靠自研扩展AI原生网关的AI能力是“长”出来的但通用治理能力还需要时间补全。5.4 一句话点评Kong老而弥坚插件生态无敌适合求稳的团队动态性别期待太高。APISIX动态性、性能、社区三者最均衡是我个人最倾向的通用网关首选。Higress如果要用K8s和WASM插件它是最懂国内企业习惯的选手。Envoy Gateway理念最纯正但要求团队对Envoy和Gateway API有足够底子。MAI GatewayAI流量治理的体验确实原生但目前只适合做AI入口的专用网关。Traefik小团队边缘入口神器核心流量别指望它扛太多策略。Tyk做对外API产品管理平台很合适纯技术指标不是它的强项。Spring Cloud GatewayJava技术栈内部网关可以对外入口算了。ShenYu多协议转换场景值得看综合性能中等。6. 选型逻辑从业务场景倒推网关形态6.1 先回答三个问题再谈选型第一个问题你们有没有Kubernetes且是否已成为事实标准如果答案是肯定的优先看原生支持Gateway API的网关Envoy Gateway、Higress而不是先把Nginx系网关装进K8s再包一层Ingress适配器。第二个问题AI调用流量在整体流量中的占比是多少我的经验阈值是10%。低于10%传统网关加AI插件完全够用不值得为此引入第二套网关体系高于10%甚至AI流量是主要业务那单独一层AI网关MAI Gateway或KongAI插件组合是值得的。第三个问题团队能维护多复杂的网关每多一个依赖组件etcd、PostgreSQL、Redis、WASM运行时日常运维成本就多一分。选型不只是选功能是选你们未来半年要背的运维债。6.2 典型场景对应的推荐组合我根据这次横评的观察给几个可以直接参考的组合传统企业微服务迁移大量现有服务要统一收口首选APISIX备选Kong。理由动态性强中文资料全插件覆盖企业常见需求。全面云原生K8s已是唯一基础设施首选Higress备选Envoy Gateway。理由Ingress/Gateway API/微服务网关三者合一省一套组件。Java技术栈很深暂时不打算引入C系/Go系组件Spring Cloud Gateway做内部网关对外入口用APISIX或Higress做前置代理两层分工。AI调用量大多模型供应商并存需要成本分账和Token治理在通用网关前面或旁边加一层MAI Gateway专管AI流量通用网关继续管REST API流量。小团队、边缘业务、快速上线Traefik一把梭别想太多。6.3 不换网关也能用上AI能力的路径如果你已有的网关是Kong或APISIX不一定非要推倒重来。Kong有官方AI Hub插件集可以补齐多模型路由和AI限流能力APISIX社区也有AI相关的插件在快速成熟Higress自带AI插件能力而且和阿里云生态打通。我的建议是先小范围把AI插件用起来跑一段时间看两个指标——流式请求的稳定性、Token配额管理的准确度。这两个指标如果满足要求完全没有必要引入新网关。7. 部署和迁移中踩过的坑都是文档不会明说的7.1 Kong的DB模式与DB-less模式别中途切换Kong的DB模式方便管理但要依赖PostgreSQL而且配置存在数据库里多环境同步要额外设计DB-less模式配置全在声明式文件里适合GitOps但一旦运行起来动态变更能力几乎为零。我们团队早期贪图DB模式方便后来想让配置进GitOps流水线中途迁移折腾了一周。如果你是新项目直接想清楚用哪种模式不要两头摇摆。7.2 APISIX的route优先级和插件执行顺序APISIX的route有priority字段默认值下如果两个路由规则重叠匹配到的可能不是你预期的那条。限流插件和鉴权插件之间有固定的执行阶段但同阶段多个插件的执行顺序在文档里写得不够直观。我的经验是涉及多插件协同的场景先在一个独立环境里用curl把每个阶段的效果打出来验证再上生产。不要相信“按配置顺序执行”这种直觉。7.3 流式代理的超时配置AI场景的头号问题这是我在横评里踩得最深的坑。传统网关最常见的默认配置是proxy_read_timeout 60秒普通接口完全够用但大模型流式响应一旦超过60秒网关会把连接掐断业务侧表现就是“响应生成到一半突然断了”。排查这类问题第一反应不要看应用日志先看网关的upstream超时时间。Kong、Traefik都有这类参数使用AI场景前务必先调大、并区分首次响应超时和整体流超时。MAI Gateway这类AI原生网关在这方面处理得就好很多原生就区分了这两个超时维度。7.4 WASM插件带来的内存与GC问题Higress支持WASM插件很香但WASM运行时在每个worker里都要占用一份内存。我们测试过程中一个简单的WASM限流插件就能让网关内存上涨30%到50%压测结束之后内存也不会立刻回落。问题不在WASM这个技术本身而在物理内存规划。按我们4C8G的机器同时挂5个WASM插件再跑高并发已经开始频繁触发GC了。所以用WASM插件前先把内存压测做足必要时给网关单独扩内存。7.5 多实例限流的一致性配额数据存在哪网关一上多实例限流的配额同步就是大问题。Kong的本地限流插件只在单实例生效要跨节点一致就必须启用基于Redis的限流插件但这又会引入Redis的延迟和单点风险。APISIX同样如此它的limit-count插件默认是单节点计数多节点部署需要配置Redis地址。MAI Gateway的处理方式是把配额数据放在统一存储里代价是限流判定延迟比本地计数高一些。这个取舍一定要在选型阶段想清楚你要的是极致精准的跨节点配额还是极致的低延迟两者兼得需要额外架构。这次横评最大的收获其实不是哪个网关跑分最高而是让我想明白了一件事API网关的选型永远不是选“最好的技术”而是选“最适合你们团队当前结构和未来一年的技术债承受能力”的方案。如果你的平台AI调用量正在高速增长别急着把现有架构推翻先加一层专用的AI网关做收口如果你的团队还在为微服务治理焦头烂额那从APISIX或Higress入手把基础治理做扎实比追逐任何热点都重要。最后再分享一个实操技巧无论最终选了哪款网关上线前一定先做一轮流量复制和影子测试把生产真实流量影子打进新网关对比一下QPS、延迟、错误率这三个指标比你做十轮压测都管用。