Khi làm việc với kiến trúc microservice, chúng ta thường đối mặt với câu hỏi quan trọng: Có nên lưu trữ dữ liệu từ các service khác trong service hiện tại, hay chỉ gọi API mỗi khi cần thông tin? Hãy cùng xem xét vấn đề này qua ví dụ thực tế:
Bối cảnh
- Customer Service: Quản lý thông tin người dùng
- Product Service: Quản lý sản phẩm
- Order Service: Quản lý thông tin đơn hàng
Giả sử chúng ta có dữ liệu như sau:
- Customer: ID: CUS001, Name: Hoang Anh
- Product: ID: PROD0001, Name: “Áo màu xanh”, Price: 50.000 vnd
- Order: ID: ODR001, CUSCode: CUS001, PRODCode: PROD0001, Qty: 1, UnitPrice: 50.000 vnd, TotalAmount: 50.000 vnd
Câu hỏi đặt ra:
- Có nên lưu trữ Customer Name và Product Name trong Order Service không?
- Khi tạo hóa đơn, cần thông tin chi tiết người dùng và sản phẩm, thì nên làm gì? Gọi API từ Customer Service và Product Service hay lưu trữ trước trong Order Service?
Lựa Chọn: Lưu Trữ Dữ Liệu
Một số người ủng hộ việc lưu trữ dữ liệu như tên khách hàng và sản phẩm trong Order Service. Lý do chính:
- Hiệu suất: Tránh phải gọi API mỗi lần lấy thông tin. Điều này giảm tải cho các service khác và tăng tốc độ xử lý.
- Ổn định: Nếu các service Customer hoặc Product không khả dụng, Order Service vẫn có thể hoạt động độc lập.
Tuy nhiên, nhược điểm là:
- Đồng bộ dữ liệu: Thông tin có thể trở nên lỗi thời nếu tên khách hàng hoặc sản phẩm thay đổi. Điều này tạo thêm gánh nặng phải đồng bộ dữ liệu giữa các service.
Lựa Chọn: Gọi API Khi Cần
Ngược lại, việc chỉ gọi API từ Customer và Product khi cần có những lợi thế như:
- Tính cập nhật: Luôn đảm bảo thông tin là mới nhất.
- Đơn giản hóa dữ liệu: Order Service chỉ cần lưu các mã tham chiếu (Customer ID, Product ID) thay vì toàn bộ thông tin.
Nhược điểm:
- Hiệu suất: Gây ra độ trễ khi phải gọi nhiều API. Nếu một service không hoạt động, các chức năng phụ thuộc sẽ bị ảnh hưởng.
- Phức tạp: Cần thiết lập cơ chế retry hoặc caching để đối phó với lỗi mạng.
Lựa Chọn Tối Ưu: Tùy Thuộc Vào Use Case
Trong thực tế, giải pháp thường nằm ở sự cân bằng giữa hai phương pháp trên:
- Nếu yêu cầu về hiệu suất cao hơn, có thể cân nhắc lưu trữ dữ liệu. Tuy nhiên, cần có cơ chế đồng bộ hóa thông tin từ các service liên quan.
- Nếu tính chính xác và cập nhật thông tin là ưu tiên hàng đầu, nên chỉ lưu mã tham chiếu và gọi API khi cần.
Hơn nữa, việc sử dụng các chiến lược như caching hoặc event-driven architecture có thể giảm thiểu nhược điểm của mỗi phương pháp.
Tính bất biến và tính chính xác theo thời điểm giao dịch.
Ví dụ, tại thời điểm tạo Order và Bill, khách hàng khai báo:
- Tên khách hàng: Hoang Anh
- Sản phẩm: “Áo màu xanh”
Tuy nhiên, thông tin này có thể thay đổi trong tương lai:
- Tên khách hàng: Hoàng Anh Nguyễn
- Sản phẩm: “Áo màu xanh có viền”
- Tính đúng đắn của dữ liệu tại thời điểm giao dịch:
- Thông tin trong hóa đơn (bill) cần phản ánh chính xác trạng thái tại thời điểm giao dịch xảy ra.
- Ví dụ: Tên khách hàng là “Hoang Anh” và sản phẩm là “Áo màu Xanh” tại thời điểm đó, thì những thông tin này cần được ghi nhận bất biến trong hóa đơn. Điều này đảm bảo:
- Hóa đơn hợp lệ trong trường hợp kiểm tra hoặc đối soát sau này.
- Dữ liệu có giá trị pháp lý và phù hợp với bối cảnh thời điểm giao dịch.
- Chi phí hiệu năng khi gọi API qua lại:
- Khi ref nhiều service để lấy dữ liệu, hệ thống sẽ chịu thêm chi phí:
- Độ trễ: Gọi nhiều API làm chậm quá trình tạo hóa đơn.
- Tính phụ thuộc: Nếu bất kỳ service nào gặp lỗi, việc tạo hóa đơn có thể bị gián đoạn.
- Chi phí mở rộng (scalability): Cần tăng số lượng instance của các service khác để đáp ứng lượng gọi API lớn từ Order Service.
- Khi ref nhiều service để lấy dữ liệu, hệ thống sẽ chịu thêm chi phí:
- Một góc nhìn thực tiễn:
- Mỗi dự án và trường hợp sử dụng (use case) sẽ có cách xử lý khác nhau, nhưng nguyên tắc chung:
- Với dữ liệu bất biến: Nên lưu trữ tại thời điểm giao dịch để đảm bảo tính đúng đắn và hiệu năng.
- Với dữ liệu thay đổi thường xuyên hoặc cần cập nhật: Có thể ref để đảm bảo tính cập nhật (ví dụ: trạng thái đơn hàng).
- Tính chất của dữ liệu (bất biến hay không).
- Tần suất thay đổi dữ liệu.
- Mức độ yêu cầu hiệu năng của hệ thống.
- Mỗi dự án và trường hợp sử dụng (use case) sẽ có cách xử lý khác nhau, nhưng nguyên tắc chung:
