2026 年微服務架構轉型：從 Microservices 到 Modular Monolith 的思考
1.3 當摩爾定律不再拯救複雜度
過去的架構辯論中，隱含著一個樂觀假設：硬體會越來越便宜，雲端會越來越無感。但 2023 年之後的現實是，雲端成本成為許多公司的前三大支出項目之一，而且成長速度遠超營收。當一個 40 個微服務的系統，光是閒置的容器編排負載與跨區網路流量就佔掉三成的雲端帳單，FinOps 團隊自然會開始問一個尖銳的問題：這些服務真的都需要獨立存在嗎？
與此同時，人才結構也變了。能夠同時掌握分散式追蹤、服務網格、Kubernetes 維運、事件驅動設計的資深工程師，始終是稀缺資源。當架構的複雜度超過團隊的承載能力，系統就會進入一種「沒人敢改」的僵化狀態，這比單體架構的技術債更難償還。
二、Modular Monolith 不是回到過去，而是螺旋上升
很多人第一次聽到「模組化單體」時，第一反應是：「這不就是十年前的三層式架構嗎？」這個反應可以理解，但並不完全正確。模組化單體與傳統單體的差異，恰恰在於它把微服務時代學到的紀律，內化到了單一部署單元之中。
2.1 定義與核心特徵
模組化單體（Modular Monolith）可以定義為：以單一部署單元運行，但在內部嚴格劃分模組邊界，模組之間只能透過明確定義的公開介面溝通，且每個模組擁有自己的資料所有權。
它的關鍵特徵包括：
單一部署單元：一次建置、一次部署、一個行程。維運面積回到最小。
換句話說，模組化單體是一個「保留未來選擇權」的架構。它把分散式系統的複雜度延後到真正需要的那一刻，而不是提前支付。
2.2 三種架構型態的差異矩陣
為了讓差異更清楚，我們可以用幾個維度來對照傳統單體、模組化單體與微服務：
比較維度
傳統單體
模組化單體
微服務
部署單元
模組邊界強制力
無（靠自律）
建置期／語言層強制
網路邊界強制
跨模組呼叫成本
無感
極低（程序內）
高（網路＋序列化）
資料一致性
單一交易
單一交易（模組內）
最終一致性為主
獨立擴展能力
有限（可先做行程內資源隔離）
完整
本地開發體驗
適合團隊規模
1～10 人
5～100 人
50 人以上且需獨立節奏
這張表最重要的訊息是：模組化單體並不是「比較差的微服務」，而是在一個更小的複雜度預算下，取得接近的模組化收益。它把微服務最珍貴的那部分——邊界紀律——保留了下來，同時丟掉了最昂貴的那部分——分散式治理。
2.3 模組邊界怎麼切？三個實務原則
模組化單體失敗的最常見原因，是「切錯了邊界」。如果模組切得跟資料表一樣細碎，你會得到一個「單體裡的分散式系統」，只是換了個地方痛苦。以下三個原則在實務中最有幫助：
第一，以業務能力而非技術層次切分。「訂單模組」、「庫存模組」、「帳務模組」是對的；「Controller 層」、「Service 層」、「DAO 層」是錯的。後者會讓每一個業務變更都必須橫跨所有模組，等於沒有邊界。
第二，讓資料庫層也反映模組邊界。這是最常被忽略的一點。如果訂單模組可以直接 SELECT 庫存模組的表，那麼模組邊界就只是裝飾。實務上可以透過獨立的 Schema、獨立的資料庫帳號權限，或在程式碼層用 Repository 強制隔離來達成。
第三，接受「不完美的邊界」並保留重構空間。領域邊界不是一次畫對的，它會隨著業務理解而演化。模組化單體的好處之一，正是重構成本遠低於微服務——把兩個模組合併，可能只是移動幾個套件，而不是一場跨團隊的服務退役專案。
三、2026 年的技術推力：為什麼現在是轉折點
架構趨勢不會無緣無故轉向。這一波「從微服務到模組化單體」的移動，背後有幾個明確的技術與經濟推力。
3.1 AI 輔助開發改變了「程式碼庫規模」的意義
在 2020 年代初期，反對大型單體的主要理由之一是「人腦無法理解」。一個百萬行的程式碼庫，新人要花幾個月才能上手，資深工程師也只能記住自己熟悉的那一小塊。
但 2024 年之後，AI 程式碼助手的能力已經從「補全下一行」進展到「理解跨檔案呼叫鏈並提出重構建議」。這帶來一個微妙的變化：程式碼庫的「可理解性」不再完全依賴人類的記憶容量，而是部分外包給了工具。當一個 AI 代理可以在數秒內回答「這個欄位被哪些模組使用」、「變更這個介面會影響哪些呼叫點」，單體架構最大的劣勢就被大幅削弱了。
與此同時，AI 代理在面對分散式系統時仍然力不從心。它可以看到程式碼，卻看不到網路逾時、服務網格的實際路由、跨服務的執行時序。這使得「把所有邏輯收斂在一個可被完整靜態分析的倉庫中」變成了一種對 AI 友善的架構選擇。
3.2 雲端成本與碳排治理的雙重壓力
2026 年的企業雲端治理，已經不只是財務問題。許多地區開始要求一定規模以上的企業揭露資訊系統的能耗與碳排，而微服務架構在這一項上天然吃虧：每個服務都有自己的最低資源佔用、自己的健康檢查流量、自己的跨區複本。當你把 40 個服務收斂成 6 個模組，基礎設施的閒置成本往往能下降三到五成。
這不是要否定微服務的擴展價值，而是要提醒：擴展性是可選的，成本是必然的。對大多數沒有極端流量峰值的系統而言，垂直擴展加上少量水平複本，已經足以應付絕大多數場景。
3.3 平台工程的成熟，讓「模組化」不再需要自建
過去要實現嚴格的模組邊界，團隊往往得自己寫一堆腳本或依賴靜態分析工具。現在，主流程式語言與生態都提供了成熟的方案：Java 的 JPMS 與 Spring Modulith、.NET 的內部可見性與解決方案過濾、Kotlin 的 internal 修飾詞、TypeScript 的專案參考與套件邊界、Rust 的 crate 邊界等。搭配 ArchUnit 這類架構測試工具，模組違規可以在 CI 階段就被擋下。
換句話說，2026 年的模組化單體，是一個「有工具支撐的架構」，而不是靠團隊文化維持的理想。這是它與十年前單體架構最本質的差別。
3.4 法規、資料主權與部署複雜度的交互作用
另一個常被忽略的推力來自合規。當資料必須留在特定區域、稽核軌跡必須完整可追溯時，分散式架構的資料流會變得極難說明。相較之下，單一部署單元搭配模組化的資料邊界，更容易向稽核人員解釋「這筆資料從哪裡來、經過哪些處理、存在哪裡」。
四、轉型路線圖：如何從微服務收斂回模組化單體
如果你的團隊已經身處微服務架構，並且開始思考收斂，那麼最危險的做法是「大爆炸式重寫」。以下是一條在實務中相對可行的路線。
4.1 第一步：診斷，而不是先動手
在收斂之前，先回答幾個問題：
有多少服務之間是同步呼叫鏈超過三層的？這類鏈路通常是最脆弱、最難除錯的部分。
有多少服務共用同一份資料，卻又各自維護快取或複本？這是資料一致性問題的主要來源。
團隊規模是否小於 50 人？如果是，微服務的組織收益通常不足以抵銷其成本。
如果前三題的答案都指向「服務切得比實際需求細」，那麼收斂的投資報酬率通常很高。
4.2 第二步：模組化優先，先合併程序，再談重構
收斂的核心策略是「先合併部署單元，暫不動程式邏輯」。具體做法是：把多個服務的程式碼放進同一個倉庫與同一個建置產物，但保留原有的套件結構與介面，只是把網路呼叫換成程序內呼叫。
這個階段最重要的是建立「模組邊界檢查」機制。例如用 ArchUnit 寫測試，規定「訂單模組不得直接引用庫存模組的內部類別」，只能引用其公開的 API 介面。這樣一來，雖然執行時是同一個行程，但架構約束依然存在。
4.3 第三步：資料庫的收斂策略
資料是收斂過程中最棘手的部分。常見的做法是「Schema per Module」：所有模組共用一個資料庫實例，但每個模組擁有獨立的 Schema 與獨立的連線帳號。應用層的資料存取必須經過該模組的 Repository，跨模組的資料需求則透過公開介面或事件處理。
如果原本是 Database per Service，可以先做「邏輯合併」——把多個資料庫掛在同一個實例下，減少連線與維運數量，但保留 Schema 隔離。等到時機成熟，再處理資料表層級的整合。
需要特別注意的是交易邊界。合併之後，許多原本必須用 Saga 處理的流程，可以簡化回單一本地交易。這往往是收斂後最直接、最有感的品質提升。
4.4 第四步：觀測性、測試與部署的重新設計
合併之後，分散式追蹤的需求會大幅下降，但日誌與指標的「模組維度」變得重要。建議在日誌中標記模組名稱，並在指標上保留模組層級的標籤，以便未來若某個模組需要獨立抽離時，能夠快速取得效能基線。
測試策略上，整合測試會變得容易許多，因為不再需要啟動整套服務。但也要小心「測試依賴全系統啟動」的退化，仍然應該以模組為單位撰寫測試。
部署方面，最大變化是「全有全無」的發布風險。為了降低風險，可以採用功能旗標（Feature Flag）與漸進式發布，讓某個模組的新功能只對部分使用者開放，而不需要為此拆出獨立服務。
五、實務案例與反模式
5.1 案例：從 42 個服務收斂到 6 個模組
設想一個中型電商平台的真實情境（細節經過抽象化）。該平台在 2021 年完成微服務化，共有 42 個服務，涵蓋商品、搜尋、購物車、訂單、支付、庫存、通知、會員、優惠券等。團隊規模約 35 人，分成 6 個小組。
三年後的痛點非常典型：本地開發需要啟動 18 個服務才能完成一個下單流程；一次跨服務的欄位變更平均需要 9 天才能上線；每月雲端帳單中有 31% 來自閒置與低利用率的服務執行個體；線上事故的根因分析平均需要 4.5 小時。
收斂計畫分三階段執行。第一階段花兩個月，把 42 個服務依照領域邊界合併為 12 個部署單元，同時導入架構測試。第二階段再花三個月，收斂到 6 個模組，並把資料庫從 42 個實例整合為 1 個實例、6 個 Schema。第三階段花兩個月，處理測試、CI/CD 與觀測性的調整。
結果是：本地開發啟動時間從 12 分鐘降到 40 秒；平均功能上線時間從 9 天降到 2.5 天；雲端成本下降約 44%；事故根因分析時間縮短到 1 小時以內。而唯一的犧牲，是失去了「每個服務獨立選擇技術棧」的自由——但這個自由在過去三年內，實際上只被使用過一次。
5.2 反模式：把單體寫成「分散式單體」
收斂過程中最常見的失敗，是形式合併但實質未變。症狀包括：模組之間仍然頻繁互相呼叫，形成複雜的循環依賴；所有模組共用同一組資料表；沒有任何自動化的邊界檢查，全靠資深工程師提醒。
這種架構被戲稱為「分散式單體」（Distributed Monolith），只是把複雜度從網路搬回了程式碼，卻沒有得到模組化的好處。避免的方式很簡單也很困難：把邊界檢查寫進 CI，讓違規無法被合併。
5.3 什麼情況下你仍然需要微服務
必須強調，這篇文章並不是主張「微服務已死」。以下幾種情況，微服務仍然是更合理的選擇：
不同元件的負載特性差異極大，例如影像轉碼需要 GPU 密集運算，而會員查詢是輕量 I/O。
不同團隊必須採用完全不同的技術棧，且整合成本高於維護成本。
組織規模超過百人，且團隊之間存在明確的交付節奏差異。
合規要求強制隔離某些資料處理流程，需要獨立的部署與網路邊界。
需要針對單一功能進行極細緻的獨立擴展，且流量規模足以證明其必要性。
關鍵在於，這些條件應該是觀測到的事實，而不是架構設計階段的猜測。
六、2026 之後：架構的第三條路
6.1 模組化單體加上選擇性服務化
未來幾年最可能成為主流的，不是二選一，而是一種混合形態：以模組化單體作為預設架構，只有在明確的效能、規模或合規需求出現時，才把特定模組抽離為獨立服務。這種「選擇性服務化」的關鍵，是模組邊界必須先存在——因為只有邊界清晰，抽離才不會變成災難。
換句話說，模組化單體不只是終點，它也是微服務的前置準備。一個設計良好的模組化單體，隨時可以演化為微服務；而一個設計不良的微服務系統，卻很難優雅地收斂回來。
6.2 與 Serverless、WASM 與邊緣運算的組合
另一個值得觀察的方向，是模組化單體與新執行環境的結合。WebAssembly 元件模型（Component Model）在 2025 年後逐漸成熟，讓「同一個模組可以在不同宿主環境中執行」變得可行。這意味著未來的模組邊界可能不只是程式碼層的約束，而是可部署的邊界——同一個模組既能以程序內函式呼叫的方式運行，也能被編譯為 WASM 元件部署到邊緣節點。
這會讓「單體或微服務」這個二分法逐漸失效，架構決策會從「部署形態」轉向「模組介面與資料契約的設計」。而這正是模組化單體思維最有價值的地方。
七、給工程團隊的實務建議與檢核清單
如果你正在考慮啟動這類轉型，以下檢核清單可以幫助你避免最常見的陷阱：
保留模組的資料所有權。跨模組直接查表是模組化單體最致命的自殺行為。
定期重新評估。每年檢視一次服務化的觸發條件是否出現，避免架構僵化。
結語：架構的成熟，是學會選擇複雜度的位置
從 Microservices 到 Modular Monolith，這條路徑看起來像是往回走，但實際上是一次認知的升級。微服務時代教會我們最重要的一課，不是「服務越小越好」，而是「邊界要清晰、職責要單一、資料要有主人」。這些原則在單體架構裡同樣適用，只是過去我們沒有工具去強制執行，也沒有意識到它的價值。
2026 年的架構討論，正在從「要不要拆」轉向「複雜度該放在哪裡」。分散式系統的複雜度是一種昂貴的資源，應該被用在真正需要它的地方——極端的擴展需求、明確的組織邊界、不可迴避的合規要求。對於其他 90% 的場景，模組化單體提供了一個更務實的答案：用最小的維運面積，換取最大化的模組化紀律。
架構沒有終點，只有當下的最適解。而真正成熟的團隊，不是追逐最新的架構名詞，而是清楚知道自己的系統為什麼長成現在這個樣子，以及什麼時候該讓它改變。