🏗️ 微服務架構入門：從單體到微服務

📌 什麼是微服務？

微服務（Microservices）是一種軟體架構風格，將應用程式拆分成一組小型、獨立的服務，每個服務圍繞特定的業務功能建構，可以獨立開發、部署和擴展。

核心概念： 每個微服務就像一個獨立的小團隊，負責一件事，做好做滿。

📌 單體架構 vs 微服務架構

單體架構 (Monolithic Architecture)

所有功能都打包在一個應用程式中：

┌─────────────────────────────────┐
│         單體應用程式              │
│  ┌─────┐ ┌─────┐ ┌─────┐       │
│  │用戶  │ │訂單  │ │支付  │       │
│  │管理  │ │處理  │ │系統  │       │
│  └──┬──┘ └──┬──┘ └──┬──┘       │
│     └───────┼───────┘           │
│          共用資料庫               │
│       ┌──────────┐              │
│       │ Database │              │
│       └──────────┘              │
└─────────────────────────────────┘

微服務架構 (Microservices Architecture)

每個服務是獨立的應用程式，有自己的資料庫：

┌──────────┐  ┌──────────┐  ┌──────────┐
│ 用戶服務  │  │ 訂單服務  │  │ 支付服務  │
│          │  │          │  │          │
│ ┌──────┐ │  │ ┌──────┐ │  │ ┌──────┐ │
│ │ DB1  │ │  │ │ DB2  │ │  │ │ DB3  │ │
│ └──────┘ │  │ └──────┘ │  │ └──────┘ │
└──────────┘  └──────────┘  └──────────┘
     ↕              ↕              ↕
  ═══════════ API Gateway ═══════════

📌 為什麼要用微服務？優缺點分析

✅ 優點

❌ 缺點

📌 微服務的核心原則

1. 單一職責原則 (Single Responsibility)

// ✅ 好的拆分：每個服務只負責一個業務領域
public class OrderService     // 只處理訂單相關邏輯
public class InventoryService // 只處理庫存相關邏輯
public class PaymentService   // 只處理支付相關邏輯

// ❌ 不好的拆分：一個服務做太多事
public class EverythingService // 訂單 + 庫存 + 支付 + 用戶 + ...

2. 獨立部署 (Independent Deployment)

每個服務都有自己的：

• 程式碼倉庫（或 monorepo 中的獨立專案）
• CI/CD Pipeline
• 部署環境

3. 去中心化治理 (Decentralized Governance)

// 每個服務可以選擇最適合的技術棧
// 訂單服務：ASP.NET Core + SQL Server
builder.Services.AddDbContext<OrderDbContext>(opt =>
    opt.UseSqlServer(connectionString));

// 快取服務：可以用不同的資料庫
// 例如 Redis、MongoDB 等

📌 真實世界案例

Netflix

• 從單體 Java 應用遷移到 700+ 微服務
• 每天處理超過 20 億 API 請求
• 使用自研的 Eureka（服務發現）、Zuul（API Gateway）

Amazon

• 從龐大的單體架構拆分成微服務
• "兩個披薩團隊"原則：每個服務團隊不超過兩個披薩能餵飽的人數
• 這直接催生了 AWS 雲端服務

Uber

• 原本單體架構導致部署時間長達數小時
• 拆分為微服務後，各團隊可以獨立且頻繁地部署

📌 什麼時候不該用微服務？

重要提醒： 微服務不是銀彈！

❌ 不適合微服務的情境：
├── 小型專案或 MVP（單體就夠了）
├── 團隊人數少於 5 人
├── 業務邊界不明確（還在探索階段）
├── 沒有 DevOps 自動化能力
└── 對分散式系統缺乏經驗

建議的演進路線

// 階段 1：先用模組化的單體架構
// 將程式碼按業務邊界分模組，但部署為單一應用
public class ModularMonolith
{
    // 模組 A：訂單
    // 模組 B：庫存
    // 模組 C：支付
    // 各模組透過介面溝通，為未來拆分做準備
}

// 階段 2：識別出需要獨立擴展的模組，逐步拆出
// 例如：訂單模組流量特別大 → 拆成獨立服務

📌 .NET 微服務生態系工具概覽

📌 本系列學習路線圖

1. 微服務入門（本章）
2. DDD 與邊界劃分
3. 建立微服務 API
4. 服務間通訊
5. API Gateway
6. Docker 容器化
7. 韌性模式（Polly）
8. 資料管理（Saga）
9. 可觀測性
10. Kubernetes 部署

下一章： 我們將深入 Domain-Driven Design（DDD），學習如何正確劃分微服務的邊界。