路由遷移實戰：從舊站到本地站的五個坑

上個月，我們把團隊的本地推論路由從內網上的舊節點遷到了各工作站的本地埠。聽起來只是改幾個位址，實際踩坑踩了整整五天。記錄一下，給同樣在做這件事的同行參考。

前置準備：先承認「看起來在用」不等於「實際在用」

遷移按鈕還沒按下去之前，先做一件事：把現有模型名稱全部列出來，挨個打一遍煙霧測試。我們列完才發現，舊路由背後其實掛了四個不同的上游，其中兩個在韌體層已經報 429，只是沒傳出來——因為舊的路由帶了靜默的重試和降級。

這個教訓很扎心：**遷移前，「看起來在用」和「實際在用」是兩個不同的資料集**。灰度發布前先把真實流量畫像摸清楚，別在驗收環節吃了一臉盲。

兩層合一層之後，故障特徵全變了

舊環境裡其實跑著兩層：一層做認證與限流，一層做模型路由。遷移時我們把這個職責整體收進了本地的 router 裡。事後後悔嗎？不後悔。但有一個坑：舊的限流層在併發四十多個請求時，會出現短暫的 502 堆積，而新方案反而沒這個現象。

不是說新方案「更好」，而是**新舊方案的故障特徵完全不同**，監控告警和應急預案不能直接搬過來。我們的「限流超閾值」告警，在新架構下需要重新定義觸發條件。

驗收按 token 抽樣，別憑直覺

把終端喊「通過、通過」叫驗收，那是不叫驗收。我們的驗收流程是這樣的：

- 每台機器發一條小請求走 router，驗證串流 token 完整；

- 再發一條非串流請求，驗證工具呼叫和回應主體完整；

- 任意一個不通過，遷移就不宣佈完成。

這次就有一個請求：串流是完好的，但結束幀少了一個 `[DONE]`，光看 HTTP 200 完全發現不了。是反覆對比了三次的原始回應主體才看出規律的。這類問題，「看起來正常」永遠 cover 不住，必須拆到 token 粒度去對齊。

日誌工具選慢還是選快

遷移當天加班到夜裡十點，用手機翻設備管理裡逐條核對 HTTP 狀態碼分佈，來確認舊閘道真的沒流量。好處是證據鏈完整，壞處是工具慢、不能平行處理。

等切第二台機器時，直接寫了腳本批次驗證，時間從四十分鐘壓到五分鐘。別在第一次切換的時候追求「完美溯源」，先快速通，再回頭補證據鏈，成本更低。

別在遷移當天兼做「順手小改」

這次最大的坑，是我在遷移當天順手把健康檢查的逾時從 3 秒改到 1.5 秒，沒寫回滾註解。表面上收益是 `curl` 兩秒內返回，但有個走長連線的用戶端，在那個視窗期陸續報了四十多分鐘的網路錯誤。改設定檔的那天，只改要改的那一行。**原則比速度重要。**

切流時的一個細節

把用戶端指向從舊位址換到新位址，我們不是全量翻，而是按「小時」灰度發布：先切掉一半的非生產會話，跑滿一個時鐘週期，把日誌裡的狀態碼分佈跑一遍，確認沒有回退再切剩下的部分。這一步沒有戲劇性，但它是當天夜裡沒有人被叫醒的原因。

小結

路由遷移裡最貴的不是搬設定，而是新舊兩套架構的故障模式對不上。驗收按 token 抽樣檢查，告警按指標重建，別靠肉眼。下次有人問遷移要幾天——看你要不要留逆天的時間視窗。