跳轉到

B.1 淘寶 14 次演進 vs 本書章節對照總表#

教學模型，非淘寶真實路徑。用法：上課前先看「瓶頸」，猜「解法」，再翻對應章節驗證。

# 演進 瓶頸 → 解法 → 對應章節
1 單機 LAMP 一體 流量稍漲單機即滿載 → Web 與 DB 分離部署 → Ch 1.2
2 應用性能調優 CPU/內存/I-O 競爭 → JVM 調優、連接池 → Ch 1.3
3 引入快取 DB 讀寫瓶頸 → 本地快取 + Redis/Tair → Ch 2.1–2.2
4 快取治理 穿透、擊穿、雪崩 → 布隆過濾、熔斷、預熱 → Ch 2.3–2.4
5 無狀態 + 負載均衡 單機扛不住併發 → Nginx 集群 + Session 共享 → Ch 3.1–3.2
6 入口與多活 單機房單點 → DNS/CDN/LVS/異地多活 → Ch 3.3–3.4
7 資料庫拆分 單庫寫滿 → 讀寫分離、垂直分庫 → Ch 4.1–4.2
8 分庫分表 大表慢查詢 → Hash/時間水平拆分 → Ch 4.3–4.4
9 服務化拆分 單體發布耦合 → DDD 垂直拆分、Dubbo RPC → Ch 5.1–5.2
10 服務治理 級聯雪崩 → Nacos、限流熔斷降級 → Ch 5.3–5.4
11 異構數據 + 訊息 搜尋與削峰撐不住 → ES/HBase、RocketMQ/Kafka → Ch 6.1–6.3
12 容器化 環境不一致、部署慢 → Docker、Compose → Ch 7–8
13 容器編排 上千容器管不動 → K8s、Service/Ingress/HPA → Ch 9–11
14 Serverless + AI 原生 成本與 AI 推理壓力 → Knative、FinOps、AI 網關/AgentInfra → Ch 12–16 
# 建議讀法：按演進順序做實驗
docker compose up -d --build        # 演進 12：單機多容器（Ch 7.4）
kubectl apply -f shop.yaml          # 演進 13：上 K8s（Ch 9.3）
kubectl scale deploy shop --replicas=5  # 演進 13：水平擴展（Ch 11.2）

分組速記（四階段）#

階段 演進範圍 核心矛盾 關鍵詞
單機與快取 1–4 一台機器撐不住讀寫 分離部署、Redis、防雪崩
規模化 5–8 流量漲、庫寫滿 無狀態、LVS/CDN、分庫分表
服務化 9–11 單體耦合、峰值壓垮 DDD、熔斷降級、MQ 削峰
雲原生 12–14 環境亂、容器多、成本高 Docker、K8s、Serverless/AI 
# 期中自測：遮住右欄，說出解法與章節
# 瓶頸「DB 讀寫瓶頸」→ 解法？→ 章節？
# 瓶頸「上千容器管不動」→ 解法？→ 章節？
kubectl get deploy,svc,hpa          # 演進 13 驗收：三種物件都在才算通

實驗對應表#

演進 動手做 驗收命令
3–4 快取 Compose 起 Redis，壓測穿透 docker compose ps、redis-cli ping
5 負載均衡 Nginx + 2 副本 Web curl http://localhost 輪詢命中
11 削峰 RocketMQ 收發 1 萬條 生產消費無堆積
12–13 容器編排 Compose → K8s 遷移同一服務 kubectl get pods -o wide 全 Running

本章小結#

  • 前 4 次演進：單機與快取（Ch 1–2）；5–8：規模化與拆庫（Ch 3–4）。
  • 9–11：服務化與削峰（Ch 5–6）；12–13：容器與編排（Ch 7–11）。
  • 14：Serverless 與 AI 原生（Ch 12–16），是本書後半主線。

想一想#

  1. 為什麼「快取」出現在「負載均衡」之前？順序顛倒會付出什麼代價？
  2. 第 8 次（分庫分表）與第 9 次（服務化）都談「拆」，拆的對象與代價有何不同？
  3. 若只能選一次演進上容器，你會選第 12 次還是第 13 次？為什麼？