Monolith 與 Microservice 的責任差異

Monolith 用「同一個程式碼庫、同一個部署單位、同一個資料庫」換取低協作成本與簡單事務語意。Microservice 用「獨立程式碼庫、獨立部署、獨立資料邊界」換取團隊獨立性、技術選型彈性與局部故障隔離。

讀者要從這張表反推自己的真實壓力來源。如果痛點是「部署互相卡住、發布頻率被別人拖慢」，拆分能解決；如果痛點是「程式碼太亂、新人看不懂」，拆服務只會把亂的範圍擴大成跨服務契約混亂。

這張表是兩端對比、實際系統常落在中間。常見折衷形態：

• Modular monolith（單一部署 + 模組化邊界）：保留 monolith 的部署簡單、用模組邊界防止程式碼互相穿透。Shopify、Basecamp、Stack Overflow 是大規模長期維持的代表 — monolith 不是進化中段、是 valid endgame。
• Macro-services（少量大服務、5-15 個）：避免 microservice 的極端碎片化、保留拆分帶來的部署獨立性。是多數中型團隊的實際終點、不是過渡形態。
• Cell-based architecture（多 cell 各自獨立、跨 cell 共用標準介面）：AWS、Slack、DoorDash 用來控制 blast radius — 把整個系統複製成多個 isolated cell、每個 cell 內可以是 monolith 或 microservice。

拆分不是進化方向、是壓力應對工具。維持 monolith 在某些情境（極小團隊、PMF 前期、無 DevOps 能力）是更負責任的選擇。

拆分軸的判讀

服務邊界不只一條軸。常見的四條軸對應不同的壓力來源，正確的拆法是「壓力在哪裡、就沿那條軸拆」，不是同時動四條軸。

資料邊界

當兩塊業務的資料生命週期不同、一致性需求不同、查詢模式不同時，資料邊界已經形成。例如訂單資料需要強一致性與長期保留，瀏覽紀錄可以最終一致性、定期清理。把這兩類資料放同一個 schema 會讓 backup、migration、index 策略互相干擾。

判讀訊號：同一張表上不同欄位的 read/write QPS 差三個數量級、同一個 transaction 同時寫入多種業務概念、schema migration 一動就要鎖住整個業務的寫入。

團隊邊界

當兩塊業務由不同團隊維護、發布節奏不同、技術棧偏好不同時，團隊邊界已經形成。Conway’s Law 反過來操作：用服務邊界保護團隊邊界，避免一隊改動觸發另一隊重 review。

判讀訊號：PR review 跨團隊比例過半、發版需要協調多個團隊、技術升級（語言版本、framework 升級）因為其他團隊未準備好而被擋住。

部署邊界

當部分功能需要獨立的部署節奏、獨立的擴展策略、獨立的可用性等級時，部署邊界已經形成。背景批次工作要按小時排程、API 服務要 7×24 線上、報表服務只在工作日運行，三者放同一個部署單位會讓最嚴格的可用性要求拖累其他。

判讀訊號：高峰時某個功能擴展速度跟不上、低峰時某個功能浪費資源、單一發版策略覆蓋不了所有功能的風險等級。

流量邊界

當不同功能的流量形狀、失敗代價、SLO 等級不同時，流量邊界已經形成。付款 API 一秒 100 個請求、商品搜尋一秒 10000 個請求、後台報表一天 100 個請求，三者放同一個服務會讓彼此爭資源，付款被搜尋擠掉是業務災難。

判讀訊號：高頻 endpoint 壓爆低頻 endpoint 共用的連線池、不同 endpoint 的 latency 分布同時惡化、無法針對核心交易設定獨立的 SLO 跟 alert。

其他常見拆分軸

上面四條是技術驅動的主要拆分軸。實務上還有其他軸常成為真實驅動力、要一併納入判讀：

• 失敗代價 / blast radius 軸：核心交易（掛了會有業務災難）跟邊緣推薦（掛了沒人在意）的可用性等級差距大、適合拆開降低 blast radius。跟 SLO 軸高相關但不同 — 重點在「失敗時誰受影響」的範圍隔離。
• 變更頻率 / 風險軸：high-velocity 實驗功能跟 stable 核心應拆開、降低實驗對核心穩定性的牽連。跟團隊軸高相關但獨立 — 同一團隊也可能維持兩種變更頻率的程式碼。
• 資料敏感度 / 合規邊界：PCI / PII / 醫療資料的隔離常是合規硬要求（GDPR data residency 強制資料拆境），不是技術選擇。這類軸跟資料邊界相關但服從不同壓力。
• 組織非技術約束：併購整合、外部合規節奏、團隊 reorg、預算切分都會強制拆分 — 比 metric 訊號更早觸發、技術上不一定最佳但無法繞過。

這些軸跟前四條可以同時生效、也可能彼此衝突（合規逼資料拆境、但流量軸建議聚合）。處理衝突時優先順序通常是「合規 > 失敗代價 > 部署 / 流量 > 團隊 > 資料 > 變更頻率」、但每個組織會有自己的權重。

拆分時機的判讀

拆分時機不能等到「已經痛到動不了」才開始，那時候拆分要付的代價最高。也不能在「還沒長出邊界」時提早拆，那會用 microservice 的協調成本懲罰一個還沒到規模的系統。

提早訊號（可以開始準備但不一定立刻動手）：

• 程式碼裡同一份邏輯被三個 PR 同時修改、merge conflict 增加
• 同一個 service 的不同功能開始有不同的擴展需求
• 不同團隊對同一個發版視窗的需求開始衝突

該動手訊號（再拖就要付高昂代價）：

• 任何一個功能改動需要 freeze 整個服務發版
• 局部高峰擴展時整個服務一起擴展，成本翻倍
• 一個團隊的事故會直接影響另一個團隊的營運指標
• 跨團隊 deadlock：A 等 B 改完才能上、B 等 A 改完才能上

過晚訊號（拆分要付遷移代價）：

• 已經出現過跨團隊事故、且復盤結論是「無法分離責任」
• DB 連線池在多個業務間爭搶、無法用 connection pool 隔離解決
• 部署平台跑不動：CI 太慢、build 太大、本地開發無法啟動完整環境

拆分代價與回退路徑

拆分不是免費操作。每多一個服務，就多一份運維成本、跨服務 trace 成本、契約治理成本。讀者要在拆分前認知這些代價，而不是事後才發現。

拆分失敗的回退路徑要在拆分前設計好。常見回退策略：保留原 monolith 程式碼一段時間（雙寫期），新服務出問題可以切回；先拆讀路徑驗證流量，再拆寫路徑；用 feature flag 控制是否走新服務。沒有回退路徑的拆分一旦撞牆，會比不拆更難收拾。

拆分後的通訊優先級：事件 > 同步 RPC

拆完後跨服務通訊有兩條路：同步 RPC（gRPC、REST）跟異步事件（message queue、event bus）。預設應該選事件、保留 RPC 給「真的需要同步回應的查詢」。

理由：

• 失敗代價隔離：服務 A 發事件給 B、B 掛了不影響 A — 事件留在 queue 等。同步 RPC 下、B 掛了 A 也跟著掛
• 流量解耦：事件本身就是 buffer、能吸收 burst。同步 RPC 是 throughput 的硬上限、A 的尖峰 = B 的尖峰
• 可重放：事件可以重放（replay）做資料修補、debug、新服務 backfill。同步 RPC 過了就過了
• 服務獨立演進：事件 schema 可以加欄位向下相容、consumer 慢慢 adapt。RPC interface 改動是 breaking change

該用同步 RPC 的少數場景：使用者請求路徑需要立即回應（「使用者按下查詢、顯示結果」）、且兩個服務都在同一個 latency budget 內。其他都優先事件。

詳見 03 模組訊息佇列 跟 0.3 非同步與事件傳遞選型。

反例：拆分過度的收回

服務拆分的反向動作是合併。當拆分後發現「服務間呼叫太頻繁、近乎同步、跨服務事務太多」時，代表這條邊界拆錯了。處理方式是把這兩個服務合回去，繼續增加跨服務工具只會堆疊複雜度。

判讀「該合併」的訊號：服務 A 與 B 之間每秒幾百次同步呼叫且失敗會連鎖、A 改動必定觸發 B 改動且兩者由同一團隊維護、跨服務事務佔總業務動作比例過高、跨服務 latency 是 SLO 主要消耗者。

合併不是失敗。它代表團隊已經理解這條邊界不該存在，及時收回比硬撐更負責任。Modular monolith（單一部署、模組化邊界）是常見的折衷形態：保留模組邊界、避免分散事務代價、未來壓力出現時再分拆。

判讀訊號

常見誤區

把「technical debt」當成拆分理由。Monolith 程式碼髒亂的解法是重構，不是拆服務。拆服務只是把髒亂從單庫變成跨服務契約混亂，問題並沒有消失。

把「跟風 microservice」當成決策。沒有業務壓力、團隊規模不到位、運維能力不夠的情況下拆服務，新的協作成本會壓垮整個團隊，這比 monolith 的痛苦更大。

把拆分當成單向操作。沒有設計回退路徑、沒有保留合併選項，拆錯了就只能硬撐。成熟的服務演進策略要把「拆」跟「合」當成雙向可逆操作。

定位邊界

本章專注「該不該拆、沿哪條軸拆、拆完怎麼收尾」。當問題進入具體拆分後的部署、流量、觀測責任，分別交給以下模組：

• 服務獨立部署 → 05 deployment platform
• 跨服務交接與事件 → 03 message queue
• 跨服務觀測與 trace → 04 observability
• 跨服務一致性與冪等性 → 03 idempotency-replay + outbox pattern

案例回寫

服務拆分判讀可用以下案例回寫：

• 9.C23 Netflix：把關聯式 DB 統一到 Aurora、效能 +75%、成本 -28% — 反例方向：原本各 microservice 各自 DB 造成運維碎片化、最後做 consolidation；對照本章「拆分過度的收回」段。
• 5.C2 Condé Nast：EKS 平台整併與標準化 — Condé Nast 把多 brand 各自的 K8s cluster 整併到統一 EKS 控制面、降低跨團隊運維分歧。對照本章「拆分代價 / 運維複雜度」段：拆出去快、合回來慢、設計時就要評估這種非對稱性。
• 9.C12 Riot Games：246 個 EKS cluster 的多遊戲多地區治理 — Riot 的拆分軸是「遊戲 × 地區 × 環境」三維交集、246 個 cluster 是這三軸的笛卡兒積取一個 subset。對照本章「拆分軸 / 部署邊界」段：實務上的拆分常常是多軸交集、不是單軸推進。

Netflix Aurora consolidation 是反例最有教學價值的一筆 — 它證明「拆 microservice 各自 DB → consolidation 回 Aurora」是 valid endgame、拆服務不是單向操作。Condé Nast 跟 Riot Games 補充另兩條維度：碎片化的運維代價、多軸交集的設計複雜度。把這三筆放回「拆分時機判讀」框架的不同節點上、能看出拆分決策的本質是「沿哪幾條軸 + 接受哪些代價」的組合。

跨模組路由

1. 與 0.1 後端服務能力地圖 的交接：拆分前要先理解每塊責任屬於哪種能力分類，避免拆出語意混亂的服務。
2. 與 0.5 流量與資料量評估 的交接：流量軸拆分要先有流量基線。
3. 與 03 message queue 的交接：拆分後跨服務通訊優先用事件、不是同步 RPC。
4. 與 9.13 擴展軸 的交接：拆分常常是水平擴展的前提（無狀態服務拆分後才能獨立水平擴展）。

下一步路由

規模成長路線下一站 → 9.13 擴展軸與 Stateless 前提：拆分後接著要為每個服務選擇擴展軸。

其他延伸方向：

• 實作層：服務如何獨立部署 → 5.2 Kubernetes 部署策略
• 事件層：拆分後跨服務通訊設計 → 03 模組訊息佇列

Strangler Fig Pattern 的工程含義

Strangler Fig（絞殺榕）是 Martin Fowler 對漸進拆分的命名比喻：榕樹依附在宿主樹上、慢慢長大、最終取代宿主。應用到服務拆分：

• 舊系統繼續運作：拆分過程中、monolith 仍是 source of truth、新服務從旁長出
• 流量逐步遷移：用 routing layer（API gateway、proxy、feature flag）控制哪些 request 走新服務、哪些走舊
• 驗證 → 擴大：每個遷移的功能先小流量驗證、確認新舊一致後再加流量比例
• 舊系統最終下架：當所有功能都遷出後、monolith 才被退役

Strangler Fig 跟 big bang 拆分的本質差異是「失敗代價可控」— 大爆炸拆分失敗就整個服務掛、Strangler 拆分失敗只影響該功能、且可即時切回 monolith。

拆分執行階段

把 Strangler 細化成可操作的四階段：

階段 1：邊界冷凍 + Adapter 抽出

動手拆之前、先在 monolith 內部把「將要拆出去」的功能用 adapter / interface 封起來。所有外部呼叫該功能都走 adapter、不直接呼叫實作。

這層動作的責任：

• 強制 dependency 清楚：哪些功能依賴它、哪些功能被它依賴、必須變成顯式 interface 而非分散在 codebase
• 資料邊界明示：該功能用到哪些 table / column、用 repository / DAO 封裝、不讓其他功能直接 access
• 變更頻率冷凍：拆分期間原則上不接受該功能的新需求、避免「拆到一半新需求又進來」

階段 1 在 monolith 內完成、不動部署、不動資料。完成後、拆分的「邊界」已經在 codebase 顯現、是 prerequisite。

階段 2：新服務 + 雙寫期

新服務 spin up、實作 adapter 同樣的介面。寫入路徑進入「雙寫期」：所有寫入同時寫 monolith 跟新服務、讀取仍從 monolith 取。

雙寫期的設計關鍵：

• 寫入順序：先寫 monolith 還是先寫新服務？通常先寫 monolith（保持 source of truth 一致性）、新服務寫失敗時記 error 但不影響業務
• 跨服務一致性：兩邊寫入用 outbox pattern 或 saga 保證最終一致、不能容忍長期不一致
• 資料對賬機制：每天 / 每小時跑對賬 job、找出兩邊不一致的 row、修正 + 統計差異率
• 雙寫期長度：通常 1-4 週、視差異率收斂速度決定。差異率穩定在 0.01% 以下、可進階段 3

雙寫期的失敗訊號：差異率持續高於 1%、代表資料模型對應有 gap、不該進切流階段。

階段 3：切流（讀路徑遷移）

雙寫期穩定後、讀路徑開始從 monolith 切到新服務。切流策略選擇：

• 按 user / tenant ID hash 分流：取 user_id mod 100、x% 走新服務、其餘走 monolith。漸進 ramp up（1% → 5% → 25% → 100%）
• 按 endpoint 分流：read endpoint A 全切、endpoint B 跟 C 還在 monolith。適合「不同 endpoint 風險不同」的場景
• Dark launch：每個 request 同時打兩邊、用 monolith 結果回應、log 兩邊差異。是 shadow read、不是真實切流、但能在切流前找出 edge case

切流期間的觀測重點：

• 錯誤率對比：新服務 vs monolith 同 endpoint 的 5xx / 4xx 比例
• 延遲分布對比：P50 / P95 / P99 latency
• 業務指標對比：轉換率、跳出率、訂單成功率 — 確認沒有「技術指標看起來正常、業務指標掉」的隱形 regression

任一指標惡化、切回 monolith、不繼續推進。

階段 4：寫路徑遷移 + Monolith 退役

讀路徑 100% 切完、且穩定觀察一段時間後（建議至少 2 週）、寫路徑才從「雙寫」變成「只寫新服務」。

寫路徑切換的步驟：

1. 雙寫變成「新服務 + 異步 backfill 到 monolith」：以新服務為主、monolith 變成 standby
2. 觀察期 1-2 週：確認新服務寫入路徑穩定、無資料遺失或不一致
3. 停止 backfill：monolith 不再被寫入、變成 read-only
4. Monolith 該功能下架：等確認所有 dependency 都已遷移後（通常還要再 1-4 週觀察）、刪掉 monolith 對應 code 跟 table

階段 4 是 point of no return — 過了寫路徑切換、回 monolith 的成本變得很高（要把新服務累積的寫入 backfill 回去）。這個 checkpoint 必須有明確的 go/no-go 決策、不是「順勢推進」。

回退路徑設計

回退條件必須在拆分啟動前就定義、不是事故時臨時決策。常見回退路徑：

階段 4 之後的回退代價是指數成長的。設計時要把 monolith 下架時點延後到「確信不需要回退」、寧可多保留 monolith 1-2 個月。

拆分執行的判讀訊號

常見誤區

把拆分當成「直接把功能搬出去」、跳過階段 1 adapter 抽出。沒有 adapter 抽出、新服務跟 monolith 的 dependency 邊界不清楚、雙寫期會出現難以排查的隱式依賴問題。

把雙寫期當成「過渡而已、隨便寫」。雙寫期是拆分的 source of truth verification 階段、差異率沒收斂前不能進切流。隨便寫的結果是切流後出資料一致性事故。

把「monolith 下架」當成拆分成功訊號。Monolith 下架太早是常見事故來源 — 即使流量 100% 切完、可能仍有 batch job / report / 內部 tool 在用 monolith。下架前先用 access log audit 確認真實流量為 0。

定位邊界

本章專注「Strangler Fig 漸進拆分的執行流程」。當問題進入「該不該拆」的判讀、回 10.1 服務拆分與邊界判讀；進入跨服務通訊設計（同步 vs 異步、event-driven）、進 03 message queue；進入部署層的切流機制（feature flag、canary、blue/green）、進 5.8 deployment rollout；進入資料庫遷移層的具體技術（dual write、shadow read、cutover），進 1.6 資料庫轉換實作。

案例回寫

09 / 05 案例庫中、Strangler 拆分案例不算多（多數案例是已拆完的狀態描述、而非拆分過程紀錄）。可用以下案例反向追問：

• 9.C23 Netflix Aurora consolidation — Netflix 的故事是「拆完合回去」、隱含 strangler 反向。對照本章可問：合併過程是否也走了類似四階段、只是方向相反（雙寫期把多 DB 合到 Aurora、再切讀路徑、最後下架原 DB）？
• 5.C2 Condé Nast：EKS 平台整併 — 平台層整併。本章在「服務層」、整併在「平台層」、邏輯類似但 surface 不同。

跨模組路由

1. 與 10.1 服務拆分判讀 的交接：10.1 給「該拆」的判讀、本章給「怎麼拆」的執行。
2. 與 03 message queue + outbox 的交接：雙寫期跟拆分後跨服務通訊都依賴 outbox / saga 保證一致性。
3. 與 5.8 deployment rollout 的交接：階段 3 切流的技術機制（feature flag、canary）跟部署層的 rollout 同源。
4. 與 1.6 資料庫轉換實作 的交接：階段 2 雙寫期跟資料庫遷移的雙寫期是同一套機制、只是 surface 不同。

下一步路由

要看拆分判讀（該不該拆）、回 10.1 服務拆分與邊界判讀。要看拆分後跨服務通訊設計、進 03 模組訊息佇列。要看部署層的切流技術細節、進 5.8 Deployment Rollout。