企业官网建设流程全解析

深夜的告警群里，连续刷屏的不是模型服务本身，而是网关把请求全部打回"上游 429"的拦截日志。值班同事第一反应是加大限流阈值，结果加了之后账单反而更高——因为大模型接口的计费单位是 token，不是请求次数，而传统网关的限流面板上根本看不到 token 消耗。类似的场景这两年我见了不少：很多团队在把业务接入大模型之后，才意识到自己手里的 API 网关面对 LLM 流量几乎是个"睁眼瞎"——它管得住 QPS，管不住成本和上下文长度，更别提模型故障时的自动切换。

这篇文章不谈概念，不列榜单，只把 Higress、Kong、Envoy/Istio 这三条技术路线的 AI 原生演进方向放在同一张桌上，从架构基因、AI 能力、选型决策、落地部署踩坑四个层面逐项拆开。我的建议是：没有"最好"的大模型网关，只有"最匹配你现状"的网关；读完你至少能知道该用哪一套决策框架去验证，而不是被官网的酷炫功能带偏。

1. 当 API 网关遇到大模型流量：三个"失聪"现场

在讨论选型之前，先得搞清楚一个大前提：为什么传统的 API 网关拿到大模型流量后会这么别扭。不是它们性能不行，而是它们的核心模型设计是围绕"短请求、短响应、按次数计价"的 REST 场景建立的。LLM 流量有三件事直接撞翻了这套模型。

1.1 现场一：按 QPS 限流，账单却在悄悄失控

传统网关的限流逻辑是基于请求次数的。但在大模型场景里，一次请求的代价可能相差几十倍：同样调一次对话接口，用户问一句"今天天气如何"可能只消耗几百 token，而 RAG 场景拼上一大段检索文档上下文，一次调用就是几千上万 token。如果只按 QPS 限流，你会看到一个诡异的现象：请求数很平稳，成本却在毫无规律地爬升。

更麻烦的是，不同模型、不同供应商的计费单位还不一样，有的按输入输出分开计价，有的带缓存折扣。传统网关的记录里只有"请求次数"和"响应字节数"，换算不成账单。所以我在评估网关时，第一个硬指标就是：它能不能做到 token 级限流、能不能按模型和供应商配置价格表、能不能把每次调用的预估 token 消耗和实际用量记录到日志里。光这一条，就能淘汰掉一半的"传统网关套壳 AI 插件"的产品。

1.2 现场二：长连接流式响应把超时和重试逻辑全打乱

大模型接口现在几乎默认走 SSE 流式返回，一个连接可能从建立到结束持续几十秒甚至几分钟。传统网关的超时配置、缓冲区、重试策略，全都是为"毫秒级响应"设计的，放到流式场景里就是连环坑：

• 网关默认缓冲响应体，等上游全部输出完才一次性转发给客户端，用户那边等了半天一个字都不出，体验直接归零；
• 网关的 idle timeout 一触发，长连接被掐断，客户端反而收到一个"半截响应"，前端解析 JSON 直接报错；
• 更致命的是重试。传统网关在收到上游 5xx 时会自动重试，但如果 5xx 出现在响应体已经开始输出之后，重试就意味着同一份内容被计费两次、推送两次。上游的扣费不会因为你网关重试就退款。

处理流式流量的核心，是把网关从"转发字节"升级为"理解内容流"：该透传的实时透传，该对断点做事件化通知的通知，绝不能盲目重试。这是考察 AI 原生网关时最容易忽略、但线上事故率最高的一环。

1.3 现场三：模型路由和降级只能靠业务代码硬扛

很多团队现在这么做主备模型切换：在业务代码里写 if/else，捕获上游超时和限流，然后手动改配置切到备模型。这样做的后果是，每次模型供应商故障都是一次线上发布，还要等业务重启。而我见过最夸张的例子，是一个团队为了切换模型，把已经部署的二十多个服务全部重新构建了一遍——就为了改一个环境变量。

网关层的价值就在于把路由、降级、灰度这些确定性动作集中到接入层：主模型连续报 429 或 5xx 时自动切换备模型；同一套接口按用户等级路由到不同的模型规格；按成本策略把非核心流量调度到更便宜的供应商。这些能力，必须由网关原生支持，而不是靠业务代码补丁。这也是"AI 原生演进"和"传统网关加一个 AI 插件"最本质的区别。

2. 三种基因，三条路线：Higress、Kong 与 Envoy/Istio 的架构底色

同一个目标，三条技术路线背后是完全不同的设计哲学。理解它们的出身，比背功能清单重要得多，因为出身决定了它们在 AI 时代的演进速度和边界。

2.1 Higress：从云原生 Ingress 长出来的大模型网关

Higress 是近年来在云原生圈子里讨论度很高的一个开源网关项目，数据面基于 Envoy，控制面兼容 Ingress 与 Gateway API，同时复用了一部分 Istio 的能力。它最初的身份是"云原生网关"，定位就是 K8s 集群的流量入口，后来在插件体系里逐步注入了 AI 能力，包括 AI Proxy、语义缓存、提示词防护、token 限流等，甚至开始支持 MCP 协议代理。

Higress 的特点一句话总结：它是"长在 Envoy 上的平台"，把 Envoy 的高性能和 Istio 生态的标准化能力包了一层更友好的外壳，AI 能力以插件和 CRD 的方式暴露出来。如果你已经在用 K8s，Higress 的上手曲线很平滑，能把 Ingress、微服务网关、AI 网关统一成一个入口。它的问题是"绑定 K8s"——如果你的生产环境没有 K8s，或者你的团队对 K8s 不熟，Higress 给你的就不是便利而是负担。

2.2 Kong：老牌 API 网关的插件化自救

Kong 是资格最老的 API 网关之一，商业版叫 Kong Gateway（Kong Konnect 是云版本），开源版也积累了庞大的插件生态和运维文档。Kong 的核心设计就是"插件化":鉴权、限流、转换、日志，全部通过插件叠加在请求链路上。进入 AI 时代，Kong 并没有推翻这个模型，而是在插件库里新增了一批 AI 插件：AI Proxy（做模型代理和路由）、AI Rate Limiting Advanced（token 级限流）、AI Semantic Cache（语义缓存）、AI Prompt Guard（提示词注入防护）等。

Kong 的路线是典型的"传统 API 网关 + AI 扩展"，它的优势主要在成熟度：管理界面、用户体系、RBAC、开发者门户、多环境管理，这些企业级能力打磨了很多年，对大企业有天然的吸引力。如果你团队已经跑着 Kong，那么加上 AI 插件可能是成本最低的演进路径。它的短板也很明显：AI 插件的深度不如专门建设的大模型网关，比如模型路由的故障恢复策略、语义缓存的效果调优，都还停留在"插件能用"的程度，细节上需要大量手工配置和时间打磨。

2.3 Envoy/Istio：服务网格系在大模型时代的位置

Envoy 是整个云原生生态里公认的高性能数据面，Istio 是它最出名的控制面搭档。严格来说，Envoy 和 Istio 不是"大模型网关"产品，而是"可以拿来拼出大模型网关的底座"。

这个底座的灵活度极高：Envoy 的过滤器机制允许你用 Lua 或 Wasm 写任意自定义逻辑，Istio 的流量管理能力可以做精细的路由和故障注入。社区也出现了基于 Envoy Gateway 的 AI 网关扩展（如 Envoy AI Gateway），试图把模型供应商接入、token 计量这些能力标准化。但对大多数团队来说，这条路的工程成本不是一般的高：你要自己组装认证、租户隔离、成本计量、语义缓存、模型路由，还要维护控制面和数据面的版本兼容。选它的人，多半是已经重度投入 Istio 体系、并且有充足平台工程能力的团队。

3. AI 原生能力正面交锋：七个关键维度的实测对照

进入具体功能对比时，不能只看官网的"支持/不支持"，得看它在真实流量下到底扛不扛得住、配置起来复杂不复杂。下面几个维度是我实测和压测中比较关注的。

3.1 Token 级限流与成本治理：谁真正懂计价单位？

Kong 的企业版 AI Rate Limiting Advanced 支持基于请求中携带的 token 计数做限流，也可以通过插件获取 LLM 响应头里的用量信息来做后置统计。Higress 的 ai-token-ratelimit 插件则提供了更细的维度：可以分别限制输入 token、输出 token 和总 token 的速率，支持按消费者维度做配额控制，还能配合价格表做成本告警。

这里有一个几乎所有网关都避不开的天然限制：在请求发出之前，网关并不知道这次调用到底会消耗多少 token，只能做一个预估。所以真正的成本治理需要"预估限流 + 后置对账"两步走：请求进来时按预估 token 快速放行或拦截，请求结束后用上游返回的实际用量更新统计。哪个网关能把这两步都做得干净，哪个才配叫"懂计价"的 AI 网关。实测下来，Higress 在这块的默认策略更完整，Kong 则需要你去仔细接插件链路的顺序和日志字段，少配一环就统计不全。

3.2 模型路由、Failover 与语义缓存：智能才是硬道理

先看路由。Kong 的 AI Proxy 支持通过配置多个 provider 做基础分发，请求里带什么模型名就转发给对应供应商，也能在部分错误码下做简单切换。Higress 的 AI Proxy 更进一步：支持按模型名、请求体特征、消费者组做路由，支持故障切换和权重灰度，切换逻辑里还可以自定义判定条件（比如连续多少次 429 才触发切换、冷却时间多长）。Envoy 系的方案里，模型路由需要靠 AIGatewayRoute 这类新 CRD 去实现，能达到什么精细度，取决于你所在版本和扩展能力。

再看语义缓存。这个功能听着高级，但在生产环境里翻车率不低。语义缓存不是"命中就返回"，它是先把新请求做 embedding，再和缓存库里的历史问题做相似度匹配，相似度超过阈值才复用答案。这里的关键参数是相似度阈值和缓存 TTL：阈值设太高命中率极低，设太低会把两个意义不同的问句当成同一个问题，返回牛头不对马嘴的答案。Kong 的语义缓存插件和 Higress 的 ai-semantic-cache 我都压过，Higress 在缓存 key 的设计和相似度算法的可选性上更灵活，Kong 的优势是 Redis 生态成熟、集群缓存成本可控。

3.3 流式协议与可观测性：从"请求活着"到"内容在流"

流式支持是硬伤高发区。前文提到的缓冲、超时、重试问题，三个方案理论上都能通过配置解决，但默认配置救不了一个没经验的团队。Higress 因为从 Envoy 底座弱化了默认缓冲行为，对流式转发的处理更贴近"透传"；Kong 需要你显式注意 proxy buffering 的开关和插件链对响应体的处理；Envoy 系则需要自己确认 HTTP filter 是否会对流式响应做缓存或重组。

可观测性方面，传统指标（请求量、延迟、错误率）只够回答"请求有没有成功"，AI 场景还要求回答"模型到底烧了多少钱、响应首字的延迟是多少、有没有流到一半断开"。Higress 内置了 AI 统计插件，能输出 token 消耗、首字延迟、生成耗时这类指标；Kong 企业版的 AI 观测仪表盘也不错，但开源版基本要靠你从日志里自己扒；Envoy/Istio 系则要靠 Prometheus 自定义 metrics，工程量不小。

3.4 安全能力和 MCP 支持：AI 原生不只是加个插件

安全问题里，提示词注入是最容易被忽略的。网关层做防护的意义在于：你可以把检测动作集中在入口，而不是在每个业务服务里重复实现。Kong 的 AI Prompt Guard 能做正则和敏感词策略，Higress 的 ai-prompt-guard 支持更丰富的模型推理式检测，但注意推理式检测本身也会产生 token 成本，生产环境通常只在关键路由上开启。

MCP（Model Context Protocol）是最近绕不开的话题。当你的大模型应用开始通过 MCP 协议调用工具，网关要管的不只是 HTTP 转发，还有 MCP 服务器的发现、鉴权和流量治理。Higress 是目前三者里对 MCP 支持最明确的，已经可以直接代理 MCP 服务端并复用一套鉴权限流能力；Kong 的相关插件还在演进；Envoy/Istio 则是标准的"等社区方案"。这个维度现在看不出绝对胜负，但演进速度的差距已经出来了。

4. 选型推演：不同家底的团队到底该怎么选

功能对比完，真正难的决策来了。选型永远不是"哪个最强选哪个"，而是"哪个最不别扭地融入你现有体系"。我给你一套决策框架，配合三个典型场景推演。

4.1 决策框架：五个问题先想清楚

在打开官网、对比功能之前，先回答这五个问题：

1. 你的业务和基础设施目前在 K8s 里吗？如果不在，Higress 的很多能力会大打折扣。
2. 团队里有没有人能维护控制面和数据面？Envoy/Istio 路线需要的人，不是一个熟悉 YAML 的运维，而是能写 Filter、能调 Envoy 配置的工程师。
3. 你要的是"开箱即用"还是"可编程底座"？想 1 周内接完模型、上线跑，和想自己控制每一个转发细节，是两种完全不同的建设思路。
4. 成本治理和安全合规的粒度要求是什么？是按租户、按部门做预算分摊，还是只要一个全局总额就行？
5. 未来半年会不会接入 MCP、多模型供应商、多区域容灾？这决定了你现在的选择会不会半年后又推翻。

这五个问题的答案，比任何官方对比文档都值钱。我见过太多团队选型失败，不是选了弱产品，而是拿"我们想拥有最强底座"的心态，去选择一个需要 3 个月才能磨出来的方案。

4.2 三个典型场景的推演结果

场景一：中小团队，业务全在 K8s，希望快速把大模型能力接入多个内部应用。这个场景我首推 Higress。理由很简单：已经是 K8s 体系，Higress 以一个标准 Ingress/Gateway 资源的形态部署进去，不用引入一套新的管理面；AI 能力通过 CRD 配置，团队学习成本低；后续要加 MCP 工具调用，也是同一套接入路径。

场景二：已有成熟的 Kong 体系，跑着几十个传统 API，现在要统一接入 AI 供应商。这个场景不要动架构，直接在 Kong 上加 AI Proxy 和相关插件即可。重点是先梳理清楚现有插件链和新增 AI 插件的顺序，因为 Kong 的插件执行顺序会影响 token 统计和限流的准确性。只有当 AI 流量大到需要独立网关隔离时，再考虑单独部署一套 Higress 做 AI 入口，与 Kong 分工。

场景三：大型微服务集团，已经全量上了 Istio，有专门的平台工程团队。对这类团队，直接用 Envoy/Istio 底座自建也不是不行，但我的建议是：先了解基于 Envoy Gateway 的 AI Gateway 扩展是否满足核心需求，如果满足，用社区方案而不是自研 Filter；如果核心需求涉及多供应商智能路由和语义缓存，那就再叠一层 Higress 承担 AI 流量，让 Istio 继续专注微服务治理。两层入口各管一摊，比硬生生在 Istio 里塞 AI 逻辑要容易维护得多。

4.3 POC 验证清单：别只看官网文档

不管最后倾向哪个方案，我强烈建议你花两周时间做一个 POC，按下面这份清单验证：

• 并发 100 路的流式请求压测，观察网关的转发延迟、内存、连接数表现；
• 人为构造上游故障：返回 500、超时、连接中断、429 限流，验证路由切换的触发条件和恢复时间是否符合预期；
• 验证 token 计数：用同一个 prompt 分别走不同供应商，核对网关记录的 token 与供应商账单里的 token 是否一致；
• 令牌桶限流生效时，客户端收到的错误码和响应体是否友好；
• 语义缓存压测：构造相似但意图不同的问题，确认命中率没有高到离谱；
• 故障恢复后，网关有没有出现"我把备模型流量切回去"的能力，还是需要人工干预。

这些测试做完，你基本能知道这个方案在你的真实流量下是"能用"还是"堪用"。

5. 落地实录：Kong Manager 健康检查、Higress 插件与 Envoy 的坑

选型定完，真正的战斗才开始。下面是我在实际落地过程中踩过、且网上讨论比较少的几个具体问题。

5.1 Kong Manager 节点主动健康检查配置实操

大模型供应商经常不稳定，你在 Kong 后面挂的模型上游节点能否被及时摘除，直接决定你的请求会不会持续被导到"半死不活"的节点上。Kong 的健康检查分为主动和被动两种：主动模式是网关定期以探测请求主动检查上游节点健康状态；被动模式是根据实际业务请求的成败来判定节点健康。

对大模型流量，我建议"主动 + 被动"同时配置，但主动探测的路径一定要选便宜的。比如你挂了 OpenAI 系上游，主动探测路径用/v1/models这种不产生生成费用的接口，而不要用对话接口，否则健康检查本身就在烧钱。用 deck 配置大致如下：

upstreams: - name: openai-upstream algorithm: round-robin healthchecks: active: type: http http_path: /v1/models timeout: 5 concurrency: 10 healthy: interval: 30 successes: 2 http_statuses: [200, 301, 302] unhealthy: interval: 30 failures: 3 http_statuses: [429, 500, 502, 503, 504] passive: type: http healthy: successes: 3 unhealthy: http_failures: 3 http_statuses: [429, 500, 502, 503, 504]

同步之后，在 Kong Manager 的 Upstreams 页面里打开对应上游，能看到每个 target 节点的健康状态；如果节点变黄或变红，说明主动健康检查已经把它摘除了。我踩过的坑是：只配了主动检查，忘了配被动检查。结果探测接口正常，但实际模型调用已经被供应商限流到 429，网关依然认为节点健康，流量照发不误。正确做法是主动探测负责周期性体检，被动检查负责按真实调用结果快速兜底。

另外注意一点：Kong Manager 页面里的"节点"页面和有健康检查的上游 target 是两回事。前者看的是 Kong 网关自身数据面节点的存活状态，后者才是上游模型服务的健康状态。很多刚上手的人会把这两个概念搞混，排查时绕一大圈。

5.2 Higress 实战：AI Proxy 插件与 WASM 踩坑

Higress 的 AI Proxy 用起来确实舒服，配置一个多供应商的模型代理大概是这样的思路：先通过 Ingress 或 Gateway 资源把域名接进来，再挂上 AiProxy 类型的 CRD 配置供应商、模型、token 来源和 fallback。它的模型路由支持主备切换，切换条件可以按错误码自定义，这一点在生产里非常实用。

真正要小心的反而是 Higress 的插件机制。Higress 的插件大多以 Wasm 形式运行，每一个请求都会经过这些 Wasm 过滤器。我碰到的几个实际问题：

• 插件链加的越多，内存占用越明显，尤其是语义缓存这种需要做向量计算的插件。上线前要做一次几百 QPS 的长时间压测，盯内存曲线，而不是只看功能演示。
• 插件顺序会影响功能：token 限流插件如果放在 AI Proxy 之前，它读不到模型信息，也就没法按模型做限流维度。顺序错了，功能等于白配。
• 升级 Higress 版本时，Wasm 插件的版本兼容性是个隐藏雷区。官方文档很少提醒，但小版本升级后插件失效的情况我遇到过不止一次。建议升级前先在测试环境把插件链完整回归一遍。

还有一个常被忽略的细节：Higress 同时兼容 Ingress 和 Gateway API，但如果你在同一个集群里跑着多个 Ingress Controller，要注意资源的归属关系，否则你配的某条路由可能被另一个 Controller 接管，出现"配置了但流量不过去"的诡异现象。

5.3 Envoy/Istio 侧车资源与配置分发的坑

如果团队最后真的选了 Envoy/Istio 路线，第一个坑就是资源开销。Istio 的默认 sidecar 注入会让每一个 Pod 多跑一个 Envoy 代理，CPU 和内存成本在节点数上来之后相当可观。处理大模型流式流量时，连接数高、持续时间长，sidecar 的内存占用会比传统短连接场景膨胀得更快，需要专门设置资源限制和连接池参数。

第二个坑是配置分发链路变长。在 Istio 里加一条 AI 路由，往往要同时改 VirtualService、DestinationRule、ServiceEntry 等多个资源，任何一个资源的配置有误，流量都不会走到预期目标。而且 Istio 的配置更新有传播延迟，大模型流量出现故障需要快速切换模型供应商时，这个延迟会让人很难受。我的经验是：如果选 Istio 路线，务必把配置变更的自动化做起来，用 GitOps 工具链管理那些 CRD，不要靠人工一个个 apply。

6. 结语：网关会继续进化，选型要跟着流量走

从我自己的使用体会来说，这三个方案里没有谁可以一劳永逸。Kong 在成熟度和治理能力上依然能打，适合已经在用它的大企业平滑升级；Higress 在 AI 原生能力和云原生生态上的推进速度肉眼可见，是目前最值得新项目优先考虑的入口；Envoy/Istio 则适合那些愿意投入工程能力、把底层控制权抓在自己手里的硬核团队。

最后分享一个我在几次选型中沉淀下来的小技巧：不要一开始就追求"全都要"，先用一个网关把大模型流量接入并在生产跑 1-2 个月，期间重点记录三个数字——token 成本、故障切换时长、运维排查平均耗时。这三个数字会告诉你当前方案到底行不行，也会告诉你是该深挖现有方案，还是该换一条路线。网关这种基础设施，永远是跟着真实流量走的，会议纪要里的架构图再漂亮，也不如线上一次平稳的故障切换来得有说服力。