ITLC - Hanoi - CQRS - ES - 22-10 - 2015

CQRS – COMMAND AND QUERY
RESPONSIBILITY SEGREGATION
ITLC HANOI
MONTHLY PUBLIC MEETUP

“If you can’t split it, you can’t scale it”
(Randy Shoup, Distinguished Architect, eBay)
ITLC Hanoi (https://facebook.com/itlchanoi) - Le Minh Nghia

CÁC NỘI DUNG CHÍNH
1. Các yêu cầu về việc xây dựng hệ thống lớn
2. Mô hình CQRS và các khái niệm căn bản
3. Một số phương pháp cơ bản để phân tích thiết kế
phần mềm
4. Cách thức hoạt động của mô hình CQRS
5. Sử dụng pattern Event Sourcing với CQRS
6. Các vấn đề khó khăn khi áp dụng mô hình
CQRS-ES và hướng giải pháp giải quyết
7. Các đòi hỏi về hiệu năng và các hướng giải pháp
giải quyết

THÁCH THỨC KHI XÂY DỰNG
 Khả năng mở rộng của hệ thống.
 Tính ổn định
 Tính nhất quán của dữ liệu
 Tranh chấp tài nguyên
 Đòi hỏi hiệu năng cao

KHẢ NĂNG MỞ RỘNG

KHẢ NĂNG MỞ RỘNG
 Chiều X horizontal duplication: mở rộng bằng cách
nhân bản. Ví dụ thực hiện cân bằng tải nhiều web
application
 Mở rộng theo chiều Y Functional Decomposition:
mở rộng bằng cách chia nhỏ thành nhiều chức
năng. Ví dụ quản lý sản phẩm, quản lý đơn hàng…
Trong quản lý đơn hàng chia tiếp thành thanh toán,
ghi đơn hàng, tìm kiếm đơn hàng…
 Mở rộng theo chiều Z chia nhỏ dữ liệu: sharding
data, partion data…

CÁC KHÓ KHĂN
 Sử dụng cùng một model cho tất cả các nghiệp vụ
 Logic phức tạp
 Các nghiệp vụ ghi dữ liệu quan trọng và chặt chẽ
 Các nghiệp vụ đọc dữ liệu thì linh hoạt

MÔ HÌNH CRUD

MÔ HÌNH CRUD
 Có ba tầng chính: Data Layer, Business Layer,
Presentation
 DAL query giả lại DTO để Presentation hiển thị
 Presentation thay đổi DTO qua DAL lưu vào vào
database
 Model dùng chung cả việc đọc và ghi dữ liệu

MÔ HÌNH CRUD
 Ưu điểm: nhanh, không cầu kì thiết kế
 Nhược điểm:
- Model phức tạp do dùng chung cho cả đọc và ghi
dữ liệu
- Tăng tranh chấp dữ liệu giữa đọc và ghi dữ liệu
- Không scale được độc lập yêu cầu hiệu năng cho
cả phần đọc và ghi

MÔ HÌNH CQRS
 Người đưa ra: Greg Young – 2006
 CQRS – Command and Query Responsibility
Segregation
 Mục tiêu phân chia các luồng ghi và đọc dữ liệu ra
riêng biệt
 Scale độc lập các thành phần đọc và ghi dữ liệu

MÔ HÌNH

CÁC THÀNH PHẦN CHÍNH
 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 lệnh 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
 Query Façade: mô hình query dữ liệu

CQRS

MÔ HÌNH HOẠT ĐỘNG
 Phát sinh command. Vd: đặt hàng – placeorder
 Command Bus gửi command
 Command Handler nhận command, thực thi xử lý
nghiệp vụ tại domain model
 Phát sinh các Event báo kết thúc quá trình xử lý.
 Event Bus publish các event đi

XÉT VÍ DỤ CỤ THỂ
 Xây dựng ứng dụng thương mại điện tử đơn giản:
cho phép người dùng xem và mua hàng
 Sau đặt hàng xong người dùng có thể thanh toán
online
 Sau khi thanh toán online xong, đơn hàng được
xác nhận thì gửi tin nhắn và email xác nhận cho
người dùng

PHÂN TÍCH VÀ THIẾT KẾ
 Xác định các phạm vi bài toán nghiệp vụ:
+ Quản lý sản phẩm
+ Đơn hàng
+ Thanh toán
+ Thông báo

CONTEXT BOUNDARY
Product
Order
Payment
Notification

XÂY DỰNG UBIQUITOUS LANGUAGE
 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ở để thiết kế các 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ụ

XÂY DỰNG UBIQUITOUS LANGUAGE
 Người dùng liệt kê sản phẩm
 Chọn lựa sản phẩm và số lượng mua
 Đặt hà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

XÁC ĐỊNH CÁC NOUN VÀ VERB
 Phân tích ubiquitous language để xác định các
object và behaviour
 Xác định mối quan hệ giữa các object
 Xây dựng model dựa trên các noun và verb

XÁC ĐỊNH CÁC VERB VÀ NOUN
Noun Verb
Product Listing Product
Order Place Order, Confirm Order, Reject
Order
Payment Accept, Reject
Email Send
SMS Send

MÔ HÌNH THIẾT KẾ CHO TỪNG BOUNDED
CONTEXT
 Không dùng chung một mô hình thiết kế cho tất cả
 Mỗi context có mô hình xử lý và schema riêng
 Các bounded context kết nối thông qua message

PRODUCT, ORDER, PAYMENT, NOTIFICATION
Product Order Payment Notification
Application Service
WriteSide
ReadSide
DDD
Core Domain
CQRS-ES
Core Domain
CQRS
Core Domain
CRUD
None Core Domain

PHÂN TÍCH PROCESS ORDER VÀ PAYMENT
Ubiquitous Language:
 Người dùng gửi lệnh đặt hàng – Place Order
 Hệ thống tạo đơn hàng – Create Order
 Chờ thanh toán để xác nhận – Wait Payment
Accepted
 Nhận được xác thức thanh toán – Payment
Accepted
 Xác nhận đơn hàng thành công – Confirm Order
 Gửi email cho người dùng – Send Email
 Gửi SMS cho người dùng – Send SMS

AGGREGATE
 Có định danh duy nhất trong hệ thống
 Được lưu trữ trong hệ thống
 Chứa các business logic
 Có dữ liệu và hành vi

ORDER AGGREGATE

PHÂN TÍCH COMMAND VÀ EVENT
Command Event
PlaceOrder
CreateOrder OrderCreated
SubmitOrder OrderSubmited
SendSMS
SendEmail
PaymentAccepted

KẾT HỢP CÁC BOUNDED CONTEXT
Order
Process
Manager
PlaceOrder
OrderCreated
ConfirmOrder
OrderConfirm
PaymentAccpetd
SendSMS
SendEmail

PROCESS MANAGER PATTERN
 Giới thiệu lần đầu 2004 trong cuốn:
Enterprise Integration Patterns: Designing, Building,
and Deploying Messaging Solutions
(Gregor Hohpe - Bobby Woolf )

ORDER PROCESS MANAGER
Order
OrderProcesManager
Payments Notifications
Command
Event
1. PlaceOrder
2. CreateOrder 3. OrderCreated
4. PaymentAccepted
5. ConfirmOrder
7. SendEmail
6. SendSMS

PLACEORDER COMMAND
Command Bus
Web Application
1. PlaceOrder Command
Process
Manager
CommandHandler
Receive Command

CHANGE STATE, SAVE AND SEND COMMAND
 Order Process Manager nhận PlaceOrder
Command
 Change to CreateOrder State
 Save state and Send CreateOrder Command

ORDERPROCESS MANAGER
OrderProcessManager
Database
Command Bus
Save To DB Send CreateOrder to Command Bus

HANDLE CREATEORDER COMMAND
Command Bus
ProcessManage
r
2. CreateOrder Command
Order Aggregate
CommandHandler
Receive Command

ORDERCOMMAND HANDLER
 Receive CreateOrder Command
 Get Order Aggregate
 Process Create Order Logic
 Save Order and Publish OrderCreated Event

ORDERCOMMAND HANDLER
Order
Database
Event Bus
Save To DB Send OrderCreated Event to Event Bus

HANDLE ORDERCREATED EVENT
Event Bus
ProcessManager Order Aggregate
OrderCreated

HANDLE ORDERCREATED EVENT
 Change to WaitPaymentAccepted State
 Save and Wait PaymentAccepted Event

HANDLE PAYMENTACCEPTED EVENT
 Change to Confirmed State
 Save state and send commands:
- Send ConfirmCommand to Order
- Send SendEmail to Notification Domain
- Send SendSMS to Notification Domain

HANDLE PAYMENTACCEPTED EVENT
OrderProcessManager
Event Bus Command Bus
Payment Order
PaymentAccept
ed
ConfirmOrder
SendEmail
SendSMS
Email
ConfirmOrder
SendEmail SendSMS
SMS

ORDER AGGREGATE
HANDLE CONFIRMORDER COMMAND
 Update to Confirmed State
 Save and Publish OrderConfirmed Event

READ SIDE
HANDLE ORDERCONFIRMED EVENT
 Receive OrderConfirmed Event
 Update Read Database

READ SIDE
HANDLE ORDERCONFIRMED EVENT
Order
Read DBEvent Bus
Publish OrderCreated
OrderReadDBHandler
Update DB
Query Data
Thin Data Layer
Read SideWrite Side
Receive Event

CÁC ƯU ĐIỂM CỦA CQRS
 Các logic thực thi rõ ràng
 Phân tách thành các quá trình xử lý độc lập
 Dễ dàng scale độc lập từng thành phần
 Sử dụng tài nguyên tính toán hiệu quả hơn

NHẬN XÉT
 Tất cả các thay đổi của object đều có event tương
ứng
 Quá trình cập nhật read side tương ứng với các sự
kiện phát ra
 Có thể sử dụng event để tái tạo lịch sử object.

EVENT SOURCING PATTERN

EVENT SOURCING PATTERN
 Lưu trữ trạng thái của object là danh sách sự kiện
thay đổi trạng thái của object
 Lưu stream event của object
 Load event stream để tái tạo tất cả trạng thái của
object
 Replay lại các event để xác định lịch sử thay đổi

ÁP DỤNG EVENT SOURCING CHO CQRS
 Tất cả các tác động làm thay đổi trạng thái đơn
hàng được coi là chuỗi các sự kiện
 Thay đổi cấu trúc class nhưng không thay thế cấu
trúc model
 Thay đổi data context để lưu trữ event
 Giữ nguyên toàn bộ cấu trúc của phần mềm

THAY ĐỔI CẤU TRÚC CLASS
 Mỗi hành vi của object sẽ phát sinh một event
tương ứng
 Mỗi event sẽ được handle bởi một hàm update
trạng thái của object
 Khi khởi tạo object load lại toàn bộ event và thực
thi

base.Handles<OrderPlaced>(this.OnOrderConfirmed);
…
Public void ConfirmOrder(ConfirmOrder cmd)
{
this.Update(new OrderConfirmed());
}
….
private void OnOrderPlaced(OrderConfirmed e)
{
//….
}

THAY ĐỔI DATA LAYER/DATA CONTEXT

CHUYỂN ĐỔI CQRS-ES
Application Application
Order For CQRS Order For ES
OrderRepository
For CQRS
OrderRepository
For ES
DDD/CQRS:
Business Logic không thay đổi
Application Logic không thay đổi
Chỉ thay đổi cấu trúc lưu trữ
CRUD:
Rất khó khăn để làm tương tự

ƯU ĐIỂM CỦA EVENT SOURCING PATTERN
 Lưu trữ được lịch sử thay đổi của một đối tượng
 Cho phép dễ dàng playback lại các sự kiện để xác
định các vấn đề trong hệ thống

DEMO
 Các tính năng cũ vẫn giữ nguyên
 Có thể theo dõi được lịch sử đơn hàng
 Không cần thêm phần log history nữa

CÁC VẤN ĐỀ KHÓ KHĂN
 Hệ thống monitor
 Việc gửi và nhận message ổn định
 Chống trùng lặp việc xử lý message
 Eventually consistency giữa read side và write side

GỬI MESSAGE ỔN ĐỊNH
 Không có transaction giữa database và message
queue
Giải pháp:
 Lưu state và các message chưa gửi đi trong một
transation
 Gửi message và xóa các message
 Thiết lập chế độ chống trùng message trong
message queue

GỬI MESSAGE ỔN ĐỊNH
Undispatched
Message
States
Message Queue
Transaction
Save Send
Delete Undispatched Messages
Lưu ý: cần phải chống trùng lặp message

IDEMPOTEMCY FILTERING
 Lưu giữ message id nhận được
 Kiểm tra trạng thái xử lý message khi nhận được
message
 Thiết lập chế độ chống gửi trùng message nếu
message queue hỗ trợ.
 Thiết kế logic để việc xử lý không bị ảnh hưởng bởi
trung lặp message

EVENTUALLY CONSISTENCY GIỮA WRITE SIDE
VÀ READ SIDE
 Dữ liệu giữa read side và write side bị lệch
Giải pháp:
 Đánh version tăng dần cho dữ liệu
 Kiểm tra version hiện tại khi submit:
submited version = current version
 Đánh version bằng timespan
 Phải có giải pháp trong trường hợp bắt buộc dữ
liệu giữa write side và read side phải strong
consistency

VẤN ĐỀ CONCURRECY
 Hai tác nhân cùng thay đổi trạng thái của hệ thống
 Sử dụng cơ chế optimistic lock bằng timestamp

CÁC ĐIỂM THẮT CỔ CHAI
 Giới hạn throughput của đường bus
 Giới hạn của database

CÁC GIẢI PHÁP
 Tăng số làn bus – partition bus
 Sharding database – horizontal scaling
 Non Blocking IO Programming
 Using Priority Queue pattern

GIẢI QUYẾT VẤN ĐỀ THẮT CỔ TRAI
Message Bus
Message Bus
Message Bus
Message Bus
Worker
Worker
Worker
….
Shardlet
Shardlet
Shardlet
Sharding dataMultiple Worker
Partition
Message
Queue

UBER ARCHITECTURE

THANK YOU
 Lê Minh Nghĩa
 Facebook: https://www.facebook.com/NghiaLeMinh
 Email: nghia.fit@gmail.com
 Phone: 0936 073 986
Shared to be Share!

Q&A

ITLC - Hanoi - CQRS - ES - 22-10 - 2015

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (19)

ITLC - Hanoi - CQRS - ES - 22-10 - 2015