【架構反思】微服務 (Microservices) 其實是包裹糖衣的毒藥？從「分散式交易」的數據不一致災難，看台灣團隊為何該停止盲目拆分 Monolith

在雲原生狂熱的當下，微服務架構被視為數位轉型的萬靈丹。然而，對於絕大多數未達 Netflix 或 Google 規模的團隊而言，這往往是一場忽視計算機科學基礎的工程災難。本文將從 CAP 定理與分散式系統的「物理限制」出發，剖析分散式交易（Distributed Transactions）帶來的數據一致性噩夢，並論證為何在現代硬體效能下，精心設計的模組化單體（Modular Monolith）才是追求優雅、效率與系統正確性的架構師應有的選擇。

摘要 (The Abstract)

軟體工程界近年來陷入了一種對微服務（Microservices）的集體狂熱。這種架構模式承諾了解耦、獨立部署與無限的可擴展性。然而，身為一名長期研究分散式系統的架構師，我必須指出國王的新衣：對於 99% 的企業——尤其是大多數台灣的中型技術團隊而言，盲目地將單體應用（Monolith）拆分為微服務，無異於吞食包裹著糖衣的毒藥。這不是解決技術債，而是將原本記憶體內（In-Memory）的函數呼叫，轉換為不可靠網路上的遠端程序呼叫（RPC），引入了指數級的複雜度與延遲，最終在分散式交易的泥沼中窒息。

深入剖析 (Deep Dive)：當 ACID 遇上網路分區

要理解這場災難的根源，我們必須回歸第一原理（First Principles）。在單體架構中，我們依賴資料庫的 ACID（原子性、一致性、隔離性、持久性）特性來確保業務邏輯的正確性。當你執行一個轉帳操作，扣款與存款發生在同一個交易（Transaction）中；若中途失敗，資料庫會自動回滾（Rollback），世界依然美好。

然而，當你將系統拆分為「訂單服務」、「庫存服務」與「支付服務」時，你就不再擁有一個全域的資料庫交易。你面對的是跨越多個資料庫節點的分散式交易。根據 CAP 定理，在網路分區（Partition Tolerance）不可避免的情況下，我們必須在強一致性（Consistency）與可用性（Availability）之間做出抉擇。

大多數微服務架構選擇了「最終一致性（Eventual Consistency）」，這是一個在學術上優雅但在實務上極其痛苦的概念。為了處理跨服務的交易，工程師被迫引入 Saga 模式或兩階段提交（2PC）。試想一下，當「支付服務」扣款成功，但「庫存服務」卻因為網路抖動或邏輯錯誤而失敗時，你該怎麼辦？你必須編寫複雜的補償交易（Compensating Transaction）來「退款」。這不僅大幅增加了程式碼的複雜度，更引入了許多難以除錯的邊緣案例（Edge Cases）。這不再是業務邏輯的挑戰，而是分散式系統共識演算法的挑戰。

效能迷思與硬體現實 (Hardware Reality)

另一個常被忽略的是硬體層面的現實。現代 CPU 的 L1/L2 快取存取速度是以奈秒（ns）計，記憶體存取是以數十奈秒計。然而，即便是在同一個資料中心內，一次網路請求的往返時間（RTT）也是以毫秒（ms）計。

當我們把一個單體內的函數呼叫（Function Call）變成微服務間的 HTTP/gRPC 呼叫時，我們是在主動引入數個數量級的延遲（Latency）。此外，還有序列化與反序列化（Serialization/Deserialization）的 CPU 開銷。

許多團隊宣稱需要微服務是為了「擴展性（Scalability）」。這往往是過早優化。現代單台伺服器可以配備 128 核心 CPU 與 TB 級別的 RAM。對於絕大多數台灣企業的用戶規模，一台經過優化的單體伺服器（Vertical Scaling）足以應付所有的流量，且其運維成本遠低於管理一個龐大的 Kubernetes 叢集。我們不該忘記，Stack Overflow 在很長一段時間內都是運行在少數幾台巨大的 SQL Server 上。

批判與反思 (Critique)：簡約的優雅

台灣的技術團隊往往面臨資源有限的挑戰，卻常受到矽谷巨頭架構的影響，患上了「履歷驅動開發（Resume Driven Development）」的症狀。我們必須認清，Netflix 需要微服務是因為他們有數千名工程師同時修改程式碼，且需服務全球數億用戶。如果你的團隊只有 20 人，你的日活躍用戶（DAU）只有幾萬，採用微服務只是在自我設限。

真正的架構素養並非在於使用了多少新穎的框架，而在於對系統邊界的精準把控。模組化單體（Modular Monolith）——即在單一部署單元內保持清晰的模組邊界與嚴格的依賴規則——才是大多數場景下的最佳解。它保留了重構的靈活性、除錯的便利性以及資料的一致性，同時避免了分散式系統的固有缺陷。

架構的終極目標是解決問題，而非製造問題。停止盲目的拆分，回歸代碼的品質與結構本身，這才是工程師應有的修養。

🛠️ CULTIVATE Recommended Tools | 精選工具推薦

Interactive Brokers: Low cost professional trading platform for global markets.
Poe: Access all top AI models (GPT-4, Claude 3, Gemini) in one place.