Kiến trúc phần mềm monolithic: vì sao monolith vẫn thắng nhiều dự án

Kiến trúc monolithic đóng gói toàn bộ ứng dụng thành một đơn vị triển khai duy nhất. Nó vẫn thắng phần lớn dự án vừa vì ba lý do: ít thứ phải vận hành, giao dịch dữ liệu đơn giản, và chi phí thêm chức năng thấp khi ranh giới mô-đun rõ.

Tóm tắt nhanh

• Monolith không phải "mã viết lộn xộn". Monolith là một đơn vị triển khai; chất lượng bên trong do ranh giới mô-đun quyết định, không do số tiến trình.
• Ba lợi thế chi phí: chỉ một thứ để triển khai, không có lỗi mạng giữa các phần, và giao dịch dữ liệu vẫn là giao dịch của một cơ sở dữ liệu.
• Monolith thua khi có nhiều đội phải phát hành độc lập, hoặc khi tải giữa các phần lệch nhau rất lớn.
• Bốn kiểu hỏng cần tránh: ranh giới mờ, dữ liệu dùng chung không chủ, triển khai chặn mọi người, và một lỗi làm sập toàn bộ.

Monolithic là gì và không là gì

Monolithic là một đơn vị triển khai. Toàn bộ ứng dụng được đóng gói, kiểm thử và phát hành như một khối. Bên trong có thể chia thành nhiều mô-đun với ranh giới rõ, mỗi mô-đun có dữ liệu và giao diện riêng.

Monolithic không phải một mức chất lượng. Một monolith có thể được viết rất tốt hoặc rất tệ. Số tiến trình không nói gì về chất lượng mã. Một hệ microservices cũng có thể là mớ hỗn độn phân tán, chỉ khác là khó tìm lỗi hơn.

Monolithic không phải lựa chọn của người thiếu kinh nghiệm. Nhiều hệ thống lớn trên thế giới vẫn chạy dưới dạng một đơn vị triển khai và phục vụ tải rất cao. Lý do chúng không tách thường rất thực dụng: tách không giải quyết vấn đề nào có thật của chúng.

Monolithic không cấm việc tách sau này. Nếu ranh giới mô-đun bên trong rõ ràng, việc tách một mô-đun thành dịch vụ riêng là công việc có giới hạn. Nếu ranh giới mờ, tách cũng không giúp gì, vì vấn đề không nằm ở chỗ triển khai.

Tiêu chí phân biệt thực dụng: monolith tốt là monolith trong đó bạn có thể trả lời câu "mô-đun nào sở hữu dữ liệu này" trong vòng mười giây. Monolith xấu là monolith trong đó câu trả lời là "cả hệ thống".

Năm lý do monolith thắng nhiều dự án

Lý do 1 — Chỉ một thứ để triển khai và giám sát

Mỗi đơn vị triển khai kéo theo một bộ việc: cấu hình, quy trình phát hành, log, giám sát, cách khôi phục khi hỏng, và một chỗ nữa để kiểm tra khi có sự cố. Với một đội nhỏ, số việc này tăng tuyến tính theo số đơn vị triển khai, trong khi lợi ích tăng chậm hơn nhiều.

Monolith có một bộ việc duy nhất. Khi hệ thống hỏng, chỉ có một chỗ để xem. Khi cần khôi phục, chỉ có một bản phát hành để quay lại. Đây là lợi thế lớn nhất và cũng bị đánh giá thấp nhất.

Lý do 2 — Không có lỗi mạng giữa các phần

Trong một đơn vị triển khai, lời gọi giữa các mô-đun là lời gọi hàm. Nó thành công hoặc ném lỗi, và không có trạng thái thứ ba. Trong hệ nhiều dịch vụ, lời gọi qua mạng có thêm trạng thái thứ ba rất khó xử lý: không biết bên kia đã nhận được hay chưa.

Trạng thái đó buộc phải có cơ chế thử lại, và thử lại buộc phải có cách chống xử lý hai lần. Hai cơ chế này cần được thiết kế, viết, kiểm thử và vận hành cho từng luồng quan trọng. Đây là loại chi phí không hiện ra trong kế hoạch ban đầu.

Lý do 3 — Giao dịch dữ liệu vẫn là giao dịch

Khi một thao tác phải cập nhật ba bảng và cả ba phải cùng thành công hoặc cùng thất bại, một cơ sở dữ liệu giải quyết việc đó trong một giao dịch. Đây là thứ có sẵn, đã được kiểm chứng, và không cần viết thêm mã.

Trong hệ nhiều dịch vụ, mỗi dịch vụ sở hữu dữ liệu riêng, nên không có giao dịch chung. Phải dùng cách bù trừ: nếu bước ba thất bại, chạy bước hoàn tác cho bước một và hai. Cách này hoạt động, nhưng mỗi luồng cần thiết kế riêng và mỗi trường hợp lỗi cần kiểm thử riêng.

Lý do 4 — Thay đổi xuyên nhiều phần vẫn nhanh

Trong monolith, thêm một trường vào một thực thể và dùng nó ở ba màn hình là một thay đổi trong một kho mã, một lần kiểm thử, một lần phát hành. Trong hệ nhiều dịch vụ, cùng thay đổi đó có thể cần sửa hợp đồng của hai dịch vụ, phát hành theo thứ tự, và xử lý giai đoạn hai phiên bản cùng chạy.

Với nghiệp vụ còn thay đổi nhiều — giai đoạn phổ biến của phần lớn sản phẩm — đây là lợi thế quyết định. Tách dịch vụ có lợi khi nghiệp vụ đã ổn định và ranh giới đã rõ; làm ngược lại thì mỗi lần đổi ranh giới là một lần di chuyển dữ liệu.

Lý do 5 — Ít người hơn để vận hành

Một hệ nhiều dịch vụ cần người trực, công cụ theo dõi xuyên dịch vụ, và quy trình phát hành phối hợp. Với một đội ba người, số người này thường không có. Kết quả là hệ thống chạy nhưng không ai dám sửa, vì không ai hiểu đủ để sửa an toàn.

Monolith cần ít người hơn để vận hành ở cùng mức chức năng. Đây là lý do thực tế nhất và cũng ít được nói nhất trong các bài so sánh kiến trúc.

So sánh chi phí ba năm

Đọc bảng này theo hướng chi phí, không theo hướng công nghệ: monolith rẻ hơn ở sáu trên tám dòng. Hai dòng còn lại — mở rộng riêng phần chịu tải và tách biệt rủi ro — là lý do chính đáng để tách, và chỉ khi chúng thật sự xảy ra với bạn.

Bảng so sánh đầy đủ tám kiến trúc, kèm cột chọn khi nào và tránh khi nào, có trong các kiến trúc phần mềm phổ biến. Cách một quyết định kiến trúc ảnh hưởng chi phí dài hạn được phân tích trong kiến trúc phần mềm là gì.

Monolith mô-đun hoá: ranh giới nằm bên trong

Điểm khác biệt giữa một monolith tốt và một monolith tệ không nằm ở công nghệ, mà ở chỗ ranh giới mô-đun có được viết ra và tôn trọng hay không.

Mỗi mô-đun sở hữu dữ liệu của mình. Không mô-đun nào đọc thẳng bảng của mô-đun khác. Muốn lấy dữ liệu, gọi qua giao diện của mô-đun sở hữu. Quy tắc này nghe khắt khe nhưng là quy tắc duy nhất giữ được khả năng tách về sau.

Phụ thuộc một chiều. Nếu mô-đun đơn hàng cần dữ liệu khách hàng, nó gọi mô-đun khách hàng. Chiều ngược lại không được phép, vì phụ thuộc hai chiều là dấu hiệu ranh giới sai và sẽ khiến hai mô-đun dính thành một.

Giao diện hẹp. Mỗi mô-đun công bố một tập hàm nhỏ cho bên ngoài. Nếu bên ngoài gọi được mọi thứ bên trong, ranh giới chỉ là hình thức.

Kiểm tra định kỳ. Mỗi quý, kiểm tra xem có lời gọi nào xuyên qua ranh giới không. Ranh giới bị xuyên một lần sẽ bị xuyên nhiều lần, và sau một năm không ai còn biết ranh giới ở đâu.

Cấu trúc này thường đi kèm tổ chức theo lớp bên trong mỗi mô-đun, và ở tầng giao diện thường dùng MVC — xem kiến trúc phần mềm MVC để biết khi nào cần thêm lớp nghiệp vụ.

Bốn kiểu hỏng của monolith

Kiểu hỏng thứ ba là kiểu khiến nhiều đội quyết định tách dịch vụ. Nhưng nguyên nhân thường không phải monolith, mà là quy trình phát hành: nếu mọi thay đổi phải đi cùng một lần phát hành, việc tách dịch vụ giải quyết được vấn đề đó, còn việc tách mô-đun bên trong thì không.

Kiểu hỏng thứ tư đáng lo hơn và thường bị bỏ qua. Cách phòng rẻ nhất không phải tách dịch vụ, mà là đặt giới hạn tài nguyên và cô lập những phần rủi ro cao như xử lý tệp tải lên, gọi dịch vụ bên ngoài, hoặc tính toán nặng.

Khi nào nên tách

Có bốn điều kiện cụ thể, và nên có ít nhất hai trước khi tách.

Nhiều đội cần phát hành độc lập. Khi hai đội phải chờ nhau để phát hành, việc tách theo ranh giới đội có lợi thật. Điều kiện này thường đi kèm việc đội đã đủ lớn để có người trực.

Tải lệch nhau rất lớn. Khi một phần chịu tải gấp mười lần phần còn lại, mở rộng riêng phần đó tiết kiệm đáng kể. Nếu tải tương đương, tách chỉ thêm chi phí.

Một phần cần công nghệ khác hẳn. Ví dụ phần tính toán nặng cần một môi trường chạy khác, hoặc phần xử lý tín hiệu cần thư viện riêng. Đây là lý do chính đáng và thường bị bỏ qua.

Một phần có yêu cầu cô lập. Khi một phần phải cô lập vì lý do an toàn hoặc vì tần suất thay đổi rất khác, tách giúp giảm rủi ro. Cần nói rõ: cô lập là giảm phạm vi ảnh hưởng, không phải bảo đảm an toàn tuyệt đối.

Nếu chưa có hai điều kiện nào ở trên, việc tách chủ yếu là tăng chi phí vận hành. Điều nên làm trước là viết rõ ranh giới mô-đun, ghi lại quyết định, và đặt điều kiện tách cụ thể để sau này có căn cứ quyết định thay vì tranh luận lại từ đầu.

Một lưu ý khi đội dùng công cụ AI để viết mã: công cụ sẽ mở rộng đúng cấu trúc hiện có, kể cả khi cấu trúc đó sai, và làm rất nhanh. Ranh giới mô-đun càng cần viết ra trước — xem AI coding là gì.

Bảng kiểm trước khi quyết định tách

Trước khi ký quyết định tách một monolith, chạy qua sáu câu dưới đây. Nếu có từ ba câu trả lời "chưa", việc tách nên hoãn lại và xử lý nguyên nhân gốc trước.

Câu thứ năm là câu hay bị bỏ qua nhất. Nhiều đội tách dịch vụ vì muốn phát hành nhanh hơn, nhưng vấn đề thật nằm ở quy trình phát hành chứ không ở mã. Nếu mọi thay đổi vẫn phải qua một cửa kiểm duyệt duy nhất, tách dịch vụ không làm phát hành nhanh hơn; nó chỉ làm việc phát hành phức tạp hơn.

Câu hỏi thường gặp

Monolith có chịu được tải lớn không?

Có, trong nhiều trường hợp. Giới hạn thật của monolith thường là số bản sao chạy song song và khả năng mở rộng cơ sở dữ liệu, không phải bản thân việc đóng gói một đơn vị. Nhiều hệ thống phục vụ tải cao vẫn chạy dưới dạng một đơn vị triển khai với nhiều bản sao phía sau bộ cân bằng tải. Chỉ khi tải giữa các phần lệch nhau rất lớn thì việc tách mới có lợi rõ rệt.

Làm sao biết monolith của mình đã đến giới hạn?

Ba dấu hiệu: hai thay đổi không liên quan phải chờ nhau phát hành, một phần chịu tải cao buộc phải mở rộng cả hệ thống, và thời gian chạy kiểm thử tăng tới mức đội bắt đầu bỏ qua kiểm thử. Dấu hiệu thứ ba thường bị xem nhẹ nhưng nó là dấu hiệu sớm nhất của chi phí tăng dần.

Có nên tách monolith thành microservices không?

Chỉ nên khi có ít nhất hai điều kiện cụ thể: nhiều đội cần phát hành độc lập, tải lệch lớn giữa các phần, một phần cần công nghệ khác, hoặc một phần cần cô lập. Nếu chỉ vì monolith "không hiện đại", việc tách sẽ tăng chi phí vận hành mà không giải quyết vấn đề nào có thật.

Monolith mô-đun hoá khác monolith thường ở chỗ nào?

Khác ở chỗ ranh giới được viết ra và kiểm tra. Monolith thường để mọi mô-đun truy cập mọi bảng; monolith mô-đun hoá buộc mỗi mô-đun sở hữu dữ liệu của mình và chỉ trao đổi qua giao diện. Về công nghệ hai cách giống nhau, nhưng chi phí thay đổi và khả năng tách về sau khác hẳn.

Cập nhật và kiểm chứng

Cập nhật tháng 10/2026. Nội dung phản ánh quy trình bốn chặng WinSell áp dụng — Khám phá, Đặc tả, Xây dựng, Bàn giao và đo lường — và được rà soát theo thông lệ thiết kế hệ thống đang áp dụng. Bài viết không mô tả hạ tầng nội bộ của WinSell, không nêu giá dịch vụ và không sử dụng số liệu khách hàng của bất kỳ bên nào.

Nếu bạn cần một bên đánh giá xem monolith hiện tại có nên tách hay không, kèm chi phí ba năm của từng phương án, xem dịch vụ xây dựng phần mềm theo yêu cầu của WinSell. Báo giá sau khi chốt phạm vi.