Khi bắt đầu một phần mềm quản lý cho doanh nghiệp, câu hỏi kiến trúc hay được đặt ra sớm nhất là: chia thành nhiều dịch vụ nhỏ hay giữ một khối duy nhất? Câu trả lời ngắn: với phần lớn hệ thống quản trị nội bộ, một khối được tổ chức tốt là lựa chọn đúng — và phần thú vị nằm ở chữ "được tổ chức tốt".
Cái giá thật của microservices
Microservices giải quyết một bài toán cụ thể: nhiều đội phát triển cần phát hành độc lập với nhau, hoặc vài phần của hệ thống có nhu cầu mở rộng rất khác phần còn lại. Nếu doanh nghiệp không ở trong hai tình huống đó, bạn nhận đủ chi phí mà không nhận được lợi ích:
- Giao dịch phân tán. Một nghiệp vụ chạm vào hai dịch vụ thì không còn giao dịch nguyên tử; phải xử lý bù trừ, trạng thái trung gian, và những tình huống nửa vời.
- Gỡ lỗi khó hơn nhiều. Một yêu cầu đi qua bốn dịch vụ cần hệ thống truy vết tập trung, nếu không sẽ mất hàng giờ chỉ để biết lỗi phát sinh ở đâu.
- Dữ liệu tham chiếu bị nhân bản. Danh mục nhân viên, khách hàng bị sao chép sang nhiều nơi, rồi lệch nhau.
- Vận hành đắt hơn. Nhiều dịch vụ nghĩa là nhiều đường ống triển khai, nhiều cấu hình, nhiều thứ có thể hỏng lúc nửa đêm.
Monolith không đồng nghĩa với hỗn độn
Vấn đề của những khối lớn cũ không nằm ở chỗ chúng là một khối, mà ở chỗ bên trong không có ranh giới. Một khối duy nhất vẫn có thể được chia thành các phần nghiệp vụ rõ ràng, mỗi phần có mô hình dữ liệu riêng và chỉ giao tiếp với phần khác qua giao diện đã định.
Cách tổ chức thường dùng trong hệ sinh thái .NET:
- Phân tầng rõ: miền nghiệp vụ không phụ thuộc vào hạ tầng; tầng ứng dụng giữ luồng xử lý; tầng hạ tầng giữ truy cập dữ liệu và dịch vụ ngoài.
- Chia theo tính năng, không chia theo loại tệp. Một thư mục chứa trọn vẹn một nghiệp vụ dễ đọc hơn nhiều so với ba thư mục chứa toàn bộ lệnh, toàn bộ truy vấn, toàn bộ mô hình.
- Tách lệnh và truy vấn. Đường ghi cần kiểm tra quy tắc nghiệp vụ và giao dịch; đường đọc cần nhanh và linh hoạt. Ép cả hai dùng chung một mô hình là nguồn gốc của những truy vấn cồng kềnh.
Khi nào thì tách dịch vụ là hợp lý
Có vài trường hợp tách ra rõ ràng đáng làm, ngay cả với hệ thống nhỏ:
- Công việc nền nặng: xuất báo cáo lớn, xử lý ảnh, đồng bộ định kỳ. Tách ra để một tác vụ nặng không làm chậm giao diện người dùng.
- Phần tiếp xúc công khai: cổng API cho website hoặc ứng dụng di động, có yêu cầu bảo mật và giới hạn truy cập khác hẳn phần nội bộ.
- Tích hợp bên thứ ba hay thay đổi: nên gói sau một lớp riêng để khi đối tác đổi giao thức thì chỉ sửa một chỗ.
Lưu ý là cả ba trường hợp trên đều tách vì lý do vận hành cụ thể, không phải vì "kiến trúc hiện đại".
Thứ tự ưu tiên thực dụng
Ranh giới đúng quan trọng hơn số lượng dịch vụ. Một khối có ranh giới rõ luôn tách ra được sau; nhiều dịch vụ có ranh giới sai thì gần như không gộp lại nổi.
Trình tự nên theo:
- Bắt đầu bằng một khối, chia module theo nghiệp vụ ngay từ ngày đầu.
- Cấm truy cập chéo vào bảng dữ liệu của module khác — đây là ranh giới quan trọng nhất và cũng dễ bị phá nhất.
- Đo trước khi tách: nếu không có số liệu cho thấy một phần đang nghẽn, việc tách chỉ là phỏng đoán.
- Khi tách, tách theo đường đã có sẵn trong mã nguồn, không vẽ đường mới.
Những dấu hiệu cho thấy ranh giới đang hỏng
- Sửa một nghiệp vụ phải mở nhiều module không liên quan.
- Truy vấn nối bảng xuyên qua ba, bốn khu vực nghiệp vụ khác nhau.
- Một thay đổi nhỏ về danh mục làm hỏng phần báo cáo mà không ai lường trước.
Những dấu hiệu này không được chữa bằng cách tách dịch vụ. Tách một khối rối chỉ tạo ra các dịch vụ rối và thêm mạng ở giữa. Chữa ranh giới trước, rồi mới nói tới chuyện chia tách.
