　　应用部署到 Kubernetes，并由网关控制流量后，副本更新和流量切换可以分开处理。新版本可以先部署到生产环境，用户请求仍由旧版本处理，等到发布窗口再逐步切换。这段时间里，两个版本都在运行，部署页面显示就绪，生产流量仍然停留在旧版本。

　　V2 开始接收请求，发布状态也随之发生变化。除了 Deployment 和 Pod 状态，还会看到新版本实际承担的请求量、错误率、延迟和业务处理结果。旧版本剩余多少容量、数据结构还能不能兼容，也会影响后面的恢复。

　　等待切流时，V1、V2 都可以保持 Ready；进入灰度后，两个版本仍然可以保持同样的工作负载状态，但请求已经开始按路由分配。再到撤流阶段，Pod 依然可以继续运行，变化的是请求落到哪个版本，以及两个版本分别处理了什么数据。

　　Deployment 根据镜像、副本数和更新策略管理工作负载。新副本是否创建、是否可用、更新是否完成，都有对应状态。Pod Ready 表示当前配置的就绪检查已经通过，具体检查到什么程度，取决于应用配置的探针。[1]

　　这类检查通常覆盖进程、端口以及应用自身提供的健康接口。真实请求进入后，还会经过数据库、缓存、下游接口和业务数据。Pod 已经 Ready，只说明当前就绪条件已经满足，后面的业务调用还要经过真实请求验证。

　　新旧版本分别部署时，V2 可以先保持就绪，不接生产请求。两个 Deployment 分别运行 V1、V2，各自关联 Service，再由网关选择后端。Gateway API 的 HTTPRoute 支持给不同后端配置权重，两个版本同时运行时，生产流量仍然可以全部进入 V1。[2]

　　V2 承担的请求逐步增加，配置里的目标副本数和当时真正可用的副本数也会出现差异。副本数已经调整，但部分 Pod 还没有 Ready，请求仍然由当前可用的实例承担。流量继续增加时，实际承载能力取决于当时已经可用的副本。

　　灰度推进到后段，V1 往往已经缩容。如果这时把流量切回 V1，而旧版本副本还没有恢复，新增请求会先落到现有实例上。V1 还在运行，但现有容量未必能马上接回全部流量。

　　V1 缩得越多，回退时等待副本恢复的时间越长。保留较多旧版本副本，恢复时等待会少一些；随着 V2 放量逐步缩减 V1，可以降低资源占用，但回退时也会多出副本恢复这一段时间。Argo Rollouts 对稳定版本的副本保留和动态缩容提供了相应配置。[3]

　　撤回 V2 时，还有一部分处理不经过入口路由。Kafka Consumer、定时任务以及应用内部的后台任务不会经过这条 HTTP 路由。网关把 V2 权重调成 0，后续入口请求不再分配到 V2，已经运行的消费者和后台任务仍会继续执行。

　　如果异常出在异步处理链路，入口流量撤掉以后，后台处理还在继续。V2 保留下来排查时，消费者和后台任务是否继续运行，要和入口流量分开处理。

　　一次发布从提交部署到结束，会经过副本启动、等待切流、灰度验证、暂停或撤流，以及全量后的观察。V2 还没有 Ready 时，生产流量仍然停留在 V1；V2 已经 Ready、但还没有切流时，新版本只处在待发布状态；流量进入 V2 后，错误率、延迟和业务处理结果才开始反映新版本的实际运行情况。

　　V2 启动失败时，生产流量还没有进入新版本；灰度验证失败时，已经有请求经过 V2。如果切流前已经执行数据库迁移，即使 V2 没有成功启动，相关结构或数据也已经发生变化。

　　V2 开始接流量后，按版本拆开的指标分别记录 V1、V2 的错误率、延迟和请求情况。新版本承担的请求还比较少时，自身出现的错误放到整个应用的总体指标里，容易被 V1 的正常请求摊薄。

　　请求数量也会影响灰度结果。短时间内进入 V2 的请求不多，或者这些请求没有经过本次修改涉及的业务路径，曲线保持平稳，也只能说明这批请求没有暴露问题。真正涉及修改的路径有没有被走到，还要看实际请求覆盖到了哪里。

　　入口请求返回后，后台处理还可能继续。接口已经返回 200，后面仍然可以执行数据库写入、消息发送和异步任务。HTTP 响应反映的是请求返回阶段，后续处理结果还在另外一条链路上。

　　Argo Rollouts 等工具可以把放量、暂停和 Analysis 放进发布步骤，并在分析结果不满足条件时停止继续放量。[4] 指标、阈值和检查程序由应用侧提供。数据库恢复、消息补偿和业务处理则继续由对应流程处理。

　　暂停时，V2 仍然保持当前流量比例，只是不再继续增加；撤流则把后续入口请求重新转回 V1。网关中的 V2 权重调为 0 后，新请求会按照新的路由配置选择后端，已经建立的连接和正在执行的请求仍按原来的过程结束。普通短请求退出得快，长连接、流式调用以及连接复用较多的服务，排空时间会更长。

　　网关里的权重记录的是配置目标，监控里的请求量和活动连接反映的是实际运行情况。权重已经归零时，V2 上仍可能残留一部分请求；这些请求处理结束后，入口流量才真正退干净。监控还有统计窗口，切换前产生的数据也会继续保留一段时间。

　　重新放量时，上一轮验证结果能不能继续使用，取决于这期间有没有改动。外部依赖恢复、应用版本没有变化，可以继续沿用原来的验证对象；镜像、环境变量或者工作负载配置发生变化后，上一轮结果对应的已经是修改前的状态。

　　V2 接入全部流量后，V1 还可以保留一段时间，直到观察结束或者回退窗口关闭。

　　流量切回 V1，只改变后续请求进入哪个版本。工作负载回退，则把当前运行程序恢复到旧镜像以及相应配置。数据库已经写入的数据、Kafka 中已经产生的消息和已经触发的业务操作，不会随着镜像一起恢复。

　　数据库字段调整会直接影响旧版本。V1 仍然读取的字段已经删除，切回旧版本就会出现问题；字段还在，但 V2 已经不再更新，V1 读到的就可能是旧值。

　　这类问题从程序状态上不一定马上暴露。V1 可以正常启动，SQL 也能执行，但读取到的数据已经和原来的处理假设不一致。

　　数据兼容既包括 V2 读取 V1 留下的数据，也包括 V1 处理 V2 新写数据。V1 仍作为回退版本保留时，这条反向兼容链路也要继续存在。[5][6]

　　V2 已经接入全部流量，V1 依赖的旧字段和兼容逻辑仍然可能保留。只要 V1 还在回退窗口里，这些结构就还没有退出使用范围。

　　兼容窗口里，增加新结构和清理旧结构通常分开进行。先增加新结构，让 V1、V2 在共存阶段都可以正常读写；等 V1 不再承担回退职责，再清理只为旧版本保留的字段和逻辑。字段保留多久、兼容逻辑什么时候退出，取决于实际的数据读写关系。[5][6]

　　兼容结构保留下来，还要看两个版本交叉读写时的结果。V2 写入过的数据交给 V1 读取和修改，V1 处理后的数据再由 V2 使用，这些操作覆盖的是版本共存期间真实存在的数据变化。

　　消息处理也是一样。V2 接流量期间已经写入 Kafka 的消息，即使入口已经撤回，队列中的消息仍然存在。消费端同时退回 V1 时，队列里这些已经产生的消息还会继续进入旧版本。

　　Schema 校验检查的是消息结构，业务语义仍然在应用代码里。消息字段没有变化，新版本增加了旧程序未处理过的状态值，V1 依然可能处理失败。Schema 通过，表示消息格式符合约定，业务状态能不能被旧程序处理，还要看实际执行结果。

　　数据库迁移检查覆盖数据库变化，Schema 检查覆盖消息格式，应用读写和业务状态处理则由应用测试验证。

　　数据库结构、消息处理方式或者外部配置如果改动了 V1 的回退依赖，之前的验证结果就不再对应当前运行条件。V1 能不能回去，取决于回退时实际保留下来的运行条件。

　　入口流量已经恢复到 V1，数据修复和业务补偿仍然可以继续执行。流量恢复和数据补偿因此会保留各自的进度。

　　Deployment 记录的是工作负载状态，路由、验证和数据处理各自还有自己的结果。

　　V1 已经恢复全部入口流量，Kubernetes 中的工作负载也已经稳定时，Kafka 中的消息仍可能继续消费，数据库补偿任务也可能还没有结束。Deployment 已经恢复正常，后续处理仍然可以继续。

　　路由工具记录当前流量配置，Kubernetes 记录工作负载状态，验证程序记录检查结果，数据流程记录迁移和补偿结果。同一次 Release 关联镜像版本、配置版本、路由调整、验证结果和恢复任务，具体操作仍由原有工具执行。

　　网关配置的后端权重记录路由目标，监控中的实际请求比例还会受到请求数量、连接状态和统计窗口影响。验证结果为 Passed 时，记录里同时保留镜像版本、执行时间和检查范围，用来区分不同版本和不同阶段的验证结果。V2 修改后重新发布时，上一轮验证结果对应的是哪一版程序，也能沿着这条记录查到。

　　发布暂停时，当前流量、暂停原因和恢复进度放在一起，V2 还在接多少请求、V1 容量恢复到哪里、入口是否已经开始撤流、异步任务是否仍在运行，都能落到同一次发布记录里。

　　人工把流量切回 V1 后，如果原来的自动发布任务没有停止，后续步骤仍会继续修改网关权重。人工恢复和自动放量同时修改同一份路由配置时，路由状态会随着两边后续的配置写入继续变化。

　　任务中断后重新执行，路由可能已经修改、副本已经扩容，迁移任务也可能已经提交。如果仍按原有步骤重新执行，而相关操作没有做幂等处理，同一个动作就可能被重复执行。

　　CI/CD 状态页或者开发者门户展示同一次 Release 下的版本、流量、验证结果和恢复进度。应用团队看到的不只是 Deployment 成功或失败，还包括当前运行的版本、流量分配、已经完成的验证，以及尚未结束的数据处理。

　　发布结束后，V1 退出、兼容结构清理和后续恢复任务，继续沿着同一次发布记录保留对应关系。

从部署到发布：流量切换与版本回退

新版本部署完成后，生产流量仍可能停留在旧版本。随着流量逐步切换，副本容量、连接排空、异步任务和数据兼容会陆续进入发布过程；发生回退时，流量、工作负载和数据也各有自己的恢复进度。

运维

后端

架构设计

Kubernetes部署中，版本更新与流量切换解耦，通过网关权重控制灰度发布。本文详解V1/V2共存、就绪探针、异步任务影响及回滚数据兼容，强调验证需覆盖真实请求路径，并结合Argo Rollouts实现精准流量管理。

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

apigw

tkeserverless

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

从部署到发布：流量切换与版本回退

从部署到发布：流量切换与版本回退

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐