高併發架構設計：從單體到微服務的演進之路

前言：架構設計決定系統命運

你的系統一開始跑得好好的。用戶從 100 變 1,000，還是撐得住。但當用戶突破 10,000，一切開始崩壞。

資料庫連線爆掉、API 回應變慢、偶爾還會整個掛掉。

這不是 bug，是架構問題。

從「能用」到「好用」再到「撐得住」，每個階段都需要不同的架構思維。本文將帶你走一遍高併發架構的演進之路，從單體架構的瓶頸，到微服務的設計原則。

如果你還不熟悉高併發的基本概念，建議先閱讀高併發是什麼？完整指南。

---

一、單體架構的瓶頸

1.1 什麼是單體架構

單體架構（Monolithic Architecture）是最傳統的架構方式。

所有功能都打包在一個應用程式裡：用戶管理、訂單處理、支付系統、通知服務，全部放在同一個 codebase、同一個部署單元。

早期這樣做很合理。開發簡單、部署方便、除錯容易。一個團隊、一套程式碼、一個資料庫。

但隨著業務成長，問題開始浮現。

1.2 單體架構的問題

單點故障

一個模組出問題，整個系統跟著掛。支付服務有 bug 導致記憶體洩漏？對不起，用戶連首頁都打不開。

擴展困難

訂單模組需要更多運算資源，但你只能把整個應用複製一份。其他模組不需要擴展？沒關係，一起複製，浪費資源。

部署風險高

每次部署都是全量發布。改了一行程式碼，整個系統都要重新上線。部署頻率被迫降低，迭代速度變慢。

技術債累積

所有程式碼耦合在一起，改 A 壞 B 是常態。新人上手困難，老鳥也怕動到「神秘區域」。久而久之，沒人敢重構。

團隊協作瓶頸

10 個人改同一份 code，merge conflict 是日常。功能開發互相卡住，協作效率直線下降。

二、擴展策略：向上還是向外？

當系統撐不住流量時，有兩個方向可以選。

2.1 垂直擴展（Scale Up）

垂直擴展就是「升級硬體」。

CPU 不夠快？換更好的。記憶體不夠大？加到 256GB。磁碟太慢？換 NVMe SSD。

優點：

• 簡單直接，不需要改架構
• 對應用程式透明，不用改 code
• 適合快速解決燃眉之急

缺點：

• 有物理上限（單機再強也有極限）
• 成本指數成長（高規格硬體貴得離譜）
• 依然是單點故障

適用時機：

• 早期階段，用戶還不多
• 緊急狀況，先撐過去再說
• 資料庫等難以水平擴展的元件

2.2 水平擴展（Scale Out）

水平擴展是「加機器」。

一台不夠？開兩台。兩台不夠？開十台。用負載均衡把流量分散到多台機器上。

優點：

• 理論上無上限
• 成本線性成長
• 天然具備容錯能力

缺點：

• 架構複雜度增加
• 需要處理分散式問題（資料同步、Session 共享）
• 對應用有設計要求（Stateless）

適用時機：

• 用戶成長到單機扛不住
• 需要高可用性（單機掛了還有其他機器）
• 長期規劃，預期流量會持續成長

2.3 選擇策略

實務上，兩者應該搭配使用：

1. 先垂直擴展到合理規格：不需要一開始就開很多小機器，先把單機規格拉到合理水準
2. 到達甜蜜點後水平擴展：當單機成本效益開始下降，再增加機器數量
3. 針對不同層採用不同策略：Web 層容易水平擴展，資料庫層可能需要先垂直擴展

---

三、分層架構設計

高併發系統的標準做法是分層架構。每一層職責明確，可以獨立擴展。

3.1 接入層（Gateway / Load Balancer）

接入層是流量的入口，負責：

• 流量分發：把請求分配到後端多台伺服器
• SSL 終止：處理 HTTPS 加解密
• 基本過濾：WAF、IP 黑名單、Rate Limiting
• 健康檢查：自動剔除故障節點

常用技術：

• Nginx / HAProxy（自建）
• AWS ALB / GCP Cloud Load Balancing / Azure Application Gateway（雲端託管）

3.2 應用層（Application Tier）

應用層是業務邏輯所在，設計原則：

Stateless（無狀態）

不要在應用伺服器上存放 Session。用戶的下一個請求可能打到不同機器，如果狀態存在本機，就會出問題。

Session 應該放在：

• Redis（推薦）
• 資料庫
• JWT（無狀態 Token）

水平擴展友好

任何一台應用伺服器都能處理任何請求。新增機器只需要：啟動 → 註冊到 Load Balancer → 開始服務。

容錯設計

假設任何一台機器隨時可能掛掉。有 N+1 冗餘，掛一台不影響服務。

3.3 快取層（Cache Tier）

快取層是高併發系統的效能關鍵。

為什麼需要快取？

資料庫查詢是昂貴的操作。一次 SQL 查詢可能要 50-100ms，而 Redis 只要 0.5ms。

把熱點資料放在快取，能減少 90% 以上的資料庫壓力。

快取策略

• Cache Aside：先查快取，沒有再查資料庫，然後寫入快取
• Read Through：應用只跟快取互動，快取自己去取資料
• Write Through：寫入時同時更新快取和資料庫
• Write Behind：寫入時只更新快取，非同步更新資料庫

詳細的快取設計，請參考高併發資料庫設計。

3.4 資料層（Data Tier）

資料層是系統的最後一道防線，也是最難擴展的一層。

常見優化手段

• 讀寫分離：寫入走主庫，讀取走從庫
• 分庫分表：把資料分散到多個資料庫
• 索引優化：確保查詢走索引
• 連線池管理：避免連線數爆掉

雲端資料庫選擇

如果你用雲端，可以考慮：

• AWS Aurora / RDS
• GCP Cloud SQL / Cloud Spanner
• Azure SQL Database / Cosmos DB

這些託管服務幫你處理備份、擴展、高可用，省下大量維運心力。

更多雲端資料庫比較，請參考雲端高併發架構。

---

四、微服務拆分策略

當單體架構到達極限，微服務是下一步。但微服務不是銀彈，拆錯比不拆更慘。

4.1 何時該拆分

該拆的訊號：

• 部署頻率被架構拖累（想快速迭代卻做不到）
• 團隊規模超過 10 人，協作衝突頻繁
• 不同模組有明顯不同的擴展需求
• 技術債累積到難以維護

不該拆的情況：

• 團隊只有 3-5 人
• 業務邏輯還在快速變化，邊界不清楚
• 沒有基礎設施支援（監控、日誌、部署流程）
• 為了拆而拆，沒有明確痛點

4.2 拆分原則

按業務領域拆分（DDD）

每個微服務對應一個業務領域：用戶服務、訂單服務、支付服務、庫存服務。

服務內部高內聚，服務之間低耦合。一個服務的變動不應該影響其他服務。

單一職責

一個服務只做一件事，做好一件事。用戶服務不應該知道訂單的細節，訂單服務不應該直接操作用戶資料。

獨立部署

每個服務有自己的 repository、自己的 CI/CD pipeline、自己的部署節奏。團隊 A 發布用戶服務，不影響團隊 B 的訂單服務。

資料隔離

每個服務擁有自己的資料庫。不共享資料庫，避免耦合。服務間通過 API 交換資料。

五、服務治理基礎

拆成微服務後，服務治理變得至關重要。

5.1 服務發現

當服務數量增多，你需要知道「誰在哪裡」。

問題：服務 A 要呼叫服務 B，但服務 B 有 10 個實例，IP 還會變動。寫死 IP 不切實際。

解法：服務註冊與發現

• 服務啟動時，向註冊中心註冊自己（IP、Port、健康狀態）
• 呼叫方向註冊中心查詢目標服務的位置
• 註冊中心定期健康檢查，剔除故障節點

常用工具：

• Consul
• Eureka
• Kubernetes Service（K8s 內建）
• AWS Cloud Map

5.2 配置中心

微服務環境下，配置管理是個挑戰。

問題：100 個服務實例，要改一個配置，難道一個個 SSH 進去改？

解法：集中式配置中心

• 所有配置集中存放
• 服務啟動時從配置中心拉取
• 支援熱更新（不重啟即生效）
• 支援環境區分（dev / staging / prod）

常用工具：

• Spring Cloud Config
• Consul KV
• AWS Parameter Store / Secrets Manager
• HashiCorp Vault

5.3 服務間通訊

服務之間怎麼互相呼叫？

同步通訊（HTTP / gRPC）

• 簡單直觀，像呼叫本地函數
• 有即時回應
• 缺點：呼叫方需要等待，如果下游慢，上游也會慢

非同步通訊（Message Queue）

• 解耦合，呼叫方不用等待
• 削峰填谷
• 缺點：複雜度增加，需要處理消息遺失、重複消費

實務上兩者混用：需要即時回應的用 HTTP/gRPC，可以延遲處理的用 Message Queue。

---

六、雲端架構推薦

如果你使用雲端服務，這裡是各大平台的高併發架構模板。

6.1 AWS 架構模板

Route 53（DNS）
    ↓
CloudFront（CDN）
    ↓
ALB（負載均衡）
    ↓
ECS / EKS（容器）或 EC2 Auto Scaling
    ↓
ElastiCache for Redis（快取）
    ↓
Aurora / DynamoDB（資料庫）
    ↓
SQS / Kinesis（佇列）

6.2 GCP 架構模板

Cloud DNS
    ↓
Cloud CDN
    ↓
Cloud Load Balancing
    ↓
Cloud Run / GKE（容器）或 Compute Engine MIG
    ↓
Memorystore for Redis
    ↓
Cloud SQL / Cloud Spanner / Firestore
    ↓
Pub/Sub

6.3 Azure 架構模板

Azure DNS
    ↓
Azure CDN
    ↓
Application Gateway
    ↓
Container Apps / AKS 或 VMSS
    ↓
Azure Cache for Redis
    ↓
Azure SQL / Cosmos DB
    ↓
Service Bus / Event Hubs

詳細的雲端方案比較，請參考雲端高併發架構。

---

架構演進需要規劃？ 從單體到微服務的轉型不是一蹴可幾。 預約架構諮詢，讓有經驗的顧問幫你規劃演進路線。

---

七、架構演進案例

案例：電商平台的架構演進

第一階段：單體架構

• 1 台伺服器，跑 PHP + MySQL
• 用戶數：1,000
• 問題：無

第二階段：垂直擴展

• 升級到 8 核 32GB
• 加入 Redis 做 Session 和熱點快取
• 用戶數：10,000
• 問題：資料庫開始吃緊

第三階段：讀寫分離

• MySQL 一主兩從
• 讀流量分散到從庫
• 用戶數：50,000
• 問題：單體部署變慢，團隊協作困難

第四階段：服務拆分

• 拆出用戶、商品、訂單、支付四個服務
• 引入 API Gateway
• 用戶數：200,000
• 問題：服務間呼叫複雜度增加

第五階段：完整微服務

• 15+ 微服務
• Kubernetes 編排
• 完整的監控、日誌、追蹤
• 用戶數：1,000,000+

這個演進過程花了 3 年。重點是：每個階段解決當下的問題，不要過早優化。

---

常見問題 FAQ

Q1: 小團隊適合微服務嗎？

不建議。5 人以下的團隊，維護微服務的基礎設施成本太高。單體架構配合模組化設計，對小團隊更友善。

Q2: 微服務和 SOA 有什麼不同？

SOA（Service-Oriented Architecture）是較早期的概念，服務粒度通常較大，常用 ESB 做集成。微服務強調更細的粒度、獨立部署、去中心化治理。

Q3: 一定要用 Kubernetes 嗎？

不一定。K8s 功能強大但學習曲線陡峭。如果服務數量少於 10 個，用 Docker Compose + 雲端託管服務可能更簡單。

Q4: 怎麼處理跨服務交易？

用 Saga Pattern 或 TCC（Try-Confirm-Cancel）。避免分散式事務，改用最終一致性。詳見高併發交易系統設計。

Q5: 微服務的資料庫怎麼設計？

每個服務擁有自己的資料庫，不共享。服務間通過 API 交換資料，而不是直接查對方的資料庫。

---

結論：架構是演進出來的

沒有一開始就完美的架構，只有適合當下的架構。

本文重點回顧：

1. 單體架構適合早期，但有擴展上限
2. 垂直擴展簡單，水平擴展靈活，兩者搭配使用
3. 分層架構讓每層獨立擴展
4. 微服務不是銀彈，拆分要有明確理由
5. 服務治理（發現、配置、通訊）是微服務的基礎
6. 雲端平台提供現成的高併發架構元件

如果你正在規劃系統架構，也推薦閱讀：

• 高併發是什麼？完整指南
• 高併發資料庫設計
• 雲端高併發架構

---

架構設計需要第二意見？

好的架構能節省數倍的營運成本。如果你正在：

• 規劃新系統但不確定架構方向
• 單體架構遇到瓶頸，考慮拆分
• 評估要用哪家雲端服務

預約架構諮詢，讓我們一起檢視你的系統架構。

所有諮詢內容完全保密，沒有銷售壓力。

---

參考資料

1. Sam Newman，《Building Microservices》（2021）
2. Martin Fowler，〈Microservices〉（2014）
3. Chris Richardson，《Microservices Patterns》（2018）
4. AWS，《Well-Architected Framework》（2024）
5. Google Cloud，《Microservices Architecture on Google Cloud》（2024）