Giới thiệu

Trong quá trình phát triển ứng dụng, mô hình yêu cầu/phản hồi truyền thống (req/res) bắt đầu bộc lộ những điểm yếu. Khi số lượng dịch vụ tăng lên, từ hai dịch vụ (A -> B), mọi thứ trở nên đơn giản: một dịch vụ gọi dịch vụ khác và nhận được phản hồi. Nhưng khi có thêm nhiều dịch vụ khác tham gia (C, D,...), độ phức tạp gia tăng đáng kể. Thay vì chỉ có một vài kết nối, giờ đây bạn phải đối mặt với một mạng lưới các phụ thuộc mà trong đó mỗi dịch vụ có thể giao tiếp với mọi dịch vụ khác. Đó chính là lúc các mẫu kiến trúc điều khiển sự kiện (EDA) như Event Sourcing và CQRS trở nên hữu ích.

Sự Kiện là gì?

Một sự kiện chỉ đơn giản là một tín hiệu cho thấy có điều gì đó quan trọng đã xảy ra.

Ví dụ:

• OrderPlaced -> khi một khách hàng tạo một đơn hàng mới.
• StockDecreased -> khi cập nhật hàng tồn kho sau đơn hàng.

Các Thành Phần Chính của EDA:

• Producers: Các dịch vụ tạo ra sự kiện (ví dụ: OrderService).
• Consumers: Các dịch vụ phản ứng với sự kiện (ví dụ: InventoryService).

Event Sourcing là gì?

Thông thường, các hệ thống chỉ lưu trữ trạng thái mới nhất của dữ liệu. Nhưng với Event Sourcing, thay vì chỉ lưu trạng thái hiện tại, chúng ta lưu tất cả các sự kiện đã xảy ra để đạt được trạng thái đó. Hãy nghĩ về nó như một sổ cái ghi lại mọi thay đổi.

Ví dụ: Tài khoản ngân hàng:

• AccountOpened (Số dư ban đầu: $0)
• DepositMade (Số tiền: $350)
• WithdrawalMade (Số tiền: $300)

Trạng thái hiện tại: Số dư: $50. Thay vì chỉ lưu “Số dư = $50”, chúng ta lưu toàn bộ lịch sử các sự kiện.

Lợi ích của Event Sourcing:

• Theo dõi thay đổi: Lịch sử đầy đủ của các thay đổi luôn có sẵn.
• Xây dựng lại trạng thái bất kỳ lúc nào: Bạn có thể phát lại các sự kiện để xây dựng lại trạng thái hiện tại.

Vấn đề

Việc phát lại tất cả các sự kiện từ đầu có thể chậm và không hiệu quả.

Giải pháp cho vấn đề này:

1. Hydration & Replay

   • Hydration: Xây dựng lại trạng thái hiện tại bằng cách áp dụng tất cả các sự kiện theo thứ tự.
   • Replay: Xử lý lại toàn bộ luồng sự kiện (hoặc một phần lớn của nó) để tính toán lại trạng thái hiện tại.

2. Snapshots (Tối ưu hóa sourcing)

   • Thay vì phát lại mọi sự kiện từ đầu:
   • Định kỳ chụp trạng thái hiện tại như một snapshot (ví dụ: mỗi 100 sự kiện).
   • Để xây dựng lại, tải snapshot mới nhất và chỉ áp dụng các sự kiện đã xảy ra sau đó. Điều này cải thiện hiệu suất đáng kể.

3. Materialized Views

   • Đối với các hệ thống có nhiều truy vấn, chúng ta thường duy trì các views đã được tính toán trước, tối ưu hóa cho việc đọc trong một cơ sở dữ liệu riêng biệt. Hãy nghĩ về nó như một mô hình đọc đã được cache.
   • Các producers tiếp tục phát ra sự kiện, và các consumers xây dựng các views này trong thời gian thực.

CQRS (Phân tách trách nhiệm lệnh và truy vấn)

Các hệ thống truyền thống sử dụng cùng một mô hình cho:

• Lệnh (ghi) -> thay đổi trạng thái hệ thống.
• Truy vấn (đọc) -> truy xuất trạng thái hệ thống.

CQRS phân tách các trách nhiệm này:

• Bên lệnh: Xử lý ghi, lưu trữ sự kiện.
• Bên truy vấn: Xây dựng các views đã được materialized, tối ưu hóa cho việc đọc.

Việc phân tách này giúp hệ thống mở rộng hơn, dễ bảo trì hơn và linh hoạt hơn.

Tóm tắt

Các sự kiện ghi lại những gì đã xảy ra. Event Sourcing lưu trữ lịch sử đầy đủ, không chỉ trạng thái hiện tại. Snapshots và Hydration giúp hiệu quả hơn trong việc xây dựng lại trạng thái. Materialized Views cung cấp quyền truy cập nhanh đến trạng thái hiện tại. CQRS phân tách mô hình ghi (lệnh & sự kiện) khỏi mô hình đọc (truy vấn & views).

Thực Hành Tốt Nhất

• Lập kế hoạch cấu trúc sự kiện: Xác định các sự kiện cần lưu trữ và cách chúng liên quan đến nhau.
• Sử dụng snapshots hợp lý: Đánh giá tần suất chụp và cách thức hồi phục trạng thái.
• Tối ưu hóa Materialized Views: Đảm bảo rằng các views được tối ưu hóa cho các truy vấn thường gặp để nâng cao hiệu suất.

Những Cạm Bẫy Thường Gặp

• Quá nhiều sự kiện: Đôi khi, việc lưu trữ quá nhiều sự kiện có thể gây khó khăn trong việc quản lý và truy vấn.
• Thiếu kiểm soát: Không duy trì kiểm soát tốt về các sự kiện có thể dẫn đến việc tái tạo trạng thái không chính xác.

Mẹo Tối Ưu Hiệu Suất

• Sử dụng caching: Để giảm tải cho cơ sở dữ liệu trong các truy vấn đọc.
• Phân chia dữ liệu: Tách biệt các dịch vụ và cơ sở dữ liệu cho các hoạt động ghi và đọc để cải thiện hiệu suất.

Câu Hỏi Thường Gặp

1. Event Sourcing có phù hợp cho mọi loại ứng dụng không?
   • Không, Event Sourcing thường phù hợp hơn với các ứng dụng có lịch sử thay đổi quan trọng.
2. CQRS có phức tạp không?
   • Có, CQRS có thể mang lại độ phức tạp cao hơn nhưng đổi lại là hiệu suất và khả năng mở rộng tốt hơn.

Kết luận

Event Sourcing và CQRS là những công cụ mạnh mẽ cho các nhà phát triển trong việc xây dựng ứng dụng quy mô lớn. Hy vọng rằng bài viết này đã giúp bạn hiểu rõ hơn về chúng và cách áp dụng chúng vào dự án của mình. Đừng ngần ngại áp dụng những kiến thức này để tối ưu hóa ứng dụng của bạn ngay hôm nay!