模型 API 灰度切换时，怎么确认回滚真的生效？

本文经 AI 辅助整理。假设一个摘要服务要把少量流量切到 nexo 中转站，首批请求出现异常后决定切回原端。作者参与该站运营，下面用本地模拟端点演练这次切换。给模型 API 换接入端时，配置改回原值只是回滚的第一步。真正要确认的是改动之后发出的请求去了哪里，以及改动之前已经发出的请求如何结束。否则界面显示回滚成功，旧进程仍可能握着另一套配置继续工作。

先给每次配置变更一个版本标识。请求开始时记录这个标识、请求标识和客户端版本，并贯穿整次请求。服务地址可以记成测试环境中的逻辑别名，日志不用记录凭证或用户输入。回滚时选取变更后的第一批新请求，确认日志里出现的是回滚后的版本。多进程环境要分别看各实例，否则单次成功只能说明某个实例已经加载新配置。

演练可以用两个本地模拟端点。A 返回固定文本，B 返回固定文本前先等待几秒。让一个请求进入 B，在它返回之前切回 A，再发第二个请求。第二个请求应使用 A；第一个请求按设计继续完成或被明确取消。检查它有没有被无条件重发。带工具调用的场景尤其需要这个检查，因为重复发起业务动作可能留下两条记录。

正式切换前，建议再覆盖一个常驻进程和一个新启动的进程，分别核对配置版本，防止只验证到重启后的路径。

最后保存三项回滚证据：新请求使用的版本、旧请求的结束状态、外部动作是否重复。用这三项判断回滚，比仅检查控制台显示的地址更接近应用的实际行为。

回滚演练记录

把两个模拟端点分别记为 A 和 B。给 A 配置版本 v1，给灰度到 B 的配置版本 v2；回滚到 A 时发一个新版本 v3。即使 v1 和 v3 指向同一个地址，版本号也能区分进程究竟加载了旧缓存还是收到了回滚配置。

1. 将测试用户固定到 B，发送请求 R1。让 B 等待五秒，并在收到请求时写一行日志，确认 R1 已经发出。
2. R1 仍在等待时下发 v3。等应用记录 v3 已加载，再从同一个常驻进程发 R2，并从新启动的进程发 R3。
3. 预期日志为 R1 / v2 / B，R2 / v3 / A，R3 / v3 / A。若 R2 仍走 B 而 R3 正常，重点查常驻进程的配置缓存和连接复用逻辑。若两条都走 B，先核对配置是否下发到正确环境。
4. 模拟工具写操作时，用本地计数器记录同一个业务动作实际执行了几次。让 R1 超时后检查计数器。若操作状态未知，就保留待查状态，别为了回滚自动补发。

把这四步做成发布前检查。能证明回滚成功的是变更后每个测试实例的新请求都走 A，以及旧请求按约定完成或取消。