系統設計面試題：如何用 Cell-Based Architecture 限制故障影響？
題幹與適用場景
一個全球服務經常因單次錯誤發布、過載或共享依賴故障導致大範圍中斷。請設計 Cell-Based Architecture，把使用者流量分配到相互獨立的 cell，並說明路由、資料、容量、發布、跨 cell 操作和災難復原策略。
面試官考察點
- 是否把 cell 定義為可獨立執行、擴展和回滾的完整副本。
- 是否能解釋故障半徑、路由對映和新使用者分配的一致性。
- 是否能處理共享控制面、跨 cell 資料、容量傾斜和熱點遷移。
- 是否能把漸進發布、指標門禁和復原演練落到具體流程。
回答前需要釐清的問題
- 隔離鍵是使用者、租戶、地域還是業務分區？跨區存取是否允許？
- 哪些資料必須全域一致，哪些資料可以 cell 內最終一致？
- 目標是限制單次部署影響，還是應對區域級災難？
- 負載是否可預測，熱點租戶能否遷移，遷移期間如何保證冪等？
30 秒回答框架
我會把每個 cell 做成包含計算、快取和主要資料依賴的獨立服務副本，用穩定的使用者到 cell 對映把請求路由過去。全域控制面只保存對映、版本和容量摘要，資料面盡量不跨 cell 呼叫。新版本先在一個 cell 金絲雀，依據錯誤率、延遲和飽和度逐步擴展；故障時停止該 cell 的流量並回滾，其他 cell 保持服務。跨 cell 任務透過非同步編排、冪等鍵和明確的降級策略完成。
分步驟深入解答
1. Cell 的邊界
Cell 是可獨立部署、擴展和復原的系統單元，通常包含服務實例、快取、佇列和專屬資料分片。共享的 DNS、身分或設定服務應盡量保持低權限、低耦合，並定義它們故障時的降級行為。
2. 路由與對映
路由層根據使用者或租戶鍵查找對映，把請求轉發到目標 cell。對映需要版本、校驗和過期策略；遷移時先寫入新對映，再等待舊請求排空，避免同一實體同時寫入兩個 cell。
3. 資料隔離
每個 cell 擁有本地寫入邊界，跨 cell 查詢優先使用非同步複製的唯讀投影。全域唯一約束應放到專門的協調服務，或改成分區內唯一加最終合併，避免把所有寫入重新集中到單點。
4. 容量與熱點
為每個 cell 設定請求、佇列、資料庫連線和儲存配額，控制單 cell 的最大爆炸半徑。監控租戶分布和資源水位，熱點租戶可遷移到空閒 cell，但遷移必須支援雙讀、單寫和可重播事件。
5. 共享控制面風險
控制面負責對映、版本和編排，不應承載所有業務資料。控制面不可用時，路由器應使用帶 TTL 的本地快照繼續服務；快照過期後只允許安全的讀流量或返回可重試錯誤。
6. 發布與回滾
先選一個 cell 執行新版本，比較基線 cell 的錯誤率、尾延遲、資源飽和度和業務指標。達到門檻後按批次擴散；任何 cell 出現回歸就暫停擴散並回滾該版本，不把健康 cell 一起降級。
7. 跨 cell 操作
跨 cell 報表、批處理和帳戶遷移應透過任務編排器執行，使用冪等鍵、租約和進度檢查點。任務失敗時只重試未完成分片，並把部分完成狀態明確暴露給呼叫方。
8. 災難復原與演練
為每個 cell 備份資料和設定，定義復原點與復原時間目標。定期演練單 cell 隔離、控制面失聯、區域故障和對映損壞，驗證流量轉移、資料復原和回滾腳本，而不只依賴理論上的冗餘。
設計取捨與邊界
- Cell 越小故障半徑越低，但維運、容量碎片和跨 cell 協調成本越高。
- 強全域一致性會重新引入共享瓶頸；應按業務價值拆分一致性邊界。
- 路由快照提高控制面故障時的可用性，卻可能把請求送到已下線或容量不足的 cell，需要 TTL 和熔斷。
- 多 cell 發布降低爆炸半徑，不能取代相容的資料遷移和可回滾 schema 設計。
落地計畫與證據
- 畫出 cell、路由層、控制面、資料面和共享依賴的邊界圖，標註每條跨 cell 呼叫。
- 用壓測確定單 cell 的容量上限和熱點遷移閾值，記錄 P95、P99、錯誤率和佇列深度。
- 實作對映版本、TTL、雙讀單寫和事件冪等，並演練遷移中斷復原。
- 建立單 cell 金絲雀、指標門禁、自動暫停和回滾流水線。
- 對照 AWS Cell-Based Architecture 指南與 Well-Architected Reliability Pillar 複核故障隔離和復原目標。
常見誤區與追問
誤區一：只複製計算實例就稱為 cell
如果快取、佇列或資料庫仍是全域共享，關鍵故障仍會跨 cell 擴散。必須列出每個依賴的隔離和降級方案。
誤區二：用隨機分流取代穩定對映
隨機分流會讓同一租戶跨 cell 寫入，破壞快取和資料邊界。需要可版本化、可遷移的確定性對映。
誤區三：把控制面當成永不失敗
控制面故障是常見爆炸源。應快取對映、設定 TTL，並定義快照失效後的安全行為。
追問：如何選擇 cell 數量？
從單 cell 容量、目標故障半徑、部署批次和維運成本反推，保留至少一個可承接故障流量的餘量，再用壓測和演練校準。
追問：跨 cell 交易如何保證一致？
優先避免跨 cell 交易；必須協同時使用冪等事件、補償動作和可見的部分完成狀態，不把分散式鎖當作萬能方案。