自包含系統：解決微服務亂象的新思路
人們喜歡嘲笑 JavaScript 框架的複雜性，但坦白說，後端架構也好不到哪裡去。過去 15 年來，單體架構和微服務架構之間一直反覆搖擺。我們都至少知道一個專案，其後端過度設計，以至於為 50 個甚至還沒付費的客戶部署一個基本應用程式，感覺就像發射太空梭一樣。但或許有更好的方法，那就是自包含系統 (Self-Contained System, SCS)。與現今流行的架構術語不同，這種架構可能真正解決你的問題。
微服務的困境
微服務本應將我們從單體地獄中拯救出來，但實際上卻帶來了分散式地獄，以及無數複雜的架構圖。這個概念在紙上聽起來很棒：不再是單一緩慢的單體應用程式，而是將系統拆分為獨立的微小服務，這些服務可以獨立部署、獨立擴展，並由自主團隊負責。
然而，在實踐中，只有真正具有擴展性問題和部署限制的產品才需要增加這一層複雜性。當資深後端開發人員和自封的系統架構師意識到他們並非在 Netflix 工作，而他們開發的企業軟體是在一個網路連線都受限的政府大樓裡運行時，業界開始回歸單體架構的簡單性。
微服務的執行問題
如果我們誠實面對，微服務的失敗並非因為概念不好，而是因為執行不當。團隊將服務拆分得太小，甚至出現了「奈米服務」這樣的詞彙。每個人都在談論可擴展性，但 90% 的系統根本不需要它。一般來說，人們開始將單體架構與過時且充滿錯誤的軟體聯繫起來。
但問題在於，大多數時候，他們處理的並非乾淨的單體應用程式，而是一團糟的「泥球」。猜猜看，將這團泥球拆分成多個 HTTP 呼叫並不會讓它神奇地消失。你仍然面對同樣的泥球，只是現在它分散在各處而已。
自包含系統的崛起
自包含系統是對上述所有問題的回應。這個概念非常簡單：不要將所有東西拆分成微服務，並假裝你在解決模組化問題，而是構建獨立的垂直切片。每個系統都包含自己的 UI、後端邏輯和資料庫，而且關鍵是，沒有對其他系統的運行時依賴。將它們視為獨立的應用程式，而不是假裝模組化的緊密耦合服務。
自包含系統的魔力不在於技術，而在於邊界。你不需要斷路器，因為你的系統不會互相調用。你不需要分散式追蹤，因為沒有需要追蹤的分散式邏輯。你不需要六層 DevOps，因為你不會在每個星期五部署 50 個服務。而且，由於系統包含自己的 UI，你也不會遇到單體前端與 100 個微小 API 通訊的經典反模式。
系統間的資料交換
那麼，這些系統如何交換資料呢？經驗法則是，應盡量減少通訊，畢竟這些都是自包含系統。但當它們需要通訊時，可以透過 UI 中的連結或非同步解耦的基於事件的訊息傳遞來實現。
如果這聽起來很像 90 年代的模組化應用程式，那是因為它的確很像。但這種結構確實有意義：
-
團隊規模小且自主。
-
邊界與業務對齊。
-
與微服務不同，它不會因可維護性和無用的複雜性而崩潰。
自包含系統的成功案例
在 Spring IO 2025 會議上，有人討論了自包含系統，並且分享了使用這種架構的成功案例。例如，曾有人使用 SCS 將舊的 ERP 系統拆分為自包含系統，並使用事件複製進行資料共享。每個團隊擁有自己的端到端切片，UI、後端和儲存都保持在一起，最終一切都很好地整合在一起。
當然，這個模型並非完美，但它更乾淨，並且以正確的方式進行擴展。
結論
如果你正在構建一個具有數千個並發用戶的即時交易平台，那麼可以盡情使用微服務。但如果你正在構建業務應用程式、內部工具或不需要超大規模的系統，那麼可能不需要分散式複雜性，僅僅為了感覺現代化。