Ý 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ự.
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.
Thiết kế và 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. |
Đư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.
Đ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.