＊＊ 本文同步發表於 FB社群-軟體設計鮮思維 ＊＊

要談及微服務，就需要回頭檢視典型單體 (Monolithic) 式的系統建構與開發方式。下圖可能是一個醫療領域的單體式系統架構。

這個「Monolithic」可以翻譯爲「單體」或「整體」，也就是我們一般典型的大堆頭式的開發系統，它有以下特點：

• 應用程序被建構爲單個單元 (single unit)。
• 多個功能模組共用同一個資料庫。
• 使用同一種技術框架 (ex. .NET or Java/Spring Framework) 實作。
• 對系統的任何變更都涉及建構與部署伺服端應用程序的新版本。
• 伺服器系統的延展性主要採以運行多個複製實例 (clone instance) 以達成負載平衡的需求。

它會造成哪些問題呢？

• 多個功能模組很難保持彼此間的隔離性，而導致複雜度的提昇，造成緊密耦合 (tight coupling) 難以維護的問題。
• 非常難以部署到雲端平台上！因爲對應用程式一小部分的變更，仍需建構與部署整個整體。
• 實體伺服器擴展時需要對整個應用程式，而無法只針對某一較需較多資源的特定功能模組。

上述第二點難以部署到雲端平台上，這才是雲端服務商會這麼力推約 15 年前的微服務理論架構，再延伸談及 CI/CD (Continuous Integration / Continuous Deployment) 工具乃至方法論 (ex. DevOps) 的主要原因了。

但，還是要回到根本，軟體的變動設計議題仍是開發單位更應當重視的。如果僅表面設計爲微服務，但微服務內部結構還是一團亂，那麼因爲整個業務領域邏輯隨着微服務的分散卻又難以應變，這個可是會更等比提昇系統的複雜度！