xDev Asia

Monolith 的實際遷移路線圖。絞殺者無花果圖案。單體分析：熱點、耦合、依賴。遷移後端：Extract Service。遷移前端：提取 MFE。雙寫，資料遷移。時間表和團隊組織。

微服務與微前端系統設計－從基礎到生產

第 10 部分：案例研究和遷移指南

亞洲開發網

簡介

大多數實用的系統都是從一個整體開始的－而且是一個好的整體！遷移到微服務+微前端是一個漫長的過程，而不是一次大爆炸重寫。本文將引導您完成安全、逐步的遷移路徑。

Strangler Fig 模式 — 從整體遷移到微服務

1. 扼殺者無花果圖案

1.1 想法

Strangler Fig Tree: cây phụ bao quanh cây chủ,
dần dần thay thế cho đến khi cây chủ biến mất.

Phase 1: Monolith xử lý mọi thứ
┌──────────────────────┐
│      Monolith        │
│ Users│Products│Orders│
└──────────────────────┘

Phase 2: Extract service, route traffic
┌───────────────────────┐
│     API Gateway       │
├───────────┬───────────┤
│ Monolith  │  Product  │
│ (Users,   │  Service  │
│  Orders)  │  (new)    │
└───────────┴───────────┘

Phase 3: Extract more services
┌───────────────────────────┐
│       API Gateway         │
├────────┬────────┬─────────┤
│Monolith│Product │  Order  │
│(Users) │Service │ Service │
│        │        │  (new)  │
└────────┴────────┴─────────┘

Phase N: Monolith is gone
┌────────────────────────────────┐
│          API Gateway           │
├────────┬────────┬──────────────┤
│  User  │Product │    Order     │
│Service │Service │   Service    │
└────────┴────────┴──────────────┘

2. 遷移評估

2.1 整體分析

Trước khi migration, hiểu monolith:

Code Analysis:
├── Module coupling (which modules call which?)
├── Database coupling (shared tables?)
├── Hot spots (most changed code)
├── Complexity (cyclomatic, LOC)
└── Team ownership (ai maintain gì?)

Prioritization Matrix:
┌──────────────────────────────────────┐
│         Business Value               │
│ High │ ★ Extract first │ Rewrite    │
│      │   (Product,     │ later      │
│      │    Order)       │            │
│──────┼─────────────────┼────────────│
│ Low  │ Leave in        │ Consider   │
│      │ monolith        │ removing   │
│      │ (low ROI)       │            │
│      └──── Low ─────── High ────────│
│           Change Frequency           │
└──────────────────────────────────────┘

3. 後端遷移手冊

3.1 第 1 階段：API 閘道（第 1-4 週）

1. Deploy API Gateway trước monolith
2. Route ALL traffic qua Gateway
3. Gateway forward mọi thứ đến Monolith
4. Không thay đổi behavior — chỉ thêm routing layer

Frontend → API Gateway → Monolith (no change)

3.2 第 2 階段：提取第一個服務（第 5-12 週）

Chọn service ít coupling nhất (ví dụ: Product Catalog)

Steps:
1. Create Product Service (new codebase)
2. Copy/rewrite product logic
3. Setup database (copy product tables)
4. Dual-write: monolith write cả old DB + new service
5. Verify data consistency
6. Switch reads: Gateway route GET /products → new service
7. Switch writes: Gateway route POST/PUT /products → new service
8. Remove product code from monolith
9. Drop product tables from monolith DB (after verification)

3.3 資料遷移策略

Dual-Write Pattern:

Phase A: Monolith writes to Old DB + New DB
         Reads from Old DB
         → Verify New DB data matches

Phase B: Monolith writes to Old DB + New DB
         Reads from New DB (switch)
         → Verify reads correct

Phase C: New Service writes to New DB only
         Monolith no longer involved
         → Clean up Old DB tables

4. 前端遷移手冊

4.1 第 1 階段：Shell 應用程式（第 1-4 週）

1. Create Shell App (new React app)
2. Shell wraps existing monolith frontend (iframe initially)
3. Shell provides Header, Footer, Navigation
4. Gradually replace iframe sections with MFEs

4.2 第 2 階段：提取第一個 MFE（第 5-8 週）

Extract Product pages as first MFE:

1. Create product-mfe project
2. Configure Module Federation (expose ProductList, ProductDetail)
3. Shell loads product-mfe via Module Federation
4. Remove product pages from monolith frontend
5. Verify routing, styling, functionality

Shell App
├── Header (Shell)
├── /products/* → Product MFE (new, Module Federation)
├── /cart/* → Monolith Frontend (iframe, temporary)
├── /orders/* → Monolith Frontend (iframe, temporary)
└── Footer (Shell)

4.3 逐步更換

Month 1: Shell + Product MFE
Month 2: + Cart MFE
Month 3: + Order MFE
Month 4: + Account MFE
Month 5: Remove iframe, monolith frontend retired

5. 遷移反模式

❌ Big Bang Rewrite
   → 12-18 months later: "it's not ready yet"
   → Business can't wait, original monolith diverges

❌ Extract based on technical layers
   → "API service", "DB service", "Auth service"
   → Should be business domains: Product, Order, User

❌ Shared database between old and new
   → Defeats the purpose of database per service
   → Temporal coupling, schema changes break both

❌ Migration without observability
   → Can't compare old vs new behavior
   → Can't detect regressions

6. 遷移時間表（典型）

E-Commerce Monolith → Microservices + MFE:

Month 1-2:  Infrastructure setup
            (K8s, CI/CD, monitoring, API Gateway)

Month 3-4:  First service extraction
            (Product Service + Product MFE)

Month 5-6:  Second service extraction
            (Order Service + Order MFE)

Month 7-8:  Third + Fourth services
            (Cart, User)

Month 9-10: Supporting services
            (Payment, Notification, Inventory)

Month 11-12: Cleanup monolith
              Remove old code, drop old tables

Ongoing:    Optimize, add services as needed

7. 成功指標

指標	前（整體）	之後（微*）
部署頻率	1/週	每隊 5-10 次/天
交貨時間	2 週	1-2 天
平均修復時間	2-4小時	15-30 分鐘
改變失敗率	15%	< 5%
團隊自治	低（公關衝突）	高（獨立）
建置時間	15 分鐘	2-3 分鐘（每次服務）

總結

扼殺者圖模式：逐漸遷移，而不是大爆炸重寫
依業務領域擷取，而非技術層
雙寫保證資料遷移安全
首先是 API 閘道 → 增量路由流量
前端：Shell App→一一提取MFE
時間表：典型電子商務為 9-12 個月
衡量成功：部署頻率、交貨時間、MTTR

🎉 恭喜您完成本系列！

你已經經歷了整個旅程：

平台：單體→微服務→微前端演進
後端：服務分解、API設計、非同步通信
資料：每個服務的資料庫、Saga、事件溯源
前端：微前端架構、模組聯合、Shell App
整合：BFF、API 網關、GraphQL 聯合
品質：測試策略、合約測試
部署：CI/CD、Canary、GitOps
生產：可觀察性、性能、安全性
實踐：個案研究、遷移指南

**下一篇：**應用於實際專案！從小處著手，儘早驗證，快速迭代。

第 30 課：遷移指南 — 從整體架構到微服務與微前端

簡介