微服務還是單體？老闆與 PM 看得懂的系統架構選型：什麼時候該拆、拆錯的代價與遷移路線

先講一個會得罪工程師的結論

大部分中小企業不需要微服務。如果有工程師或外包廠商一開口就跟你說「我們要用微服務架構，比較先進、好擴展」，你該先警覺——這句話有可能是為公司著想，也有可能是想用你的專案練技術、或把帳單做大。微服務不是越多越好，用錯地方它會讓你的系統更慢、更貴、更難改。

這篇文章寫給要決定系統怎麼蓋、或正在審外包報價的老闆與 PM。不需要你會寫程式，但讀完你會知道單體和微服務各自適合什麼情境、什麼訊號才代表「真的該拆」、以及拆錯會付出什麼代價。軟體架構大師 Martin Fowler 提出過一個很有名的原則叫 MonolithFirst（先做單體）——連最推崇微服務的人都說，幾乎所有成功的微服務系統，都是從一個單體長出來的，而不是一開始就拆。

單體架構是什麼？為什麼它被汙名化了

單體架構（Monolith）就是「把整個系統做成一個應用程式」——前台、後台、訂單、會員、金流，全部寫在同一個專案裡，一起開發、一起部署。聽起來很「原始」，但它有巨大的優點：簡單。一個團隊、一套程式碼、一次部署，開發快、除錯容易、找問題直接。

這幾年「單體」變成一個帶貶意的詞，好像用單體就是落伍。這個印象其實是被大公司的故事帶歪的——Netflix、Amazon 拆微服務的案例被講到爛，但很少人提到：他們是「成長到幾千名工程師、單體真的撐不住」才拆的。你的公司如果只有 3-10 個工程師，硬學它們拆微服務，等於穿著太空衣去買菜。

有意思的是，連大公司也在回頭。Amazon 旗下 Prime Video 團隊就公開分享過，他們把一套微服務監控系統 改回單體後，成本直接降了 90%。架構沒有「先進」與「落後」，只有「適不適合現在的你」。

微服務是什麼？解決的是什麼問題

微服務（Microservices）是「把系統拆成很多個獨立的小服務」——訂單一個服務、會員一個服務、金流一個服務，各自獨立開發、獨立部署、甚至用不同的程式語言和資料庫。它們之間透過 API 或訊息佇列溝通。

微服務解決的是「大」的問題，不是「小」的問題。當你有上百個工程師、分成幾十個團隊，大家擠在同一個單體裡互相卡——A 團隊改個東西要等 B 團隊一起部署、一個小 bug 拖垮整個系統上線——這時候把系統拆開、讓各團隊獨立作業，才划算。它買的是「組織能平行作業」和「局部故障不擴散」，代價是「分散式系統的複雜度」。

這個「拆開後各服務怎麼溝通」的議題，跟我們寫過的 SOA 服務導向架構 和 Message Queue 非同步系統設計 是同一個家族的問題。微服務拆得越細，服務間的溝通與協調就越關鍵，這也是它複雜度的主要來源。

單體 vs 微服務：6 個維度對照

看這張表真正要抓的重點是「成本和收益要對應你的規模」，「微服務缺點比較多」反而只是表象。微服務的優點（獨立部署、局部容錯）在大團隊、高流量時才兌現得了；在小團隊，這些優點用不太到，缺點（複雜、貴）卻全要承擔。這就是為什麼對多數中小企業，單體或模組化單體才是理性選擇。

什麼時候該拆？4 個真正該上微服務的訊號

與其問「要不要用微服務」，不如看有沒有出現這些訊號。只要符合其中兩三個，才真的到了該認真考慮拆的時候。

• 訊號一：團隊大到互相卡。工程師超過 20-30 人、分成多個團隊，大家在同一個單體裡改 code 互相踩腳，部署要排隊。
• 訊號二：某些功能的流量/負載差異極大。例如「下單」尖峰時要大量擴充，但「後台報表」幾乎沒人用，綁在一起就得整套一起放大，浪費資源。
• 訊號三：不同部分需要不同技術或迭代節奏。例如 AI 推論服務要用 Python、即時通訊要用特殊框架、核心交易要極度穩定，硬塞同一個專案很彆扭。
• 訊號四：單體已經大到「改一個小功能要重測全部、部署提心吊膽」，技術債高到動彈不得。

如果你一個訊號都沒中，那答案很清楚：先把單體做好。把單體做乾淨、模組分清楚，未來真的需要時再拆，永遠來得及。反過來，一開始就硬拆，才是最貴的賭注。

拆錯的代價：最慘的結局叫「分散式單體」

微服務最可怕的失敗，其實是「拆錯」，比「沒拆」嚴重得多。最常見的災難叫「分散式單體（Distributed Monolith）」——你把系統拆成了十幾個服務，但它們彼此緊緊綁在一起，改一個服務就得連動改其他好幾個、還得一起部署。結果你同時承擔了「單體的綁死」和「微服務的複雜」，兩邊的缺點全收，優點一個沒拿到。

為什麼會變這樣？通常是因為拆的邊界畫錯了——沒有按「業務領域」拆，而是按「技術層次」亂拆，或是好幾個服務共用同一個資料庫。判斷一個微服務架構是不是健康，有個簡單標準：每個服務能不能「自己獨立改、獨立部署、不用通知別人」。做不到，那就是分散式單體，比單純的單體還糟。

中間選項：模組化單體（Modular Monolith）

單體和微服務之間有一個被嚴重低估的甜蜜點：模組化單體。它的做法是「還是一個應用、一起部署（單體的簡單），但內部按業務領域切成清楚的模組，模組之間界線分明（為未來拆分預留空間）」。

這個選項對中小企業幾乎是最佳解：你享有單體的開發速度與部署簡單，又因為模組劃分清楚，避免了「程式碼長大後變一坨」的命運。等到哪天某個模組真的需要獨立（流量爆、要換技術），把那一個模組抽出來變微服務就好，不必一開始就全拆。這正呼應了前面講的 MonolithFirst——先做好單體，需要時再從中長出微服務。

要把模組化單體做好，關鍵在「模組邊界」的設計與長期的程式碼整潔，這跟我們寫過的 技術債怎麼管 直接相關。邊界清楚、技術債控制得好的單體，遠比一個亂拆的微服務系統健康。

從單體遷移到微服務的 5 個階段

如果你真的成長到該拆了，正確的做法是「漸進式」，絕不是打掉重練。打掉重練是軟體專案最大的死法之一。

業界把這套漸進手法叫「絞殺者模式（Strangler Fig）」——讓新服務像藤蔓一樣慢慢包覆舊系統，一塊一塊取代，全程系統照常運作。每抽出一個服務都要能獨立上線、獨立回滾。最忌諱的是「停下所有開發，花半年重寫成微服務」，這種專案的失敗率高得嚇人。

不同規模公司的架構建議

這張表的精神是「架構要跟著規模長」，不是一步到位。絕大多數台灣中小企業會落在前兩列——單體或模組化單體就是最划算的選擇。把錢花在把產品做對、把單體做乾淨，比追求架構潮流實際得多。

找外包做系統時，架構決策要問的 5 件事

• 「以我們現在的團隊規模和流量，為什麼建議這個架構？」——逼對方用你的實況回答，而不是搬大公司案例。
• 「如果用微服務，誰來維護服務間的溝通、監控、部署？這些成本算在報價裡了嗎？」——揪出被藏起來的長期成本。
• 「未來要擴展時，這個架構怎麼演進？」——好架構是能長大的，不是一開始就過度設計。
• 「部署和上線流程長怎樣？出問題怎麼回滾？」——架構越複雜，部署與回滾越關鍵，可參考測試環境與正式環境的分流設計。
• 「能不能先用模組化單體起步，需要時再拆？」——如果對方堅持一定要全拆微服務，請他說清楚理由。

這些問題不用你懂技術，但能快速分辨出對方是「為你的需求設計」還是「想用你的專案做自己想做的事」。架構選型背後其實是成本與風險的取捨，部署、效能與成本怎麼平衡，也可以參考我們談 Next.js 16 效能與伺服器成本 的實作角度。

如果你正在為架構選型卡關

架構是系統的地基，選錯了，後面每一步都更貴。但「選對」對非技術背景的老闆來說很難判斷，因為你只能聽工程師或廠商說，又難以驗證對方說的是否為你的利益著想。

在系統客製化的專案經驗中，我們做過 生產力管理系統 與 AnyTime 遠距團隊工作計時工具 這類從 MVP 一路長大的系統，深知「一開始別過度設計、該拆時才拆」的價值。如果你正在規劃新系統、或在評估外包報價裡的架構建議合不合理，可以參考 客製化網站 & 系統開發服務，或透過 AI 顧問服務 找人幫你做一次中立的技術選型診斷。

結語：架構服務於業務，不是業務服務於架構

技術選型最該避免的心態，是「用最潮的技術」。對的問題永遠是「用最適合我現在規模和痛點的技術」。對台灣絕大多數中小企業，那個答案是單體或模組化單體，把產品做對、把程式碼做乾淨，遠比追求微服務的架構潮流更能帶來實際價值。

下次有人跟你提架構建議時，先問一句：「這是為我現在的需求設計的，還是因為它比較新？」這個問題問下去，很多過度設計的提案會自己現形。架構是手段，能準時上線、好維護、撐得起你未來三年的成長，才是目的。