我們總是從 Cloud-Native 微服務的文章中、演講中, 看到、聽到關於單體 (Monolithic) 的系統是如何的不易維護、不易快速的獨立發布。Cloud-Native 微服務是如何的容易擴展、快速的獨立發布、容易維護等等。

然而, 我想, 我們應從產品開發的視角, 認真且客觀的看待 Cloud-Native 微服務與單體 (Monolithic) 的系統; 以避免我們從單體 (Monolithic) 系統的地獄走向 Cloud-Native 微服務的地獄。

  • Cloud-Native 微服務會不會取代單體 (Monolithic) 的系統?
    • 當然不會。
    • 而且是永遠不會的。
  • 單體 (Monolithic) 的系統目前的問題,在Cloud-Native 微服務中會不會發生?
    • 當然會。
    • 太多的團隊,轉型到 Cloud-Native 微服務後,同時深陷單體 (Monolithic) 系統的地獄與 Cloud-Native 微服務地獄中。
  •  Cloud-Native 微服務是為了解決單體 (Monolithic) 系統上的問題?
    • 不能說不是,但當你這麼想時,你就會有很大的概率做錯事,而同時深陷 Cloud-Native 微服務地獄與單體 (Monolithic) 系統地獄中。

Cloud-Native 微服務最重要的思路是告訴我們:

軟體可以不再只是 「系統」, 而是可以是 「服務」。

“系統” 可以保證企業內的運作正常。

但,假如只是用系統的思維去構建直接為用戶提供服務的系統,有時候是沒問題的。但有的時候是, 版本計劃、開發,趕不上變化,變化趕不上ㄧ通電話的。

所以,我們要做些改變⋯

要做些改變, 並不是代表著我們要按著課本上的定義去做產品;定義什麼是單體 (Monolithic) 系統?什麼是 Cloud-Native 微服務?

要做些改變, 我們應將產品的架構區分出:

  • 不易變」、甚至是 「不可變」
  • 易變」、「常變」

再根據產品架構上的 「變化」 的質量屬性,將產品分成:

  • 那部分是 「系統」
  • 那部分又應該是 「服務」
圖一

 

如圖一所示, 產品團隊先將產品識別出:

  • 核心 (Core) 的業務領域
  • 通用 (Generic) 類型的子業務領域
  • 支撐 (Support) 類型的子業務領域
圖二

 

如圖二所示, 產品團隊與領域的業務專家, 再將各業務領域; 核心 (Core) 的業務領域、通用 (Generic) 類型的子業務領域、支撐 (Support) 類型的子業務領域; 中的 「不易變」 甚至是 「不可變」與 「易變」、「常變」 的業務場景給區分出來。

  • 不易變」 甚至是 「不可變」 的業務場景, 將會構成產品的 「系統」
  • “易變」、「常變」 的業務場景, 將會構成產品的 「服務」

 別忘了,有的產品是只要有 「系統」 就夠了。

會不會有產品只有服務,微服務的實現?有的。但,相當、相當、相當的不建議這 樣的產品架構。

所以,Cloud-Native 微服務除了需關注團隊的成員是否具備 Cloud-Native 微服務的關鍵技術外,更難的一點是:

  • 要花很多的時間識別所謂的 「系統」、 「服務」。

然後,才能明白什麼時候應該或不應該引入 Cloud-Native 微服務。

 

相關閱讀:

Cloud-Native 微服務的世界裡, 你不能忽略的關鍵人物與解決方案

Cloud-Native 產品級敏捷 2.0: 協作,可視化, 輕量級的微服務設計 

Cloud-Native 微服務架構元素卡

Cloud-Native 微服務設計元素卡

Cloud-Native 微服務開發元素卡

 

 

 

 

發表評論

您的電子郵箱地址不會被公開。 必填項已用*標註

此站點使用Akismet來減少垃圾評論。了解我們如何處理您的評論數據