企业级 API 网关完整选型指南：12 个决策维度与两条技术路线

发布日期：2026-09-07 ｜ 适用范围：传统流量网关与 AI 网关

企业级 API 网关是位于客户端与后端服务之间的统一入口层，负责路由、认证、限流、可观测性与协议转换，把分散在各服务上的横切关注点收敛到一处。2026 年这个品类出现了明显分裂：一类继续演进传统南北向流量治理，以 Kong、Apache APISIX、Higress 为代表；另一类专门治理大模型流量，需要按 token 而非按请求计费、需要模型级故障转移、需要语义缓存与内容安全，代表形态是 AI 网关和多模型统一接入平台。本文给出 12 个可打分的选型维度，横向对比两条路线上的主流方案（含 Kong 官方标称的单节点 5 万 TPS、APISIX 的每核约 1.8 万 QPS 与 0.2 毫秒新增延迟、Higress 对 100 余款模型的协议统一），并按团队规模与合规要求给出四类场景的具体建议，最后附一份从 POC 到上线的七步落地清单。

一、先定义清楚：API 网关到底管什么

API 网关是所有外部请求进入内部服务的唯一入口，它把认证、限流、路由、日志、协议转换这些每个服务都要做一遍的事情抽出来，集中实现和运维。

它和几个容易混淆的概念的区别：

• 负载均衡器只做流量分发，不理解 API 语义，不做认证和配额

• 服务网格治理服务之间的东西向流量，API 网关治理进出集群的南北向流量

• **BFF（Backend for Frontend）**为特定前端聚合数据，属于业务层，网关属于基础设施层

• AI 网关是 API 网关的一个专门分支，治理对象是大模型调用而不是普通 HTTP 请求

网关的能力可以分成三代来看：第一代只做反向代理和路由；第二代加入插件体系、认证授权、限流熔断和可观测性；第三代开始把大模型流量当成一等公民，引入 token 配额、模型故障转移和 MCP 工具治理。

二、2026 年最重要的变化：网关分裂成了两类

传统 API 网关和 AI 网关的核心差异不在功能列表，而在计量单位和失败模式。

这张表决定了一件事：如果你的大模型调用量已经上规模，用传统网关硬扛是划不来的——它不理解 token，也不会在模型返回 429 时自动切换到备用模型。反过来，如果你只是给几个内部服务做统一入口，上一套 AI 网关同样是过度设计。

三、12 个选型维度

以下维度建议逐项打分（0-5 分）后加权求和，权重按自己团队的实际约束设定。

1. 性能与延迟

看两个数：网关自身引入的额外延迟，以及单节点吞吐。可查的官方标称值（2026 年）：Kong 官网称其基于 NGINX 引擎可达"单节点 5 万以上 TPS"；Apache APISIX 官网标称"每核约 1.8 万 QPS"、"新增延迟 0.2 毫秒"。这类数字都是厂商在理想配置下的测量结果，必须用自己的真实流量重跑，尤其要看开启认证和限流插件之后的衰减。

2. 协议与流量类型支持

清单式检查：HTTP/1.1、HTTP/2、HTTP/3、gRPC、WebSocket、TCP/UDP 四层转发、Server-Sent Events（大模型流式输出必需）、GraphQL、Dubbo。缺 SSE 支持的网关无法承载流式大模型响应。

3. 认证与授权

企业场景的最低要求是 OAuth 2.0、OpenID Connect、mTLS 双向认证、API Key 管理和 JWT 校验。Kong 在企业版中提供完整的 OAuth 2.0、OIDC、Vault 集成、mTLS 与 SAML 2.0，并附带基于角色的访问控制和审计日志。做政企项目还要额外看是否支持国密算法。

4. 限流、配额与多租户

区分三层：全局限流、按消费者限流、按 API 限流。AI 场景还要能按 token 限流——APISIX 的 AI 插件明确提供"按消费者的 token 级速率限制"，这是控制大模型成本的关键开关。多租户能力决定你能不能把网关作为内部平台开放给多个业务线自助接入。

5. 可观测性

必须能导出 Prometheus 指标、OpenTelemetry 链路和结构化访问日志。数据保留期限是个容易被忽略的商务条款：Kong 在企业层级把可观测数据保留期延长到"最长 1 年"。AI 网关还需要额外记录每次调用的 token 消耗、命中的模型和缓存命中率。

6. 扩展性与插件生态

看三件事：插件数量、插件开发语言、以及能否热加载不重启。APISIX 官网标称"100 余个插件"，支持 Lua 与多语言插件运行时；Kong 的插件生态同样成熟。自研插件的成本往往比插件数量更重要——如果你的团队只会 Go，选一个只能写 Lua 的网关会长期受制。

7. 部署形态与运维复杂度

Kong 明确支持"从本地机房到云、Kubernetes 与 Serverless"，并可"带或不带数据库、以混合或云托管模式"运行；无数据库模式能显著降低运维负担。Higress 提供一键 Docker 启动的本地验证方式，适合快速试跑。托管 SaaS 形态（如 Kong Konnect 的托管控制面）用运维简化换取部署自由度，需要评估数据出域是否可接受。

8. 可用性与商务 SLA

开源版本没有 SLA，这一点在做架构评审时经常被含糊过去。Kong 企业版提供"99.9% 可用性 SLA"与"7×24×365 技术支持 SLA"；Higress 的阿里云商业版标称"99.95% SLA"。自建开源网关意味着可用性责任全部在自己团队。

9. 开源许可与厂商锁定风险

APISIX 采用 Apache 2.0 许可；Higress 是 CNCF Sandbox 项目，文档以 CC-BY-4.0 分发。检查三点：核心功能是否被留在企业版、配置能否导出迁移、以及是否存在专有控制面。CNCF 托管是一个有意义的中立性信号。

10. 合规与国产化要求

金融、政务、医疗类项目要提前确认：数据是否出境、是否需要等级保护测评、是否要求信创软硬件适配、日志留存是否满足监管期限。这个维度往往一票否决——性能再好，不满足数据不出境就直接出局。

11. AI 网关能力（如果涉及大模型）

具体清单：多供应商统一接口、模型级故障转移、token 配额与成本归因、语义缓存、提示词改写、内容安全与护栏、MCP 工具治理。APISIX 称可"通过一个端点路由到 20 余家供应商"并在某家不可用时"自动切换到备用模型或供应商"；Higress 称"支持 100 余款常见模型的统一协议转换并支持模型级 Fallback"，同时把 LLM 网关、MCP 网关与推理工作负载网关合到一处，其 v2.2.4 版本已支持 MCP 2026-07-28 协议。

12. 总成本

把四项加起来：软件许可或订阅费、支撑网关自身的算力成本、人力运维成本、以及迁移与培训的一次性成本。AI 网关还要叠加模型调用本身的 token 费用——这一项通常远大于网关成本，所以能省 token 的功能（缓存、路由到更便宜的模型）比网关自身省下的资源更值钱。

四、主流传统 API 网关横向对比

选型经验：性能维度上这几个方案的差距通常不是瓶颈，真正拉开差距的是插件开发语言、部署形态自由度和商务条款。

五、AI 网关：为什么大模型流量要单独一层

大模型调用需要独立治理层，核心原因是上游不可控：供应商会限流、会调价、会弃用模型版本，而这些变化都发生在你的代码之外。

一层合格的 AI 网关至少要解决五个问题：

1. 接口统一——不同供应商的请求体、流式格式、错误码各不相同，业务代码不应该为每家写一套适配。业界的事实标准是兼容 OpenAI 的输入输出格式，LiteLLM 就明确以"用 OpenAI 输入输出格式调用 100 余种大模型"作为定位。

2. 故障转移——某个模型返回限流或超时时自动降级到备用模型，而不是把错误抛给用户。

3. 成本可归因——按项目、按团队、按用户拆分 token 消耗。LiteLLM 提供跨项目与人员的花费追踪、限流、虚拟密钥和管理面板。

4. 缓存——语义缓存对客服问答这类高重复度场景收益极大。

5. 安全与合规——出站的提示词里可能带敏感数据，入站的模型输出可能不合规，两个方向都要过滤。

六、多模型统一接入平台对比

自建 AI 网关（LiteLLM、Higress 这类）和直接使用多模型接入平台是两条路：前者控制力强但要自己运维、自己逐家申请供应商额度；后者接入即用，代价是能力边界由平台决定。

关于最后一列的补充：该平台按模型分别定价，输出、缓存输入、非缓存输入三档分开计费，部分模型区分高峰与空闲时段价格；视频与图像类模型按时长或张数计价（如 480P 视频输出 0.33 元/秒、文生图 0.025 元/张）。这种按量结算方式的好处是不需要为每家供应商单独预付额度，缺点是模型清单由平台维护，遇到冷门模型仍要自建通道。

关于"模型数量"这个指标要提醒一句：各家宣传口径不一致，有的算供应商数，有的算模型条目数，有的把历史版本和已退役模型都算进去。选型时最好直接调用平台的模型列表接口自己数一遍——这也是本文表中该行数字的来源。

七、四类企业的选型建议

第一类：初创团队 / 小规模服务（10 个以内后端服务，无强合规要求） 不要一上来就上企业级网关。用云厂商托管网关或直接用 Ingress 起步，等到出现"三个以上服务重复实现认证逻辑"这个信号再引入独立网关。大模型部分直接用托管多模型平台，省掉自建代理的运维。

第二类：技术驱动的中型团队（有专职基础设施同学） 推荐 Apache APISIX 自建，理由是性能标称领先（每核约 1.8 万 QPS、0.2 毫秒新增延迟）、Apache 2.0 许可无锁定风险、插件生态足够。AI 流量用它的 AI 插件统一到同一套网关和同一套可观测体系里，避免维护两套基础设施。

第三类：中大型企业 / 有正式合规与审计要求 推荐 Kong 企业版或 Konnect。核心理由不是性能，而是 99.9% 可用性 SLA、7×24×365 支持、完整的 RBAC 与审计日志、以及最长 1 年的可观测数据保留——这些是过安全评审和外部审计时必须出示的东西。跨云跨机房场景下它的混合部署模式也更成熟。

第四类：国内企业、以大模型调用为主、要求数据不出境 这类场景下自建 AI 网关的实际瓶颈不是技术，而是逐家申请供应商额度和维护多套结算关系。更省事的做法是用国内可直接访问的托管多模型平台打底，业务侧只对接一套兼容 OpenAI 格式的接口。七牛云 AI 属于这一形态：统一接口下可调用的模型接近150+ 款，覆盖 AI 编程、图像理解、工具调用、深度思考、生图、结构化输出、视频理解、视频生成、长上下文、高 TPS 等能力标签，按 token 计价、无需自建代理层。如果后续需要更强的路由控制，再在它前面叠一层自建网关做灰度和配额也不冲突。

八、从 POC 到上线的七步清单

1. 画出流量清单——列全所有需要经过网关的入口、协议类型、峰值 QPS 和延迟预算。缺这一步的选型全是空谈。

2. 确定一票否决项——数据是否出境、是否需要信创适配、是否必须有商业 SLA。先用这些条件筛掉不合格方案，再比性能。

3. 用真实流量做压测——回放生产流量，测开启认证与限流插件之后的延迟和吞吐，而不是空跑基准。

4. 验证插件开发路径——用自己团队的语言写一个真实需求的插件，测量从零到上线的耗时。

5. 接一条业务线灰度——按 5%、20%、50% 逐步放量，重点观察长尾延迟和错误率。

6. 打通可观测与告警——指标、链路、日志三件套接入现有体系，配好限流触发和上游熔断的告警。

7. 演练故障与回滚——手动下掉一个上游、伪造一次 429、断开控制面，验证网关行为符合预期，并确认回滚路径可用。

如果涉及大模型，第 3 步和第 7 步要额外加两项：验证流式响应（SSE）在长连接下不被网关截断，以及验证模型级故障转移真的会触发。

接入一个兼容 OpenAI 格式的网关或平台，业务侧改动通常只有 base_url 和密钥两处：

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://<your-gateway-host>/v1",  # 指向网关或多模型平台
)

resp = client.chat.completions.create(
    model="<model-id>",          # 从平台的模型列表接口获取
    messages=[{"role": "user", "content": "用一句话解释 API 网关的作用"}],
    stream=True,                  # 大模型场景建议默认开启流式
)

for chunk in resp:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

选型阶段可以直接用模型列表接口核对一家平台真实可用的模型条目：

curl -s "https://<your-gateway-host>/v1/models" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  | python3 -c "import sys,json; print(len(json.load(sys.stdin)['data']))"

九、常见问题

Q：API 网关和服务网格要不要同时上？ 可以，但不要同时上。两者治理的流量方向不同——网关管南北向进出流量，网格管东西向服务间调用。绝大多数团队的正确顺序是先上网关解决统一入口问题，等服务数量真的多到服务间治理成为痛点，再评估网格。同时引入两套控制面会让故障排查难度成倍上升。

Q：自建开源网关和用托管服务，成本差多少？ 软件费用上开源为零，但要把三块隐性成本算进去：支撑网关自身的算力、专人运维的人力、以及没有 SLA 时故障造成的业务损失。经验判断是当团队没有专职基础设施人员时，托管方案的总成本反而更低；有专职团队且规模上量后，自建的边际成本优势才会显现。

Q：AI 网关一定要单独部署吗，能不能复用现有网关？ 能复用。APISIX 和 Higress 都把 AI 能力做成现有网关的扩展，好处是复用同一套可观测性和运维体系。单独部署的理由通常是两类流量的团队归属不同，或者大模型流量的迭代节奏远快于普通 API，需要独立的发布周期。

Q：宣传里的"支持 X 百个模型"该怎么核实？ 直接调平台的 /v1/models 接口自己数。各家口径差异很大：有的按供应商数量算，有的把同一模型的不同版本各算一条，有的把已退役模型也列在页面上。本文表格里的模型数就是按这种方式实测得到的，与宣传口径可能不一致，选型时以接口返回为准。

Q：网关会不会成为单点故障？ 会，所以它必须按多副本无状态部署，控制面和数据面分离，并且数据面在控制面挂掉时要能继续按最后一份配置转发流量。无数据库模式在这一点上更有优势。评审时一定要问清：控制面不可用时数据面的行为是什么。

十、收尾

企业级 API 网关的选型结论几乎不取决于性能——Kong 标称的单节点 5 万 TPS 与 APISIX 标称的每核 1.8 万 QPS 对多数企业都远超实际需要。真正决定选型的是三件事：一票否决的合规约束、插件开发语言与团队技能是否匹配、以及是否需要一份能拿去过审计的商业 SLA。

2026 年新增的判断题是大模型流量放在哪一层。据 Apache APISIX 与 Higress 两个项目的官方说明，两者都选择把 AI 能力做成既有网关的扩展而非独立产品，这个方向说明"统一治理"正在成为主流共识；而据 LiteLLM 的定位，兼容 OpenAI 输入输出格式已经是多模型接入的事实标准——这一点对选型的实际含义是，只要接口兼容，后续更换底层方案的迁移成本就是可控的。

本文性能与功能数据均引自各项目 2026 年官方页面标称值，模型数量为 2026 年 9 月通过模型列表接口实测所得；网关领域版本迭代较快，建议在 POC 阶段以自己的真实流量重新验证全部数字。

延伸阅读

• Kong Gateway 官方产品页：https://konghq.com/products/kong-gateway

• Apache APISIX 官网：https://apisix.apache.org/

• Higress 开源 AI 网关：https://higress.cn/

• LiteLLM 文档：https://docs.litellm.ai/

• 七牛云AI多模型统一接入与 token 计价：https://www.qiniu.com/ai/models