簡介
本文總結了前28篇文章的所有知識，應用於實際的電子商務平台。從架構決策→實作→部署→監控。
1. 系統需求
1.1 業務需求
ShopX E-Commerce Platform:
├── Product catalog: 100K+ products
├── Users: 500K registered, 50K DAU
├── Orders: 5K orders/day, peak 500 orders/hour
├── Teams: 5 feature teams + 1 platform team
├── SLA: 99.9% uptime, p95 < 500ms
└── Growth: 3x yearly
1.2 架構決策記錄（ADR）
ADR-001: Microservices Architecture
- Status: Accepted
- Context: Monolith đã quá lớn (500K LOC), 5 teams conflict
- Decision: Decompose thành Microservices theo DDD
- Consequences: Distributed complexity, cần invest vào infra
ADR-002: Micro Frontend with Module Federation
- Status: Accepted
- Context: Frontend monolith (React, 300+ components)
- Decision: Module Federation, 1 MFE per team
- Consequences: Shared UI library cần, performance budget enforce
ADR-003: Event-Driven Architecture (Kafka)
- Status: Accepted
- Context: Cần loose coupling, event replay, audit trail
- Decision: Apache Kafka cho domain events
- Consequences: Eventual consistency, team cần learn async patterns
2. 服務設計（基於DDD）
Bounded Contexts → Services:
┌─────────────────────────────────────────────────┐
│ Core Domain │
│ ├── Product Service (Catalog, Search, Review) │
│ │ DB: PostgreSQL + Elasticsearch │
│ │ Team: Product Team (4 devs) │
│ │ │
│ └── Order Service (Checkout, Tracking, History) │
│ DB: PostgreSQL (Event Sourcing) │
│ Team: Order Team (4 devs) │
├─────────────────────────────────────────────────┤
│ Supporting Domain │
│ ├── User Service (Auth, Profile, Address) │
│ │ DB: PostgreSQL │
│ ├── Cart Service (Cart, Wishlist) │
│ │ DB: Redis │
│ ├── Inventory Service (Stock, Warehouse) │
│ │ DB: PostgreSQL │
│ └── Notification Service (Email, Push, SMS) │
│ DB: PostgreSQL │
├─────────────────────────────────────────────────┤
│ Generic Domain │
│ ├── Payment Service → Stripe/VNPay integration │
│ └── Auth → Keycloak (off-the-shelf) │
└─────────────────────────────────────────────────┘
3.微前端分解
Shell App (Platform Team):
├── Global Header, Footer, Sidebar
├── Routing orchestration
├── Auth integration (Keycloak)
└── Design System (@shopx/ui)
Product MFE (Product Team):
├── Product List / Grid
├── Product Detail
├── Search & Filters
├── Reviews
└── Route: /products/*
Cart MFE (Cart Team):
├── Cart Page
├── Mini Cart (header widget)
├── Wishlist
└── Route: /cart/*, globally: MiniCart component
Order MFE (Order Team):
├── Checkout flow
├── Order History
├── Order Tracking
└── Route: /orders/*, /checkout/*
Account MFE (User Team):
├── Profile, Addresses
├── Payment Methods
├── Preferences
└── Route: /account/*
4.基礎架構架構
AWS Architecture:
┌─────────────────────────────────────────────┐
│ CloudFront CDN │
│ (MFE static assets, caching) │
├─────────────────────────────────────────────┤
│ ALB (Application Load Balancer) │
├─────────────────────────────────────────────┤
│ EKS Cluster (Kubernetes) │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Kong │ │ Web BFF │ │ Services│ │
│ │ Gateway │→│ (Node) │→│ (pods) │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Kafka │ │ Redis │ │ OTEL │ │
│ │ (MSK) │ │(Elasti- │ │Collector│ │
│ │ │ │ Cache) │ │ │ │
│ └─────────┘ └─────────┘ └─────────┘ │
├─────────────────────────────────────────────┤
│ RDS PostgreSQL (Multi-AZ) │
│ ElastiCache Redis │
│ Amazon MSK (Kafka) │
│ Amazon Elasticsearch │
└─────────────────────────────────────────────┘
5. 關鍵技術決策
| 決定 | 選擇 | 理由 |
|---|---|---|
| 前端框架 | React + 模組聯盟 | 團隊專業知識、MFE 支援 |
| 後端執行時期 | Node.js（Fastify） | 與 FE 相同的語言，快速 I/O |
| API風格 | GraphQL (BFF) + gRPC（內部） | 靈活查詢+快速內部 |
| 資料庫 | PostgreSQL + Redis + ES | 多語言、經過驗證、可擴充 |
| 訊息代理 | 阿帕契卡夫卡 | 事件溯源、重播、持久性 |
| 授權 | 鑰匙斗篷 | 開源、OIDC、RBAC |
| 持續整合/持續交付 | GitHub 作業 + ArgoCD | GitOps、K8s 原生 |
| 監控 | Grafana + Prometheus + Loki + Tempo | 完整的可觀測性堆疊 |
| 部署 | Canary（Argo 推出） | 漸進式自動分析 |
6. 經驗教訓
1. Start with 3-4 services, not 15
→ Quá nhiều services ban đầu = quá nhiều complexity
2. Design System trước khi build MFE
→ UX inconsistency rất khó fix sau
3. Contract Testing saves production
→ Đầu tư vào Pact sớm, ROI rất cao
4. Observability từ Day 1
→ Không phải "thêm sau được" — cần tracing từ đầu
5. Feature Flags cho mọi feature mới
→ Decouple deploy from release
6. Event Sourcing chỉ cho Order Service
→ CQRS cho Product (search), CRUD cho User/Cart
→ Đừng over-engineer
7. Mono-repo (Turborepo) cho giai đoạn đầu
→ Cross-cutting changes dễ, shared code seamless
→ Evaluate multi-repo khi team > 50
總結
此案例研究表明，當將正確的模式應用於正確的用例時，架構可以是實用和生產就緒。並非每個服務都需要事件溯源，並非每個前端都需要微前端。