爲何會使用微服務架構?!

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

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

爲何會使用微服務架構?!

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

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

它會造成哪些問題呢?

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

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

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

文章導覽

   

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。