企业官网建设流程全解析

最近因为业务里接了大模型，我在给团队选型“大模型网关”这件事上花了整整两个月，把 Higress、Kong、Envoy/Istio 三条主流路线从原理到实测都过了一遍。期间最大的感受是：这三样东西虽然都被叫“网关”，但技术底座、演进方向、团队上手成本完全是三个物种。网上讨论大多是“我用了某个方案挺顺”，很少有从架构层把三者差异讲透的文章。这篇文章就把我整个选型过程中的判断依据、实测结果和踩坑记录完整写出来，希望能给同样在纠结的朋友省点时间。

先说结论：如果你在公有云体系里、团队规模不大、要快速把多模型接入和灰度跑起来，Higress 的 AI 原生能力最省事；如果你已经有很强的 API 管理需求、团队对 OpenResty/插件体系熟悉，Kong 的 AI Hub 插件能一步到位；如果你公司有专门的平台团队、愿意在数据面投入开发资源，Envoy/Istio 才是长期主义的选择，但代价是你得自己把 AI 这个人做出来。下面展开说我为什么得出这些结论。

1. 大模型流量进来后，传统网关的治理逻辑先崩了一半

1.1 从 URL 路由到内容理解：网关第一次要“读”请求

传统网关的路由逻辑核心是看 URL、Header、Method 这些“信封”信息。比如/api/v1/orders走订单服务，Authorization: Bearer xxx触发鉴权，这套东西在 REST 时代非常成熟。但大模型接入后出现了一个根本变化：同一个 endpoint（比如/v1/chat/completions）背后可能要对接 OpenAI、Claude、通义、国产开源模型等多个供应商，请求的目标完全由 body 里的提示词内容决定。

我举一个实际例子。我们的客服机器人和代码助手走同一个网关入口，但客服场景要求低延迟、用便宜模型，代码助手要求高智商、用大参数模型。如果网关只能按 URL 分流，你只能在客户端做逻辑——让客户端决定该调哪个供应商。这很快会出问题：客户端不可信、密钥容易泄露、策略一变就得发版。网关如果不能理解 body 里的意图，那这套统一接入和管理就是不成立的。

Higress 的 semanticRouting 插件就是针对这个场景设计的，它允许你写类似“当 prompt 涉及代码生成时路由到 claude-3.5-sonnet，涉及闲聊时路由到 qwen-plus”这样的规则。Kong 也有 AI Semantic Prompt 插件。Envoy 原生的路由还是看 URL/Header，做到语义路由基本得靠自己写 filter。这是“AI 原生”和“传统网关”最直观的分水岭。

1.2 多模型、多密钥、多租户：流量管理变成了令牌调度

第二个冲击是密钥管理。以前一个网关后面挂的是你自己的微服务，鉴权是验证调用方身份；现在网关后面挂的是第三方的模型供应商，你需要管理的是上游 API Key。一个网关可能要同时维护 OpenAI、Azure OpenAI、Anthropic、各家国产模型的十几个 Key，还要支持不同业务线用不同的配额。

我记得有个同事第一次配 Kong 的 AI Proxy 插件时，一脸懵地问我：“这个 plugin 到底是管理上游 Key 的还是我理解错了？”其实对上就是对，AI 网关的核心职责之一就是做上游凭证托管和调度，避免把第三方 Key 透传给客户端。从安全角度，这也是必须的：如果客户端直连 OpenAI，你既控不住量也控不住钱，一个 Key 泄露可能一夜之间烧掉几万块钱。

Higress、Kong 的 AI 插件都支持多 provider 的凭证配置和按路由指定模型供应商。Envoy 虽然有envoy.filters.http.jwt_authn这类过滤器，但它解决的是“你是谁”的问题，不解决“你的令牌该调度到哪个上游、走哪个 Key”的问题，后者仍然需要你自己实现。这也是为什么我倾向于说：大模型网关在本质上是流量调度器，而不是传统的转发器。

2. 三条路线各自的底牌：Higress 的 AI 原生、Kong 的插件生态、Envoy/Istio 的底座哲学

2.1 Higress：把 AI 能力焊进网关本体

Higress 是阿里开源的一个云原生网关，底层基于 Envoy 内核，但它的产品定位从一开始就冲着“AI 原生网关”去。我接触下来最大的感受是：它不是在传统 API 网关上加 AI 插件，而是专门为 LLM 流量重新设计了数据面能力。

举个例子。Higress 的流式转发是默认行为，它很清楚 SSE（Server-Sent Events）流式响应是 LLM 应用的标准形态。它不像某些网关那样需要你专门调 buffer 关闭缓存才能让流式响畅通。而且它还直接提供了 prompt 模板管理、上下文缓存（针对 RAG 场景）、多模型聚合代理这类偏应用层的能力，这些在传统网关里是没有坐标的。

Higress 的插件体系是 Go/Wasm 写的，性能损耗相对小，而且它和 Kubernetes Ingress/ Gateway API 兼容。对国内开发者，它还有一个额外加分项：跟阿里云百炼的打通比较顺，如果你本来就在阿里云上跑模型，Higress 的 AI 插件可以直接把 Model Studio 作为 provider 接进来，配置门槛低很多。不过需要理性看待的是：Higress 的 AI 生态还比较年轻，社区里踩过的坑主要出现在 Wasm 插件版本兼容和配置项不够文档化上。我们在测试 semanticRouting 时就碰到过规则不生效的问题，最后发现是插件顺序问题——AI 插件需要在路由插件之后加载，文档里没有写清楚。

2.2 Kong：用二十年的 API 网关沉淀去覆盖 LLM 场景

Kong 是老牌 API 网关，从 Kong Gateway 1.x 时代就开始做企业级 API 管理。它在 AI 时代的应对策略非常鲜明：不跟你拼 Envoy 内核，而是把 LLM 相关能力封装成标准插件，放进成熟的插件市场里。这种做法对已经有 Kong 基础、熟悉插件管理思路的团队非常友好。

Kong 从 3.6/3.7 版本开始陆续推出 AI Hub，包含 AI Proxy、AI Rate Limiting Advanced、AI Semantic Prompt、AI Request/Response Transformer 等插件。我在 test 环境里用 Docker 起了一个 Kong Gateway 3.7，配置 AI Proxy 指向 OpenAI 兼容的本地推理服务，过程是流畅的：先定义一个 LLM 插件，填上 provider 类型和 key，再在 service 路由上绑定插件。这套操作逻辑跟配置普通限流插件一模一样，团队几乎是无缝迁移。

Kong 还有一个明显优势是它的企业版功能，像开发者门户、Key 生命周期管理、审计日志这些，对传统企业做 AI 能力对外开放时非常有用。但它的问题也很突出：Kong 的底层是 OpenResty/NGINX，虽然借助 lua-resty 扩展能力很强，但性能天花板上限不如纯 C++ 数据面的 Envoy。我们压测时，Kong 在单实例上开启 AI 相关插件后，QPS 从无插件时的 2 万出头掉到 1.1 万左右，HTTP/2 场景还能再低一些。这个数字在大流量场景下是要被认真考量的。

2.3 Envoy/Istio：给了你一块最好的画布，但画布不负责画画

Envoy 本身是一个 L4/L7 的高性能代理，Istio 是建立在 Envoy 之上的服务网格控制面。从技术底子看，这是三者中最扎实的：Envoy 的线程模型、连接池、熔断器、负载均衡都是生产级。但在 AI 原生问题上，Envoy 的哲学是“框架不管业务”。

什么意思？Envoy 提供的是机制，不是策略。你要语义路由，得自己在 HTTP filter 里写插件，解析 body、调用某个 NLP/LLM 服务判断意图，再动态改写路由簇目标。你要 token 维度的限流，Envoy 的 rate limit 默认基于请求数，没有 token bucket 语义（不是完全不能做，但需要自己扩展或外接一个限流服务）。也就是说，Envoy 能给你一个极其稳定和灵活的数据面，但 AI 网关那些“开箱即用”的体验，它是给不了的。

Istio 的定位更偏服务间东西向流量治理，南北向的 AI 网关它并不直接负责。真正用 Envoy/Istio 做 AI 网关注的大厂，通常是在 Envoy 之上自己封装一层控制逻辑：比如写一个 Wasm filter 做请求内容解析和改写，或者外挂一个控制面组件，负责从 Redis 拉取每个租户的 token 配额下发到限流器。这种方案的工程量从两周到三个月不等，取决于你对 Envoy filter 的掌握程度。

还有一个经常被忽略的点：Envoy Gateway 是 CNCF 下的一个独立项目，它的目标就是做一个基于 Envoy 的 Kubernetes 原生 API 网关。如果你不想碰 Istio，Envoy Gateway 是个更好的选择，但它目前的 AI 能力同样处于“提供扩展点”的阶段，不少 AI 场景依赖 Contour/HTTPRoute 的自定义 filter 开发。

3. 核心场景实测：语义路由、模型容灾与流式转发的真实差异

3.1 语义路由：开关即用还是连乘指令

这里先明确一个概念：语义路由有两种做法。一种是粗粒度关键词路由——读取 prompt 里是否有“代码”“翻译”“客服”这类词，然后路由到不同模型；另一种是基于大模型判断的路由——网关先把请求发给一个便宜的模型，让它判断意图，再根据返回结果路由到目标模型。前者简单但不聪明，后者聪明但有额外延迟。

我的测试里，Higress 的 semanticRouting 走的是第一种，配置方式是写规则，例如：

rules: - name: code-gen condition: - key: "{{request.body.prompt}}" operator: contains value: "代码" target: model: claude-3-5-sonnet

Kong 的 AI Semantic Prompt 插件也是类似的思路，但配置字段和逻辑略有差异。如果你需要更智能的语义理解，恐怕要自己接一个小模型做 Intent 服务。我在实际选型时更看重网关能否把“推理前处理”的扩展点暴露出来，而不是它内置了多少规则。这一点上 Higress 的 Wasm 插件机制比 Kong 的 Lua 插件机制更现代，但 Kong 的文档和社区例子更多，调试起来更容易。

3.2 多模型 Fallback 与限流：Token 维度的流量治理

AI 网关第二个重要能力是多供应商容灾。大模型供应商说挂就挂，这一点过去一年我们碰上不止一次。传统网关的熔断只是“转发失败就返回 503”，AI 网关更想要的逻辑是：A 供应商超时失败时，自动把请求转发给 B 供应商，并且记录本次 fallback 的原因，方便后续做对账。

Higress 的多 provider 配置天然支持这种 fallback 场景，它的 ai-proxy 插件里可以配置多个 provider 的优先级。Kong 也可以通过配置多个 AI Proxy 实例 + 路由优先级实现，但配置复杂度明显高一层：你需要建多个 service、多个 route 并在上游配 health check。Envoy 的 cluster outlier detection 也能做被动健康检查，但 failover 的粒度是 host 而不是“模型供应商”，要按模型维度做编排还是得自研。

Token 维度限流又是一个容易踩的坑。传统的网关限流是“每秒多少请求”或“每分钟多少请求”，但 LLM 调用的成本是由输入+输出 token 数决定的。一个 200 QPS 的请求量，如果每个请求都带很长的上下文，你的账单可能比不做限制高一个数量级。Kong 的 AI Rate Limiting Advanced 插件能按每次响应中的 usage 字段扣除配额，Higress 也有 Token Limiter 插件，这一层是传统网关没有的。

3.3 SSE 流式转发：这里是最容易翻车的一道坎

流式响应是 LLM 应用的标准交互方式，而网关对流式响应的支持直接决定了用户的首 token 延迟。传统网关如果默认缓冲响应，第一个字可能要等整个响应生成完才返回，体验完全不能接受。

我的压测结论是这样的：Higress 对 SSE/流式是默认透传的，基本不用配。Kong 需要确认 Nginx 的proxy_buffering off，或者用 Lua 插件处理 chunked 响应。Envoy 的流式支持本身很好，但很多基于 Envoy 的二次封装产品如果没有做透传配置，同样会出现缓冲问题。我自己在 Kong 上就吃过亏：第一次配 AI Proxy 走流式，忘记关缓冲，结果客户端那边 stream 事件是一坨一坨地蹦出来，前端同学直接懵了。

还有一个容易被忽略的细节：流式响应时的超时设置。长对话场景下，模型生成可能超过 60 秒，如果网关沿用原有的普通 HTTP 超时（比如默认 30 秒），请求会在中间被切断。我在测试 Kong 时把stream_read_timeout调到了 300 秒才稳定；Higress 的默认超时对长流式也做了适配。这类参数在实际部署中必须列到 checklist 里，否则上线当天就会有人投诉“回答到一半断了”。

4. 部署形态与生态集成：单体网关、服务网格和 K8s 的三角关系

4.1 控制面和数据面的拆分逻辑

到了生产环境，网关的选型指标就不仅是功能了，还有你愿意为它付出的运维成本。Higress 和 Kong 更接近“单体网关”的形态：一个控制面（配置管理）+ 一个数据面（代理实例），配置变更通过 API 或控制台下发。Envoy/Istio 则是典型的“控制面/数据面分离”：Envoy 只做转发，Istio 负责配置下发和证书管理，组件数量更多，但每个组件的职责更单一。

从故障排查角度，单体网关更容易入手：日志、配置、插件都在一处。Istio/Envoy 的好处是数据面可以独立弹性扩容，控制面故障不影响已下发的配置。但如果你团队没有专门的 Mesh 运维经验，Istio 的复杂性是实实在在的成本。我们团队当时评估过，Istio 方案的上手周期比 Kong 多至少一倍，这还没算自定义 filter 的开发时间。

4.2 可观测性、告警和成本核算：AI 网关的运维新账单

可观测性是网关落地时绕不开的硬指标。三大体系都支持 Prometheus 指标，但指标粒度差别很大。

Higress 在阿里云版上有跟云监控打通的控制台，自建版则需要自己采集 Envoy 的标准指标。Kong 的指标模型是传统的 HTTP 指标（状态码、延迟、带宽），AI 插件会额外暴露 token 使用量相关的指标，这很实用。Envoy 的指标最丰富，但要自己定义哪些是核心指标、哪些是噪音，配置一个好的 Grafana 大盘本身就是个小型项目。

我特别想提醒的是：AI 网关的告警阈值不能沿用传统的 4xx/5xx 比例。模型供应商返回 429（限流）或上游超时，是常态而不是异常。我们把“A 供应商 429 的比例超过 5%”设成了一个专用告警，触发后自动将流量切到 Backup 供应商。这套逻辑在 Higress 里通过 fallback 规则能实现，在 Kong 里要配合服务优先级，Envoy 则完全靠自研。成本核算也是一个容易被忽略的点：网关如果能在指标里记录每个租户/业务的 token 消耗，就能在月底直接生成账单。这一步价值很大，但要确认你选的网关能在插件层面透出这些数据。

5. 我的选型决策框架和落地避坑记录

5.1 三类团队的选型建议

我把团队分成三类，直接给结论：

• 云原生入门团队（5-20 人，无专职网关维护）：首选 Higress。它本来就兼容 K8s Ingress/Gateway API，AI 能力开箱即用，部署成本相对低，文档里踩坑的信息也比较透明。
• 已有 API 治理体系的企业（需要开发者门户、精细 K8s 权限、审计）：Kong 会顺手很多。它的企业版功能是成熟可用的，AI Hub 插件让你不用改架构也能支持 LLM 接入。
• 流量规模大、有平台团队的公司：Envoy（或 Istio）长期上限更高。但记得把“AI 原生能力自研”的工作量算进工期，别把它当成一个开箱即用的产品来验收。

5.2 实测中的几个坑和补救方案

最后记录几个我实际踩过的坑，希望你不用再踩：

坑一：插件顺序导致语义路由失效。在 Higress 里，插件执行顺序是有讲究的。如果 AI 插件在鉴权插件之前执行，可能直接把未鉴权的请求也路由出去。我们一开始按文档默认配置，结果测试时发现绕过鉴权也能拿到模型响应——后来把所有插件顺序显式排为“鉴权 -> 路由 -> AI 转发 -> 限流”，问题解决。Kong 的插件也有priority字段，原理一样，不要忽略。

坑二：Kong 的流式响应必须关缓存。前面提过，proxy_buffering off是跑通 SSE 的前置条件。如果你用了企业版里的 Response Transformer 之类插件，它可能默认会缓冲 body，导致流式失效。建议在测试环境用 30 行的 Python SSE 客户端脚本反复验证，确认“首 token 时间”和“每 token 间隔”都正常再上生产。

坑三：Envoy 的 cluster outlier detection 只能做主机级熔断，不能做模型级熔断。我们当时以为配置好 outlier detection 就能实现“某模型挂了自动切另一个 model”，结果发现它判断的是上游主机的健康度，而非你想调用的目标模型。最后是通过自研 filter + 外部健康检查服务才实现了按模型的 failover。如果你只是想快速跑通，Higress 和 Kong 的多 provider failover 会省力得多。

坑四：一定要在网关层做 provider 访问日志的脱敏。大模型请求的 body 里可能包含用户隐私，网关日志如果默认打全量 body，就有数据合规风险。我测过三款产品，只有通过统一日志格式自定义才能把 prompt 内容脱敏到只看长度和意图标签。别以为这是小事，真的上线出过一次事故后你会回来找这条的。

现在回头看我这两个月的选型过程，三套方案其实没有优劣之分，只有适配度。我们最终结合团队规模选择了 Higress 方向，核心原因是“快速落地 AI 能力”比“极致底层可控”对现阶段业务更重要。如果你也处在这个阶段的十字路口，建议先把自己的核心诉求排序——是三天上线一个多模型网关 Demo，还是用半年去搭建一套平台级的 AI 流量治理体系？排序清楚，答案其实就在题目里。