Tuy nhiên, đối với một hệ thống lớn, mô hình CRUD tỏ ra không hiệu quả và tỏ ra các khó khăn khi: - Chỉ sử dụng cùng một model cho tất cả nghiệp vụ - Các logic nghiệp vụ luôn phát sinh v
Triển khai CQRS
Triển khai
Vậy sau khi đã nắm rõ về khái niệm CQRS và chắc chắn rằng không tồn tại những hiểu lầm về nó, chúng ta có thể áp dụng parttern này vào dự án của mình Việc triển khai CQRS vào dự án là một điều không quá phức tạp Bạn hoàn toàn có thể áp dụng pattern này vào ngay dự án của mình.
3.2.1 Một mô hình non-CQRS Đầu tiên nhìn vào một hệ thống thông thương, chúng ta sẽ có các thành phần cơ bản trong hầu hết các hệ thống như sau Đi từ ngoài vào trong, tầng ngoài cùng là nơi nhận và phản hồi các yêu cầu từ người dùng Tiếp đó là tầng Application Service chứa các logic nghiệp vụ, là lõi của toàn bộ hệ thống Tiếp đến là Model nơi giao tiếp và truy cập với các hệ thống lưu trữ Tại tầng data access thường chúng ta sẽ chỉ triển khai duy nhất một model (một class, một struct) duy nhất để truy cập dữ liệu cũng như giải quyết tất cả các logic nghiệp vụ.
Trong ví dụ trên, có thể thấy chung ta sử dụng một đối tượng Reservation duy nhất cho tất cả các thao tác dữ liệu Hay thậm chỉ là có thể triển khai logic lên cùng một model duy nhất này.
3.2.2 Mô hình CQRS cơ bản
Tuy nhiên đối với CQRS chung ta sẽ sử dụng các model khác nhau cho command và query
Cũng tương tự như lệnh, đôi khi chúng ta chỉ cần một vài trường nhất định để thực hiện logic nghiệp vụ Một mô hình chỉ với các trường cần thiết và nhỏ gọn, đáp ứng tốt cho các nghiệp vụ ghi phức tạp là lựa chọn hoàn hảo.
Và đối với các đối tượng tách biệt như trên, ta hoàn toàn có thể triển khai riêng biệc các thao tác dữ liệu cho chúng được mô tả bằng hai repository như bên dưới.
Và tất nhiên với sự tách biệt trên, các logic nghiệp vụ hoàn toàn có thể được thực hiện tách biệt và không phụ thuộc lẫn nhau.
Có thể thấy các đối tưởng xử lý (các handler) giao tiếp với các đối tượng riêng biệt cho các nghiệp vụ khác nhau. Đó là một trong những cách triển khai đơn giản nhất mà bạn có thể áp dụng ngay vào dự án của mình Với các model như vậy, bạn hoàn toàn có thể sử dụng chúng cho các truy vấn trên cũng một database như bình thường.
Hình trên mô tả việc sử dụng một database duy nhất cho tất cả các thao tác.
3.2.3 Mô hình CQRS với các database khác nhau
Như đã đề cập từ trước, đối với các hệ thống phức tạp, thì thường sẽ không có sự đồng đều giữa việc đọc và việt ghi.
Trong hệ thống phần mềm, tác vụ đọc dữ liệu chiếm phần lớn nhu cầu, lên đến hơn 90% Các tác vụ đọc dữ liệu đòi hỏi tính đa dạng và linh hoạt cao để phục vụ từng mục đích cụ thể.
Các thao tác ghi là cốt lõi của hệ thống, đóng vai trò quan trọng đảm bảo hoạt động ổn định và chính xác của hệ thống Mặc dù đôi khi ít hơn so với thao tác đọc dữ liệu, các thao tác ghi lại đòi hỏi sự chính xác và ràng buộc dữ liệu cao, ảnh hưởng trực tiếp đến tính toàn vẹn và độ tin cậy của hệ thống.
Vậy nên với sự bất cân xứng ấy, chúng ta hoàn toàn có thể nghĩ đến giải pháp sử dụng các hệ cơ sở dữ liệu khác nhau phù hợp riêng biệc cho các command và query.
Chúng ta có thể sẽ để các model giao tiếp với các database riêng biệt cho các nhiệm vụ đọc và ghi, và đường nhiên giữa chúng cần có sự đồng nhất về mặt dữ liệu với nhau.
Ví dụ như đó có thể là một hệ thống replica trong đó có các node để thực hiện command và các node khác ở chế độ read-only phục vụ cho các query.
Hoặc có thể sử dụng các database SQL cho việc ghi và các database NoSql cho việc đọc để tận dụng ưu điểm của từng loại và từng như cầu sử dụng.
Như ví dụ trên ta có thể thấy rằng chúng ta có thể sử dụng mysql để thực thi các command và elastic search cho việc đọc, và đồng bộ giữa chúng thông qua một message queue.
Tuy nhiên tới đây chúng ta cần phải làm rõ lại một lần nữa cqrs không nhất thiết phải cần sử dụng nhiều database khác nhau cho việc đọc ghi Và việc nhân đôi database ra cũng không phải là cqrs.
Chương 4: CQRS, ES và DDD
Và ở một mức độ cao cấp hơn, CQRS thường được triển khai cùng với Event Sourcing và Domain Driven Design để tạo ra một hệ thống mạnh mẽ, linh hoạt và dễ mở rộng.
Event Sourcing (ES)
Event Sourcing là một mô hình kiến trúc lưu trữ, trong đó trạng thái của một ứng dụng được xây dựng bằng cách áp dụng một chuỗi các sự kiện (events) lên trạng thái ban đầu.
Vậy tại sao lại kết hợp Event Sourcing và CQRS?
Vấn đề đồng bộ hóa dữ liệu
Trong CQRS, dữ liệu bên đọc thường được phi chuẩn hóa và tối ưu hóa cho các truy vấn, trong khi dữ liệu bên ghi tập trung vào việc duy trì tính toàn vẹn và nhất quán của nghiệp vụ.
Event Sourcing giúp duy trì sự đồng bộ hóa giữa hai bên bằng cách phát sinh các sự kiện khi có thay đổi trạng thái ở phần ghi Các sự kiện này sau đó được truyền đến phần đọc để cập nhật dữ liệu, giúp đảm bảo dữ liệu bên đọc luôn được cập nhật gần như theo thời gian thực.
Nhìn vào hình trên, ta thấy khi thực hiện “Write side", thì hệ thống sẽ lưu lại event vào Event store, việc này nhằm mục đích:
Phục hồi và tái tạo dữ liệu:
Với CQRS, việc tách biệt phần ghi và phần đọc giúp dễ dàng quản lý và tối ưu hóa từng phần riêng lẻ, nhưng cũng đòi hỏi cơ chế để giữ cho dữ liệu bên đọc luôn đồng bộ với bên ghi.
Event Sourcing cung cấp cơ chế để phát lại các sự kiện từ kho sự kiện, cho phép tái tạo lại trạng thái của dữ liệu bên đọc bất kỳ lúc nào Điều này rất hữu ích khi cần phục hồi dữ liệu hoặc thay đổi cấu trúc dữ liệu bên đọc để hỗ trợ các yêu cầu truy vấn mới.
Ví dụ: trong trường hợp phía database read bị mất đồng bộ với bên database write vì một vài lý do nào đó, ta có thể dễ dàng “tua lại" dữ liệu ở phía read database bất cứ lúc nào.
Domain-Driven Design (DDD)
DDD là một phương pháp luận phát triển phần mềm hướng đối tượng và thiết kế phần mềm, xây dựng phần mềm dựa trên các khái niệm và quy trình kinh doanh.
Mối liên hệ giữa DDD (Domain-Driven Design) và CQRS (Command Query
CQRS và DDD có mối liên hệ chặt chẽ do CQRS ra đời để giải quyết các thách thức gặp phải khi áp dụng DDD vào thực tế.
– Nguồn gốc ý tưởng: CQRS được phát triển từ các vấn đề mà các chuyên gia DDD đối mặt khi làm việc với các hệ thống phức tạp Việc tách biệt rõ ràng giữa các hành động thay đổi trạng thái hệ thống (commands) và các hành động truy vấn dữ liệu (queries) trong CQRS giúp giải quyết nhiều khó khăn về thiết kế mà DDD gặp phải.
– Sự phù hợp tự nhiên: Khi áp dụng DDD, hệ thống thường được chia thành các ngữ cảnh giới hạn (bounded contexts) Trong nhiều trường hợp, CQRS có thể là một sự phù hợp tự nhiên cho những ngữ cảnh này, giúp rõ ràng hơn về trách nhiệm và cải thiện khả năng mở rộng của hệ thống.
– Thuật ngữ và khái niệm chung: Tài liệu và các cuộc thảo luận về CQRS thường sử dụng thuật ngữ và khái niệm từ DDD Điều này làm cho việc hiểu và triển cả hai đều tập trung vào việc tách biệt rõ ràng các khía cạnh khác nhau của hệ thống để dễ quản lý và mở rộng.
Tóm lại, DDD và CQRS có một mối liên hệ mật thiết với nhau, với CQRS thường được coi là một phần mở rộng hoặc một sự phát triển tự nhiên của các nguyên tắc và thực tiễn trong DDD.
Tuy vậy DDD thường được áp dụng cho các dự án lớn và phức tạp, nơi mà việc quản lý miền (domain) và logic nghiệp vụ đòi hỏi sự tách biệt rõ ràng và tổ chức cẩn thận Mặt khác, không có lý do gì mà các dự án vừa và nhỏ lại không thê áp dụng CQRS Ví dụ, một dự án nhỏ hoàn toàn có thể phân tách thao tác ghi và thao tác đọc theo CQRS để cải thiện hiệu suất, nhưng vì đó là dự án nhỏ nên nó thực tế đã đủ đơn giản và không cần phải áp dụng DDD làm gì nữa.
CQRS, ES và DDD
Nhìn vào mô hình trên, ta có thể phân tích sự kết hợp giữa CQRS, ES và DDD:
Mọi command được truyền vào command bus => chịu trách nhiệm routing command đến nơi xử lý cần thiết (Vấn đề tại sao cần command, ví dụ trên mainboard có rất nhiều linh kiện, khi có một yêu cầu không thế nào xác định chính xác nên kết nối đến linh kiện nào để thực hiện, hay cần một giao thức gì để thực hiện, lúc này ta cần một hệ thống bus để abstract vấn đề kết nối, giúp có tất cả yêu cầu có thể đi vào cùng một đường).
Handler nơi giải quyết các vấn để domain cụ thể khác nhau Sau đó có các aggregates phát sinh và cần được lưu vào hệ thống thông qua các repository. Read side:
Khi các command được thực hiện thành công thì phát sinh một event Event này được gửi đến read side thông qua event bus có trách nhiệm routing đến các event handler cần thiết để xử lý, và lưu trữ vào database Ở phia read side có thể không chỉ là một mà rất nhiều database thậm chí là database khác nhau phục vụ các mục đích khác nhau…
- Command: Lệnh phát sinh xử lý một nghiệp vụ
- Event: bảo một quá trình xử lý kết thúc
- Command Bus: đường vận chuyển các command.
- Event bus: đường vận chuyển các event.
- Domain Model: mô hình xử lý nghiệp vụ
- DTO: Data transfer object (rất linh hoạt)
- Query Facade: Mô hình query dữ liệu (REST, GRAPHQL,…)
Xét ví dụ cụ thể:
- Xây dựng ứng dụng thương mại điện tử cho phép mua và bán hàng.
- Sau đặt hàng người dùng có thể thanh toán.
- Sau khi thành toán xong đơn hàng được xác nhận thì gửi tin nhắn và email xác nhận cho người dung.
Xác định các phạm vi bài toán nghiệp vụ (các domain):
Các domain có sự liên quan đến nhau, tuy nhiên vẫn là các nghiệp vụ riêng biệt, và có ranh giới rõ ràng.
- Nhằm xác định rõ các tính chất của yêu cầu đầu vào
- Xác định các đối tượng và các hành vi
- Cơ sở dữ liệu thiết kế model, command và event
- Đảm bảo một mô hình thống nhất giữa người lập trình và người phát triển nghiệp vụ
Hãy tưởng tượng trong một dự án lớn với rất nhiều bên tham gia nào là dev, nào là test, người phát triển nghiệp vụ, và mỗi người đều sử dụng ngôn ngữ chuyên ngành của riêng mình Dẫn đến việc miss thông tin khó khăn trong giao tiếp và phát triển sản phẩm.
Ta có thể xác định được Ubiquitous Language như sau:
- Người dùng liệt kê sản phẩm
- Cho lựa chọn sản phẩm và số lượng
- Thanh toán để xác nhận đơn hàng
- Gửi tin nhắn và email báo đã đặt hàng thành công.
Từ đó ta có thể xác định các Noun và Verb khác nhau
Xác định noun và verb
Noun Verb product List product
SMS Send Đối với từng domain trên ta hoàn toàn có thể sử dụng các model, các hướng tiêp cận phù hợp nhất đối với yêu cầu của domain đó.
Mô hình CQRS kết hợp với ES là sự lựa chọn thích hợp trong trường hợp Order, nơi liên tục nhận các lệnh từ người dùng.
Trong các hệ thống gửi thông tin như email hay SMS, các mô hình CRUD cơ bản có thể đáp ứng được nhu cầu Các hệ thống này chỉ cần nhận, gửi thông tin và lưu lại nhật ký nếu cần, do đó không đòi hỏi các chức năng phức tạp.
Và từ các phân tích đó, ta cũng có thể xây dựng tiêp tục các Aggregate cho từng để phục vụ lưu trữ dữ liệu và thực hiện các logic nghiệp vụ.
Và cũng từ các Noun và Verb này ta có thể xác định được các command và event
Và qua phân tích trên, ta thấy rằng các commad sẽ tạo ra các event Và với các event này chúng ta có thể thay đôi hoàn toàn các ghi dữ liệu ở phía read side, từ một database lưu các thực thể như ban đầu, chúng ta có thể lưu lại các sự kiện này Và như đã giải thích ở phần 4.1 Việc lưu lại các event và chuyển tiếp các event này đến phia read side là một sự kết hợp tốt cho việc bảo đảm tính nhất quán và toàn vẹn dữ liệu trong mô hình CQRS.
Hạn chế
Complexity (Độ phức tạp)
- Thay vì một cơ sở dữ liệu quan hệ đơn giản như SQL, giờ đây ứng dụng sẽ có các bộ xử lý lệnh (command handlers), việc phân phối (dispatching) và ghi nhật ký (logging) Tất cả mã nguồn bổ sung này tạo ra khả năng gây ra lỗi.
- Việc triển khai CQRS có thể đem lại thêm phức tạp cho hệ thống trong giai đoạn development, đặc biệt nếu không quen với mô hình này
Đặc biệt, khi tách biệt việc đọc và ghi dữ liệu, quá trình đồng bộ dữ liệu và đảm bảo sự nhất quán giữa các mô hình có thể gây ra các vấn đề phức tạp.
Delayed data synchronization
- Delayed Data Synchronization (Đồng bộ dữ liệu trễ) trong CQRS xảy ra khi có một khoảng thời gian giữa việc thực hiện một lệnh (command) và việc cập nhật tương ứng được phản ánh trên phần đọc của hệ thống Điều này có nghĩa là sau khi một lệnh được thực hiện
- Ghi dữ liệu (Write Process): Khi một lệnh được gửi đến hệ thống, nó được xử lý bởi phần ghi Cơ sở dữ liệu ghi được cập nhật ngay lập tức với những thay đổi tương ứng.
Sau khi hoàn thành việc ghi, dữ liệu sẽ được đồng bộ hóa thông qua cơ chế gửi một sự kiện hoặc thông báo đến hàng đợi tin nhắn Cơ chế này đảm bảo dữ liệu được cập nhật đồng thời trên tất cả các hệ thống liên quan.
Xử lý thông điệp: Luồng thông tin sẽ được truyền đến bộ phận Đọc Tại đây, bản sao của dữ liệu sẽ được cập nhật dựa trên những thông tin đã được truyền.
- Truy vấn dữ liệu (Read Process): Khi người dùng gửi một truy vấn, phần đọc sẽ sử dụng dữ liệu từ cơ sở dữ liệu đọc Do độ trễ trong việc đồng bộ dữ liệu, dữ liệu trả về có thể không phải là dữ liệu mới nhất ngay lập tức sau khi lệnh được thực thi.
Giả sử một hệ thống quản lý đơn hàng trực tuyến sử dụng mô hình CQRS:
- Khi người dùng đặt hàng (command), hệ thống sẽ ghi thông tin đơn hàng vào cơ sở dữ liệu ghi.
- Sau đó, một sự kiện "OrderPlaced" được gửi đến hàng đợi tin nhắn.
- Các dịch vụ tiêu thụ sự kiện từ hàng đợi sẽ xử lý sự kiện và cập nhật cơ sở dữ liệu đọc với thông tin đơn hàng mới.
Người dùng có thể kiểm tra trạng thái đơn hàng của họ (query) thông qua cơ sở dữ liệu đọc, nhưng có thể có một độ trễ ngắn trước khi họ thấy trạng thái mới nhất của đơn hàng.
Eventual consistency (Tính nhất quán dữ liệu cuối cùng) 28 1 Distributed transaction
Khi tách biệt cơ sở dữ liệu đọc và ghi trong mô hình CQRS, dữ liệu đọc có thể trở nên lỗi thời nếu không được cập nhật kịp thời để phản ánh các thay đổi từ cơ sở dữ liệu ghi
Điều này gây ra vấn đề về tính nhất quán dữ liệu, vì khó phát hiện ra việc người dùng đưa ra yêu cầu dựa trên dữ liệu đọc cũ.
- Phạm vi giao dịch (Transaction Scope) bao phủ cả hai hành động này.
- Điều này đảm bảo rằng cả hai hành động đều thành công hoặc cả hai đều thất bại, duy trì tính nhất quán giữa "Write side" và "Read side".
Ví dụ thực tế ở 1 của hàng cà phê
Quá trình đặt hàng (Command):
- Khách hàng đặt lệnh (order) cà phê tại quầy thu ngân.
- Lệnh này yêu cầu thực hiện một hành động cụ thể: chuẩn bị đồ uống.
- Việc thực hiện lệnh có thể bị từ chối nếu có vấn đề về cấu trúc hoặc vi phạm quy tắc nghiệp vụ.
- Khi lệnh được chấp nhận và thực hiện, hệ thống sẽ chuyển sang trạng thái mới. Quá trình truy vấn tình trạng đơn hàng (Query):
- Khách hàng hỏi nhân viên thu ngân về tình trạng đơn hàng.
- Truy vấn là yêu cầu lấy thông tin, không thực hiện thao tác nào và không có logic nghiệp vụ.
- Truy vấn không có tác dụng phụ và hoàn toàn idempotent, nghĩa là kết quả trả về luôn giống nhau nếu trạng thái hệ thống không thay đổi.
- Nhân viên thu ngân có thể phải hỏi người pha chế hoặc dựa vào vị trí cốc cà phê trong hàng đợi để trả lời truy vấn.
Phạm vi giao dịch thu gọn:
- Giao dịch chỉ bao gồm việc lưu thay đổi vào "Write side data store".
- Việc đặt tin nhắn vào hàng đợi tin nhắn diễn ra bên ngoài phạm vi giao dịch.
- Sau khi lệnh (Command) cập nhật "Write side", một tin nhắn được đặt vào hàng đợi tin nhắn một cách không đồng bộ.
- Nếu quá trình đặt tin nhắn vào hàng đợi gặp sự cố, "Write side" vẫn được cập nhật, nhưng "Read side" có thể bị chậm trễ trong việc nhận thay đổi.
- Phương pháp được đề cập ở đây không sử dụng giao dịch phân tán để đồng bộ hóa dữ liệu giữa phần ghi (write side) và phần đọc (read side) Thay vào đó, nó sử dụng khái niệm "nhất quán cuối cùng" (eventual consistency).
Không đảm bảo thứ tự cập nhật là nhược điểm của tiếp cận này Với cách tiếp cận này, không thể bảo đảm thứ tự cập nhật dữ liệu trên phần đọc sẽ giống với thứ tự trên phần ghi.
- Phụ thuộc vào chức năng của cơ sở dữ liệu phần ghi: Phương pháp này phụ thuộc vào chức năng của cơ sở dữ liệu phần ghi (write-side data store) Cơ sở dữ liệu này phải có khả năng gửi một tin nhắn (message) để phản hồi mỗi lần cập nhật dữ liệu trên mô hình ghi
- Kết hợp với Event Sourcing: Cách tiếp cận này phù hợp đặc biệt khi kết hợp
CQRS với Event Sourcing Nếu kho lưu trữ sự kiện (event store) có thể gửi một bản sao của mỗi sự kiện đã lưu vào hàng đợi tin nhắn (message queue), thì bạn có thể đạt được tính nhất quán cuối cùng (eventual consistency) cho phần đọc
- Tính nhất quán hợp lý
- Đơn giản hơn trong quản lý giao dịch
- Không đảm bảo thứ tự cập nhật
- Yêu cầu hệ thống vận chuyển tin nhắn tin cậy
- Đơn giản, dễ triển khai
- Phù hợp với Event Sourcing
- Tính nhất quán cuối cùng
- Không đảm bảo thứ tự cập nhật
- Phải quản lý bất đồng bộ
Cost (Chi phí)
5.4.1 Operational Cost (Chi phí Vận hành):
- Quản lý Các Dịch vụ: Vận hành một hệ thống CQRS có thể đòi hỏi quản lý nhiều dịch vụ phức tạp hơn so với hệ thống truyền thống Bạn cần phải đảm bảo rằng các dịch vụ này hoạt động một cách đồng nhất và hiệu quả.
Để đảm bảo tính nhất quán trong kiến trúc CQRS, thách thức nằm ở việc duy trì sự đồng bộ giữa các dịch vụ đọc và ghi Điều này đòi hỏi việc xác định cơ chế sao chép dữ liệu và đảm bảo dữ liệu được cập nhật đồng nhất trên mọi dịch vụ, đảm bảo tính toàn vẹn và chính xác của thông tin.
- Giám sát và Điều chỉnh: Để đảm bảo hiệu suất và sẵn sàng của hệ thống, bạn cần thường xuyên giám sát và điều chỉnh các thành phần vận hành Điều này có thể đòi hỏi việc triển khai các công cụ giám sát và tự động hóa để giảm thiểu thời gian dừng hệ thống và các vấn đề liên quan đến hiệu suất.
5.4.2 Performance Cost (Chi phí hiệu suất)
- Tính Nhất quán và Độ trễ: Một trong những thách thức của CQRS là đảm bảo tính nhất quán giữa phía đọc và phía ghi của hệ thống Việc này có thể tạo ra độ trễ, đặc biệt là trong các tình huống mà cần phải đồng bộ hóa dữ liệu giữa hai phía Điều này có thể ảnh hưởng đến hiệu suất tổng thể của hệ thống.
Tối ưu cơ sở dữ liệu bao gồm việc tối ưu cả hoạt động đọc và ghi Đối với hoạt động đọc, sử dụng các kỹ thuật như đệm hoặc định dạng trước dữ liệu giúp giảm tải lên cơ sở dữ liệu, cải thiện hiệu suất Đối với hoạt động ghi, các kỹ thuật như phân cấp hoặc lập chỉ mục phù hợp cho phép tăng hiệu suất và khả năng mở rộng.
- Xử lý Sự kiện (Event) và Lệnh (Command): Xử lý các sự kiện và lệnh trong hệ thống CQRS có thể ảnh hưởng đến hiệu suất của hệ thống Việc thiết kế và triển khai các trình xử lý sự kiện và lệnh hiệu quả có thể giảm thiểu độ trễ và tăng tốc độ xử lý.
Quản lý thời gian chờ và đáp ứng đóng vai trò quan trọng trong việc đảm bảo hệ thống hoạt động nhanh chóng, hiệu quả, mang lại trải nghiệm tốt nhất cho người dùng Bằng cách quản lý thời gian chờ và thời gian phản hồi cho các truy vấn và lệnh, hệ thống sẽ xử lý yêu cầu nhanh chóng và hiệu quả hơn, từ đó cải thiện hiệu suất tổng thể.
Chương 6: Trường hợp nên áp dụng và không nên áp dụng.
Trường hợp nên sử dụng
- Collaborative Domains một ứng dụng ghi chú hợp tác, cho phép nhiều người dùng cùng chỉnh sửa các ghi chú Ví dụ như Google Doc, Google Sheet…
- Dùng để đồng bộ hóa dữ liệu giữa nhiều người dùng cùng chỉnh sửa tài liệu cùng một lúc.
- Dữ liệu được phân tách thành lệnh ghi và lệnh đọc, giúp hệ thống xử lý các thay đổi đồng thời từ nhiều nguồn khác nhau mà không gây ra xung đột.
- Xử Lý Xung Đột: Trong quá trình hợp tác, có thể xảy ra xung đột khi nhiều người dùng cùng chỉnh sửa cùng một ghi chú CQRS cung cấp cơ chế để xử lý xung đột này, bằng cách đảm bảo rằng chỉ có một phiên bản của ghi chú được chấp nhận và lưu trữ.
- Các ứng dụng thương mại điện tử như Shopee, Amazon, Lazada… sử dụng CQRS để xử lý hàng triêu giao dịch mua bán hàng ngày
- Điều chỉnh Tải: Với việc tách biệt dữ liệu đọc và ghi, hệ thống có thể điều chỉnh tải làm việc một cách linh hoạt Các máy chủ dữ liệu đọc có thể được mở rộng theo nhu cầu để xử lý lượng truy cập đồng thời từ nhiều người dùng.
- Tối Ưu Hóa Hiệu Suất: Bằng cách tối ưu hóa dữ liệu đọc cho việc truy vấn nhanh chóng và hiệu quả, hệ thống có thể đáp ứng với các yêu cầu truy cập của người dùng một cách linh hoạt và nhanh chóng, giúp cải thiện trải nghiệm người dùng và tăng cường hiệu suất
- Mô Hình Dữ Liệu Đọc Tối Ưu Hóa: Các mô hình dữ liệu đọc được thiết kế để chứa các thông tin cần thiết cho việc hiển thị dòng thời gian, bao gồm các bài đăng từ bạn bè, các hoạt động mới nhất, và các tin nhắn đến người dùng Các quán hoặc hiệu suất, việc triển khai CQRS có thể là quá mức và không cần thiết.
- Yêu cầu tính nhất quán mạnh mẽ: Trong các trường hợp mà tính nhất quán ngay lập tức và mạnh mẽ là rất quan trọng, như các hệ thống tài chính hoặc giao dịch, việc sử dụng CQRS có thể gây ra thách thức do nó thường tập trung vào việc tối ưu hóa tính nhất quán
- Kinh nghiệm phát triển hạn chế: Trong các dự án nơi mà đội ngũ phát triển chưa có kinh nghiệm đầy đủ với mô hình CQRS và không có thời gian hoặc tài nguyên để học và triển khai nó một cách hiệu quả, việc sử dụng CQRS có thể gây ra rủi ro và thất bại.
Best practices
Một case study thực tế
Công ty xuất bản số Axel Springer cần quản lý hàng nghìn hình ảnh trên nền tảng trực tuyến, bao gồm: mua bản quyền, theo dõi cách sử dụng và thời gian sử dụng hình ảnh.
Họ đã xây dựng một ứng dụng SaaS nội bộ để tổng hợp thông tin mua hàng và siêu dữ liệu hình ảnh từ các nền tảng trực tuyến khác nhau Ứng dụng này hoạt động như một kho lưu trữ trung tâm, đồng bộ hóa với hệ thống bên thứ ba để cập nhật thông tin.
Hệ thống cần đáp ứng nhu cầu truy cập và cập nhật dữ liệu khác nhau, bao gồm:Truy vấn:
Theo dõi nơi hình ảnh được sử dụng
Kiểm tra thời hạn hình ảnh có thể tiếp tục sử dụng trực tuyến
Chọn nhiều hình ảnh và kích hoạt xử lý hàng loạt cho các lần cập nhật
Chọn nhiều nhà cung cấp và kích hoạt xử lý hàng loạt để tạo hóa đơn
Sử dụng DynamoDB làm kho lưu trữ sự kiện.
Sử dụng Aurora MySQL Serverless làm mô hình đọc.
Sử dụng Simple Queue Service của AWS để xử lý các yêu cầu không đồng bộ.
Trong sơ đồ trên thì:
- ELB là dịch vụ giúp phân phối lưu lượng truy cập đến các ứng dụng web đang chạy trên nhiều máy chủ ảo (EC2 instances) trong AWS
- Elastic Fabric Adapter (EFA) là giao diện mạng dành cho các phiên bản Amazon EC2, cho phép khách hàng chạy các ứng dụng yêu cầu mức độ giao tiếp giữa các nút cao trên quy mô lớn trên AWS
- Lean CMS Event Provider cung cấp cho nhà bán lẻ những công cụ họ cần để xuất bản nội dung lên web mà không yêu cầu kỹ năng kỹ thuật nâng cao
- Fotoware là một phần mềm quản lý tài liệu và hình ảnh
- SAP Accounting Module là một phần mềm quản lý tài chính toàn diện được thiết kế để giúp doanh nghiệp quản lý các hoạt động tài chính
- Hệ thống Lean CMS cung cấp cho nhà bán lẻ những công cụ họ cần để xuất bản nội dung lên web mà không yêu cầu kỹ năng kỹ thuật nâng cao.
Phần triển khai CQRS (trong khung màu đỏ)
Sử dụng Aurora MySQL Serverless làm mô hình đọc để xử lý và định hướng tất cả các truy vấn đọc, giúp truy xuất trạng thái hiện tại của hệ thống.
Lệnh sẽ tạo ra các sự kiện riêng lẻ cho mỗi hình ảnh được cập nhật (hoặc tạo hóa đơn).
Sử dụng DynamoDB làm kho lưu trữ sự kiện để cho phép tìm nguồn cung ứng sự kiện và xử lý tất cả các yêu cầu ghi.
Đối với việc cập nhật hình ảnh, các cập nhật này sẽ được đẩy lên hàng đợi Simple Queue Service của AWS để cập nhật mô hình lưu trữ với siêu dữ liệu hình ảnh mới nhất được tạo Sau đó sẽ triển khai thêm nhiều sự kiện cập nhật mô hình đọc với dữ liệu được cập nhật
Đối với việc tạo hóa đơn, các cập nhật sẽ được đẩy lên hàng đợi Simple Queue Service để ghi sự kiện với dữ liệu hóa đơn được tạo và sau đó sẽ triển khai thêm nhiều chế độ xem với các thành phần được tạo
Các API dùng để gửi các lệnh và xem trạng thái của một công việc hàng loạt nhằm đảm bảo khả năng quan sát được trạng thái hiện tại của công việc trong hệ thống.
Sử dụng Event Sourcing (Tìm nguồn cung cấp sự kiện):
Lưu trữ một sự kiện riêng lẻ trong DynamoDB.
Cho phép phát lại sự kiện để thực hiện các thao tác.
Giảm số lần nhấp chuột cần thiết để cập nhật siêu dữ liệu của hàng nghìn hình ảnh.
Cho phép người dùng xếp hàng cập nhật nhiều hình ảnh cùng lúc.
Cho phép người dùng tạo nhiều lời khuyên tín dụng cùng lúc.
Cải thiện hiệu suất ứng dụng.
Nâng cao trải nghiệm người dùng.
Best practices
Khi sử dụng CQRS ta có thể áp dụng các practices sau để đạt được hiệu quả tốt.
1 Xác định rõ ràng yêu cầu truy vấn và cập nhật dữ liệu:
- Phân tích cách thức người dùng truy cập và cập nhật dữ liệu trong hệ thống
- Sử dụng các API riêng biệt cho truy vấn và lệnh như RESTful API cho truy vấn; GraphQL cho cập nhật.
3 Sử dụng hàng đợi tin nhắn để xử lý lệnh:
- Sử dụng hàng đợi tin nhắn như RabbitMQ, Amazon SQS hoặc Kafka để lưu trữ các lệnh.
- Khi người dùng thực hiện hành động, tạo ra một lệnh và gửi đến hàng đợi tin nhắn.
- Các dịch vụ xử lý riêng biệt sẽ lắng nghe hàng đợi tin nhắn và xử lý các lệnh tương ứng.
4 Sử dụng Event Sourcing (Tìm nguồn cung cấp sự kiện):
- Lưu trữ lịch sử thay đổi của các thực thể dưới dạng chuỗi các sự kiện bằng Amazon Kinesis, Apache Pulsar.
- Cho phép truy vấn trạng thái của một thực thể tại bất kỳ thời điểm nào trong quá khứ.
- Hỗ trợ phục hồi dữ liệu và tạo báo cáo chi tiết bằng Apache Cassandra,
5 Thiết kế hệ thống cho khả năng mở rộng:
- Sử dụng các dịch vụ vi mô (microservices) để chia nhỏ hệ thống thành các thành phần độc lập như Docker để container hóa, Kubernetes cho quản lý container
- Sử dụng cơ sở hạ tầng đám mây như AWS, Google Cloud Platform, Azure để dễ dàng mở rộng hệ thống theo nhu cầu.
6 Sử dụng công cụ giám sát để theo dõi hệ thống:
- Theo dõi hiệu suất của hệ thống, bao gồm hiệu suất truy cập và cập nhật dữ liệu bằng Prometheus, Datadog.
- Phát hiện và khắc phục sự cố kịp thời dùng Sentry, New Relic.
7 Thử nghiệm kỹ lưỡng hệ thống:
- Viết các bài kiểm tra đơn vị bằng JUnit (Java) hoặc pytest (Python) và kiểm tra tích hợp để đảm bảo hệ thống hoạt động chính xác.
- Thử nghiệm hệ thống với tải trọng cao bằng JMeter, LoadRunner để đảm bảo hệ thống có thể xử lý được lượng truy cập lớn
