　　一个业务系统只调用两三个后端服务时，接口怎么接通常不是什么问题。服务多起来以后，麻烦才慢慢出现：认证、权限、限流各有一套，调用方还要知道不同服务的地址，后端一调整，前面的调用关系也可能跟着改。业务服务、数据服务、模型服务越来越多以后，这些共性问题就不适合再留给每个系统自己处理。

　　但服务跑进 Kubernetes 以后，地址本身反而没那么重要了。Pod 会重建，实例会扩缩容，服务版本也会变化。调用方访问的还是同一个接口，接口后面的运行对象却可能一直在变。到了模型在线服务这里，还会再多一层：新版本已经部署好了，并不代表生产流量已经开始使用它。

　　Gateway 面对的问题，也就从“请求转到哪个地址”，慢慢变成了“后端一直在变，调用关系怎么保持稳定”。

服务动态起来以后，Gateway 和 Kubernetes 各管一层

　　一个逻辑服务落到 Kubernetes 里，背后通常不会长期对应某个固定 Pod。扩容会增加实例，缩容会减少实例，节点故障也可能触发 Pod 重建。Pod 的 IP、数量和运行位置本来就是运行状态的一部分，如果这些变化还需要业务应用自己感知，服务化带来的隔离也就没剩下多少了。

　　Kubernetes 已经在处理这层变化。Pod 承担实际计算，EndpointSlice 记录 Service 当前对应的后端端点，Service 再向上提供相对稳定的服务入口。上层不需要知道一个服务后面现在是两个 Pod 还是五个 Pod，也不用因为某个 Pod 重建就修改调用地址。

　　API Gateway 处理的是再上一层的关系：哪类请求应该进入哪个逻辑服务，谁可以访问，是否需要限流，不同服务或者版本之间的流量怎么处理。

　　Service 和当前 Pod 集合之间的变化，由 EndpointSlice 等 Kubernetes 服务发现机制维护。

　　这里的 API Gateway 和 Kubernetes Gateway API 也不是一个概念。Spring Cloud Gateway、Kong、APISIX 这类 API Gateway 更偏向应用和服务调用治理；Kubernetes Gateway API 则是一套 Kubernetes 原生的流量配置模型，通过 GatewayClass、Gateway、HTTPRoute、GRPCRoute 等资源描述入口和路由关系，实际转发由对应的 Controller 和数据面处理。两边都会涉及路由和流量，只是抽象层次不同。

　　回到应用层 Gateway 和 Kubernetes 的分工，更需要避免的是重复维护同一份运行状态。

　　如果 Kubernetes 已经通过 Service 和 EndpointSlice 维护后端实例，Gateway 又单独保存一套 Pod 或 EndpointSlice 级别的实例状态，同一个问题就出现了两份事实来源。Pod 重建以后，Kubernetes 已经更新了服务和实例的关系，Gateway 还要再同步一次。两边在更新时间、健康检查或者异常摘除上只要出现差异，就可能得到不同的“可用实例集合”。

　　重复维护同一类运行状态，并不会自然让系统更可靠，反而多了一份需要保持一致的信息。

　　一些 Kubernetes 原生网关、Service Mesh 或数据面代理会直接使用 EndpointSlice，这是实现方式本身决定的。需要避免的不是 Gateway 绝对不能看到实例，而是在已有机制能解决问题的情况下，再独立做一套重复的状态管理。

　　业务应用依赖稳定的 API，Gateway 面向逻辑服务，Service 屏蔽实例变化，EndpointSlice 维护后端端点，Pod 承担实际计算。每一层把自己负责的变化挡住，底层的扩缩容、迁移和重建才不需要一路传到调用方。

模型服务把运行时的问题放大了

　　业务服务、数据服务跑在 Kubernetes 上，同样会碰到动态实例的问题。模型服务更特别一点，它把计算资源、运行状态和版本变化同时带进了请求链路。

　　创建训练任务、查询训练状态、申请 GPU 资源、注册模型、发起模型部署，仍然属于平台控制面的操作。请求经过 Gateway 进入训练或者模型管理服务，后面的资源调度再去处理 Kubernetes 和 GPU。

　　训练任务可能运行几个小时，但创建训练任务的 HTTP 请求不会一直保持。管理服务把任务创建出来以后，这次调用就结束了，后面的计算由平台内部继续完成。

　　从 Gateway 的角度看，这类接口和其他管理接口没有太大区别。它处理的是谁可以调用、请求应该进入哪个服务，以及这次操作有没有被正常受理。

　　模型部署成在线推理服务以后，请求链路就变了。推理请求直接处在生产调用链里。服务响应变慢、实例异常或者发生超时，不再只是平台内部的一条运行状态，而会直接影响调用它的业务应用。

　　所以控制面接口和推理接口即使都使用 HTTP 或 gRPC，也不能因为协议一样就把它们看成同一种流量。前者是在操作平台里的对象，后者已经是一条持续存在的生产调用链。模型还是被管理对象时，Gateway 更多承担统一接入；模型真正变成在线服务以后，流量治理的重要性才会显出来。

　　这并不是 AI 平台需要一种特殊的 Gateway。模型服务只是把原本就存在的运行时问题放大了。

部署完成，不等于生产已经在用

　　模型开始迭代以后，版本问题会把“运行”和“使用”分得更清楚。

　　假设 V1 还在提供服务，V2 已经完成部署。V2 的 Pod 已经创建，资源已经分配，模型加载完成，健康检查也通过，只能说明 V2 已经具备运行条件。

　　生产请求现在到底进入 V1 还是 V2，是另外一件事。

V1 和 V2 同时运行，并不意味着两个版本都在接流量。

　　模型部署处理的是工作负载：创建实例、分配资源、加载模型、健康检查、服务就绪。真正投入生产以后，还多了一层流量关系：业务请求进入哪个版本、如何分配流量、异常以后怎么切换。

　　把两件事分开以后，发布方式会灵活很多。旧版本可以继续运行，新版本也可以提前准备好，而生产流量暂时仍然留在稳定版本；需要验证新版本时，再调整流量关系。如果发现异常，也可以先把流量恢复到原来的版本，而不是重新部署整个工作负载。

　　MLOps、Kubernetes 和 Gateway 在这里处在不同的位置。MLOps 处理模型从训练、评估、注册到部署的过程，Kubernetes 负责模型实例怎么运行，API Gateway、Kubernetes Gateway API 或其他流量治理组件处理模型已经运行以后，请求怎样进入不同的服务和版本。

　　它们连在同一条交付链路上，但解决的不是同一件事。

　　如果“部署成功”自然就等于“生产开始使用”，实例状态和业务使用状态仍然绑在一起。版本少、发布简单时不一定能感觉出来，一旦出现多版本并存、渐进式发布或者快速回退，这种绑定就会限制发布方式。

　　反过来，让 API Gateway 去管理模型注册、GPU 分配甚至 Pod 生命周期，同样会把流量治理和资源管理混在一起。

　　需要分开看的其实就是两件事：

实例能不能运行，以及它现在应不应该被使用。

　　Gateway 参与运行期流量以后，能够看到的信息自然会更多。请求量、响应时间、错误码、调用方、目标服务和版本路由，都能从请求侧反映服务现在发生了什么。

　　但看到异常和解释异常不是一回事。某个模型接口突然变慢，Gateway 可以确认哪些请求受到了影响，却很难仅靠这一层判断原因。问题可能出在 Model Runtime，也可能来自 GPU 资源竞争、Pod 重启或者下游数据访问。

　　AIOps 更需要把 Gateway 指标和 Kubernetes 状态、GPU 资源、应用日志、Model Runtime、Trace 等信息放到同一条时间线上，看不同层面的变化能不能对应起来。Gateway 可以提供重要的请求侧数据，没有必要因此把异常分析也塞进 Gateway。

　　业务判断也是一样。认证、限流、服务路由、版本流量和异常切换，都围绕“请求怎样进入服务”展开；但“某种工况应该选择哪个预测模型”“某类数据应该采用哪一种算法”，已经属于业务规则或者模型编排。

　　Gateway 可以执行已经确定的流量决策，却没有必要为了完成一次路由不断理解更多业务语义。否则业务规则一变化，公共流量层也跟着变化，原本用来隔离变化的组件反而容易变成新的耦合点。

　　业务服务、数据服务和 AI 服务可以按照各自的方式继续演进，Kubernetes 可以调整实例，MLOps 可以管理模型生命周期。Gateway 需要维持的，是这些变化发生以后，上层调用关系仍然尽量稳定。

　　插件、协议和治理策略当然是 Gateway 能力的一部分，但从平台架构来看，还有一件事更能说明它的位置是否合适：后端实例重建、扩缩容、版本变化甚至局部异常以后，这些细节还有多少需要调用方自己理解和处理。

一个好的 Gateway，不是自己知道得越来越多，而是让调用方需要知道的东西越来越少。

　　它隔离的不只是接口地址，也是业务、数据和 AI 能力服务化以后，平台内部不断发生的运行变化。

以不变应万变：API Gateway 从统一入口到运行时流量治理

API Gateway真正变复杂，不是因为接口多了，而是后端服务开始动态运行。Kubernetes带来实例变化，模型服务又带来版本和流量问题。文章从这些变化出发，讨论Gateway为什么从统一入口走向运行时流量治理，以及它和Kubernetes、MLOps之间该怎么划边界。

架构设计

云计算

后端

API网关在Kubernetes环境中通过分层管理维持服务稳定性：Kubernetes负责Pod实例变化，网关聚焦逻辑服务路由与流量治理。模型服务部署与流量切换分离，让多版本发布更灵活。网关隔离底层动态变化，调用方无需感知实例重建、扩缩容等细节。

Gateway API

Kubernetes

路由

AIOps

2026上云采购 | AI焕新·智启新局

apigw

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

以不变应万变：API Gateway 从统一入口到运行时流量治理

以不变应万变：API Gateway 从统一入口到运行时流量治理

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐