淘寶技術這十年

📌 30 秒摘要（Layer 3）

用第一手故事講淘寶從一個買來的小網站，長成扛得住雙十一巨量流量的超大型系統的十年歷程。看它如何一路被業務逼著演進：從 LAMP 單體、到分庫分表、到自研中間件、到「去 IOE」（去掉昂貴的商用軟硬體改用開源+自研）。最大的啟示不是某項技術，而是架構是被業務規模「逼」出來的，該在痛點真的出現時才演進，而非一開始就過度設計。

🗺 心智圖（Canvas）

淘寶技術這十年

淘寶技術這十年

子柳（趙超）｜架構是被業務規模逼出來的

🌱 演進而非一步到位 架構隨業務一起長出來

工具-架構隨業務規模演進

🎯 什麼情境該想到我

當你在猶豫「現在就該上分散式/微服務/複雜中間件嗎，還是先簡單做」時。

⚙️ 怎麼用

1. 在痛點真的出現時才演進：DB 撐不住才分庫分表、單體真的擋路才拆服務。別為「想像中的未來規模」預先過度設計。
2. 每次升級對準一個真實瓶頸：先量測、確認瓶頸，再針對它升級（呼應 工具-找出並管理約束點）。
3. 保留演進空間，但不預先實作：介面/邊界留好（工具-限界上下文），讓未來好改，但現在保持簡單。
4. 把共通難題沉澱成平台/中間件：等同類需求重複出現，再抽象共用，而非一開始就造框架。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 兩個極端都要避免：過早複雜化（YAGNI）與拖到系統崩潰才動。用「真實痛點 + 數據」判斷時機。

🔗 相關工具

• 工具-服務架構的演進與拆分 —— 具體到微服務這一題，什麼規模該拆、怎麼拆
• 工具-管理複雜度 —— 判斷準則，提早上複雜架構等於提早付複雜度的帳
• 工具-沒有銀彈 —— 同一種清醒，新架構不會讓問題消失，只會換一批問題

痛點驅動升級 每一次架構升級，都對應一個 真實出現的瓶頸：DB → 單機 → 成本 而非一開始就過度設計

🔧 去 IOE 擺脫昂貴的商用軟硬體

用開源＋自研中間件 替換昂貴的商用資料庫／小型機 兼顧成本與可控

🧱 中間件的價值 把難題沉澱成平台

把共通的分散式難題沉澱成平台 分庫分表 × 快取 × 訊息 讓上層業務不必重造輪子

👥 人與組織

技術演進背後是 團隊成長與工程文化

💬「架構不是設計出來的， 　　是隨著業務一起長出來的。」

Link to original

🧰 這本書給我的工具

• 工具-架構隨業務規模演進 — 判斷「現在該不該上這個複雜架構」時

（具體技術對照 鳳凰架構、設計資料密集型應用、工具-資料分區）

✨ 關鍵重點（Layer 1–2）

• 演進而非一步到位：每一次架構升級，都對應一個真實出現的瓶頸（DB、單機、成本）。
• 去 IOE：用開源與自研中間件替換昂貴的商用資料庫/小型機，兼顧成本與可控。
• 中間件的價值：把共通的分散式難題（分庫分表、快取、訊息）沉澱成平台，讓上層業務不重造。
• 人與組織：技術演進背後是團隊成長與工程文化。

💬 金句原文（Layer 0）

• 「架構不是設計出來的，是隨著業務一起長出來的。」

🔗 相關

• 現代化的分散式架構理論見 鳳凰架構；資料層見 設計資料密集型應用