Giả sử bạn đã xây dựng ứng dụng theo kiểu monolith được 6 tháng. Mọi thứ vẫn ổn — cho đến khi nhóm của bạn bắt đầu “choảng nhau” vì conflict khi merge code. Việc deploy mất 30 phút. Một lỗi nhỏ trong module thanh toán khiến cả ứng dụng sập. Và rồi, microservices thì thầm: “Tách anh ra đi…”
Nhưng khoan đã. Việc chia nhỏ có thực sự là lời giải? Hay chỉ là một cái bẫy ngọt ngào? Hãy cùng nhau bóc tách vấn đề khỏi những định kiến mù quáng nhé.
Monolith: Căn hộ studio ấm cúng (nhưng chật chội) của bạn
Ưu điểm:
- Cực kỳ đơn giản: Một codebase, một lần deploy, một database.
- Trải nghiệm dev dễ chịu: Chạy/debug chỉ với npm start.
- Không hỗn loạn phân tán: Không có gọi mạng, không cần khám phá dịch vụ.
Nhược điểm:
- Nỗi ám ảnh khi deploy: Đổi một cái nút? Có thể làm hỏng cả ứng dụng.
- Khó mở rộng: Không thể scale riêng module AI bị quá tải.
- Va chạm trong team: 10 dev giẫm chân nhau trên nhánh chính mỗi ngày.
Khi nào nên giữ nguyên kiểu monolith:
- Cả nhóm của bạn vừa đủ hiển thị trong một màn hình Zoom.
- Bạn vẫn chưa đạt được “product-market fit”.
- Bạn chưa từng nói: “SRE sẽ lo vụ quan sát hệ thống đó!”
Microservices: Biệt thự siêu rộng nhưng chia nhỏ thành từng phòng
Ưu điểm:
- Scale đúng chỗ: Đẩy dịch vụ AI nặng GPU lên 100 instance; giữ billing ở mức 1.
- Tự chủ theo nhóm: Nhóm frontend sở hữu dịch vụ Next.js; nhóm thanh toán sở hữu Go service.
- Tự do công nghệ: Dùng Python cho ML, Rust cho xử lý video, Node cho API.
Nhược điểm:
- Địa ngục phân tán: Truy vết request qua 5 dịch vụ? Chúc may mắn.
- Chi phí vận hành cao: Kubernetes, Istio, Prometheus… chào mừng bạn đến với công việc DevOps toàn thời gian.
- Dữ liệu phân mảnh: “Sao địa chỉ người dùng lại xuất hiện ở ba database khác nhau?!”
Khi nào nên tách nhỏ:
- Các nhóm bị chặn vì chờ deploy (ví dụ: mobile vs. web).
- Các module quan trọng cần scale độc lập (ví dụ: dịch vụ giỏ hàng ngày Black Friday).
- Bạn thực sự có đủ nhân lực DevOps.
Điểm gãy trong thực tế: Câu chuyện của một startup Fintech
Startup X gắn bó với monolith dùng Rails cho đến khi:
- Deploy: Từ 45 phút → đóng băng deploy mỗi ngày.
- Sự cố: Một bản sửa CSS làm hệ thống duyệt khoản vay sập.
- Giận dữ: 20 dev sống trong “địa ngục merge conflict”.
Chiến lược tách:
- Tách module Thanh toán (Go + PostgreSQL) → trở thành một service độc lập có thể deploy riêng.
- Tách module Thông báo (Node.js + Redis) → scale độc lập.
- Giữ module Hồ sơ người dùng trong monolith (vì ràng buộc quá chặt).
Kết quả:
- Deploy: Từ 45 phút → 2 phút (mỗi service).
- MTTR: Từ 4 tiếng → 15 phút (do lỗi được cô lập).
- Chi phí: Tuy nhiên cần thuê thêm 3 DevOps.
Quy tắc vàng khi tách ứng dụng
Chỉ nên tách khi:
- (Team cảm thấy mệt mỏi) + (Nhu cầu scale) > (Chi phí vận hành)
Dấu hiệu cần tách:
- Deploy thất bại mỗi ngày vì thay đổi không liên quan.
- Một module chiếm 80% tài nguyên hệ thống.
- Các nhóm giẫm chân nhau liên tục.
Đừng tách chỉ vì:
- Mơ mộng “code sạch”.
- AWS bảo bạn làm vậy.
- Bạn chưa xác định rõ điểm nghẽn hệ thống.
Giải pháp kết hợp: Monolith theo kiểu mô-đun
Không dám “chơi lớn” với microservices? Hãy thử:
- Tổ chức theo module:
/src /payments // Independent domain /notifications /users
- Shared Kernel: Chia sẻ các công cụ như auth, logging, utils.
- Deploy cùng nhau, build riêng lẻ:
nx run payments:build # Build only payments
Công cụ gợi ý: Nx, Turborepo, Lerna.
Checklist chống hối hận
Trước khi tách:
- Phân tích trước: Dùng Pyroscope/Datadog để xác định bottlenecks thực sự.
- Cắt ranh giới rõ ràng: Thanh toán ≠ Xác thực người dùng.
- Chuẩn hóa hệ thống quan sát: Thiết lập Jaeger (tracing), Prometheus (metrics) trước khi tách.
- Thử nghiệm sự cố: Dùng chaos monkey test trên một service trước.
Tóm tắt:
- Monolith: Tốt cho tốc độ, nhóm nhỏ, và sự đơn giản.
- Microservices: Phù hợp để scale có chọn lọc, nhóm lớn, và đa dạng công nghệ.
- Chỉ tách khi: Nỗi đau > chi phí vận hành. Nếu không? Bạn chỉ đang đổi một cái tủ quần áo lộn xộn lấy một cái nhà kho đang cháy.
Việc bạn cần làm:
- Kiểm tra ứng dụng: Đâu là nỗi đau thực sự?
- Nếu cần tách: Bắt đầu từ một service ít rủi ro.
- Đừng chia nhỏ chỉ vì “cảm thấy đúng”.