Monolith, Modular Monolith hay Microservices: Chọn ranh giới triển khai phù hợp

Tóm tắt nhanh (TL;DR)

Hiếm có hệ thống nào sụp đổ chỉ vì codebase mang danh "Monolith". Nhưng vô số dự án đã rơi vào vũng lầy kiệt quệ khi vội vã xẻ nhỏ hệ thống thành 20 microservices theo trào lưu Big Tech: một tính năng đơn giản đòi hỏi phối hợp phát hành đồng loạt trên 5 repository khác nhau; việc debug lỗi nghiệp vụ trở thành cơn ác mộng dò tìm log phân tán; và chỉ một cú chập chờn mạng nội bộ cũng đủ kéo sập dây chuyền toàn bộ ứng dụng. Kiến trúc phần mềm không phải là bảng xếp hạng danh tiếng—đó là bài toán cân não giữa tính toàn vẹn dữ liệu, chi phí vận hành phân tán và sự tự chủ phát hành thực tế của đội ngũ.

💡 Quy tắc bỏ túi: Luôn bắt đầu với mô hình triển khai ít phân tán nhất đáp ứng được các ràng buộc kỹ thuật thực tế. Hãy cưỡng chế ranh giới module nghiêm ngặt trong mã nguồn trước khi dựng ranh giới mạng. Chỉ tách microservice khi việc triển khai độc lập tạo ra giá trị đo lường được—chẳng hạn như gỡ bỏ nút thắt release giữa các team, cô lập tải biến động đặc thù hoặc khoanh vùng rủi ro sự cố.

• Hình thái triển khai không đồng nghĩa với chất lượng mã nguồn: Monolith hoàn toàn có thể có cấu trúc module mẫu mực và sạch sẽ, trong khi chia microservices cẩu thả sẽ tạo ra một "Monolith phân tán" tệ hại với chi phí vận hành đắt đỏ gấp bội.
• Lời gọi hàm in-memory giữ trọn giao dịch ACID: Monolith và Modular Monolith tận dụng bộ nhớ cục bộ và một cơ sở dữ liệu duy nhất, loại bỏ hoàn toàn gánh nặng phải thiết kế Saga, Outbox hay quy trình bù trừ (Compensating workflow) phức tạp.
• Triển khai độc lập luôn đi kèm "thuế phân tán" (Distribution Tax): Microservices đem lại sự tự chủ phát hành cho các team lớn hoạt động độc lập, nhưng đòi hỏi hạ tầng tự động hóa cao: CI/CD độc lập, Distributed Tracing, API Gateway và năng lực xử lý lỗi cục bộ (Partial Failure).
• Gánh nặng vận hành phụ thuộc vào số lượng bản triển khai: Chi phí giám sát, mạng lưới giao tiếp, bảo mật và áp lực trực on-call tỷ lệ thuận với số lượng tiến trình độc lập thay vì số dòng code.
• Cạm bẫy chết người: Tách microservice khi ranh giới nghiệp vụ chưa ổn định. Tách dịch vụ khi các domain model còn thay đổi liên tục sẽ dẫn đến thảm họa gọi chéo database, transaction phân tán và phát hành đồng loạt kiểu bậc thang (lockstep deployment)—chịu trọn rủi ro của hệ phân tán mà không thu về được chút tự chủ nào.

Khung đánh giá quyết định

Hãy làm rõ các lực cản kỹ thuật trước khi gán mác một tên gọi kiến trúc:

• Có bao nhiêu đội ngũ kỹ thuật thực sự cần lịch phát hành (release schedule) độc lập?
• Những mảng nghiệp vụ nào có ranh giới ổn định và tốc độ thay đổi khác biệt rõ rệt?
• Những thao tác nào được hưởng lợi tối đa từ một giao dịch ACID nội bộ?
• Những tải công việc nào đòi hỏi chính sách mở rộng (scaling), tính sẵn sàng hoặc môi trường runtime khác biệt rõ rệt?
• Tổ chức có đủ năng lực vận hành hệ thống nhiều tiến trình phân tán: cơ sở dữ liệu riêng, giám sát phân tán, cảnh báo, hợp đồng tương thích API và lịch trực on-call phức tạp không?
• Nỗi đau hiện tại bắt nguồn từ việc phải phối hợp triển khai, hay do ranh giới mô-đun trong mã nguồn bị lỏng lẻo?

So sánh chi tiết 3 mô hình

Monolith (Nguyên khối truyền thống)

Monolith được phát hành như một khối ứng dụng duy nhất. Nó có thể được cấu trúc rất tốt hoặc bị gắn kết chặt chẽ (spaghetti code); "monolith" chỉ hình thái triển khai, không phản ánh chất lượng code.

Các lời gọi hàm diễn ra cục bộ trong bộ nhớ (in-memory), các giao dịch dữ liệu nằm gọn trong một cơ sở dữ liệu ACID, và việc gỡ lỗi không phải đi qua nhiều chặng mạng. Đánh đổi lại là tất cả các mô-đun phải chia sẻ chung một chu kỳ release.

Modular Monolith (Nguyên khối theo mô-đun)

Modular Monolith giữ nguyên mô hình 1 đơn vị triển khai nhưng áp đặt các ranh giới nghiệp vụ nghiêm ngặt bên trong mã nguồn. Các mô-đun chỉ giao tiếp qua interface định sẵn, ẩn giấu chi tiết cài đặt và kiểm soát chặt chẽ quy tắc phụ thuộc dữ liệu.

Đây là lựa chọn lý tưởng khi tổ chức cần ranh giới phân quyền rõ ràng nhưng việc triển khai chung vẫn hoạt động hiệu quả. Nó cũng là phép thử thực tế: nếu một ranh giới nghiệp vụ không thể giữ sạch sẽ bên trong 1 tiến trình thì việc đẩy nó ra sau một API mạng chỉ biến nó thành một "Monolith phân tán" với đầy đủ các lỗi phức tạp của hệ phân tán.

Modular Monolith hoàn toàn có thể là kiến trúc đích lâu dài của nhiều hệ thống lớn.

Microservices (Kiến trúc vi dịch vụ)

Microservices tách các ranh giới nghiệp vụ thành các dịch vụ triển khai độc lập, giao tiếp qua API mạng hoặc hàng đợi sự kiện (Event-driven), sở hữu cơ sở dữ liệu riêng biệt.

Ma trận đánh giá quyết định

Tình huống thực tế trên Production

Tình huống: Bẫy "Zombie User" khi tách dịch vụ quá vội vàng

Một startup 15 kỹ sư quyết định chia tách ứng dụng cốt lõi thành 12 microservices ngay từ giai đoạn sơ khởi. Trong quy trình đăng ký tài khoản mới:

1. auth-service tạo thành công tài khoản và mật khẩu trong cơ sở dữ liệu xác thực.
2. auth-service gọi HTTP sang profile-service để tạo hồ sơ người dùng.
3. Do mạng nội bộ chập chờn (network jitter), cuộc gọi đến profile-service bị timeout sau 5 giây.

Vì không thiết kế giao dịch phân tán (Saga) hay cơ chế bù trừ (Compensation), hệ thống bỏ dở quy trình và báo lỗi cho người dùng. Khách hàng rơi vào trạng thái "Zombie": họ không thể đăng nhập vì chưa có hồ sơ cá nhân, nhưng cũng không thể đăng ký lại vì email đã bị auth-service ghi nhận là đã tồn tại! Đội ngũ kỹ sư đã phải mất tới 30% thời gian làm việc mỗi tuần chỉ để viết script chạy bằng tay nhằm đối soát và dọn dẹp dữ liệu rác giữa 12 database khác nhau.

• Hậu quả: Trải nghiệm người dùng tồi tệ, tỷ lệ rơi rụng khách hàng mới cao, đội ngũ kiệt sức vì vận hành thủ công.
• Nguyên nhân cốt lõi: Áp dụng ranh giới mạng khi chưa chuẩn bị các giải pháp xử lý lỗi cục bộ (Partial Failure) và tính nhất quán cuối cùng (Eventual Consistency).
• Cách khắc phục chuẩn:
  1. Nếu còn ở quy mô nhỏ, giữ quy trình đăng ký trong một Modular Monolith để hoàn tất trong 1 giao dịch ACID duy nhất (BEGIN ... COMMIT).
  2. Nếu bắt buộc phải tách microservices, triển khai mô hình Transactional Outbox và thông điệp sự kiện bất đồng bộ qua message broker (Kafka/RabbitMQ) đảm bảo profile-service luôn nhận được thông báo để hoàn thành việc tạo hồ sơ.

Bẫy "Distributed Monolith" cần tránh

Cây quyết định kiến trúc (Decision Tree)

Bài tập củng cố tư duy

Tình huống: Một đội ngũ gồm 6 kỹ sư quản lý một website thương mại điện tử chạy dưới dạng Monolith duy nhất. Thời gian build kiểm thử mất 12 phút, và việc triển khai diễn ra 2 ngày một lần. Một kỹ sư đề xuất: "Chúng ta hãy đập Monolith ra làm 8 microservices ngay lập tức để giảm thời gian build và mỗi lập trình viên có thể tự do triển khai độc lập."

Là một kỹ sư trưởng đánh giá kiến trúc, bạn sẽ nhận định đề xuất này ra sao?

Checklist đánh giá kiến trúc

• Độ ổn định của ranh giới: Ranh giới nghiệp vụ đã đủ ổn định để bảo vệ bằng interface trước khi đẩy nó ra sau mạng chưa?
• Ma sát phát hành thực tế: Việc triển khai chung có thực sự gây trễ tiến độ hay rủi ro cho các nhóm sở hữu khác nhau không?
• Ranh giới giao dịch: Những giao dịch nào sẽ phải vượt qua ranh giới dịch vụ, và cơ chế khôi phục lỗi khi bước sau thất bại là gì?
• Xử lý lỗi cục bộ: Chuyện gì xảy ra khi dịch vụ phía trước thành công nhưng dịch vụ phía sau bị timeout không rõ kết quả?
• Khả năng quan sát (Telemetry): Hệ thống có cơ chế truyền Correlation ID và Distributed Tracing để theo dõi một luồng nghiệp vụ qua các dịch vụ không?
• Quyền sở hữu khi có sự cố: Mỗi dịch vụ có một đội ngũ chịu trách nhiệm trực tiếp với runbook và trực on-call rõ ràng không?
• Nhu cầu co giãn tải thực chứng: Yêu cầu mở rộng độc lập bắt nguồn từ số liệu đo đạc trên production hay chỉ là giả định lý thuyết?
• Kiểm nghiệm trong mã nguồn trước: Các ranh giới mô-đun và quy tắc phụ thuộc đã được kiểm tra và thực thi nghiêm ngặt trong 1 bản triển khai trước khi tách rời chưa?

Nguồn tham khảo chuẩn mực

• Microservices — Martin Fowler and James Lewis
• MonolithFirst — Martin Fowler
• Microservices architecture style — Azure Architecture Center