sinka vietnam @dinhthelam · lợi ích của event sourcing - giải quyết được vấn đề...

Sinka Vietnam

@dinhthelam

sinka.vn

Kiến trúc Microservices phân tách sự phức tạp của hệ thống bằng cách module hóa

sinka.vn

Microservices = Business Capability

sinka.vn

Catalog Service

Review Service

Order Service

… Service

Catalog Database

Review Database

Order Database

… Database

API Gateway

Store Front UI

Mobile Device

Browser HTML

REST

REST

Simple Microservices Architecture

sinka.vn

Contents

01 Domain Model trong Microservices Vấn đề với Domain Model & ACID transactions

02 Domain Driven Design Sự quan trọng của Aggregates trong môi trường phân tán

03 Consistency giữa các Microservices Làm sao để duy trì sự đồng bộ

04 Sử dụng Event-sourcing với Aggregates The best solution nhưng có phải lựa chọn tốt nhất

05 Simplified ES Đơn giản hóa với eShopOnContainer

sinka.vn

Product service

Customer service Order service

Order …

Domain Model = Liên kết chặt giữa các lớp

Address Street City …

OrderItem Quantity …

Product Name Price …

Customer CreditLimit …

?

?

sinka.vn

Phụ thuộc vào ACID transaction để đảm bảo đồng bộ

BEGIN TRANSACTION … SELECT ORDER_TOTAL FROM ORDERS WHERE CUSTOMER_ID = ? … SELECT CREDIT_LIMIT FROM CUSTOMERS WHERE CUSTOMER_ID = ? … INSERT INTO ORDERS … COMMIT TRANSACTION

[A]tomicity [C]onsistency [I]solation [D]urability

Order Service

Customer Service

…và phụ thuộc vào 2PC

sinka.vn

- Đảm bảo tính đồng bộ

2PC không phải là một lựa chọn hay

- NoSQL hiện đại không support - CAP theorem => 2PC ảnh hưởng tới Availability

Nhưng

sinka.vn

Contents






sinka.vn

Domain Driven Design chính là câu trả lời

- Entity

- Value object

- Services

- Repositories

- Aggregates

Đã áp dụng

Ít được chú ý

sinka.vn

Các tầng trong DDD

Phối hợp các xử lý. Lưu ý là không chứa logic nghiệp vụ ở đây

Chứa các mô hình biểu diễn nghiệp vụ của hệ thống. Thể hiện logic của nghiệp vụ. Đây là tâng quan trong nhât

Lớp này đóng vai trò như một thư viện hỗ trợ cho tât cả các lớp còn lại.

sinka.vn

Ubiquitous Language

sinka.vn

Bounded Context

sinka.vn

Layer càng cao thì càng được sử dụng nhiều

Layer càng thấp thì độ tái sử dụng càng cao

Tránh thiết kế độ phức tạp ngang nhau giữa các layer

Tốc độ phát triển ngày một nhanh, vì tích lũy được logic trước đó

Phải luôn kiểm soát, refactor mã nguồn

Phải ám ảnh triết lí: Don’t Repeat Yourself

sinka.vn

Order CustomerId …

Về Aggregates


OrderItem Quantity ProductId ProductName ProductPrice …

- Một nhóm các đối tượng có thể được coi như 1 đơn vị - Trong mỗi nhóm sẽ có một root và tập hợp các entities

và value objects - Thường thì các đối tượng nghiệp vụ sẽ là một

Aggregates

sinka.vn


Aggregate: rule #1



- Liên kết tới các Aggregates khác qua Id (Primary key)

Foreign keys trong Domain Model!?

sinka.vn

Product service


Order …

Các Aggregates sẽ được liên kết lỏng tới nhau


OrderItem Quantity …

Product Name Price …


sinka.vn


Aggregate: rule #2



Transaction =

Xử lí một hành động lên một aggregates

sinka.vn

Độ lớn của Aggregates

- Nếu một update mà bắt buộc phải là cùng nhau thì bắt buộc phải xử lí bởi một Aggregates

Customer

Order Product

Customer

Order Product

Consistency Scalability

Customer

Order Product

sinka.vn

Design Infrastructure persistence layer

• Sử dụng Repository pattern • Mỗi Repository tương ứng với 1 Aggregate Root

sinka.vn

Contents






sinka.vn


Làm sao để đảm bảo consistency giữa các microservices

Order Customer

placeOrder()

updateCreditLimit()

Event-driven architecture

sinka.vn

Public void CheckoutCart(Order order) {

SaveOrder(order);

SendEmailNotification(order);

ShipToNearestWarehouse(order);

ScheduleShipToCustomer(order);

ExportToERP(order);

}

Ưu điểm:

Dễ viết, dễ hiểu với tư duy truyền thống

Nhược điểm:

Khi nghiệp vụ phát triển code sẽ trở nên vướng mắc vào

nhau và tốn thời gian maintain lẫn testing

Mỗi khi có nghiệp vụ mới sẽ cẩn chỉnh sửa class đã có. Vi

phạm SOLID

Request Driven Architecture

sinka.vn

Ưu điểm: Các component loosely-coupling và không phụ thuộc

vào nhau

Immutable states

Các sự kiện được xử lý async nên tăng perfomance

Phù hợp với DDD và CQRS

Tránh dùng khi:

Simple CRUD

Các xử lý cần tính tuần tự

Event Drivent Architecture

sinka.vn

Domain Event là:

Một sự kiện liên quan đến Domain đã xảy ra trong quá khứ

Bản thân Domain Event chỉ là DTO chứa dữ liệu gửi đi

Mỗi hành động xảy ra với Domain Event sẽ được xử lí bởi một hoặc

nhiều Domain Event Handler

Thích hợp với tư duy của DDD: 1 command chỉ nên ảnh hưởng tới 1

AggregateRoot

Domain Event cũng giống như database transaction,

hoặc là toàn bộ Event thành công hoặc không Event nào

(single atomic transaction)

Domain Event

sinka.vn

Sử dụng event-driven và eventually consistent

Order Service

Customer Service

placeOrder()

OrderCreated

Order State Total …

create()


reserveCredit()

CreditReserved

CreditCheckFailed

approved/reject()

- ACID transaction chỉ cần rollback

- Developer phải tự viết application logic để “rollback”

- Cần sự thiết kế cẩn thận!

sinka.vn

Contents






sinka.vn

Event Sourcing

- Với mỗi đối tượng Domain Model (VD: DDD aggregate): - Xác định các sự kiện làm thay đổi trạng thái - Định nghĩa các đối tượng Event

- VD như các event cho Order: OrderCreated, OrderCancelled, OrderApproved, OrderRejected, OrderShipped

- Chỉ lưu trữ các events chứ không phải trạng thái của đối tượng

Order CustomerId State …

Entity Id Entity Type Event Id Event Type Event Data

101 Order 901 OrderCreated …

101 Order 902 OrderApproved …

- Replay lại các event để lấy được trạng thái của đối tượng

sinka.vn

Hoạt động cụ thể của Event Sourcing

sinka.vn

Lợi ích của Event Sourcing

- Giải quyết được vấn đề data consistency trong Microservices mà không cần đến 2PC

- Có một hệ thống event publishing vững chắc - Loại bỏ được O/R mapping - Xem được lịch sử trạng thái thay đổi

- Bản thân là 1 Audit log ổn định - Có thể queries theo thời gian

- Xem được lịch sử => dễ dàng phân tích các yêu cầu trong tương lai

sinka.vn

Nhược điểm của Event Sourcing

- Cần viết lại toàn bộ hệ thống - Phong cách code kì lạ và khó làm quen - Cần phát hiện và bỏ qua các event duplicate - Query event store khó khăn - Một số query như: lấy tất cả các tài khoản với creditLimit > x rất khó làm để thực

hiện - Event store chỉ hỗ trợ các entities có Id

- Phải sử dụng với Command Query Responsibility Segregation (CQRS) để xử lí queries => application phải tự xử lí eventually consistency

sinka.vn

sinka.vn

Bước 1: tạo domain event Bước 2: tạo command gây ra event đấy

Bước 2b: thêm actor thực hiện command

Bước 3: thêm aggregate tương ứng https://en.wikipedia.org/wiki/Event_storming

https://en.wikipedia.org/wiki/Event_storming

sinka.vn

Contents






sinka.vn

CQRS • Queries: những truy vân trả về kết quả và không thay đổi trạng thái

của hệ thống, không gây ra side effects. • Commands: những hành động thay đổi trạng thái của hệ thống

sinka.vn

CQRS mapping với Usecase

• Command & Query đều ứng với 1 Usecase cụ thể của hệ thống

• API của tâng API Gateway để thực hiện các logic Usecase cụ thể

• API của các Microservice cân là fine-grained. Đáp ứng được phân lớn các yêu câu logic riêng của Microservice đây

sinka.vn

Integrated Event là:

Bản chất giống như Domain Event nhưng sự kiện nhằm

thông báo cho Microservice khác

Integrated Event bắt buộc xử lí asynchronous giữa các

Microservice (eventual consistency)

Integrated Event là Pub/Sub pattern. Khác với Observer

pattern ở chỗ Publisher và Subsriber không biết lẫn nhau

Sử dụng RabbitMQ & Polly:

Đang sử dụng Polly để quy định rule mỗi khi có lỗi

Integrated Event

sinka.vn

sinka.vn

Event persist trong eShopOnContainer

sinka.vn

Phiên bản cải tiến được recommend

sinka vietnam @dinhthelam · lợi ích của event sourcing - giải quyết được vấn đề...

Documents