Giới thiệu
Hầu hết các hệ thống phần mềm đều bắt đầu là Monolith — và điều đó hoàn toàn đúng đắn. Nhưng khi hệ thống phát triển, team mở rộng, và yêu cầu thay đổi liên tục, kiến trúc Monolith dần trở thành bottleneck. Bài học này giúp bạn hiểu toàn bộ hành trình tiến hóa kiến trúc phần mềm và tại sao Microservices + Micro Frontend là đích đến cho các hệ thống phức tạp.
1. Monolith — Điểm khởi đầu hợp lý
1.1 Kiến trúc Monolith là gì?
Monolith là kiến trúc mà toàn bộ ứng dụng được xây dựng, deploy và scale như một đơn vị duy nhất. Tất cả các module (User, Product, Order...) chạy trong cùng một process, chia sẻ cùng database, và deploy cùng nhau.
1.2 Ưu điểm của Monolith
| Ưu điểm | Mô tả |
|---|---|
| Đơn giản | Dễ phát triển, debug, test ban đầu |
| Dễ deploy | Chỉ cần deploy 1 artifact |
| Performance | Gọi function nội bộ (in-process) thay vì qua network |
| ACID Transactions | Dễ dàng thực hiện transaction xuyên module |
| Dễ refactor | IDE hỗ trợ tốt, tìm kiếm và đổi tên dễ dàng |
1.3 Khi nào Monolith trở thành vấn đề?
Khi hệ thống phát triển, Monolith gặp phải các bottleneck:
Về Development:
- Codebase quá lớn, dev mới cần nhiều thời gian để hiểu
- Build time tăng lên hàng chục phút
- Merge conflicts liên tục giữa các team
- Một bug nhỏ có thể crash toàn bộ hệ thống
Về Deployment:
- Deploy toàn bộ ứng dụng cho 1 thay đổi nhỏ
- Release cycle kéo dài (tuần/tháng)
- Rollback phức tạp, ảnh hưởng toàn bộ
Về Scaling:
- Phải scale toàn bộ khi chỉ 1 module cần thêm tài nguyên
- Không thể dùng technology khác nhau cho từng phần
Rule of thumb: Nếu bạn có dưới 5 developers và hệ thống chưa quá phức tạp, Monolith vẫn là lựa chọn tốt nhất.
2. Hành trình tiến hóa kiến trúc
2.1 Monolith → SOA → Microservices
Timeline:
2000s 2010s 2015+ 2020+
┌──────┐ ┌──────────┐ ┌──────────────┐ ┌───────────────────┐
│Monolith│ → │ SOA │ → │ Microservices│ → │ Microservices + │
│ │ │Services │ │ │ │ Micro Frontend │
└──────┘ └──────────┘ └──────────────┘ └───────────────────┘
2.2 SOA (Service-Oriented Architecture)
SOA là bước đầu tiên tách Monolith thành các services. Tuy nhiên, SOA có một số hạn chế:
- Sử dụng ESB (Enterprise Service Bus) tập trung → single point of failure
- Services thường không thực sự độc lập (shared database, shared libraries)
- Protocol phức tạp (SOAP, WS-*)
2.3 Microservices — SOA done right
Microservices kế thừa ý tưởng SOA nhưng với các nguyên tắc cốt lõi:
┌──────────────────────────────────────────────────────┐
│ API GATEWAY │
└──────┬──────────┬──────────────┬─────────────────────┘
│ │ │
┌────┴────┐ ┌───┴────┐ ┌─────┴─────┐
│ User │ │Product │ │ Order │
│ Service │ │Service │ │ Service │
│ │ │ │ │ │
│ ┌─────┐ │ │┌─────┐ │ │ ┌──────┐ │
│ │ DB │ │ ││ DB │ │ │ │ DB │ │
│ └─────┘ │ │└─────┘ │ │ └──────┘ │
└─────────┘ └────────┘ └───────────┘
Mỗi service: Own database, Own deployment, Own team
So sánh SOA vs Microservices:
| Tiêu chí | SOA | Microservices |
|---|---|---|
| Communication | ESB (centralized) | Smart endpoints, dumb pipes |
| Data | Shared DB phổ biến | Database per service |
| Size | Có thể rất lớn | Nhỏ, focused |
| Deploy | Thường deploy cùng | Independent deployment |
| Technology | Thường homogeneous | Polyglot |
3. Frontend Monolith — Vấn đề bị bỏ quên
3.1 Backend đã tách, Frontend vẫn gộp
Nhiều tổ chức đã áp dụng Microservices cho backend, nhưng frontend vẫn là một ứng dụng SPA khổng lồ (React/Angular/Vue monolith).
3.2 Hệ quả của Frontend Monolith
- Code coupling: Tất cả team đóng góp vào cùng 1 repo frontend
- Tech lock-in: Không thể dần dần upgrade framework
- Slow builds: Bundle size ngày càng lớn
- Deployment bottleneck: Phải deploy toàn bộ frontend
- Team dependencies: Team A chờ Team B merge code
3.3 Micro Frontend — giải pháp
┌─────────┐ ┌──────────┐ ┌─────────────┐
│ User │ │ Product │ │ Order │
│ MFE │ │ MFE │ │ MFE │
│ (React) │ │ (Vue) │ │ (React) │
└────┬────┘ └─────┬────┘ └──────┬──────┘
│ │ │
└─────────┬───┴──────────────┘
│
┌─────────┴──────────┐
│ SHELL / CONTAINER │
│ Application │
└────────┬────────────┘
│
┌─────────────┴────────────────────────┐
│ API GATEWAY │
└──────┬──────────┬──────────┬─────────┘
┌────┴────┐ ┌───┴────┐ ┌──┴────────┐
│User µS │ │Product │ │Order µS │
└─────────┘ └────────┘ └───────────┘
4. Khi nào nên chuyển đổi?
4.1 Signals cần Microservices
- Team > 10 người làm việc trên cùng codebase
- Release bị block bởi team khác
- Scaling không đều: 1 module cần scale nhưng phải scale tất cả
- Technology lock-in: muốn dùng tech mới nhưng không thể
- Failure cascade: 1 bug crash toàn bộ hệ thống
4.2 Signals cần Micro Frontend
- Nhiều team phát triển feature trên cùng frontend app
- Frontend build time > 5 phút
- Merge conflicts frontend thường xuyên
- Muốn upgrade framework nhưng phải đổi toàn bộ
- Independent release cho từng phần UI
4.3 Khi nào KHÔNG nên?
Don't fix what ain't broken.
- Team nhỏ (< 5 devs) → Monolith là đủ
- MVP / Startup → Tốc độ phát triển quan trọng hơn kiến trúc
- Hệ thống đơn giản, ít thay đổi → Over-engineering
- Team chưa đủ kinh nghiệm DevOps → Microservices tăng operational complexity
5. Tổng quan series này
5.1 Roadmap học tập
Phần 1-3: Backend Foundation → DDD, Service Design, Data Architecture
Phần 4-5: Micro Frontend → Architecture, Implementation, Design System
Phần 6: Integration Layer → BFF, API Gateway, GraphQL Federation
Phần 7-8: Quality & Deploy → Testing, CI/CD, Deployment Strategies
Phần 9: Production → Observability, Performance, Readiness
Phần 10: Real World → Case Study, Migration Guide
5.2 Dự án xuyên suốt
Xuyên suốt series, chúng ta sẽ thiết kế một E-Commerce Platform hoàn chỉnh:
- 5 Microservices: User, Product, Cart, Order, Payment
- 5 Micro Frontends: Homepage, Product Detail, Cart, Checkout, Account
- Shared: Design System, Auth, API Gateway
Tóm tắt
| Kiến trúc | Khi nào dùng | Tradeoff chính |
|---|---|---|
| Monolith | Team nhỏ, MVP, hệ thống đơn giản | Dễ bắt đầu, khó scale |
| Microservices | Team lớn, cần scale độc lập | Phức tạp hóa ops & data |
| Micro Frontend | Nhiều team FE, cần deploy độc lập | Tăng bundle size, cần design system |
| Full-stack (MS + MFE) | Tổ chức lớn, sản phẩm phức tạp | Cần DevOps maturity cao |
Đọc thêm
- Martin Fowler — Microservices
- Martin Fowler — Micro Frontends
- microservices.io — Pattern Language
- micro-frontends.org
Bài tiếp theo: Bài 2: Domain-Driven Design — Tư duy phân tách hệ thống