Chia sẻ kinh nghiệm:Thiết kế hệ thống, Tối ưu, Domain Driven Design, CQRS,Event Sourcing
Lê Minh Nghĩa,Toong, 8 Tràng Thi, Hà Nội
2015/09/09
Giới thiệu• Lê Minh Nghĩa• Phone: 0936 073 986• Email: [email protected]• Facebook: http://www.facebook.com/nghialeminh• Quá khứ: Doko.VN – Cty Mimas
Muốn giao lưu chia sẻ về• Enterprise Software Architecture• Domain Driven Design• CQRSCommand and Query Responsibility
Segregation (CQRS)• Service Oritented Architecture (SOA)• Event Driven Architecture• High Performance Database• Data Mining• Cost Optimization
Các công việc đã, đang phụ trách
• Tối ưu hóa hệ thống• Xây dựng giải pháp xử lý distributed transaction• Triển khai Enterprise Service Bus để tích hợp hệ thống• Triển khai kiến trúc hệ thống theo mô hình CQRS–ES.• Xây dựng process manager cho việc xử lý đơn hàng• Triển khai xử lý đơn hàng bất đồng bộ
Enterprise Software và các phương pháp
phân tích thiết kế phần mềm
Enterprise Software là gì• Là các phần mềm phục vụ quản lý các doanh nghiệp
như: công ty, cửa hàng, siêu thị, ngân hàng…• Không bao gồm các phần mềm về viễn thông, game,
video…• Có rằng buộc dữ liệu chặt chẽ• Thường có luồng nghiệp vụ phức tạp• Không bị gắn chắt vào phần cứng
Demo đơn giản• Xây dựng một site hiển thị danh sách sản phẩm• Cho phép đặt đơn hàng• Đơn hàng có thể xác nhận hoặc hủy• Môt đơn hàng có tên sản phẩm và số lượng
“Hello” Enterprise Software• CRUD phương pháp đầu tiên để làm• Phân tích yêu cầu• Thiết kế CSDL• Cài đặt
Nhìn lại, có gì không ổn nhỉ• Gắn chắt với thiết kế CSDL• Không gần với đời sống• Dữ liệu không đóng gói• Khả năng kế thừa hạn chế• Khả năng bảo trì hạn chế
Chúng ta nghĩ gì và CRUD nói gì
• Chúng ta nói tới các đối tượng, các thực thể• Phần mềm chúng ta nói tới các lệnh, các chức năng• Phần mềm chúng ta không mô hình hóa cái chúng ta
hình dung
Domain Driven Design• Chúng ta hình dung ra sao phần mềm cần phải xây dựng
như vậy• Cùng một model• Cùng một bộ ngôn ngữ• Dữ liệu và hành vi phải đi liền với nhau
Vấn đề khi xây dựng Enterprise Software
Vấn đề khi xây dựng Enterprise Software
Ubiquitous Language
Domain là gì• An area of knowledge or activity
Domain Model
Bounded Context
Bounded Context
Context Map
Domain Model & Bounded Context
Aggregate – Consistent Boundary
Phân tách tầng lưu trữ ra riêng rẽ
Cài đặt ra sao?• Đóng gói cao nhất• Không public set• Quên persistent, thiết kế model trước• Thiết kế data layer tách biệt domain• Thiết kế domain service• Thiết kế application service
Vậy lợi ích là gì?
• Hiệu quả với các Bussiness phức tạp• Đáp ứng với sự thay đổi liên tục của Bussiness Logic• Các bên (dev, architect, domain expert) làm việc với
nhau hiệu quả• Chi phí phát triển sau khi đã có core domain giảm
Còn có thể làm tốt hơn được không?
• Đọc dữ liệu nhanh hơn• Đọc dữ liệu đơn giản hơn• Ít rằng buộc hơn• Sử dụng các schema khác nhau• Đồng thời ghi dữ liệu vẫn phải đúng nghiệp vụ
CQRS• Viết tắt: Command And Query Responsibility Segregation• Phân tách hai luồng riêng biệt: ghi dữ liệu và đọc dữ liệu• Sử dụng hai schema khác nhau
CQRS hình thù thế nào?
Make it Works• Command: một lệnh làm hệ thống thay đổi dữ liệu• Event: một sự thay đổi đã xảy ra• Command Bus: đường truyền các lệnh• Event Bus: đường truyền các event
Có cái gì đó xuyên suốt? – Event!
• Mỗi sự thay đổi đều phát sinh event• Trạng thái của một đối tượng là một chuỗi các sự kiện xảy ra• Chạy lại event để tái tạo đối tượng
Event Sourcing• Lưu trữ nguồn event của một đối tượng• Xây dựng event store lưu trữ toàn bộ event của một
object• Khi lưu một event đồng thời publish một event
Lưu trữ thế nào – Event Store• Xây dựng event store• Một bảng dữ liệu dùng để append event
CQRS - ES• CQRS kết hợp với ES dễ dàng• Mỗi command sẽ phát sinh một hoặc nhiều event• Các event được đánh version• Version của một object là version của event
Process Manager Pattern• Mô tả luồng nghiệp vụ là luồng các message• Cần một manager để điều hướng các luồng message
Event as the Core
State Machine Pattern• Lưu trữ state của hệ thống• Xây dựng luồng chuyển trạng thái• Tách phần quản lý trạng thái ra khỏi aggregate
State Matrix• Mô tả việc chuyển trạng thái dưới dạng ma trận• Dễ dàng quản lý• Logic rõ ràng
State Matrix
Thiết kế hệ thống phân tán có hiệu năng cao
• Tránh tranh chấp dữ liệu• Tính toán trước• Sử dụng tài nguyên tính toán hợp lý
Nguyên lý CAP
Một case đơn giản mà không đơn giản
• Xây dựng web service update CSDL đảm bảo strong consistency data
Distributed Transaction• Giao dịch với nhiều nguồn dữ liệu• Cần phải đảm bảo consistency• Giải pháp là gì
Two Phase CommitThưc hiện hai phase:- Write- Commit
Nếu lỗi: Undo tất cả
Đòi hỏi: lock tất cả các resources
Eventually Consistency
• Thay thế consistency bằng eventually consistency• Eventually consistency khắp mọi nơi• Không thể eventually tất cả nhưng hãy tối đa có thể
Hạn chế của kiến trúc hướng dịch vụ theo mô hình request - response
SOA theo mô hình Event Driven
Bất đồng bộ và bài toán tối ưu về hiệu năng và kinh tế• Bất đồng bộ tối đa có thể• Không cần scale tất cả các node• Tập trung tài nguyên tính toán cho node đòi hỏi hiệu
năng cao
Sử dụng Message Bus để phân tách hệ thống
Các vấn đề cần chú ý
• Khi nào CQRS phù hợp?• Hệ thống collobrative sysytem• Phải có nền tảng message ổn định• Cần phải giải quyết transation giữa message bus và database• Xác định tính chất Idempotent• Chú ý về thứ tự event• Xây dựng event store để không bị thắt cổ trai
Các giải pháp
• Phân tích luồng nghiệp vụ thật cẩn thận• Chọn lựa nền tảng message bus có khả năng persistent và
scale out tốt cũng như có khả năng điều hướng message tốt• Tránh tình trạng bị trùng lặp message hoặc có cơ chế phòng trừ• Xây dựng giải pháp partition và sharding data cho event store
Kết luận“Không thể scale được nếu không chia tách được”
Thank you.Q&A
Top Related