模型网关迁移别一刀切：用影子流量、分批切流与回滚控制风险
企业把多个应用接入统一模型网关后，迟早会遇到入口迁移：更换网关实现、调整路由层、切换兼容协议版本，或者把分散调用收敛到统一入口。最危险的做法，是用一条 curl 请求确认新地址能返回文本，就把所有调用方的 Base URL 一次性改掉。模型网关不是普通静态网站，它同时承载鉴权、路由、请求改写、流式传输、工具调用、错误映射、重试和可观察性；其中任何一个语义发生变化，都可能出现“HTTP 成功但业务错误”。
安全迁移的核心不是把上线流程变复杂，而是让每一步都有明确证据、停止条件和撤销动作。本文给出一套不依赖特定网关产品的通用方法：先冻结旧链路基线，再做无副作用的影子验证；随后按稳定维度分批切流，用结构和语义而不是逐字文本比较结果；每个阶段都设置自动止损，并把路由、凭据、缓存和部署版本纳入同一份回滚清单。
文中涉及向量引擎时，只使用已确认的固定地址作为层级示例，不代表任何未列明的模型、价格、性能、并发、可用性或企业能力。实际迁移前必须以目标服务当前文档、账号权限和真实请求为准。
这套方法同样适用于从直连改为代理、从单一上游改为多路由，或对现有网关进行破坏性升级。区别只在于迁移对象和风险清单，不在于基本顺序：先证明旧行为，再隔离验证新行为；先让少量可识别主体使用，再逐步扩大；任何时候都保留返回上一修订的能力。若某一步无法观察或撤销，就不应通过增加流量来“帮忙发现问题”。
一、先定义“迁移对象”，不要只写一个新 Base URL
很多迁移方案只有两行：旧地址、新地址。这不足以描述真正发生变化的东西。调用方发送的是一个契约，而不是一个字符串。契约至少包括协议和主机、版本前缀、资源路径、鉴权头、模型标识、消息角色、流式开关、工具定义、错误结构、超时语义、请求 ID、重试规则和响应结束条件。
以地址层级为例，服务根地址可以是https://api.vectorengine.cn，兼容接口前缀可以是https://api.vectorengine.cn/v1，完整聊天端点可以是https://api.vectorengine.cn/v1/chat/completions。调用方配置的是哪一层，网关会追加哪一层，必须写进契约表。否则迁移后出现重复路径或遗漏版本前缀，只能在生产错误中发现。
建议建立“迁移对象清单”，每一项都标记旧行为、目标行为、验证方式、负责人和回滚动作。例如：旧网关接受system角色，新网关是否等价接受；旧网关忽略未知参数，新网关是拒绝还是转发；流式结束使用何种事件；工具调用参数是字符串还是结构对象；上游 429、502 和超时如何映射给调用方。
这张表还有一个关键字段：是否允许改变。协议兼容不等于所有细节必须相同。有些变化是明确的目标，例如统一错误对象；有些变化必须保持，例如业务方依赖的模型别名；还有些差异需要调用方共同升级。没有这层分类，团队会把所有差异都当成故障，或者把真正的破坏性变化解释成“新系统行为”。
契约盘点还要从真实调用反推，而不能只读网关文档。调用方可能依赖从未写进接口说明的行为，例如错误正文中的某个字段、响应头中的内部追踪号、空数组与缺失字段的区别，或某个模型别名自动回退。可以从脱敏后的请求 Schema、客户端代码和故障工单中收集这些隐性依赖，再决定继续兼容、给出弃用窗口，还是要求调用方升级。未经确认就删除“看起来没用”的字段，往往是迁移后小比例长尾故障的来源。
二、冻结旧链路基线，让迁移前后可比较
迁移前先观察旧链路，而不是立即搭新链路。基线应覆盖典型调用方、典型请求大小、流式与非流式、工具调用、常见错误和高峰时段。这里的目标不是建立漂亮的总览图，而是回答：旧系统在什么输入下返回什么结构，调用方真正依赖了哪些细节。
基线数据至少包含请求总数、成功率、各类状态码、连接失败、首字节时间、完成时间、流式中断比例、工具调用结构有效率、响应为空比例和重试次数。指标要按调用方、环境、请求模式和路由别名切分，但不要使用会无限增长的高基数字段作为标签。模型请求正文、完整回复、API Key、Cookie 和用户文件不应进入普通指标或日志。
对非确定性模型输出，基线不能用“答案字符串哈希”表示质量。相同请求可能生成不同措辞，但结构、约束遵守和任务结果仍然等价。更可靠的基线是多层断言：HTTP 与媒体类型正确；响应对象可解析；必需字段存在；结束原因合法；工具调用参数满足 JSON Schema；安全过滤和业务规则生效；固定评测集上的任务指标不低于约定范围。
基线窗口要覆盖足够的业务变化，同时标记发布、促销、批处理等异常时段。迁移判断应比较相似时间段和相同流量构成，不能拿工作日高峰的新网关与周末低峰的旧网关比较。若无法做到完全一致，就在报告中明确不可比因素，不要用一个合并平均值掩盖分组差异。
固定评测集需要同时包含正常样本和边界样本。正常样本反映主要业务，边界样本覆盖空内容、超长消息、非法角色、未知模型、工具参数缺失、流式中断和上游错误。每个样本都写清预期类别，而不是预期一段固定答案。例如非法模型应得到可识别错误，工具参数缺失应被结构校验拦截。这样评测集不会因为自然语言措辞变化而频繁失效，也能在迁移前发现错误映射是否改变。
三、影子流量的价值与边界：复制请求，不影响主响应
Istio 官方文档把流量镜像称为 shadowing：线上请求副本被发送到镜像服务，镜像链路位于主请求关键路径之外，镜像响应会被丢弃，并且可以只镜像一部分流量。这个模式适合让新网关接触真实请求形态，又不让它直接决定用户看到的结果。
但“响应被丢弃”恰恰说明影子流量不能直接验证最终体验。主链路仍返回旧网关结果，用户不会看到新网关的超时、错误文本或流式节奏。影子阶段能验证的是：新网关能否接受真实请求；路由、鉴权和模型映射是否工作；结构错误和资源消耗是否异常；输出是否具备离线比较条件。
在模型场景中，镜像前必须处理四类副作用。第一，调用上游模型可能产生真实用量，不能默认镜像是“免费测试”。第二，工具调用可能触发发信、写库、创建工单或外部操作，镜像链必须禁用执行或替换为桩。第三，缓存写入、会话记忆和审计记录可能被重复生成。第四，含用户内容的请求被复制到新系统，必须经过数据边界和权限审查。
因此影子入口需要一个明确的安全模式：只允许无副作用的模型生成；工具定义可保留用于结构验证，但执行器必须处于 dry-run；写缓存使用独立命名空间；所有下游凭据使用测试范围；超出允许数据分类的请求不镜像。若这些条件无法满足，就使用脱敏回放集或合成流量，而不是为了覆盖率强行复制生产请求。
影子比例也应逐步增加。先从内部测试租户和小样本开始，确认新网关不会放大流量、递归重试或污染状态，再扩大覆盖。影子链路必须有独立并发上限和熔断，不能因为新系统过载反向拖累主链路。即便镜像位于关键路径之外，共享连接池、CPU、日志管道或上游额度仍可能产生间接影响。
镜像系统还要标记每个请求的来源和目的。建议使用独立的内部标志表示 shadow，禁止该标志被外部调用方伪造，并让计量、缓存和工具执行器识别它。主请求与镜像请求共享同一个端到端 trace，但使用不同 span 和请求 ID，便于关联又不会混为一次调用。任何报表都要能排除影子流量，否则成功率、调用量和容量预测会被成倍放大，甚至错误触发限流告警。
四、不要逐字比较答案，要比较协议、结构和任务结果
大模型输出具有非确定性，逐字 diff 会产生大量无意义差异。迁移验证应先比较确定性层，再比较结构层，最后才比较任务层。确定性层包括状态码、媒体类型、响应对象类型、字段存在性、事件顺序和结束信号；结构层包括工具名称、参数 Schema、引用格式、JSON 可解析性和流式增量的可聚合性；任务层包括固定评测集上的正确性、约束遵守和人工抽检。
对普通文本任务，可以做归一化后比较：去除空白与格式噪声，检查是否为空、语言是否正确、是否满足长度和模板约束，再用规则或评测器判断关键事实。评测器不能只给一个总分，还要保留失败原因，例如遗漏必答点、输出了禁用字段、引用无法解析或拒答类型变化。
对工具调用，重点不是自然语言，而是结构契约。检查工具名是否在允许集合、参数能否通过 Schema、必填字段是否齐全、类型是否一致、是否出现多余的破坏性调用。影子链不得真正执行工具，但可以把结构送入校验器。只有当结构通过、权限策略允许且进入受控金丝雀阶段后，才让少量真实调用执行。
对流式响应，要重放网络分块而不是只比较最终拼接文本。验证事件边界、UTF-8 解码、增量字段、工具参数片段、完成事件和异常关闭。最终文本相同，也可能存在首事件迟到、代理缓冲或中途断流；最终文本不同，也可能完全满足同一个任务。迁移报告应把“协议完整性”和“内容质量”分成两组指标。
比较结果要能定位到契约条目。不要只写“新旧相似度 92%”，而应给出：多少请求在响应结构层失败，多少工具参数无法解析，多少流式请求缺少完成信号，多少任务评测低于阈值。聚合分数适合看趋势，具体失败类型才适合决定是否切流。
对于新旧结果冲突的样本，建立三态裁决：新网关退化、结果等价、无法判定。无法判定不能强行算作通过或失败，应进入人工抽检或更专门的评测器。抽检时隐藏网关来源，避免评审者先入为主；同时记录评审规则和分歧，而不是只保存最终票数。如果业务允许多个正确答案，评测器应检查事实、约束和可执行结果，不应偏好与旧答案措辞更接近的一方。
五、从影子验证进入金丝雀：分组必须稳定且可解释
影子阶段通过后，才让少量真实请求由新网关返回。Kubernetes Gateway API 官方文档说明，HTTPRoute 可以通过后端相对权重分流，这类机制适合发布、金丝雀和紧急切换。但“把 1% 流量随机发到新网关”并不总是合理，模型对话和工作流通常带有会话状态、缓存和连续上下文。
灰度分组应使用稳定键，例如租户 ID、项目 ID、应用 ID 或会话 ID 的哈希。相同会话在观察窗口内始终进入同一网关，避免一轮对话在新旧实现之间跳动。不要使用 API Key 明文作为分桶标签；可以在受控网关中映射为内部主体 ID，再对稳定 ID 做哈希。
分桶还要考虑代表性。只放内部员工流量能验证基本功能，却不能代表长上下文、批处理或第三方插件。建议分阶段纳入：内部测试应用；可快速反馈的非关键调用方；低风险生产租户；具有代表性的高负载调用方；最后才是核心业务。每一阶段都先写清覆盖范围和排除条件。
权重只是执行工具，不是发布计划。计划必须包含阶段、最短观察窗、样本量要求、升级条件、暂停条件和回滚条件。即使指标很好，也不能在样本不足时立即从 1% 跳到 100%；即使总体成功率稳定，某个调用方或某种请求模式明显退化，也应暂停扩大。
对于无法稳定分桶的无状态请求，可以按调用方和请求类型做规则路由，再在规则内部按权重分配。所有路由规则要版本化，变更必须可审阅，并记录谁在何时把哪个分组从旧网关切到新网关。临时口头切流会让后续事故无法还原。
稳定分桶还需要防止样本污染。若同一租户同时运行多个环境，应把环境纳入分桶作用域，避免测试流量决定生产路由；若一个应用包含高风险和低风险功能，应先按功能分类，再做哈希。分桶算法升级本身也是一次路由变更，需要在迁移期间冻结。否则即使权重不变，大量主体也可能重新洗牌，观察窗口中的用户构成随之改变，导致指标突然波动却找不到网关原因。
六、可观察性要跨过两套网关，但不能记录敏感正文
迁移期间最怕“旧系统一套字段，新系统另一套字段”。OpenTelemetry 的 HTTP 语义约定覆盖 span、metric 和 log，并提供迁移期间双发旧、新字段的思路。团队不必一次重命名所有指标，但要建立一个共同的最小字段集，让同一请求能跨调用方、入口、新旧网关和上游被关联。
最小字段可以包括内部调用方 ID、环境、网关版本、路由别名、请求模式、HTTP 方法、规范化路径、状态码、低基数错误类型、重试次数、请求与响应大小、首字节时间、完成时间和追踪 ID。模型名称若基数可控可以记录别名；用户提示词、完整响应、工具参数值和密钥不进入普通日志。
W3C Trace Context 定义了traceparent与tracestate的传播格式。迁移时应确保入口收到的追踪上下文能被新旧网关继续传给下游，且网关自己创建的 span 保持父子关系。若上游还返回自己的请求 ID，可以作为 span 属性保存，但不要用它替换端到端 trace ID；两个标识解决的问题不同。
脱敏不是简单删除整条 URL。OpenTelemetry HTTP span 文档给出的原则是敏感查询值应被替换，同时保留键，便于知道哪个参数存在。类似地，请求头可以保留名称和“已设置”状态，值一律不记录；正文只记录 Schema 版本、字段集合、字节数和安全哈希。这样既能比较协议，又不暴露内容。
采样策略也要考虑迁移。正常请求可以概率采样，所有结构错误、工具校验失败、超时和回滚触发请求应提高采样或完整保留安全元数据。采样决策要跨链传播，否则调用方有 trace，网关和上游却没有，关键故障仍然断链。
指标命名和维度要在放量前通过演练验证。常见错误是旧网关记录timeout，新网关记录deadline_exceeded，报表把它们当成不同问题；或旧链按调用方统计，新链只保留全局值。可以先建立一个归一化层，将供应商和实现细节映射到有限的内部错误分类，同时保留原始错误类型供深挖。归一化规则必须版本化，避免规则更新造成“错误率下降”的假象。
七、把停止条件写成机器能执行的发布闸门
“感觉还行”不能成为放量依据。每个阶段都需要自动闸门，至少包含硬失败、相对退化和质量约束三类。硬失败包括无法鉴权、路由到错误上游、响应结构不可解析、工具调用越权、敏感字段进入日志。出现任一项就应立即停止扩大，必要时自动回滚。
相对退化要与同一时间、同一调用方和同一请求模式的旧网关对照。例如新网关 5xx 率高于旧网关多少、超时比例增加多少、首字节或完成时间的分位数变化多少。阈值必须由业务风险和历史波动决定，不能从本文复制一个通用百分比。
质量约束来自固定评测集和在线结构校验。影子阶段可以比较全部安全样本；金丝雀阶段要同时观察真实用户反馈、任务成功率、工具执行结果和回退率。若内容评测器本身会变化，需要锁定版本，并保留少量人工复核，避免评测器漂移被误判为模型质量变化。
闸门还要处理“指标缺失”。新网关没有上报关键指标，不代表指标为零；追踪断链、样本不足或报表延迟都应视为不可判定，并暂停放量。发布系统必须区分 pass、fail 和 unknown，unknown 不能默认通过。
自动闸门的结果要能解释。记录触发规则、观察窗口、样本量、旧值、新值和决定动作。值班人员看到回滚时，应能立即知道是结构错误、超时退化还是工具越权，而不是只收到“发布失败”。
闸门执行应具有防抖和优先级。单个瞬时尖峰可以先暂停放量并延长观察，但工具越权、敏感数据泄露或路由到错误租户属于立即回滚的高优先级事件。多个规则同时触发时，记录全部原因，但只执行一次幂等的状态转换。发布控制器还要防止人在自动回滚同时继续手工加权，所有写操作通过同一控制面并使用乐观锁或修订号检查。
八、回滚不只是把权重改回去
很多方案把回滚写成“新网关权重设为 0”。这只能恢复后续请求的路由，无法恢复迁移过程中已经改变的状态。完整回滚至少包含流量路由、网关部署、配置版本、模型别名映射、凭据、缓存、会话状态、重试队列、指标面板和告警规则。
首先保留旧网关的可运行能力。灰度期间不能一边放量一边销毁旧实例、撤销旧凭据或清空旧配置。Kubernetes 官方文档支持查看发布历史、暂停和恢复滚动更新，并可回滚到指定修订；不论使用何种平台，都应确保目标修订、配置和依赖仍然存在。
其次处理会话黏性。已进入新网关的会话回滚到旧网关时，缓存键、会话摘要或工具状态是否兼容？如果不兼容，可能需要让已开始的会话留在新网关直到结束，同时把新会话切回旧网关。回滚策略应区分“新会话停止进入”和“存量会话立即迁回”。
再次处理凭据。若迁移同时更换密钥，回滚时必须确认旧凭据仍有效，且新凭据不会继续被后台任务使用。不要在放量前就撤销旧 Key；可以先停止新请求、核对队列和长连接，再按既定窗口完成凭据收敛。所有示例密钥都应来自环境变量，不能写进配置仓库和回滚文档。
最后清理在途请求与重试。权重归零时，已有连接、队列和客户端重试仍可能抵达新网关。回滚动作要定义连接排空、队列处理和幂等策略，并持续观察一段时间，直到新网关的真实流量归零或仅剩允许的存量会话。
回滚演练不能只在空闲测试环境执行。至少构造包含长连接、流式请求、排队任务、工具意图和缓存命中的场景，验证路由切回时每类请求的处理结果。演练后检查是否留下孤儿任务、重复工具执行或两套缓存互相覆盖。发现无法回滚的状态，就应在生产放量前重新设计数据隔离，而不是把“人工修复”写成最后兜底。
九、模型请求是 POST，镜像与重试必须先解决幂等问题
RFC 9110 明确区分安全方法和幂等方法，POST 默认既不安全也不幂等；代理不得在没有额外保证时自动重试非幂等请求。模型生成表面上像“只读计算”，但实际系统可能计量、写审计、更新会话、触发工具或产生缓存，因此不能假定重复 POST 没有副作用。
影子流量本身就是一次额外 POST。上线前要回答：是否会产生第二次上游调用；是否记两次用量；是否写两份会话；是否触发工具；是否进入相同限流桶。任何一个答案不清楚，都不能直接镜像完整生产请求。
对于允许重试的纯生成请求，可以在业务层引入幂等键或请求指纹，但前提是网关和下游明确支持相同语义。幂等键不能只存在于客户端；新旧网关必须约定作用域、有效期、并发处理和返回缓存。若无法保证，就采用有上限的重试，并在连接失败时先查询请求状态或依赖服务端请求 ID 排查，而不是盲目再次提交。
工具调用更不能由网关自动重试。模型返回工具意图与真正执行工具是两步，执行器需要自己的幂等设计、审批与去重键。迁移验证可以重复生成工具意图，但真实执行必须只发生一次。影子链应只校验工具结构，拒绝访问生产执行凭据。
流式请求中断后也不应默认从头重放。客户端可能已经向用户展示部分内容，或模型已经产生一次计量。恢复策略应由具体业务决定：提示用户重新请求、从应用层检查点继续，或创建新请求并明确标记。网关不能隐藏这些差异后声称“自动恢复成功”。
如果业务确实需要自动重试 POST，应把可重试条件写成明确协议：请求尚未到达上游，或上游提供可查询的幂等结果；重试次数、总时间和并发都有上限；每次重发带同一业务幂等键和递增的传输尝试号；观测系统能把多次尝试归并为一次业务请求。仅凭“没有收到响应”不能证明上游没有执行，尤其在连接于响应返回前中断的情况下。
十、一个可执行的七阶段迁移顺序
第一阶段是契约盘点。整理调用方、路径、鉴权、模型别名、消息角色、流式、工具、错误和重试依赖，标记必须保持、允许改变和需要协同升级的项目。没有负责人或回滚动作的条目不能进入下一阶段。
第二阶段是离线回放。使用脱敏历史样本和合成边界样本验证请求解析、模型映射、响应结构和错误对象。回放环境使用测试凭据、独立缓存和禁用的工具执行器，不接触生产副作用。
第三阶段是小比例影子。仅复制已批准的数据类别，限制并发与总量，比较确定性协议、结构约束和离线任务结果。确认新系统不会递归重试、污染会话或挤占主链资源。
第四阶段是内部金丝雀。让内部或低风险调用方真正使用新网关响应，使用稳定分桶保持会话一致。观察最短窗口和最低样本量都满足后，才允许扩大。
第五阶段是代表性生产灰度。按应用和请求模式分层纳入，逐步提高相对权重。每次只改一个路由版本，自动闸门可暂停和回滚。高风险工具调用最后进入。
第六阶段是全量但保留旧链。新请求全部进入新网关，旧网关仍保持可用，旧凭据和配置不立即撤销。观察完整业务周期，处理存量会话、后台任务和长连接。
第七阶段才是收敛。确认回滚窗口结束、在途请求清空、指标稳定、调用方完成迁移后，分批撤销旧凭据、缩容旧实例、归档配置和更新文档。收敛动作同样需要审计和可逆计划，避免误删仍被边缘调用方使用的入口。
每个阶段结束都应产出一个小型证据包：当前路由修订、覆盖调用方、样本量、指标对照、结构失败清单、人工抽检结果、未解决风险和下一阶段批准人。证据包不保存敏感正文，却能让新的值班人员理解为何可以继续。没有证据包的阶段不能凭口头确认跳过；出现重大环境变化时，上一阶段结论也应失效并重新验证。
十一、迁移配置示例：把阶段、分桶和闸门写成数据
下面的 JSON 是通用示意，不代表任何具体产品已提供这些字段。重点是把发布决策从口头指令变成可审阅、可版本化的数据：
{"release_id":"gateway-migration-2026-07","stage":"canary","routing":{"stable_bucket_key":"internal_project_id","old_weight":95,"new_weight":5},"shadow":{"enabled":false,"tools_mode":"dry_run","cache_namespace":"migration-test"},"gates":{"required_metrics":["http_success_rate","timeout_rate","response_schema_valid_rate","tool_schema_valid_rate"],"on_unknown":"pause","on_hard_failure":"rollback"},"rollback":{"route_revision":"gateway-old-stable","keep_old_credentials":true,"drain_new_connections":true}}配置文件不应该包含 API Key，也不应把用户、邮箱或外部账号直接作为分桶字段。使用内部稳定 ID，分桶算法和盐值由受控配置管理。配置变更进入代码审查，发布系统记录修订号，回滚时引用确切修订而不是手工重新拼出旧值。
闸门阈值可以放在同一发布对象中，但阈值来源必须写进评审说明。硬编码一个没有历史基线的数字，只是把主观判断藏进配置。更合理的是由历史波动、业务容忍度和最小样本共同决定，并对关键调用方设置单独上限。
十二、验收清单：证明迁移可停止、可解释、可撤销
迁移开始前，确认所有调用方和契约条目有负责人；旧网关修订、配置和凭据仍可用；影子链无生产副作用；日志和指标不含敏感正文；分桶键稳定；回滚命令已在非生产环境演练。
影子阶段，确认镜像请求不影响主响应；新系统资源有独立上限；工具只做结构校验；响应比较按协议、结构和任务分层；所有失败都能关联追踪 ID；样本覆盖代表性请求而不是只有短问答。
金丝雀阶段，确认真实响应只面向批准分组；会话不会在新旧网关之间跳动；路由权重、观察窗和样本量满足计划；关键指标缺失会暂停而不是通过；硬失败能自动止损；值班人员知道如何解释触发原因。
回滚演练，确认权重归零后新请求停止进入；存量会话按计划处理；在途连接与重试队列可见；旧凭据仍有效；缓存和模型别名能恢复；发布历史保留目标修订；回滚完成后持续观察而不是立即宣布结束。
全量后，保留一个完整业务周期的回滚能力。只有当边缘调用方、后台任务、长连接和离线批处理全部验证，新旧追踪可以对齐，质量评测与用户反馈稳定，才进入旧链收敛。
验收会议应逐项查看证据，而不是只看总指标。请调用方确认接口行为，请平台团队确认路由和容量，请安全团队确认数据边界与凭据，请值班团队现场执行暂停和回滚。任何角色只能给出自己负责范围的结论，不能用一个“整体通过”掩盖尚未验证的工具执行、存量会话或边缘任务。最终记录应列出仍接受的风险、到期时间和责任人。
迁移结束后再安排一次无故障回滚演练，确认团队没有因为旧链缩容、权限调整或文档过期而失去退路。演练只使用批准的测试流量，并验证告警、值班通知、修订恢复和连接排空都符合预案。真正可靠的回滚能力需要持续维护，不能只在上线当天成立。
如果需要查看通用接口层级和接入资料，可把 https://178.nz/dn 作为延伸阅读入口；任何具体能力仍应回到当前官方文档和真实请求核验。
一次安全的模型网关迁移，不是“新地址能通”就结束，而是把不可见的协议差异和运行风险逐层暴露。影子流量解决真实请求覆盖，稳定分桶解决会话一致性，语义比较解决非确定输出，自动闸门解决及时止损，完整回滚解决状态恢复。只要每一步都能暂停、解释和撤销，迁移才从一次赌博变成可控工程。
参考资料
- Istio：Mirroring
- Kubernetes Gateway API：HTTP traffic splitting
- Kubernetes：Update a Deployment Without Downtime
- OpenTelemetry：Semantic conventions for HTTP
- OpenTelemetry：Semantic conventions for HTTP spans
- W3C：Trace Context
- RFC Editor：RFC 9110
- OpenAI：Chat Completions API Reference
::inbox-item{title=“模型网关迁移文章可复制” summary=“完整新角度正文已交付，可直接粘贴使用”}
