微服務 vs. Serverless：開發架構該如何選擇？完整比較與應用指南

更新日期： 2025 年 3 月 4 日

當「蓋大樓」變成「拼樂高」——現代架構的模組化革命

想像你要蓋一棟摩天大樓。

傳統做法是從地基到屋頂一體成型（單體式架構），但若想新增一個空中花園，就得敲掉整面牆。

現代開發者選擇了更靈活的方式：把大樓拆成無數個樂高積木（微服務），甚至直接租用現成房間（Serverless），按需拼裝、隨時擴容。

本文將帶新手探索兩大現代架構——微服務與 Serverless，理解它們如何解決傳統開發痛點，並掌握「分散式系統」與「無伺服器」的應用場景。

微服務架構：把大象拆成螞蟻軍團

隨著業務規模的擴大，傳統的單體式架構往往變得笨重且難以維護。

微服務（Microservices）架構則是一種解決方案，它將龐大的應用程式拆解成一組小型、獨立的服務，讓開發、部署、維運更加靈活。

什麼是微服務（Microservices）？

微服務是一種軟體架構風格，將大型應用程式劃分為多個小型獨立服務，每個服務各司其職，彼此透過 API 進行通訊。

這些服務可由不同的團隊獨立開發、測試、部署和維護，降低了開發與運營的複雜性。

微服務的核心特點

1. 單一職責（Single Responsibility）
   每個微服務只專注於一個特定功能，例如：
   • 用戶管理（User Management）：處理註冊、登入、權限驗證等功能。
   • 支付處理（Payment Processing）：負責交易處理、訂單支付等。
   • 商品管理（Product Service）：管理商品資訊、庫存等。
2. 獨立開發與部署
   • 每個微服務可由不同團隊獨立開發，彼此無需共享程式碼，降低相依性。
   • 各服務可以根據需求進行單獨部署與更新，避免影響整個系統。
   • 可使用不同技術棧，例如用 Node.js 開發 API 服務、用 Python 處理機器學習任務。
3. 透過 API 進行通訊
   • 微服務之間通常使用 RESTful API 或 gRPC 來交換數據。
   • 透過輕量級的通訊協議（如 HTTP、MQTT、Kafka 等）來確保服務能夠高效交互。

微服務 vs. 單體式架構：優缺點對決

微服務與傳統的單體式架構有很大不同，以下是它們的核心比較：

單體式架構的痛點

在單體式架構下，所有功能模組被封裝在同一個應用程式中，隨著代碼量增加，問題也逐漸浮現：

• 難以維護：程式碼耦合度高，改動一個功能可能影響整個系統。
• 部署困難：即使只修改一小部分功能，也需要重新部署整個應用。
• 擴展受限：無法單獨擴展特定模組，當某個功能負載增加時，必須擴展整個系統，造成不必要的資源浪費。

微服務架構的優勢

• 彈性擴展：只需擴展高負載的服務，例如當「購物車」功能流量增加時，僅需擴展該服務，而非整個系統。
• 技術多樣性：不同微服務可根據需求選擇最適合的技術，如 Node.js 用於 API、Python 處理數據分析。
• 高容錯性：當某個微服務崩潰時，不會影響其他服務，確保系統穩定運行。

經典案例：Netflix 如何從單體式架構轉向微服務？

Netflix 早期的系統採用單體式架構，但隨著全球用戶數量的暴增，系統開始出現以下問題：

• 擴展困難：隨著新功能增加，應用變得龐大，部署一次更新需要耗費數小時甚至數天。
• 高故障風險：當某個模組出錯時，可能導致整個平台無法運行。
• 維護成本高：程式碼高度耦合，修改一個小功能可能影響整個系統，開發效率下降。

Netflix 的解決方案：微服務架構

為了提升系統的可擴展性與穩定性，Netflix 逐步將單體式系統拆分為 500 多個微服務，其中包括：

• 用戶授權服務（Authentication Service）
• 推薦系統（Recommendation Engine）
• 影片串流服務（Streaming Service）
• 支付處理（Payment Gateway）

Netflix 微服務架構的優勢

✅ 靈活擴展：當某個服務的負載增加時，只需擴展該服務，而非整個系統。
✅ 高可用性：單一微服務崩潰不會影響其他功能，確保平台穩定運行。
✅ 技術創新：不同微服務使用最佳技術，例如 Python 處理 AI 影片推薦，Node.js 提供 API 服務。

Netflix 的轉型成功，使其成為微服務架構的經典案例，許多企業如 Amazon、Uber、Spotify 也陸續採用了類似的架構來提升系統彈性與可擴展性。

分散式系統的挑戰：微服務的黑暗面

雖然微服務架構帶來了更好的擴展性與彈性，但它也引入了許多新的挑戰。

當系統被拆分成許多獨立服務後，服務之間的通訊、資料一致性、監控與除錯變得更加複雜。

這些問題如果處理不當，可能會導致系統故障、數據錯誤，甚至影響用戶體驗。

網路延遲與通訊複雜性

問題：服務間透過網路通訊，可能因延遲或封包遺失導致錯誤

在單體式架構中，函式呼叫（Function Call）通常在記憶體內執行，速度極快且不易出錯。

但在微服務架構下，服務之間透過網路進行 API 請求，這意味著：

• 網路延遲（Latency）：請求可能因為網路擁塞或物理距離造成回應時間變長。
• 封包遺失（Packet Loss）：某些請求可能因為網路問題而丟失，導致應用程式誤判失敗。
• 服務不可用（Service Unavailability）：如果依賴的微服務崩潰或過載，請求可能無法成功執行。

延伸閱讀：網際網路是如何運作？｜運作原理大解析

實際案例

情境：用戶下單流程

1. 用戶 提交訂單。
2. 訂單服務（Order Service）發送請求至 庫存服務（Inventory Service），確認是否有足夠庫存。
3. 庫存服務 檢查庫存，回應「庫存充足」。
4. 但由於 網路延遲，訂單服務未收到庫存服務的回應，誤判庫存不足並回傳錯誤訊息給用戶。
5. 用戶以為訂單失敗，可能會重新下單，造成額外的負載與不必要的庫存扣減。

解決方案

1. 重試機制（Retry Mechanism）
   • 如果請求超時或失敗，自動重新發送請求（但應該設置最大重試次數，避免無限循環）。
   • 可使用 指數退避機制（Exponential Backoff），即每次重試間隔時間逐漸增加，減少對伺服器的壓力。
2. 熔斷模式（Circuit Breaker）
   • 當某個微服務發生大量錯誤時，系統可以暫時阻斷對該服務的請求，避免造成更大影響（如 Netflix Hystrix）。
   • 熔斷器有三種狀態：
     • Closed（關閉）：請求正常流通。
     • Open（開啟）：請求被阻擋，直接返回錯誤，避免雪崩效應。
     • Half-Open（半開啟）：部分請求被允許通過，測試服務是否恢復正常。
3. 非同步通訊（Asynchronous Communication）
   • 改用 訊息佇列（Message Queue），如 RabbitMQ、Kafka、AWS SQS，確保請求即使發送失敗也不會丟失。
   • 訂單服務不直接等待庫存服務的回應，而是將請求放入隊列，庫存服務處理完後再回傳結果。

延伸閱讀：Tenacity：強大的 Python 重試機制庫

資料一致性難題

問題：每個微服務擁有自己的資料庫，如何確保數據同步？

在單體式架構中，所有業務邏輯通常共享一個資料庫，資料一致性問題較少。但在微服務架構下，每個服務通常擁有自己的獨立資料庫，這導致：

• 資料同步困難：不同服務的資料可能不同步，導致不一致的業務邏輯。
• 跨服務交易問題：在單體系統中，資料庫可透過 ACID（Atomicity, Consistency, Isolation, Durability） 保證交易一致性，但在分散式環境下無法直接使用傳統的事務機制。

實際案例

情境：用戶更新地址

1. 用戶服務（User Service）更新了用戶的送貨地址。
2. 訂單服務（Order Service）需要同步新地址，以計算正確的運費。
3. 但由於系統異步處理，訂單服務可能在新地址尚未同步完成時，就開始計算運費，導致運費錯誤。

解決方案對比

在微服務架構下，因為每個服務有自己的資料庫，如何確保跨服務的資料一致性是個挑戰。

這裡介紹三種常見的解決方案，它們各有適用的場景：

補充：交易（Transaction）是什麼意思？

交易（Transaction） 在軟體系統和資料庫中，指的是一組 需要確保完整執行的操作，這些操作要麼 全部成功，要麼 全部失敗，不留下任何影響。

這種特性確保系統中的數據不會出現錯誤或不一致的情況。

舉個例子：銀行轉帳 💰

假設你要從 A 帳戶轉 1000 元到 B 帳戶，這個過程涉及兩個步驟：

1. 從 A 帳戶扣除 1000 元
2. 將 1000 元加到 B 帳戶

這兩個步驟應該 要一起成功，否則如果只完成了第一步但第二步失敗，那麼錢就憑空消失了！

這就是為什麼銀行系統會使用「交易機制」，確保這兩步 要嘛都成功，要嘛都取消（回滾），避免數據錯誤。

交易的四大特性（ACID） 📜

在傳統的資料庫系統中，交易遵循 ACID 原則：

1. 原子性（Atomicity）：交易中的所有操作要 全部完成或全部取消，不能只執行一部分。
2. 一致性（Consistency）：交易前後，數據都要保持一致，不會出現錯誤狀態。
3. 隔離性（Isolation）：不同交易不會互相影響，避免數據衝突。
4. 持久性（Durability）：交易成功後，數據會被永久儲存，即使系統崩潰也不會丟失。

交易在微服務架構中的挑戰

在單體應用（Monolithic Application）中，交易通常由 單一資料庫 來管理，透過 ACID 原則確保資料一致性。

但在 微服務架構 中，每個服務可能擁有自己的獨立資料庫，這導致跨服務交易變得複雜，因為沒有單一資料庫可以直接管理整個交易。

為了解決這個問題，微服務通常會使用 2PC（兩階段提交）、Saga 模式、事件溯源 等方法來確保資料一致性。

再舉個例子：電商訂單處理 🛒

假設你在電商網站下單，這個交易包含幾個步驟：

1. 訂單服務 創建訂單
2. 庫存服務 檢查是否有足夠庫存，並扣除庫存
3. 支付服務 處理付款

這些步驟必須 要一起成功，否則如果支付成功但庫存不足，那用戶就白付錢了！

微服務架構會用 Saga 模式 來解決這個問題，例如：

• 如果庫存扣除成功，但支付失敗，則執行「補償操作」，把庫存恢復，讓系統回到原始狀態。

這樣就能確保系統不會出錯，雖然短時間內數據可能不一致，但最終會達成一致性。

監控與除錯地獄

問題：一個用戶請求可能橫跨 10+ 服務，如何追蹤問題根源？

在單體系統中，開發者可以透過應用內日誌輕鬆追蹤錯誤，但在微服務架構下：

• 請求可能經過多個服務（Service Chain），很難找出錯誤的源頭。
• 不同微服務的日誌分散在不同伺服器，無法輕易聚合分析。
• 異步處理增加複雜度，有些錯誤可能幾分鐘後才發生。

解決方案：監控與追蹤工具

1. 分散式追蹤系統（Distributed Tracing）
   • 使用 Jaeger、Zipkin 等工具來追蹤請求的流動。
   • 例如，當用戶發送請求時，系統可以給每個請求附加一個 Trace ID，讓開發者追蹤請求經過的所有微服務。
2. 集中化日誌（Centralized Logging）
   • 使用 ELK Stack（Elasticsearch + Logstash + Kibana） 或 Graylog，將所有微服務的日誌統一收集並可視化分析。
3. 健康檢查 API（Health Check API）
   • 定期檢查微服務是否正常運作，避免服務崩潰後才被發現。

無伺服器架構（Serverless）：雲端時代的水電工

在傳統 IT 架構中，開發者需要管理伺服器，包括安裝、運行、維護，甚至負責擴展和安全性更新。

然而，Serverless（無伺服器架構） 的出現，讓開發者不再需要關心伺服器的細節，而是專注於撰寫業務邏輯，雲端供應商則負責後端運行環境的管理。

Serverless 不代表「沒有伺服器」，而是指 開發者無需管理伺服器，由雲端平台 自動處理資源分配、擴展、負載平衡與維運，讓開發更加敏捷、彈性且成本低廉。

什麼是 Serverless？

Serverless 是一種 事件驅動（Event-Driven） 的雲端運算模型，開發者只需撰寫 函數（Function） 或使用 雲端後端服務（Backend as a Service，BaaS）。

雲端供應商會自動處理伺服器的部署、管理與擴展。

Serverless 的核心特點

✅ 無需管理伺服器：不需要自行架設或維護伺服器，一切由雲端供應商負責。
✅ 按需執行，按量計費：不會浪費閒置資源，只有當函數被觸發時才會執行，計費方式基於 執行次數 和 執行時間。
✅ 自動擴展（Auto Scaling）：當請求量變大時，系統能夠 自動分配更多運算資源，不需要人工干預。
✅ 高可用性與安全性：雲端供應商負責基礎架構的維護與安全更新。

Serverless 的核心服務模式

1️⃣ FaaS（Function as a Service）

👉 允許開發者撰寫 函數，並由雲端平台管理執行。

• 代表服務：
  • AWS Lambda
  • Google Cloud Functions
  • Azure Functions

2️⃣ BaaS（Backend as a Service）

👉 透過雲端服務提供常見的後端功能，如資料庫、認證、檔案儲存等，開發者無需自行架設後端伺服器。

• 代表服務：
  • Firebase（提供即時資料庫與身份驗證）
  • Auth0（提供身份驗證服務）
  • AWS Amplify（提供後端 API、存儲等）

3️⃣ 比較 FaaS 與 BaaS

這兩者的核心差異在於 「開發者負責的內容」 和 「雲端服務的提供方式」，簡單來說：

• FaaS（Function as a Service）：
  • 你需要撰寫「函數」（程式碼），每當有請求進來，雲端會執行該函數，完成你的業務邏輯。
  • 適合「計算、邏輯處理」的應用，例如圖片處理、API 服務等。
  • 開發者負責寫程式（函數），雲端只幫忙執行它。
• BaaS（Backend as a Service）：
  • 你不需要寫後端程式，直接使用雲端提供的「現成後端服務」，如資料庫、身份驗證、檔案存儲等。
  • 適合「後端基礎設施」，如即時資料庫、用戶登入驗證等。
  • 開發者負責使用雲端 API，雲端幫你處理後端邏輯。

用一個例子來比喻 🎭

假設你要開一家 影印店，客戶來了會要求你幫他們列印文件 📄。

• FaaS： 你自己寫了一個 影印機操作程式，當客戶上傳文件時，影印機會根據你的程式執行列印。你只負責寫「影印邏輯」，不管影印機怎麼運作（雲端幫你處理機器的維護）。
• BaaS： 你直接租用了一家影印公司的服務，不需要自己寫任何程式，客戶來了就把文件交給影印公司，他們幫你印好，然後給你收據。

實際案例比較 🚀

Serverless 的殺手級應用場景

Serverless 架構最適合 短暫執行的任務 或 無法預測流量的應用，以下是常見的應用場景：

實例：圖片縮圖生成（AWS Lambda）

假設你正在開發一個圖片上傳平台，當用戶上傳圖片時，系統需要自動產生縮圖。

傳統解法：

• 需要部署一台伺服器來監聽上傳事件，隨時待命，但伺服器大部分時間都閒置，浪費資源。

Serverless 解法：

• 當用戶上傳圖片到 AWS S3 時，S3 觸發 AWS Lambda 函數，Lambda 產生縮圖並儲存回 S3，函數執行結束後立即釋放資源，不會持續佔用伺服器。

📌 AWS Lambda 圖片處理範例（Python）

import boto3
from PIL import Image
import io

def lambda_handler(event, context):
    s3 = boto3.client('s3')
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']

    # 下載原圖
    image_obj = s3.get_object(Bucket=bucket, Key=key)
    original_image = Image.open(image_obj['Body'])

    # 生成縮圖
    thumbnail = original_image.resize((200, 200))
    output_buffer = io.BytesIO()
    thumbnail.save(output_buffer, format="JPEG")
    
    # 上傳縮圖
    s3.put_object(Bucket=bucket, Key=f"thumbnails/{key}", Body=output_buffer.getvalue())

    return {'statusCode': 200, 'body': 'Thumbnail created successfully'}

這樣的架構比傳統伺服器 更具成本效益，且無需管理伺服器。

Serverless 的隱形成本與挑戰

雖然 Serverless 擁有許多優勢，但仍然有一些挑戰需要考量：

微服務 vs. Serverless：如何選擇？

在現代雲端架構設計中，微服務（Microservices） 和 Serverless（無伺服器架構） 是兩種最流行的架構選擇。

它們都可以提高應用程式的擴展性（Scalability） 和 靈活性（Flexibility），但在開發成本、運行方式、適用場景上有明顯的差異。

架構對比指南：微服務 vs. Serverless

選擇適合的架構時，需要根據 團隊規模、執行方式、控制權限、成本模式 等因素來考量。

以下是兩者的關鍵對比：

何時選擇微服務？

✅ 需要長時間運行的 API 或高流量系統（如社交媒體、金融交易系統）。
✅ 需要對基礎設施有完全控制權（如選擇特定的資料庫、網路架構）。
✅ 適合大型團隊，開發人員可以獨立管理不同微服務模組。
✅ 有穩定且持續的流量，讓固定伺服器成本合理化。

何時選擇 Serverless？

✅ 需要快速開發和部署，不想管理伺服器（如 MVP 產品、原型測試）。
✅ 流量波動大、突發請求頻繁（如活動網站、批次處理任務）。
✅ 適合小型應用，或只需要處理特定事件（如上傳文件、發送郵件）。
✅ 希望降低基礎設施成本，只按執行次數計費。

合架構實例：電商平台設計

在現實應用中，許多系統會結合 微服務 + Serverless，各取所長，打造最佳的效能與彈性。

以下是一個電商平台的混合架構設計：

架構解讀

• 核心功能使用微服務（確保穩定性與長期運行）
  • 用戶管理（User Service） 👉 需要持久運行，負責用戶註冊、登入、購物歷史，使用 微服務 + MySQL。
  • 商品目錄（Product Service） 👉 需要高效查詢，使用 微服務 + MongoDB，確保查詢效能。
• 周邊功能使用 Serverless（減少成本，提升擴展性）
  • 庫存更新（Inventory Update） 👉 使用 AWS Lambda，當庫存變動時（如用戶下單），觸發函數更新數據。
  • 推薦引擎（Recommendation Engine） 👉 使用 AWS Lambda，根據使用者行為計算推薦商品，不需要長時間運行，只在用戶瀏覽時執行。

為何這樣設計？

• 微服務處理核心業務（穩定、長期運行），確保可靠性與持久數據存儲。
• Serverless 處理周邊功能（短時間執行、無需持續運行），減少成本、提高擴展性。

案例分析：Netflix 是如何混合使用微服務與 Serverless？

Netflix 是全球最大影音串流平台之一，它的架構結合了 微服務與 Serverless，確保高效能、可擴展性與低運營成本。

✅ 核心串流服務（微服務架構）

• 負責用戶登入、影片推薦、播放紀錄等核心業務，確保高效能與穩定性。
• 每個模組是獨立的微服務，如 用戶服務、播放服務、訂閱服務 等。
• 使用 Kubernetes + Docker 部署在 AWS 雲端。

✅ 短期運行任務（Serverless）

• 縮圖處理：當上傳新影片時，使用 AWS Lambda 生成影片縮圖。
• 異常偵測：用 Serverless 監測 API 異常，當發現錯誤時觸發警報系統。
• 分析報表：透過 Lambda 定期整理數據，產生日報與週報。

為什麼 Netflix 使用混合架構？

1️⃣ 核心業務（穩定長期運行）使用微服務，確保效能與可靠性。
2️⃣ 短期運行的批次處理、異常監測等功能使用 Serverless，降低成本。
3️⃣ 微服務 + Serverless 互補，達到最佳擴展性與靈活度。

如何選擇？

✔ 最佳策略：對於大多數應用，核心業務使用 微服務，非核心業務使用 Serverless，混合架構可以讓系統兼具彈性、擴展性與成本效益。

總結：擁抱模組化，但別為趨勢而趨勢

微服務與 Serverless 不是銀彈，選擇時應問自己：

1. 團隊是否準備好？微服務需要成熟的 DevOps 文化。
2. 真的需要無限擴展嗎？小型專案用單體式反而更高效。
3. 成本效益比如何？Serverless 在低流量時便宜，但高流量可能更貴。

未來的贏家，永遠是根據需求混合搭配的架構師。

新手常見問答