Kiến trúc Microservices: Ưu nhược điểm so với Monolithic

Monolithic là kiến trúc gom toàn bộ ứng dụng vào một khối mã và một đơn vị triển khai; microservices chia ứng dụng thành nhiều dịch vụ nhỏ, mỗi dịch vụ chạy và triển khai độc lập. Không kiến trúc nào tốt hơn tuyệt đối. Monolithic đơn giản hơn để bắt đầu và vận hành; microservices cho phép nhiều đội làm việc độc lập và mở rộng từng phần, đổi lại là độ phức tạp của hệ thống phân tán. Bài viết so sánh hai kiến trúc theo từng tiêu chí cụ thể để bạn chọn đúng cho hoàn cảnh của mình.

Hình dung hai kiến trúc qua một ví dụ

Lấy một trang thương mại điện tử với các chức năng: tài khoản người dùng, danh mục sản phẩm, giỏ hàng, thanh toán, vận chuyển, thông báo.

Trong monolithic, tất cả nằm trong một ứng dụng, có thể chia thành nhiều module trong mã nhưng được build và deploy cùng nhau, thường dùng chung một cơ sở dữ liệu. Gọi từ giỏ hàng sang thanh toán chỉ là một lời gọi hàm.

Trong microservices, mỗi chức năng là một dịch vụ riêng, có kho mã, quy trình deploy và thường có cơ sở dữ liệu riêng. Giỏ hàng gọi thanh toán qua mạng bằng HTTP, gRPC hoặc gửi sự kiện qua hàng đợi tin nhắn.

So sánh theo từng tiêu chí

Điểm mạnh thực sự của monolithic

Monolithic thường bị gắn mác "lỗi thời", nhưng nhiều sản phẩm thành công vẫn chạy trên kiến trúc này. Ưu điểm của nó là thật:

• Đơn giản để hiểu: lập trình viên mới mở một kho mã là thấy toàn bộ luồng xử lý.
• Kiểm thử end-to-end dễ: chạy một ứng dụng là kiểm thử được cả luồng.
• Hiệu năng gọi nội bộ: lời gọi hàm nhanh hơn rất nhiều so với lời gọi mạng, không có rủi ro mất gói tin hay timeout.
• Giao dịch dữ liệu: một transaction cơ sở dữ liệu đảm bảo đơn hàng và trừ tồn kho thành công hoặc thất bại cùng nhau.
• Chi phí vận hành thấp: ít máy chủ, ít thành phần cần giám sát.

Khi nào monolithic trở thành gánh nặng

Vấn đề xuất hiện khi mã nguồn và đội ngũ lớn lên. Build và kiểm thử mất hàng chục phút; mỗi lần deploy là một sự kiện cần phối hợp nhiều đội; một thay đổi nhỏ ở module báo cáo cũng buộc deploy lại cả hệ thống; ranh giới giữa các module mờ dần khi mọi thứ gọi lẫn nhau. Đây là trạng thái thường được gọi vui là "big ball of mud", nhưng nguyên nhân thường là thiếu kỷ luật thiết kế chứ không hẳn do kiến trúc.

Điểm mạnh thực sự của microservices

• Đội tự chủ: mỗi đội sở hữu một hoặc vài dịch vụ, tự quyết định lịch phát hành, giảm phụ thuộc phối hợp.
• Triển khai thường xuyên, rủi ro nhỏ: thay đổi giới hạn trong một dịch vụ, dễ rollback.
• Mở rộng có chọn lọc: dịch vụ tìm kiếm chịu tải nặng có thể chạy nhiều bản sao trong khi dịch vụ quản trị chỉ cần một.
• Linh hoạt công nghệ: dịch vụ xử lý ảnh có thể viết bằng ngôn ngữ khác dịch vụ thanh toán.

Cái giá phải trả

Microservices chuyển độ phức tạp từ trong mã ra hạ tầng và mạng:

• Lời gọi mạng có thể chậm, lỗi, hoặc trả về không đúng lúc; cần timeout, retry, circuit breaker.
• Không còn transaction chung; cần mẫu thiết kế như saga, outbox để giữ dữ liệu nhất quán.
• Gỡ lỗi một yêu cầu đi qua năm dịch vụ đòi hỏi distributed tracing và log tập trung.
• Cần nền tảng triển khai tự động, thường là container và Kubernetes, cùng pipeline CI/CD cho từng dịch vụ.
• Thay đổi giao diện giữa dịch vụ phải được quản lý phiên bản cẩn thận.

Nếu đội chưa có nền tảng container, bài containerization cho người mới bắt đầu là điểm khởi đầu hợp lý trước khi nghĩ đến chia dịch vụ.

Lựa chọn ở giữa: modular monolith

Giữa hai thái cực có một lựa chọn được nhiều kiến trúc sư khuyến nghị cho giai đoạn đầu: modular monolith. Ứng dụng vẫn deploy như một khối, nhưng được chia thành module với ranh giới rõ ràng, mỗi module có API nội bộ và vùng dữ liệu riêng, không truy cập trực tiếp bảng của nhau. Bạn có được sự đơn giản vận hành của monolithic, đồng thời giữ khả năng tách module thành dịch vụ riêng khi thực sự cần.

Câu hỏi giúp bạn quyết định

1. Đội có bao nhiêu người? Một đội nhỏ thường làm việc hiệu quả hơn với một kho mã. Microservices phát huy khi nhiều đội cần làm việc song song mà không giẫm chân nhau.
2. Miền nghiệp vụ đã rõ chưa? Startup còn đang tìm sản phẩm phù hợp thị trường thay đổi ranh giới chức năng liên tục; vẽ sai ranh giới dịch vụ sớm rất tốn kém để sửa.
3. Có yêu cầu mở rộng khác biệt rõ rệt giữa các phần? Nếu toàn hệ thống chịu tải đồng đều, lợi ích mở rộng có chọn lọc không lớn.
4. Đội đã có năng lực vận hành hệ phân tán? CI/CD, giám sát, tracing, quản lý cấu hình là điều kiện cần.

Nếu phần lớn câu trả lời nghiêng về "chưa", monolithic hoặc modular monolith là lựa chọn an toàn hơn. Khi đã quyết định chuyển, bài những thách thức khi triển khai microservices trình bày cách chuyển đổi từng bước và các mẫu thiết kế cần biết.

Một số hiểu lầm phổ biến

• "Microservices luôn mở rộng tốt hơn": monolithic cũng mở rộng ngang được bằng cách chạy nhiều bản sao sau cân bằng tải, miễn là ứng dụng không giữ trạng thái.
• "Dịch vụ càng nhỏ càng tốt": chia quá vụn tạo ra mạng lưới gọi lẫn nhau chằng chịt, mỗi thay đổi nghiệp vụ phải sửa nhiều dịch vụ.
• "Tách dịch vụ nhưng dùng chung cơ sở dữ liệu": các dịch vụ vẫn bị ràng buộc qua lược đồ dữ liệu; đây là monolithic phân tán, mang nhược điểm của cả hai.

Kết luận

Kiến trúc nên phục vụ cách tổ chức đội và giai đoạn phát triển của sản phẩm. Bắt đầu đơn giản với ranh giới module rõ ràng, đo đạc điểm nghẽn thực tế, và chỉ tách dịch vụ khi lợi ích vượt rõ chi phí vận hành tăng thêm.