路由迁移实战：从旧站到本地站的五个坑

上个月，我们把团队的本地推理路由从内网上的旧节点迁到了各工作站的本地端口。听上去只是改几个地址，实际踩坑踩了整整五天。记录一下，给同样在做这件事的同行参考。

前置准备：先承认"看起来在用"不等于"实际在用"

迁移按钮还没按下去之前，先做一件事：把现有模型名全部列出来，挨个打一遍冒烟。我们列完才发现，旧路由背后其实挂了四个不同的上游，其中两个在固件层已经报 429，只是没传出来——因为旧的路由带了静默的重试和降级。

这个教训很扎心：**迁移前，"看起来在用"和"实际在用"是两个不同的数据集**。灰度前先把真实流量画像摸清楚，别在验收环节吃了一脸盲。

两层合一层之后，故障特征全变了

旧环境里其实跑着两层：一层做认证与限流，一层做模型路由。迁移时我们把这个职责整体收进了本地的 router 里。事后悔吗？不后悔。但有一个坑：旧的限流层在并发四十多个请求时，会出现短暂的 502 堆积，而新方案反而没这个现象。

不是说新方案"更好"，而是**新旧方案的故障特征完全不同**，监控告警和应急预案不能直接搬过来。我们的"限流超阈值"告警，在新架构下需要重新定义触发条件。

验收按 token 抽，别凭直觉

把终端喊"通过、通过"叫验收，那是不叫验收。我们的验收流程是这样的：

- 每台机器发一条小请求走 router，验证流式 token 完整；

- 再发一条非流式请求，验证工具调用和响应体完整；

- 任意一个不通过，迁移就不宣布完成。

这次就有一个请求：流式是完好的，但结束帧少了一个 `[DONE]`，光看 HTTP 200 完全发现不了。是反复对比了三次的原始响应体才看出规律的。这类问题，"看起来正常"永远 cover 不住，必须拆到 token 粒度去对齐。

日志工具选慢还是选快

迁移当天加班到夜里十点，用手机翻设备管理里逐条核对 HTTP 状态码分布，来确认旧网关真的没流量。好处是证据链完整，坏处是工具慢、不能并行。

等切第二台机器时，直接写了脚本批量验，时间从四十分钟压到五分钟。别在第一次切换的时候追求"完美溯源"，先快速通，再回头补证据链，成本更低。

别在迁移当天兼做"顺手小改"

这次最大的坑，是我在迁移当天顺手把健康检查的超时从 3 秒改到 1.5 秒，没写回滚注释。表面上收益是 `curl` 两秒内返回，但有个走长连接的客户端，在那个窗口期陆续报了四十多分钟的网络错误。改配置文件的那天，只改要改的那一行。**原则比速度重要。**

切流时的一个细节

把客户端指向从旧地址换到新地址，我们不是全量翻，而是按"小时"灰度：先切掉一半的非生产会话，跑满一个时钟周期，把日志里的状态码分布跑一遍，确认没有回退再切剩下的部分。这一步没有戏剧性，但它是当天夜里没有人被叫醒的原因。

小结

路由迁移里最贵的不是搬配置，而是新旧两套架构的故障模式对不上。验收按 token 抽检，告警按指标重建，别靠肉眼。下次有人问迁移要几天——看你要不要留逆天的时间窗口。