Các kiến trúc phần mềm phổ biến: bảng so sánh trade-off

Tám kiến trúc phần mềm phổ biến nhất là phân lớp, monolith mô-đun hoá, MVC, hướng dịch vụ, microservices, hướng sự kiện, serverless và xử lý theo lô. Không kiến trúc nào đúng cho mọi trường hợp; mỗi kiến trúc đổi một loại chi phí lấy một loại khả năng.

Tóm tắt nhanh

• Kiến trúc là một lựa chọn đánh đổi, không phải một mức trưởng thành. Chọn kiến trúc phức tạp hơn năng lực vận hành là cách chắc chắn nhất để làm hệ thống chậm lại.
• Cột quyết định trong bảng dưới đây là "chọn khi nào", không phải "kiến trúc nào tốt hơn". Cùng một kiến trúc có thể đúng ở quy mô này và sai ở quy mô khác.
• Với một đội và nghiệp vụ còn thay đổi, monolith mô-đun hoá thường rẻ nhất trong ba năm đầu, vì nó ít thứ phải vận hành.
• Ba yếu tố quyết định lựa chọn: số đội cùng làm, mức lệch tải giữa các phần, và khả năng vận hành thực tế của bạn.

Cách đọc bảng so sánh này

Trước khi so sánh, cần thống nhất ba khái niệm hay bị trộn.

Kiến trúc triển khai nói về số đơn vị chạy độc lập: một ứng dụng, nhiều dịch vụ, hay các hàm không máy chủ. Đây là thứ ảnh hưởng trực tiếp tới chi phí vận hành.

Kiến trúc bên trong nói về cách tổ chức mã trong một đơn vị triển khai: phân lớp, MVC, hướng sự kiện. Đây là thứ ảnh hưởng tới chi phí thay đổi.

Kiến trúc tích hợp nói về cách các hệ thống nói chuyện với nhau: gọi đồng bộ, hàng đợi sự kiện, hay chia sẻ dữ liệu. Đây là thứ ảnh hưởng tới chi phí tìm lỗi.

Một hệ thống thực tế thường là tổ hợp của cả ba: ví dụ một monolith mô-đun hoá, bên trong tổ chức theo lớp, tích hợp với hệ thống kế toán qua hàng đợi. Vì vậy câu hỏi đúng không phải "chọn kiến trúc nào" mà "chọn gì ở mỗi tầng".

Bảng so sánh tám kiến trúc

Cột "chi phí vận hành" ở đây là chi phí tương đối về công sức vận hành, không phải tiền hạ tầng. Với nhiều đội và tải lớn, chi phí tiền của microservices có thể thấp hơn nhờ mở rộng chọn lọc, nhưng công sức vận hành thì luôn cao hơn.

Từng kiến trúc trong một đoạn

Kiến trúc phân lớp

Chia ứng dụng thành các lớp theo trách nhiệm kỹ thuật: lớp giao diện, lớp nghiệp vụ, lớp truy cập dữ liệu. Ưu điểm là dễ hiểu và dễ dạy người mới; nhược điểm là nó không nói gì về ranh giới nghiệp vụ.

Với hệ thống nội bộ có nghiệp vụ ổn định, phân lớp là đủ và rẻ. Với hệ thống mà ranh giới nghiệp vụ là điểm thay đổi chính, phân lớp thuần tuý dẫn tới tình trạng mọi thứ rơi vào lớp nghiệp vụ và lớp đó trở thành một khối không chia được.

Monolith mô-đun hoá

Một đơn vị triển khai, bên trong chia theo nghiệp vụ, mỗi mô-đun sở hữu dữ liệu của mình và chỉ trao đổi qua giao diện. Đây là lựa chọn mặc định hợp lý cho phần lớn dự án vừa.

Lý do rất thực dụng: 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. Ranh giới rõ cho phép tách một mô-đun thành dịch vụ riêng sau này nếu có lý do cụ thể.

MVC

Tách mô hình dữ liệu, giao diện hiển thị và phần điều khiển luồng. Phù hợp với ứng dụng web có nhiều màn hình đọc và ghi dữ liệu. Giới hạn của MVC là nó tổ chức theo lớp kỹ thuật, nên khi nghiệp vụ có nhiều bước và nhiều ngoại lệ, phần điều khiển phình ra và trở thành nơi chứa mọi logic.

Chi tiết về giới hạn này và cách nhận biết được trình bày trong kiến trúc phần mềm MVC.

Hướng dịch vụ

Nhiều dịch vụ có hợp đồng rõ ràng, thường đi qua một lớp trung gian để chuyển đổi giao thức và định tuyến. Kiến trúc này sinh ra trong bối cảnh phải tích hợp nhiều hệ thống cũ với nhiều giao thức khác nhau, và nó vẫn đúng trong bối cảnh đó.

Điểm khác biệt cốt lõi so với microservices là mức độ tập trung: hướng dịch vụ thường có một lớp điều phối chung, microservices thường để các dịch vụ tự phối hợp. Sự khác biệt này quyết định chi phí quản trị.

So sánh chi tiết giữa hai kiến trúc này được trình bày trong kiến trúc phần mềm hướng dịch vụ.

Microservices

Nhiều dịch vụ nhỏ, mỗi dịch vụ sở hữu dữ liệu riêng và triển khai độc lập. Lợi ích thật là cho phép nhiều đội phát hành mà không chờ nhau, và mở rộng riêng phần chịu tải cao.

Chi phí thật gồm: hạ tầng để chạy và giám sát nhiều dịch vụ, cơ chế xử lý khi một bước trong chuỗi thất bại, và nhu cầu theo dõi một yêu cầu đi xuyên nhiều dịch vụ. Với một đội, ba chi phí này thường lớn hơn lợi ích.

Hướng sự kiện

Các phần phát sự kiện và các phần khác đăng ký nhận, không gọi trực tiếp. Lợi ích là tách được thời gian: bên phát không cần chờ bên nhận, và thêm một bên nhận mới không cần sửa bên phát.

Chi phí là khó biết một việc đã hoàn tất hay chưa, và khó tìm lỗi vì luồng không nằm trong một lời gọi. Kiến trúc này chỉ nên dùng khi có ít nhất hai bên thật sự cần xử lý cùng một sự kiện một cách độc lập.

Serverless

Mã chạy theo sự kiện, không cần quản lý máy chủ. Phù hợp với tác vụ ngắn, tải không đều, và các phần ít trạng thái như xử lý ảnh, gửi thông báo, hoặc một điểm cuối nhận dữ liệu.

Hai giới hạn cần biết trước: tác vụ chạy lâu thường bị giới hạn thời gian, và chi phí có thể tăng nhanh khi tải cao liên tục vì bạn trả theo lượt gọi thay vì theo máy. Với tải đều và lớn, máy chủ thường rẻ hơn.

Xử lý theo lô

Chạy tính toán lớn theo lịch thay vì theo yêu cầu. Phù hợp với báo cáo, đối chiếu số liệu, chuyển dữ liệu định kỳ. Đây là kiến trúc bị xem nhẹ nhất và cũng thường là cách rẻ nhất để giải một bài toán tưởng như cần hệ thống thời gian thực.

Một ví dụ điển hình: báo cáo doanh thu theo ngày không cần tính lại mỗi lần mở màn hình. Tính một lần vào ban đêm và lưu kết quả rẻ hơn nhiều so với tính lại theo từng lượt xem.

Ba câu hỏi chọn nhanh

Ba câu dưới đây thu hẹp lựa chọn nhanh hơn bất kỳ bảng so sánh nào.

Câu 1 — Có bao nhiêu đội sẽ phát hành độc lập? Một đội thì monolith mô-đun hoá. Ba đội trở lên và tải lệch nhau rõ rệt thì bắt đầu cân nhắc tách dịch vụ. Số đội là yếu tố dự báo tốt hơn quy mô dữ liệu.

Câu 2 — Tải giữa các phần có lệch nhau từ mười lần trở lên không? Nếu có, tách phần chịu tải cao có thể tiết kiệm. Nếu tải tương đương giữa các phần, tách chỉ thêm chi phí vận hành mà không có lợi ích.

Câu 3 — Đội của bạn có người trực và công cụ giám sát không? Nếu không, mọi kiến trúc đòi nhiều thành phần chạy độc lập sẽ trở thành gánh nặng. Đây là câu hay bị bỏ nhất và cũng là câu quyết định nhiều nhất.

Nếu cả ba câu đều nghiêng về phía đơn giản, chọn monolith mô-đun hoá. Đây không phải lựa chọn kém hơn; đó là lựa chọn phù hợp với năng lực vận hành hiện tại, và nó không ngăn bạn tách sau này nếu ranh giới đã rõ.

Chi phí tương đối theo quy mô đội

Bảng này nên đọc cùng với bảng so sánh phía trên: cột "kiến trúc hợp lý" là điểm khởi đầu, không phải kết luận. Quyết định cuối vẫn phụ thuộc vào ràng buộc cụ thể của bạn, đặc biệt là số người có thể trực sự cố.

Cách một quyết định kiến trúc ảnh hưởng tới chi phí ba năm được phân tích trong kiến trúc phần mềm là gì. Và khi đội dùng công cụ AI để viết mã, kiến trúc càng cần chốt trước vì công cụ sẽ mở rộng đúng cấu trúc hiện có, kể cả cấu trúc sai: xem AI coding là gì.

Ba cách kết hợp thường gặp

Vì kiến trúc có ba tầng, hệ thống thật hiếm khi dùng một kiểu duy nhất. Ba tổ hợp dưới đây xuất hiện nhiều nhất và đều có lý do rõ ràng.

Monolith mô-đun hoá, bên trong phân lớp, báo cáo chạy theo lô. Đây là tổ hợp phổ biến nhất cho hệ thống doanh nghiệp vừa. Ranh giới nghiệp vụ nằm ở mô-đun, mã trong mỗi mô-đun chia theo lớp, và mọi tính toán nặng được đẩy sang một tiến trình chạy theo lịch. Chi phí vận hành thấp vì chỉ có một ứng dụng và một tiến trình nền, trong khi người dùng vẫn thấy số liệu mới mỗi ngày.

Hướng dịch vụ kết hợp hướng sự kiện cho phần tích hợp. Dùng khi phải nối nhiều hệ thống cũ. Lớp trung gian xử lý chuyển đổi giao thức, còn các thay đổi dữ liệu được phát thành sự kiện để bên nhận tự xử lý. Cách này giữ được tính ổn định của hệ cũ mà không buộc phải sửa chúng.

Microservices kèm serverless cho phần tải biến động. Dùng khi đã có nền tảng vận hành nhiều dịch vụ. Phần chạy đều nằm trong dịch vụ thường trực, phần bùng phát theo mùa hoặc theo sự kiện chạy dưới dạng hàm. Lợi ích là không phải giữ máy cho tải chỉ xuất hiện vài giờ mỗi tháng.

Điểm chung của cả ba tổ hợp: mỗi tầng được chọn theo ràng buộc riêng của nó, không theo một nhãn kiến trúc chung. Đây cũng là cách tránh tranh luận vô ích về việc "monolith hay microservices", vì câu trả lời thường là "cả hai, ở hai tầng khác nhau".

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

Microservices có luôn tốt hơn monolith không?

Không. Microservices đổi chi phí vận hành lấy khả năng phát hành độc lập và mở rộng chọn lọc. Lợi ích đó chỉ có giá trị khi bạn có nhiều đội cùng làm hoặc tải giữa các phần rất lệch. Với một đội và nghiệp vụ còn thay đổi, chi phí vận hành nhiều dịch vụ thường lớn hơn lợi ích, và monolith mô-đun hoá cho tốc độ thay đổi tốt hơn.

Kiến trúc nào phù hợp cho hệ thống nội bộ của doanh nghiệp vừa?

Monolith mô-đun hoá với phân lớp bên trong là lựa chọn phổ biến nhất. Nó đủ để chia ranh giới nghiệp vụ, đủ để nhiều người cùng làm, và chỉ cần một thứ để triển khai. Nếu có phần tính toán nặng như báo cáo, tách riêng phần đó thành tiến trình chạy theo lô thay vì tách cả hệ thống.

Có thể đổi kiến trúc sau khi đã chạy không?

Có, nhưng chi phí tăng theo thời gian và theo khối lượng dữ liệu. Đổi ranh giới mô-đun trong mã là việc của vài tuần; đổi quyền sở hữu dữ liệu khi đã có dữ liệu thật là việc của vài tháng, vì phải di chuyển dữ liệu và xử lý chênh lệch. Vì vậy quyết định về sở hữu dữ liệu nên làm đúng ngay từ đầu, còn quyết định về số đơn vị triển khai có thể thay đổi dần.

Serverless có thay thế được máy chủ truyền thống không?

Không thay thế hoàn toàn. Serverless phù hợp với tác vụ ngắn, tải không đều và ít trạng thái. Với tác vụ chạy lâu, tải đều và lớn, hoặc cần kiểm soát môi trường chạy ở mức chi tiết, máy chủ hoặc container thường phù hợp hơn và dễ dự báo chi phí 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 so sánh hai phương án kiến trúc cụ thể cho bài toán của mình, WinSell viết bảng đánh đổi kèm khuyến nghị trong giai đoạn khám phá — xem dịch vụ xây dựng phần mềm theo yêu cầu. Báo giá sau khi chốt phạm vi.