🎯 什麼情境該想到我
當你在猶豫「要不要從單體走向微服務、怎麼拆」，或被「微服務很潮」帶風向時。
⚙️ 怎麼用
- 認清各階段的取捨：單體（簡單、部署一體）→ SOA → 微服務（獨立部署/擴展，但引入分散式複雜度）→ 無伺服器。微服務不是免費的——你用開發簡單度換來運維與分散式的複雜度。
- 先具備前置條件再拆：自動化部署、監控、服務治理都到位，才適合微服務。
- 按業務邊界拆，而非技術分層——切點對齊 工具-限界上下文。
- 能單體就先單體（modular monolith），真的遇到擴展/團隊瓶頸再拆。
📌 這一組有三張卡，分工如下：
本卡＝「有哪些選項、各自的代價」｜工具-架構隨業務規模演進＝「什麼時候該演進」｜工具-服務邊界與演進式拆分＝「切在哪、怎麼切」
★ 四種架構的代價表
| 單體 | 模組化單體 | 微服務 | 無伺服器 | |
|---|---|---|---|---|
| 部署 | 一次全部 | 一次全部 | ★ 獨立 | 獨立 |
| 本地開發 | ★ 跑一個就好 | ★ 跑一個就好 | ⚠️ 要跑一堆或用 mock | 難 |
| 跨模組重構 | ★ 一次 commit，編譯器幫你檢查 | ★ 同左 | ⚠️ 跨服務的改動要協調部署順序 | 同微服務 |
| 除錯 | ★ 一份堆疊追蹤 | ★ 同左 | ⚠️ 需要分散式追蹤 | 更難 |
| 交易 | ★ 本地 ACID | ★ 同左 | ⚠️ 分散式事務（見 工具-分散式事務的取捨） | 同微服務 |
| 獨立擴展 | ❌ | ❌ | ★ 可以 | ★ 自動 |
| 團隊自主 | ❌ | ⚠️ 有限 | ★ 高 | 高 |
| 技術異質 | ❌ | ❌ | ★ 可以（但通常不該） | 可以 |
| 運維複雜度 | ★ 低 | ★ 低 | ⚠️ 高 | 中（換成廠商鎖定） |
★ 最容易被忽略的是第 3、4、5 列：
微服務讓「跨邊界的改動」從「一次 commit」變成「多個 repo、多次部署、要考慮順序與相容性」。
這個成本天天都要付，而「獨立擴展」的好處多數團隊一年用不到幾次。
★ 微服務的前置條件（沒有這些就是自找麻煩）
□ ★ 自動化部署（每個服務都能一鍵、安全地上線與回滾）
□ ★ 集中式日誌 + 分散式追蹤（不然事故時完全瞎）
□ 監控與告警（每個服務都有）
□ ★ 服務發現與設定管理
□ 契約測試或 schema 相容性檢查（見 [[工具-資料編碼與演進]]）
□ ★ 團隊真的能獨立負責一個服務（見 [[工具-康威定律]]）
★ 沒有這六項就拆微服務 = 把「一個難維護的系統」變成「N 個難維護的系統 + 一個難懂的網路」。
→ 這正是「分散式單體」的定義：拆開了，但還是要一起部署。
★ 模組化單體：最被低估的選項
internal/
sales/ ← 邊界清楚，只透過公開介面往來
warehouse/
billing/
cmd/server/ ← 一個二進位檔| 你拿到了 | 你避開了 |
|---|---|
| ★ 模型與團隊的邊界清晰 | ❌ 網路呼叫的延遲與失敗 |
| ★ 編譯期就能驗證邊界（架構測試） | ❌ 分散式事務 |
| ★ 本地交易、本地重構 | ❌ 部署協調 |
| ★ 需要時可以再拆出去 | ❌ 運維成本 |
★ 「先模組化單體，被驗證穩定的邊界才拆出去」是截至 2026-10 業界最主流的建議（判斷，非統計），
而且它讓你用低成本試錯邊界——切錯了只要改個資料夾，不是改一個 repo。
★ 什麼時候真的該拆
| 拆的正當理由 | 不是理由 |
|---|---|
| ★ 團隊互相擋住彼此的部署 | 「微服務比較現代」 |
| ★ 某個部分的資源需求差異極大（ML 推論要 GPU、影片轉檔要 CPU） | 「想試試 Kubernetes」 |
| ★ 不同的可用性/合規要求（金流要更嚴的稽核） | 「檔案太大了」 |
| 不同的發布節奏（一個一天十次、一個一季一次） | 「聽說單體不好」 |
| 需要用不同語言（真的有技術理由） | 「想用 Rust」 |
★ 注意共同點：前四個都是「組織或營運的理由」，不是技術的理由。
★ 無伺服器的真實取捨
| ✅ | ❌ |
|---|---|
| 零運維、自動擴縮、按用量計費 | ★ 冷啟動（延遲敏感的服務不適合） |
| 事件驅動天然契合 | ★ 執行時間上限 |
| 突發流量友善 | ★ 廠商鎖定、本地測試困難 |
| ★ 低流量時極省錢 | ★ 高且穩定的流量時反而比 VM 貴 |
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意 / 什麼時候不適用
- ★★ 不要一開始就微服務。你還不知道邊界在哪，而錯的邊界比單體更難改（跨服務重構極貴）。
- ★ 微服務不會讓程式碼變乾淨。爛的設計拆成十個服務只會變成十份爛設計 + 網路問題。
先把模組邊界理清楚（那在單體裡就能做）。 - ★ 「分散式單體」是最糟的結果：拆開了，但每次發布都要按順序一起部署。
判準：能不能只部署其中一個服務？不能 → 你只是把方法呼叫換成了 HTTP。 - 技術異質是雙面刃。五種語言 = 五套工具鏈、五種監控接法、人員無法流動。
★ 多數團隊應該「刻意限制」技術選擇（見 技術選型收斂）。 - ★ 拆分是難以逆轉的。合併回去比拆開更痛。所以要在「有足夠證據」時才拆。
- 團隊規模是硬限制。少於 15–20 人基本不該考慮微服務——你沒有足夠的人來維運。
🔗 相關工具
- 工具-架構隨業務規模演進 —— ★ 什麼時候該演進（觸發訊號）
- 工具-服務邊界與演進式拆分 —— ★ 切在哪、怎麼切（絞殺者模式）
- 工具-限界上下文 —— 邏輯邊界（拆分的依據）
- 工具-康威定律 —— 組織結構決定可行的架構
- 工具-分散式事務的取捨 —— 拆分後最大的技術代價
- 技術選型收斂 —— 為什麼不該濫用技術異質
- 工具-部署管線與持續交付 —— 前置條件
- 微服務設計