沒有系統一開始就長成千萬用戶的樣子——它是一步步演進出來的。這頁把單機到百萬用戶的路線串成一條敘事：每個瓶頸引出下一個元件，各元件的細節見對應概念頁。
🧠 Core Ideas
TIP
演進順序：單機 → 分離 Web/DB → 加 Load Balancer（Web 層冗餘）→ DB 複製（讀寫分離）→ Cache → CDN（靜態內容）→ 無狀態 Web 層 → 多資料中心 → Message Queue（解耦）→ 日誌/指標/自動化 → DB 分片。每一步都在解上一步暴露的瓶頸。
- 擴展是迭代的：反覆套用這些手法能走很遠；再往上就要更細的服務拆分與優化。
- 記住終局清單：Web 層無狀態、每層有冗餘、盡量快取、多資料中心、靜態上 CDN、資料層分片、拆成獨立服務、監控＋自動化。
⚖️ 演進的關鍵轉折
單機 → 分離 Web/DB → 選型
- 起點所有東西（Web、DB、Cache）擠一台。使用者經 DNS 拿 IP → HTTP 打 Web 伺服器。
- 成長後把 Web 層與資料層拆開，各自獨立擴展。
- DB 選型：RDBMS（table/row、可 join、40 年成熟）vs NoSQL（key-value / graph / column / document，通常不支援 join）。NoSQL 適合：極低延遲、非結構化、只需序列化、海量資料。詳見 SQL vs NoSQL。
垂直 vs 水平 → Load Balancer
- 垂直擴展簡單但有硬上限、無 failover；水平擴展適合大規模。
- Load Balancer 把流量分到一組 Web 伺服器，客戶端只看到 LB 的公開 IP，後端走私有 IP 互通。一台掛了流量全導向健康的那台 → 解決「無 failover」。
DB 複製 → Cache → CDN
無狀態 Web 層 → 多資料中心
- 把 session 等狀態移出 Web 層存到共用儲存 → 無狀態，任何請求可打任何伺服器，才能 auto-scaling。有狀態架構要 sticky session，擴展與故障處理都更難。
- 多資料中心：geoDNS 把使用者導向最近 DC；某 DC 故障流量全導向健康 DC。挑戰是跨 DC 資料同步、測試與部署一致性。
Message Queue → 監控 → DB 分片
- Message Queue：生產者/消費者解耦，各自獨立擴展（佇列變長就加 worker）。是構建可擴展、可靠系統的首選。
- 日誌/指標/自動化：主機層、彙整層、業務層（DAU/留存/營收）指標＋CI/CD。
- DB 分片：選好 sharding key（分布要均勻）。挑戰：resharding（用一致性雜湊）、名人熱點、跨 shard join（常靠反正規化）。
🔑 Takeaways
- 架構是演進出來的：每個元件都是為了解某個具體瓶頸，不是一次擺齊。
- 面試講擴展時，按「單機 → LB → 複製 → 快取 → CDN → 無狀態 → 多 DC → MQ → 分片」的順序推，最有說服力。
- 這頁是索引式串接；每個轉折的深入細節見連到的對應概念頁。
No notes yet — jot your takeaways or Q&A here.