考慮要不要採用微服務架構時,第一個必須記得的事是:巨石(monolithic)架構對許多應用而言完全沒有問題。它簡單、易理解、易開發——尤其在應用還小時。

不要因為微服務「比較潮」就自動選擇它。架構選擇的核心問題是:對你的應用而言,哪一種架構的好處大過壞處。

需要做出「巨石 vs 微服務」決策的場景主要有兩種:

  • 全新開發:從零打造一個新應用。
  • 巨石遇到瓶頸:既有巨石應用發展到力不從心。

全新應用:預設「巨石優先」#

從零開始開發新應用時,工程師很容易把微服務當成「最新技術清單」的一部分。但實際上,一個新應用通常不會立刻碰上微服務要解決的流暢交付問題:

  • 還沒寫半行程式,應用要變大、變複雜還很久,甚至永遠不會。
  • 組織還小,團隊自主性不是迫切問題。
  • 巨石架構就足以支撐流暢交付。

例外:其他效益帶來的初期動機#

雖然「流暢交付」不是新專案選微服務的好理由,但 1.3.3 提到的其他好處可能成立:

  • 應用必須混合多種技術棧(例如多數模組用 Java,AI 模組用 Python),簡單的微服務架構(只有少數服務)就合理。
  • 有顯著的可擴展性、可用性、安全性需求,需要把不同特性的模組分到獨立服務。

為什麼新專案做微服務容易做歪#

在新專案上立刻採用微服務,常會做出分散式巨石(distributed monolith)。

Why:鬆設計期耦合需要穩定的 API,而新專案的問題領域尚未被充分理解,API 與服務邊界往往要反覆迭代才會穩定下來。

How to apply:在巨石中迭代邊界遠比在微服務中容易。除非有強烈理由(多技術棧、模組必須分離),否則一律建議**「monolith-first」**。

重構巨石:確認根因再行動#

第二個情境:現有巨石應用已力有未逮——交付速度變慢、部署頻率下降、團隊在會議裡耗費大量時間協調變更。表面上這些都像是該轉進微服務的訊號,但動手之前必須做兩件事:

  • 確認巨石架構真的是根因。
  • 找到一條最小化風險、最大化價值交付的遷移路徑。

先確認根因:不是所有問題都靠微服務解決#

很多時候,問題的根因不在「巨石」本身,而是其他配套沒做好:

  • 也許只是巨石不夠模組化,讓團隊負責的模組不夠鬆設計期耦合——把它改造成「模組化巨石」就能解決。
  • 也許 DevOps 與 Team Topologies 沒落地。
  • 也許缺乏自動化部署管線。

在排除上述配套問題之前,別急著轉進微服務。把模組化、DevOps、Team Topologies、自動化管線先補齊;只有當這些改變仍無法達成流暢交付時,才考慮微服務遷移。

漸進式遷移:用 Strangler Fig 模式取代大爆炸重寫#

不要做大爆炸式重寫(big bang rewrite)。從零開始很誘人,因為可以無視既有混亂,但風險極高:

  • 在新應用完成前,沒有任何價值交付,而完成日往往遙遙無期。
  • 設計決策的回饋同樣要等到很久以後才會出現。

Martin Fowler 有句廣為流傳的話:「A big bang rewrite often results in a big bang.」

更好的做法是採用Strangler Fig 模式(第 21 章詳述):

  • 漸進式地把功能從巨石搬到微服務。
  • 持續交付價值、持續取得設計回饋。
  • 業務急需的新功能,可以直接以新服務的形式實作。
  • 雖然要拆解既有系統並不容易,但幾乎總是優於大爆炸重寫。

章節重點摘要#

  • 流暢交付(fast flow)是企業在當今環境生存的必要能力——持續地把小且有價值的變更交付給客戶,並從每次變更得到持續的回饋。
  • 流暢交付的成功三角:DevOps、Team Topologies、能促成兩者的軟體架構。
  • DevOps 是一套快速、可靠交付軟體的原則與實踐。
  • Team Topologies 是一套讓組織為流暢交付而設計的原則與模式。
  • 巨石架構並非反模式,但大型應用、大型組織通常需要微服務架構才能達成流暢交付。
  • 微服務架構由兩個以上的鬆設計期耦合、可獨立部署的服務組成,使團隊自主、部署管線快速。
  • 微服務有諸多缺點,包括分散式架構的複雜性、嚴謹設計的要求,而許多組織並不習慣這種紀律。
  • 預設策略:monolith-first;只有在應用真正超出巨石架構承載力時,才遷移到微服務。
Backward 微服務架構簡介 FTGO 案例研究 Forward