Ý chính: Microservices là mô hình tổ chức và vận hành, không phải mục tiêu bắt buộc của một hệ thống lớn.
Thuật ngữ trong bài: Modular Monolith: một ứng dụng nhưng được chia thành mô-đun rõ ràng; service boundary: ranh giới trách nhiệm của dịch vụ; strangler: thay thế hệ thống cũ từng phần.
Bài toán thực tế
Tách theo lớp kỹ thuật thường khiến mỗi yêu cầu phải gọi qua nhiều dịch vụ. Đội ngũ vẫn phải phối hợp khi phát hành, nhưng lại gánh thêm lỗi mạng và giao dịch phân tán. Chỉ nên tách khi ranh giới mới tạo ra quyền sở hữu hoặc khả năng mở rộng thực sự.
Điểm dễ bị bỏ qua
Microservices chỉ tạo giá trị khi ranh giới dịch vụ cho phép một đội sở hữu, phát hành hoặc mở rộng độc lập. Nếu mỗi yêu cầu vẫn đi qua nhiều đội, việc tách tiến trình chỉ thêm lỗi mạng và giao dịch phân tán.
Modular Monolith là nơi rẻ hơn để kiểm chứng ranh giới: mô-đun có API rõ, dữ liệu thuộc quyền sở hữu rõ và không truy cập tắt sang mô-đun khác.
Luồng xử lý
Quyền sở hữu và quy tắc bảo toàn→Modular Monolith
Thực thi ranh giới nghiêm ngặt→Điểm tách module
Hợp đồng API và dữ liệu→Microservice
Vận hành độc lập
Thiết kế và triển khai
Tách theo nghiệp vụ (nghiệp vụ Capability)
Góm gọn quy tắc nghiệp vụ và dữ liệu bảo vệ cùng một tính toàn vẹn vào một nơi.
Hạn chế gọi đồng bộ (Synchronous Call)
Chỉ sử dụng lời gọi đồng bộ khi bên gọi thực sự cần kết quả tức thì; phát hành sự kiện (sự kiện) để các hệ thống hạ nguồn tự phản ứng độc lập.
Quản lý toàn bộ vòng đời vận hành
Việc tách service bao gồm cả trách nhiệm trực ban (on-call), bảng giám sát, triển khai, bảo mật và năng lực hạ tầng, không chỉ là chuyển mã nguồn sang repository khác.
Đi sâu vào thiết kế
Quyền sở hữu dữ liệu là ranh giới khó nhất
Một service có thể cung cấp mô hình đọc, sự kiện hoặc API, nhưng service khác không được phép ghi trực tiếp vào bảng của nó. Việc sao chép dữ liệu tạm thời phải có chủ sở hữu và ngày gỡ bỏ cụ thể.
Chiến lược Strangler cần đối soát dữ liệu
Trong quá trình chuyển đổi, đối sánh kết quả giữa hệ thống cũ và mới, điều hướng một nhóm người dùng nhỏ và giữ đường quay lại nhanh chóng cho tới khi dữ liệu hoàn toàn khớp nhau.
Cách triển khai
- Lập bản đồ năng lực nghiệp vụ, quy tắc bảo toàn dữ liệu và đội sở hữu từng thay đổi.
- Thực thi nghiêm API mô-đun và quy tắc phụ thuộc ngay trong Modular Monolith.
- Tách một năng lực cụ thể cùng hợp đồng API, kế hoạch di chuyển dữ liệu và đường quay lui.
Mã minh họa: Quy tắc phụ thuộc trước khi tách dịch vụ
module Orders exposes OrdersApi
module Billing exposes BillingApi
Orders may call BillingApi
Orders must not import BillingRepository
architectureTest.assertNoInternalDependencyLeaks()Kiểm thử kiến trúc biến sơ đồ mô-đun mong muốn thành ràng buộc tự động trong mỗi bản build.
Rủi ro cần tính trước
- Dùng chung cơ sở dữ liệu cho phép dịch vụ mới đi vòng qua hợp đồng API.
- Ranh giới quá nhỏ khiến một thao tác người dùng tạo ra hàng loạt lời gọi mạng.
- Hai đội cùng cho rằng mình sở hữu một quy tắc dữ liệu quan trọng.
Nên theo dõi gì?
| Tín hiệu | Điều tín hiệu cho biết |
|---|---|
| Tần suất thay đổi chéo mô-đun | Cho biết ranh giới vẫn buộc nhiều đội phát hành cùng lúc. |
| Số lời gọi từ xa trên mỗi luồng | Phát hiện hệ thống bị chia quá vụn và làm tăng độ trễ. |
| Mức độc lập khi triển khai và xử lý sự cố | Kiểm chứng việc tách dịch vụ có thật sự tạo ra tự chủ vận hành. |
Cách kiểm chứng
- Chặn các truy vấn import nội bộ trái phép ngay trong quy trình CI.
- Thử nghiệm thêm độ trễ và lỗi giả lập vào ranh giới dự kiến trước khi chính thức tách.
- Chạy song song hai luồng xử lý với cùng dữ liệu đầu vào và đối soát kết quả.
Đưa vào production từng bước
Bắt đầu bằng kiểm thử kiến trúc và một mô-đun đã có người sở hữu rõ. Tách luồng đọc trước, sau đó tới luồng ghi và dữ liệu; chỉ chuyển sang dịch vụ riêng khi số liệu cho thấy lợi ích vận hành lớn hơn chi phí phân tán.
Checklist trước khi vận hành
- Mỗi service toàn quyền sở hữu dữ liệu và các quyết định nghiệp vụ của riêng mình.
- Các lời gọi inter-service có ngân sách độ trễ, thời gian chờ (timeout) và hạn mức lỗi rõ ràng.
- Nền tảng hạ tầng có thể triển khai, giám sát và bảo mật mọi service một cách nhất quán.
Điều cần nhớ
Ranh giới dịch vụ tốt làm giảm phối hợp giữa các đội; ranh giới kém chỉ biến lời gọi hàm thành lời gọi qua mạng.