可擴展性
一句話定義
可擴展性是系統在流量、資料量、使用者數、地理範圍或團隊規模變大時，仍能透過增加資源、拆分責任與調整資料流維持可接受性能與可靠性的能力。
核心要點
不是「能撐大流量」一句話
可擴展性至少要拆成幾個面向：
| 面向 | 問題 |
|---|---|
| 流量擴展 | QPS / concurrent users 增加時，入口與服務層如何承接 |
| 資料擴展 | 單一資料庫或單一磁碟放不下時，如何複製、分片、歸檔 |
| 地理擴展 | 使用者跨區域時，如何降低延遲並處理資料同步 |
| 功能擴展 | 產品功能變多時，服務邊界與資料模型是否仍可理解 |
| 團隊擴展 | 多人協作時，架構、接口、測試與 review 是否能避免互相踩踏 |
只說「上雲」「加機器」「改微服務」都太粗；必須先知道是哪一種規模壓力。
垂直擴展與水平擴展
- 垂直擴展：在同一台機器上增加 CPU、記憶體、磁碟或 I/O 能力。優點是簡單；缺點是硬體上限、成本與單點故障。
- 水平擴展：增加更多機器，讓負載分散。優點是容量上限更高；缺點是需要處理負載均衡、資料一致性、分片、部署與監控。
2026-05-14-搞定系統設計面試 的路徑是先用垂直或簡單拆分解短期瓶頸，再逐步引入水平擴展需要的元件。
常見擴展手段
| 手段 | 解決什麼 | 代價 |
|---|---|---|
| 負載均衡 | 多台服務共同接流量 | 需要健康檢查與 session 處理 |
| 無狀態服務層 | 服務可自由增加 / 移除 | 狀態要移到共享存儲 |
| 快取 | 降低讀延遲與資料庫壓力 | 失效、穿透、雪崩與一致性問題 |
| CDN | 把靜態內容移近使用者 | 快取更新與成本管理 |
| 資料庫複製 | 提高可用性與讀吞吐 | 主從延遲、failover、寫一致性 |
| 資料分片 | 單庫放不下時分散資料 | 分片 key、熱點、跨 shard 查詢 |
| 消息佇列 | 削峰、非同步、解耦 | 延遲、重試、順序、重複消費 |
| 多資料中心 | 區域容災與低延遲 | 資料同步、部署一致性、成本 |
| 監控告警 | 擴展後維持可操作性 | 指標設計與告警噪音 |
擴展不是越早越好
過早引入分散式架構會讓團隊承擔一致性、部署、觀測、除錯與資料遷移成本。更務實的問題是：
- 當前瓶頸是真實存在，還是想像中的未來流量？
- 這個擴展手段是降低複雜度，還是把複雜度提前帶進來？
- 如果流量真的成長，下一個可逆的擴展步驟是什麼？
- 有沒有先用 封底估算 檢查數量級？
與其他概念的關係
- 系統設計 — 可擴展性是系統設計中最常見的品質目標之一。
- 分散式系統元件 — 負載均衡、快取、CDN、佇列、分片與監控是實作可擴展性的常用手段。
- 封底估算 — 用數量級估算判斷是否真的需要某種擴展手段。
- 系統設計面試 — 面試中常用「如果使用者增加 10 倍怎麼辦」追問可擴展性。
- 網頁爬蟲 — 從單機爬蟲到分散式爬蟲時，會遇到任務分配、去重、佇列、節流與儲存擴展。
- AI輔助開發 — AI 加速產出程式碼不等於系統可擴展；可擴展性仍需工程設計、測試與可觀測性。
相關來源
- 2026-05-14-搞定系統設計面試 — 主來源；以從 0 到 100 萬用戶的演化路徑說明多種擴展手段。
備註
未來可補：scaling laws 在 AI / infra 的語境、SRE 容量規劃、資料庫分區策略、serverless 擴展模型、Kubernetes autoscaling 與成本治理。