itlc - hanoi - cqrs - es - 22-10 - 2015

CQRS – COMMAND AND QUERY RESPONSIBILITY SEGREGATION

ITLC HANOI MONTHLY PUBLIC MEETUP

ITLC Hanoi (https://facebook.com/itlchanoi) - Le Minh Nghia

“If you can’t split it, you can’t scale it”(Randy Shoup, Distinguished Architect, eBay)


CÁC NỘI DUNG CHÍNH1. Các yêu cầu về việc xây dựng hệ thống lớn2. Mô hình CQRS và các khái niệm căn bản3. Một số phương pháp cơ bản để phân tích

thiết kế phần mềm4. Cách thức hoạt động của mô hình CQRS5. Sử dụng pattern Event Sourcing với CQRS6. 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ết7. 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À NOUNNoun Verb

Product Listing ProductOrder Place Order, Confirm Order,

Reject OrderPayment Accept, RejectEmail SendSMS 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

Writ

e Si

deRe

ad

Side

DDDCore Domain

CQRS-ESCore Domain

CQRSCore Domain

CRUDNone Core Domain


PHÂN TÍCH PROCESS ORDER VÀ PAYMENTUbiquitous 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À EVENTCommand Event

PlaceOrderCreateOrder OrderCreatedSubmitOrder OrderSubmitedSendSMSSendEmail

PaymentAccepted


KẾT HỢP CÁC BOUNDED CONTEXTOrder

Payment

Notification

Process Manage

r

PlaceOrderOrderCreatedConfirmOrderOrderConfirm

PaymentAccpetd

SendSMSSendEmail


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 MANAGEROrder

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

ProcessManager

2. CreateOrder Command

Order Aggregate

CommandHandler

Receive Command


ORDERCOMMAND HANDLERHANDLE CREATEORDER COMMAND Receive CreateOrder Command Get Order Aggregate Process Create Order Logic Save Order and Publish OrderCreated Event


ORDERCOMMAND HANDLERHANDLE CREATEORDER COMMAND

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

PaymentAccepted

ConfirmOrderSendEmailSendSMS

Email

ConfirmOrder

SendEmail SendSMS

SMS


ORDER AGGREGATEHANDLE CONFIRMORDER COMMAND Update to Confirmed State Save and Publish OrderConfirmed Event


READ SIDEHANDLE ORDERCONFIRMED EVENT Receive OrderConfirmed Event Update Read Database


READ SIDEHANDLE 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


THAY ĐỔI CẤU TRÚC CLASS


THAY ĐỔI CẤU TRÚC CLASSbase.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

OrderRepositoryFor CQRS

OrderRepositoryFor ES

DDD/CQRS:Business Logic không thay đổiApplication Logic không thay đổiChỉ 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 queueGiả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ệchGiả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 BusMessage BusMessage BusMessage 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: [email protected] Phone: 0936 073 986

Shared to be Share!

https://www.facebook.com/NghiaLeMinh



mailto:[email protected]


Q&A

itlc - hanoi - cqrs - es - 22-10 - 2015

Software