Kiến trúc phần mềm hướng dịch vụ: SOA khác microservices thế nào

Kiến trúc hướng dịch vụ (SOA) tổ chức hệ thống thành các dịch vụ có hợp đồng rõ ràng, thường đi qua một lớp điều phối chung. Khác biệt cốt lõi với microservices không nằm ở kích thước dịch vụ mà ở mức độ tập trung quản trị.

Tóm tắt nhanh

• SOA và microservices chia sẻ cùng ý tưởng: tách hệ thống thành dịch vụ có hợp đồng. Khác biệt là SOA thường có lớp điều phối chung, microservices để các dịch vụ tự phối hợp.
• SOA vẫn là lựa chọn đúng khi phải nối nhiều hệ thống cũ với nhiều giao thức khác nhau và không thể sửa chúng.
• Ba kiểu hỏng thường gặp: lớp điều phối phình thành nút thắt, hợp đồng dịch vụ thay đổi không báo trước, và dữ liệu bị sao chép ở nhiều dịch vụ.
• Chi phí quản trị của SOA thấp hơn microservices khi số dịch vụ còn ít, và cao hơn khi lớp điều phối phải xử lý quá nhiều logic nghiệp vụ.

SOA là gì

SOA là cách tổ chức hệ thống trong đó mỗi năng lực nghiệp vụ được đóng gói thành một dịch vụ, và các dịch vụ giao tiếp qua hợp đồng được mô tả rõ. Điểm nhấn của SOA là hợp đồng: mỗi dịch vụ công bố nó nhận gì và trả gì, và bên gọi không cần biết bên trong dịch vụ làm thế nào.

Trong cách triển khai phổ biến, các dịch vụ đi qua một lớp trung gian làm ba việc: định tuyến yêu cầu tới dịch vụ đúng, chuyển đổi giữa các giao thức khác nhau, và áp dụng chính sách chung như ghi log, xác thực hay giới hạn tần suất.

Lớp trung gian này là điểm mạnh và cũng là điểm yếu. Mạnh vì nó cho phép nối các hệ thống không nói cùng ngôn ngữ mà không phải sửa chúng. Yếu vì nó trở thành một chỗ mà mọi thứ đi qua, và mọi thứ đi qua một chỗ thì chỗ đó quyết định độ tin cậy của cả hệ thống.

Bốn điểm khác biệt giữa SOA và microservices

Cần nói rõ: hai kiến trúc này không phải hai mức trưởng thành của cùng một thứ. Chúng trả lời hai bài toán khác nhau. SOA trả lời câu hỏi "làm sao để nhiều hệ thống khác nhau cùng làm việc mà không phải viết lại chúng". Microservices trả lời câu hỏi "làm sao để nhiều đội cùng phát triển một hệ thống mà không chờ nhau".

Vị trí của hai kiến trúc này trong bức tranh chung được trình bày trong các kiến trúc phần mềm phổ biến. Và lý do mỗi quyết định kiến trúc là một quyết định chi phí được phân tích trong kiến trúc phần mềm là gì.

Khi nào SOA vẫn là lựa chọn đúng

SOA còn đúng trong bốn bối cảnh cụ thể, và cả bốn đều liên quan tới hệ thống đã tồn tại.

Phải nối nhiều hệ thống cũ không thể sửa. Hệ thống kế toán, hệ thống kho, phần mềm nhân sự, máy chủ thư điện tử nội bộ. Mỗi hệ thống có giao thức riêng, có nhà cung cấp riêng, và không ai được phép sửa mã. Lớp điều phối là cách duy nhất để chúng cùng làm việc.

Cần một nơi áp chính sách chung. Khi mọi lời gọi phải đi qua cùng một chỗ, bạn áp được xác thực, ghi log và giới hạn tần suất ở một điểm thay vì ở từng hệ thống. Với hệ thống chịu quy định về lưu vết, đây là lợi ích thật.

Nhiều đơn vị cùng tham gia, ít đội kỹ thuật. Khi các bên tham gia không cùng một đội và không dùng chung công nghệ, một hợp đồng dịch vụ rõ ràng dễ thống nhất hơn việc yêu cầu mọi bên dùng chung một nền tảng.

Số dịch vụ còn ít. Với năm đến mười dịch vụ, một lớp điều phối chung vẫn kiểm soát được và chi phí quản trị thấp hơn việc dựng cả một nền tảng vận hành nhiều dịch vụ độc lập.

Ngược lại, SOA không phù hợp khi hệ thống hoàn toàn mới và không có gì để tích hợp. Lúc đó lớp điều phối chỉ thêm một tầng phải vận hành mà không giải quyết vấn đề nào có thật.

Ba kiểu hỏng thường gặp

Kiểu hỏng đầu tiên là kiểu phổ biến nhất và cũng khó sửa nhất. Nó bắt đầu từ một yêu cầu hợp lý: lớp trung gian đã có sẵn, thêm một bước xử lý ở đó nhanh hơn sửa hai hệ thống. Lặp lại vài chục lần, lớp trung gian trở thành nơi chứa toàn bộ nghiệp vụ, và mọi thay đổi đều phải chờ nó.

Cách phòng rất cụ thể: viết ra một quy tắc và kiểm tra định kỳ. Lớp trung gian chỉ được làm ba việc — định tuyến, chuyển đổi giao thức, áp chính sách chung. Mọi logic nghiệp vụ thuộc về dịch vụ sở hữu nghiệp vụ đó. Khi quy tắc bị vi phạm, chi phí sửa tăng theo số lần vi phạm.

Chi phí ba năm của SOA so với microservices

Ba dòng chi phí dưới đây giải thích vì sao lựa chọn đúng phụ thuộc vào bối cảnh chứ không vào xu hướng.

Chi phí vận hành. SOA thường rẻ hơn khi số dịch vụ ít, vì lớp điều phối là một thành phần tập trung và các dịch vụ có thể chạy chung một cụm. Microservices đắt hơn ở giai đoạn đầu vì mỗi dịch vụ cần cấu hình, triển khai và giám sát riêng.

Chi phí thay đổi. Microservices rẻ hơn khi có nhiều đội, vì mỗi đội phát hành dịch vụ của mình mà không chờ. SOA rẻ hơn khi thay đổi chủ yếu là thêm một hệ thống mới vào danh sách tích hợp, vì chỉ cần thêm một kết nối ở lớp trung gian.

Chi phí tìm lỗi. SOA có một điểm thuận lợi: mọi lời gọi đi qua một chỗ, nên log tập trung dễ dựng. Microservices linh hoạt hơn nhưng đòi mã theo dõi xuyên dịch vụ ngay từ đầu, nếu không chi phí tìm lỗi tăng rất nhanh khi số dịch vụ vượt mười.

Với phần lớn doanh nghiệp vừa đang có vài hệ thống cũ cần kết nối, SOA kèm một lớp trung gian gọn là lựa chọn rẻ nhất trong ba năm đầu. Với một sản phẩm mới hoàn toàn và một đội, monolith mô-đun hoá lại rẻ hơn cả hai — xem kiến trúc phần mềm monolithic.

Khi đội dùng công cụ AI để viết mã tích hợp, quy tắc về lớp trung gian càng cần viết rõ, vì công cụ sẽ thêm logic vào nơi có sẵn thay vì nơi đúng: xem AI coding là gì.

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

SOA có phải là phiên bản cũ của microservices không?

Không. SOA ra đời trước và giải bài toán khác: tích hợp nhiều hệ thống không đồng nhất. Microservices giải bài toán tổ chức nhiều đội phát triển độc lập. Một hệ thống có thể dùng cả hai: microservices cho phần sản phẩm mới, SOA cho phần tích hợp với hệ thống cũ.

Lớp điều phối trung gian có phải là điểm yếu chết người không?

Chỉ khi nó chứa logic nghiệp vụ. Nếu lớp trung gian chỉ định tuyến, chuyển đổi giao thức và áp chính sách chung, nó là một thành phần ổn định và ít thay đổi. Điểm yếu xuất hiện khi mỗi yêu cầu nghiệp vụ mới lại được thêm vào lớp đó, vì khi ấy mọi thay đổi đều phụ thuộc vào một chỗ.

Khi nào nên chuyển từ SOA sang microservices?

Khi số đội tăng tới mức phải chờ nhau để phát hành, hoặc khi một phần của hệ thống chịu tải cao hơn hẳn các phần khác và cần mở rộng riêng. Nếu chưa có hai điều kiện đó, chuyển sang microservices chủ yếu là tăng chi phí vận hành mà không tăng tốc độ giao hàng.

Dữ liệu dùng chung có phải là sai lầm trong SOA không?

Không hẳn, nhưng cần quy tắc. Dữ liệu dùng chung ở mức đọc thường chấp nhận được nếu chỉ một nơi được ghi. Sai lầm là cho nhiều dịch vụ cùng ghi vào một bảng: khi đó không ai xác định được giá trị đúng, và mọi báo cáo trở nên không đáng tin.

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 đang phải nối nhiều hệ thống cũ và cần một kiến trúc tích hợp viết ra rõ ràng, 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.