Monolith không phải từ xấu
Monolith là một ứng dụng lớn chứa toàn bộ tính năng. Nó đơn giản, dễ test, ít lỗi mạng, một lệnh deploy. Với team 5-20 người, monolith thường là lựa chọn đúng đắn nhất.
| Tiêu chí | Monolith | Microservices |
|---|---|---|
| Triển khai | Một lệnh | Nhiều pipeline phối hợp |
| Debug | Dễ: chạy trên một máy | Khó: truy vết qua nhiều service |
| Mở rộng | Mở rộng cả app | Mở rộng từng service theo nhu cầu |
| Cô lập lỗi | Lỗi một chỗ kéo cả app | Lỗi gói trong một service |
| Chi phí vận hành | Thấp | Cao: observability, network, versioning |
Vì sao người ta tách
Tách khi có dấu hiệu thật, không phải khi “nghe hay”: một module được deploy riêng nhanh hơn, một module cần mở rộng khác hẳn, đội phát triển độc lập, hoặc chính sách công nghệ khác nhau.
⚠ Dấu hiệu NHẦM để tách
“Để code sạch hơn” — KHÔNG, sạch là việc của module. “Để mở rộng” — KHÔNG, mở rộng monolith bằng nhiều instance là được. Tách sai thời điểm làm chậm mọi thứ gấp nhiều lần.
Modular monolith: điểm cân bằng
Monolith nhưng chia rõ module, mỗi module có API nội bộ riêng, cấm import chéo lung tung. Sau này cần tách service nào thì “bóc” module đó ra — rủi ro thấp, linh hoạt cao. Đây là lời khuyên của đa số senior hiện nay.
❓ Team 6 người, sản phẩm mới, chưa biết scale thế nào. Kiến trúc hợp lý nhất?
- Trình bày được ưu nhược điểm hai mô hình
- Nhận diện dấu hiệu thật vs dấu hiệu nhầm để tách
- Thiết kế modular monolith an toàn
- Không chọn microservices chỉ vì trend