在前兩天的文章中，我們分別介紹了微服務的 基本概念 以及 定義。那麼，今天我們要討論一個更根本的問題：為什麼我們需要導入微服務？

很多團隊在一開始接觸微服務時，往往被它的技術堆疊吸引：容器化、Kubernetes、服務網格 (Service Mesh)、API Gateway等，這些技術的確是實現微服務的重要工具，但卻不是導入的最終理由。真正驅動組織走向微服務的，不是「想要炫耀技術」，而是「業務需要快速演進，而單體式架構已經難以支撐」。

本文將透過以下四個面向來回答這個問題：

1. 問題陳述
2. 動機
3. 解決方案
4. 優缺點分析

一、問題陳述

基本上，一個軟體架構就跟中國歷史的演進很像「分久必合、合久必分」，在不同的時代會有不同的技術來協助我們做這些事情。

為什麼要「分」？通常是因為問題越來越複雜，我們需要將問題切割成小問題逐一擊破才有優勢。
為什麼要「合」？可能是因為團隊能力或是有新的工具讓問題趨於簡單，所以合起來做比較好處理。(或許 AI 輔助開發過一陣子會讓我們把這些東西又合起來，可能只要下下 prompt 就可以產生新版的軟體，這樣去處理這些可讀性跟架構問題意義就不大了)

回到線上書店的例子：

• 商品模組：管理書籍資訊
• 會員模組：管理會員註冊與登入
• 訂單模組：處理購物車及結帳
• 支付模組：處理金流交易

這些子領域都需要被實作，但問題來了：我們要把它們放在同一個應用程式裡嗎？還是要拆開來？

如果全部放在一個大型應用程式（Monolith），短期內的確簡單，但長期會出現：

• 程式碼庫越來越大，維護困難。
• 任何修改都需要整個系統重新測試與部署。
• 不同團隊在同一個程式碼庫裡衝突不斷，難以維護。
• 技術升級受限（例如某模組想用新版本 Java，但其他模組不相容）。

這些痛點，正是推動我們思考微服務的起點。

(老闆說我們要改微服務架構說不定才是真的起點)

二、動機

既然，我們要探討導入為服務的動機，基本上我們就可以分成「正向」跟「反向」兩個面向來探討。

1. 正向驅動力

   • 簡單的元件
     一個服務元件所涵蓋的業務範疇越少，其複雜度就越低，未來也就越容易維護。

   • 自主的團隊
     每個團隊能夠獨立開發、測試、部署，避免「等別人合併程式」的困境，如此才可以建立更順暢的開發與部署流水線。

   • 快速的部署
     微服務因為小，所以建置與測試的速度快，能提升部署頻率。這對於「持續交付（Continuous Delivery）」至關重要。

   • 多元的技術
     不同的業務需求可能適合不同的技術來實現，或是由團隊自己熟悉的技術來實作，不會被同一個技術語言或框架給綁架。

   • 個性化的分割
     每一個微服務可以依據「資源需求」、「可用性需求」、「安全需求」來拆分，讓系統更彈性。

     上述這些都給予團隊更多的支持去完成手上的工作，屬於「正向驅動力」動機。

2. 負向阻力

   • 簡單互動
     如果一個操作能在單一元件中完成，它一定比跨服務調用更容易理解與排錯。
     (分散式追蹤與除錯會是未來的惡夢，你準備好了嗎？)
   • 互動效率
     跨服務的網路呼叫比單體中的方法呼叫慢許多，還可能有網路延遲問題。
   • 偏好 ACID 交易
     在單體系統中，很多操作能透過單一交易（ACID）完成。
     微服務拆開後，必須用 Saga 或事件一致性機制來處理，增加複雜度。
   • 簡化耦合
     如果一個操作必須依賴多個服務的即時回應，系統可用性會被拉低。
     如果兩個服務的設計經常需要同步修改，代表拆分邊界有問題，會拖慢開發效率。

上述的論點，可以協助大家更理解微服務 (微服務通常不會帶來更好的效能，跨服務呼叫反而會讓效能下降)。

三、解決方案

針對上述的問題與動機，我們提出的方案是在導入微服務之前應該先審慎評估，確立自己的「業務目標」，然後再評估是否要採用微服務架構的手段來達成業務目標。

評估的準則，可檢視上述的「動機」部分，確認自己應用的場景以及情境評估是否合適導入微服務。

假設，經過評估你人為需要導入微服務，則進一步的手段是：

將應用程式拆解成一個由兩個或以上可獨立部署且鬆耦合的服務組成的架構，每個服務包含一個或多個子領域。

簡而言之，就是針對應用程式進行「拆解」，找到合適的大小來建構微服務。

四、優缺點分析

導入微服務的確能解決單體式架構的問題，但它不是萬靈丹。我們必須清楚看待它的優缺點，並做出符合業務需求的判斷。

優點

基本上，優點就如「動機」章節分析的「正向驅動力」，這些好處促使我們決議將軟體架構導向「微服務」。

缺點

單體式架構不是一文不值，軟體架構本身是用來達成業務目標的手段，所以單體架構開發簡單、快速的特性也特別適用於「新創」或是還在探索業務方向的企業。微服務本身架構「複雜」，有些資料處理的過程與「單體式」架構有本質上的落差。

結語

「為什麼要導入微服務？」這個問題沒有唯一的標準答案，但有一個核心邏輯：

當單體架構已經無法支撐業務快速演進的需求時，微服務是一條可行的解方。

它能帶來團隊自主性、更快的交付能力、技術堆疊的靈活性，但同時也會引入分散式系統的複雜度與一致性挑戰。

在後續的篇章中，我會進一步探討：

• 如何界定微服務邊界（Domain-Driven Design 的應用）
• 微服務的典型設計模式（Patterns）

讓我們繼續往下，從「理念」逐步走向「實作」。