題幹與適用場景
這是一道系統設計題，核心不是爭論 URL 版本還是 Header 版本，而是設計一套 API 生命週期控制平面。它要從契約變更進入影響分析，找到真實消費者，驗證新舊版本行為，分階段通知和遷移，最後用證據決定是否停用。Microsoft 建議盡量保持向後相容，Google Cloud 也強調先嘗試相容式演進；題目要求你把原則落成跨團隊可運行的系統。
面試官考察點
- 能否區分格式相容、實體語意變化和真正的破壞性變更。
- 能否把 API 契約、消費者清單、執行時流量和遷移任務連接起來。
- 能否設計相容性測試、灰度、告警、通知和回復，而非只給版本號。
- 能否解釋多版本支援的運維成本、資料轉換風險和組織協作邊界。
回答前需要釐清的問題
先確認 API 是內部、合作夥伴還是公開 API，消費者是否能被完整識別，呼叫量、延遲和可用性目標是什麼。再明確要刪除的欄位是否可選、是否改變語意、是否涉及寫入和持久化資料；確認是否已有 OpenAPI 或其他契約來源、客戶端 SDK、通知渠道、支援期限、合規要求和回復窗口。若題目沒有給規模，應先聲明估算假設。
30 秒回答框架
我會按「契約註冊、影響發現、相容驗證、遷移協調、停用證明」五段設計。所有 API 契約進入註冊中心，變更先由規則引擎判斷相容性，再結合靜態依賴和執行時呼叫識別消費者。新舊版本並行提供，消費者收到帶截止時間和遷移指南的通知；灰度期間按版本記錄成功率、錯誤和殘餘流量。只有舊版本零關鍵流量、遷移任務完成、回復方案演練通過並經過審批，才執行停用。
分步驟深入解答
1. 建立契約註冊中心和變更規則
註冊中心保存 API、版本、所有者、欄位語意、認證範圍、支援狀態、棄用時間和遷移文件。變更請求關聯契約 diff，規則引擎識別刪除欄位、收窄列舉、改變必填性、改變錯誤語意和實體關係等風險。新增可忽略欄位通常是相容式變更，但不能假定所有客戶端都正確忽略未知欄位；規則應允許團隊提交有證據的例外。
2. 發現消費者並建立影響圖
消費者目錄合併程式碼儲存庫依賴、閘道日誌、服務網格遙測、SDK 註冊和人工聲明，形成 API—版本—消費者的關係圖。靜態發現可能漏掉動態拼接請求，執行時發現可能漏掉低頻任務，因此要標記證據來源、最後觀測時間和信心度。對外部客戶端只保留必要的租戶和應用程式識別，避免把日誌當成無限期個人資料。
3. 相容性驗證與安全護欄
每次變更執行契約測試、消費者回放和樣本流量比較；讀取路徑檢查新舊回應語意，寫入路徑驗證舊客戶端請求不會遺失資料或產生錯誤副作用。破壞性變更先在影子或小租戶灰度，版本路由和功能開關必須可回復。失敗時保留舊版本，不能用「測試通過」覆蓋未納入測試的消費者。
4. 通知、遷移和多版本運行
通知服務按消費者、嚴重性和支援合約發送遷移指南、截止時間、範例請求和聯絡人；外部客戶要有可查詢的狀態頁或控制台。遷移任務記錄負責人、阻塞原因、驗證結果和最後一次成功呼叫。多版本會增加測試、部署和監控成本，應該設定版本上限、棄用階段和升級路徑，而不是無限期保留舊版本。
5. 停用決策、觀測與恢復
停用前檢查關鍵消費者已升級、殘餘呼叫低於門檻、錯誤率無回歸、資料轉換可逆、支援團隊已準備。停用採用分區和時間窗口，先拒絕新接入，再對舊呼叫返回明確的棄用錯誤和遷移連結，最後關閉路由。指標包括相容性失敗、舊版本請求量、遷移完成率、通知送達率、回復次數和按消費者分層的錯誤率。Kubernetes 的棄用政策展示了穩定級別、最短支援期、轉換和回復約束；系統應把這些約束配置化，而不是照抄成所有公司的期限。
高品質示範回答
我先確認消費者類型、契約來源、要刪除欄位的讀寫語意、外部通知義務和回復窗口。架構上建立契約註冊中心，變更進入規則引擎，識別破壞性差異並關聯影響圖；影響圖由程式碼依賴、閘道日誌和服務網格遙測共同構成，並標註證據新鮮度。相容性測試、消費者回放和灰度流量驗證新舊行為，通知服務給每個消費者發送遷移指南和截止時間。新舊版本並行運行，遷移任務記錄驗證證據，只有關鍵消費者完成、殘餘流量和錯誤率達標、回復演練通過並獲審批，才分階段停用。所有變更、通知、觀測和回復寫入稽核日誌，防止未知客戶端被一次性切斷。
常見錯誤
- 只討論 URL、Header 或語意化版本號，沒有消費者發現和停用證據。
- 只依賴靜態程式碼搜尋或單一存取日誌，忽略動態呼叫和低頻任務。
- 把刪除可選欄位當成必然安全，未驗證舊客戶端的真實解析行為。
- 同時上線新版本並立即關閉舊版本，沒有灰度、回復和遷移窗口。
- 無限期支援所有版本，未計算多版本測試、監控和資料轉換成本。
- 只發一封郵件，沒有截止時間、責任人、阻塞升級和分層指標。
追問及應對
找不到某個外部客戶端，怎麼判斷可以停用？
把「不確定」當作風險狀態，延長觀測窗口並提高日誌粒度，聯絡合約聯絡人或提供自助遷移診斷。不能把零日誌等同於零使用，停用前應設定可恢復的拒絕策略和緊急回退通道。
新增回應欄位真的總是相容嗎？
不總是。契約規則可以把新增欄位標為通常相容，但仍要用真實消費者回放、SDK 版本矩陣和錯誤樣本驗證；對嚴格 schema 驗證的客戶端，需要單獨遷移或版本隔離。
舊客戶端寫入的資料如何安全遷移？
先定義欄位語意映射和不遺失條件，使用雙讀、雙寫或離線轉換並記錄版本。轉換必須可驗證、可回復，不能在讀取時悄悄改變業務含義。
客戶在截止日期前無法升級怎麼辦？
按支援合約和風險等級提供有限的相容窗口、適配代理或人工遷移，但要記錄成本、負責人和新的退出日期。例外應減少未知流量，而不是把舊版本永久變成預設路徑。
如何防止棄用控制平面本身成為單點故障？
資料面路由不應依賴即時控制平面寫入；快取已核准的版本策略，控制平面故障時保持最後安全配置。註冊、通知和指標服務可非同步恢復，停用動作必須有雙人審批和明確回復。