🎯 什麼情境該想到我
當你在猶豫「現在就該上分散式/微服務/複雜中間件嗎，還是先簡單做」時。
⚙️ 怎麼用
- 在痛點真的出現時才演進：DB 撐不住才分庫分表、單體真的擋路才拆服務。別為「想像中的未來規模」預先過度設計。
- 每次升級對準一個真實瓶頸：先量測、確認瓶頸，再針對它升級（呼應 工具-找出並管理約束點）。
- 保留演進空間，但不預先實作：介面/邊界留好（工具-限界上下文），讓未來好改，但現在保持簡單。
- 把共通難題沉澱成平台/中間件：等同類需求重複出現，再抽象共用，而非一開始就造框架。
📌 這一組三張卡：工具-服務架構的演進與拆分＝「有哪些選項」｜本卡＝「什麼時候該動」｜工具-服務邊界與演進式拆分＝「切在哪」
★ 判準：等「觸發訊號」出現，不要等「預感」
| 演進動作 | ★ 真正的觸發訊號 | ❌ 不是訊號 |
|---|---|---|
| 加讀取副本 | 讀取造成主庫 CPU/IO 飽和 | 「聽說要讀寫分離」 |
| 加快取 | 同樣的查詢重複率高 + DB 是瓶頸 | 「先加快取比較快」 |
| 分庫分表 | ★ 單表已數億列且索引失效、或單機容量/寫入到頂 | 「資料會長很大」 |
| 拆服務 | ★ 團隊互相擋住部署、資源需求差異極大 | 「模組太多了」 |
| 上訊息佇列 | 需要削峰 / 解耦 / 非同步化 | 「架構圖有比較好看」 |
| 多地區部署 | 有跨地區的使用者且延遲是問題、或有合規要求 | 「以後要國際化」 |
★ 共同點：每一個「真正的訊號」都是可量測的。
說不出「現在的數字是多少、到多少才需要動」，就是還不該動。
★ 演進的正確節奏
① ★ 量測 → 找出「現在」真正的瓶頸（不是猜的）
② 針對「那一個」瓶頸做最小的改動
③ 再量測 → 確認瓶頸移動了
④ 回到 ①
★ 一次只解一個瓶頸。 同時改三件事 → 你不會知道哪一件有效（見 工具-用度量取代模糊判斷）。
Amdahl 的提醒：優化只佔 5% 時間的部分，最多只能快 5%。
→ 先量出「時間花在哪」，再決定優化什麼（見 工具-找出並管理約束點）。
★ 預留空間 vs 預先實作（這條線最難拿捏）
| ✅ 該做（便宜、可逆） | ❌ 不該做（昂貴、難逆） |
|---|---|
| ★ 模組邊界劃清楚（見 工具-限界上下文） | 預先拆成微服務 |
| ★ 介面收窄（不暴露內部結構） | 預先做一層抽象以支援「未來可能的第二種實作」 |
| ★ ID 用可排序且不衝突的（UUIDv7/Snowflake，未來好分片） | 預先分庫分表 |
| ★ schema 保留擴充欄位、用可空欄位 | 預先設計「通用的 EAV 表」 |
| ★ 把狀態集中（讓服務無狀態） | 預先引入服務網格 |
| ★ 遙測從第一天就有 | 預先建平台團隊 |
★ 判準：這件事「現在做」和「以後做」的成本差多少？
差很多（例如 ID 格式、資料模型、邊界）→ 現在做。
差不多（例如加快取、加副本、拆服務）→ 以後做。這也是為什麼「資料模型」值得多想，而「部署架構」不值得預先設計——
資料模型改起來痛，部署架構改起來相對容易。
★ 各階段的典型形態（參考，不是規範）
| 規模 | 典型架構 | 什麼會先爆 |
|---|---|---|
| < 1 萬 DAU | ★ 單體 + 一個資料庫 + 託管服務 | 通常什麼都不會爆。別過度設計 |
| 1–10 萬 | + CDN + 快取 + 讀取副本 | 資料庫讀取 |
| 10–100 萬 | + 模組化單體或少數服務 + 佇列 + 物件儲存 | 寫入、團隊協作 |
| 100 萬+ | 服務化 + 分區 + 多地區 | 一致性、運維複雜度 |
★ 多數系統永遠停在第一、二階段，而那是完全正常的。
「為了一百萬使用者設計」而實際只有一千個，是最常見也最昂貴的錯誤。
★ 反過來也要會：簡化
演進不只是「加東西」。 用不到的服務要合併回去、失效的快取層要拆掉、
過時的抽象要移除（見 工具-技術債功能凍結）。
★ 「架構只會變複雜」是一個可以打破的假設，但需要刻意安排時間。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意 / 什麼時候不適用
- ★ 「痛點出現才演進」不等於「等到爆了才動」。
要在「趨勢明確」時就開始——磁碟用量每月漲 10%、p99 每週惡化 5%，
這些是訊號，不要等到 100% 才反應。 關鍵是有量測、有趨勢，不是有預感。 - ★ 有些東西無法演進，必須一開始就對：資料模型、ID 格式、租戶隔離方式、稽核紀錄。
這些改起來要資料遷移 + 應用重寫——值得多花時間想。 - 不要因為「面試都這樣答」而做。你的系統不是 Twitter。
- 演進要有回滾路徑。加了快取結果一致性出問題 → 要能關掉（feature flag）。
- ★ 團隊能力也是約束。三個人維運不了 Kubernetes + 服務網格 + 多地區部署——
選擇你「養得起」的架構（見 合理地使用技術）。 - 量測本身要先有。沒有遙測就沒有觸發訊號，只能憑感覺（見 工具-遙測與監控）。
🔗 相關工具
- 工具-服務架構的演進與拆分 —— 有哪些選項與各自的代價
- 工具-服務邊界與演進式拆分 —— 決定要拆之後，切在哪
- 工具-找出並管理約束點 —— ★ 一次只解一個瓶頸
- 工具-用度量取代模糊判斷 —— 觸發訊號要可量測
- 工具-遙測與監控 —— 量測的基礎
- 工具-容量估算 —— 判斷「還有多久會到頂」
- 工具-技術債功能凍結 —— 反過來的簡化
- 合理地使用技術 —— 選養得起的架構