Đồ án 2 tìm hiểu event sourcing

TP HỒ CHÍ MINH, THÁNG 12 NĂM 2022 ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN KHOA CÔNG NGHỆ PHẦN MỀM ĐỒ ÁN 2 TÌM HIỂU EVENT SOURCING GIẢNG VIÊN HƯỚNG DẪN ThS NGUYỄN CÔNG HOAN S[.]

TP HỒ CHÍ MINH, THÁNG 12 NĂM 2022

ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

KHOA CÔNG NGHỆ PHẦN MỀM

ĐỒ ÁN 2 TÌM HIỂU EVENT-SOURCING

GIẢNG VIÊN HƯỚNG DẪN ThS NGUYỄN CÔNG HOAN

Sinh viên thực hiện:

Nguyễn Đức Phúc - 17520906

LỜI CẢM ƠN

Em xin gửi lời cảm ơn chân thành và sự tri ân đến thầy Nguyễn Công Hoan đã hướng dẫn, tạo điều kiện cho em hoàn thành đồ án 2 – Tìm hiểu về chủ đề Event Sourcing Trong khoảng thời gian thực hiện đồ án, em đã học hỏi thêm được nhiều kiến thức, kinh nghiệm, biết được thêm về nhiều công nghệ mới

Trong thời gian một học kỳ thực hiện đề tài, em đã vận dụng những kiến thức nền tảng đã tích lũy đồng thời kết hợp với việc học hỏi và nghiên cứu những kiến thức mới Từ đó, em vận dụng tối đa những gì đã thu thập được để hoàn thành một báo cáo đồ án tốt nhất Tuy nhiên, trong quá trình thực hiện, em không tránh khỏi những thiếu sót Chính vì vậy, em rất mong nhận được những sự góp ý từ phía Cô nhằm hoàn thiện những kiến thức mà em đã học tập và là hành trang để em thực hiện tiếp các đề tài khác trong tương lai

Xin chân thành cảm ơn Thầy

Thành phố Hồ Chí Minh, tháng 12 năm 2022

Nguyễn Đức Phúc

NHẬN XÉT CỦA GIẢNG VIÊN HƯỚNG DẪN

Tp.HCM, ngày tháng 12 năm 2022

GVHD

ThS Nguyễn Công Hoan

Mục Lục

I Tổng quan 6

I.1 Giới thiệu về Event 6

I.1.1 Event là gì? 6

I.1.2 Events là không thể thay đổi 6

I.1.3 Event chỉ xảy ra một lần 6

I.1.4 Events là cái đã xảy ra 6

I.2 Giới thiệu về Event-Sourcing 7

I.2.1 Event Sourcing là gì? 7

I.3 Domain Events là gì? 8

II Cách thức hoạt động của Event Sourcing 10

III Khả năng ứng dụng 14

IV Event Sourcing: Xây dựng Event Storage 14

V Ứng dụng demo minh họa 17

VI Tổng kết 29

Tài liệu tham khảo 30

dụ phổ biến nhất bao gồm:

• Lưu trữ event cho việc phân tích

• Hỗ trợ việc giao tiếp giữa các service bằng cách xuất bản các event ứng dụng

• Sử dụng Event Sourcing để cung cấp một nguồn duy nhất của trạng thái dữ liệu

Event là các buiding block mà có thể trở nên phổ biến cho nhiều trường hợp sử dụng Nhiều sản phẩm phần mềm dựa trên thiết kế của event như một core buiding block Giống như bất kỳ buiding block khác hoặc định nghĩa nó như một phần quan trọng để nhận ra rằng tất cả các event không phải là tương đương nhau Đầu tiên hãy xem các thuộc tính của event phổ biến bất kể là trường hợp sử dụng nào hoặc sản phẩm liên quan

I.1.2 Events là không thể thay đổi

Khi điều gì đó đã xảy ra trong thế giới xung quanh chúng ta nó là thực tế Chúng ta không thể thay đổi lịch sử và việc mang sự thừa nhận này đến thiết kế của phần mềm là điều rất quan trọng khi phát triển hệ thống Bạn

mô hình hóa thế giới bằng cách lắp ráp chúng lại với nhau để làm thế nào

đó nhận thức thế giới xung quanh Những điều xảy ra liên tục và không phải thứ gì chúng ta cũng có thể nắm bắt chúng Hệ thống phần mềm có thể hỗ trợ chúng ta ghi lại và nhớ những điều quan trọng và điều này là lý

do tại sao các event là một mô hình tuyệt vời

I.1.3 Event chỉ xảy ra một lần

Một event chỉ có thể xảy ra một lần Nếu điều tương tự xảy ra một lần nữa thì nó vẫn được coi là một event khác bởi khi đó nó được định nghĩa là event xảy ra sau khi event đầu tiên Khi bạn đến thăm ngôi nhà của bạn bè

và bạn bấm chuông ba lần bởi vì họ mở cửa chậm chễ thì có 3 lần xảy ra event của tiếng chuông kêu

Đôi khi, về mặt kỹ thuật có thể chọn tổng hợp nhiều event chi tiết thành một event lớn hơn vì lý do hiệu suất hoặc đơn giản vì nó có ý nghĩa hợp lý hơn trong ứng dụng mà chúng ta đang phát triển Về mặt logic, đó là một khởi đầu tốt để tách các event và làm cho chúng càng rõ ràng càng tốt

I.1.4 Events là cái đã xảy ra

Một event luôn luôn miêu tả một cái gì đó đã xảy ra trong thực tế Điều này hàm ý rằng khi chúng ta nhìn các event chúng ta thấy nó đã xảy ra trong quá khứ và điều này là lý do tại sao chúng ta viết các event trong thì quá khứ (past tense) Nó là một thực hành tốt để giới hạn về naming convention

vì event có thể dễ dàng nhầm lẫn với request đến hệ thống Request có thể

bị từ chối và chúng ta thường không lưu trữ lịch sử của request trừ khi cho mục đích phân tích

Kỹ thuật triển khaiMột event là một tập hợp của dữ liệu, đây là điều cốt lõi của nó Event không nắm giữ bất kỳ hành động nào hoặc yêu cầu bất kỳ framework chỉ định nào Để sử dụng các event bạn cần sắp xếp theo thứ tự/ không theo thứ

tự dữ liệu từ một serializable format như vậy chúng có thể gửi đi hoặc lưu trữ trong kho lưu trữ bền vững Một lựa chọn tốt ở điểm này là JSON khi

đó nó sẽ dễ đàng đễ đọc, phần nào đó ngắn ngọn trong format và nói chung

hỗ trợ tất cả các ngôn ngữ lập trình

Về mặt công nghệ, dữ liệu event nên bao gồm một timstamp để đánh dấu khi nào event xảy ra trong dữ liệu JSON của nó, cũng như một định danh (kiểu UUID là một lựa chọn tốt) để có thể phân định giữa các event với nhau Triển khai của một event sử dụng JSON có thể giống như bên dưới:

I.2 Giới thiệu về Event-Sourcing

I.2.1 Event Sourcing là gì?

Event Sourcing là nắm bắt tất cả các thay đổi đối với trạng thái ứng dụng

dưới dạng chuỗi sự kiện

Chúng ta có thể truy vấn trạng thái của ứng dụng để tìm ra trạng thái hiện tại và điều này giúp trả lời nhiều câu hỏi Tuy nhiên, có những lúc chúng ta không chỉ muốn xem mình đang ở đâu mà còn muốn biết mình đã đến đó bằng cách nào.Nó đảm bảo rằng tất cả các thay đổi đối với trạng thái ứng dụng được lưu trữ dưới dạng một chuỗi các sự kiện Chúng tôi không chỉ có thể truy vấn những sự kiện này mà còn có thể sử dụng nhật ký sự kiện để tái tạo lại các trạng thái trong quá khứ và làm cơ sở để tự động điều chỉnh trạng thái để đối phó với những thay đổi có hiệu lực từ trước

Ý tưởng cơ bản của Event Sourcing là đảm bảo mọi thay đổi đối với

trạng thái của ứng dụng được ghi lại trong một đối tượng sự kiện, và bản thân các đối tượng sự kiện này được lưu trữ theo trình tự mà chúng được áp

dụng trong cùng thời gian tồn tại của chính trạng thái ứng dụng

I.3 Domain Events là gì?

Domain Events là một khái niệm quan trọng bên trong Domain-Driven Design Tuy nhiên, khái niệm Domain Events chưa được đưa vào cuốn sách tuyệt vời của Eric Evan về Domain-Driven Design ở lần xuất bản đầu tiên nhưng nó đã được thêm ở các lần sau, điều này giải thích cách tập trung xung quanh các event khác với cách chúng ta sử dụng để thiết kế hệ thống như thế nào

Domain Events là một phần của Domain Model, như vậy để định nghĩa nó chính xác, chúng ta ta phải đưa về đúng bối cảnh Trong Domain-Driven Design chúng ta tạo một model hợp lệ bên trong một Bounded Context Bối cảnh là giải pháp cho một vấn đề cụ thể mà chúng ta cần giải quyết, như vậy nó có thể là một subsystem hoặc một microservice hoặc cả nguyên một ứng dụng Nguyên tắc cốt lõi của Domain Model là giống như vậy – chỉ hợp lệ bên trong bối cảnh của nó

Câu hỏi trong khi định nghĩa Domain Events:

• Các bên liên quan/business có quan tâm đến nó không ?

• Nó là một quyết định bởi hệ thống của chúng ta hay hệ thống khác ?

• Nó có gói gọn lý do đằng sau sự thay đổi không ? Aggregates tạo Domain Events

Một Domain Events là một event, nó được sản sinh từ model và nó là kết quả của việc quyết định bên trong domain Bên trong model, Aggregates có vai trò bảo trì những business rule và đây là nơi chúng ta triển khai những điểm quyết định trong model, như vậy Aggregates cũng có trách nhiệm cho việc tạo Domain Events

Ảnh ở trên sẽ giúp ta hình dung Domain Events là một phần của Domain Model Chúng không được gửi từ hệ thống khác và cũng không phải là do user gửi đến hệ thống khi thực hiện các hành động Trong thuật ngữ kỹ thuật, có thể gọi là những message commands

Kỹ thuật triển khai

Domain Events có thể có một số triển khai chung cho các kiểu event khác

nhau Vì vậy nó cần có một aggregateId, aggregateType, eventType trong

dữ liệu để hỗ trợ nơi sử dụng xử lý được chúng Dữ liệu này nên có thể serializable giống như bất kỳ kiểu event khác và bạn không nên định nghĩa object của Domain Event với references quá nhiều cấp

Khi nào không phải là Domain Event?

Để đủ điều kiện là một Domain Events thì event nên có một ý nghĩa sâu hơn và quan trọng đến business của hệ thống Mọi thứ xảy ra xung quanh chúng ta có thể được miêu tả như những event nhưng không có nghĩa là chúng ta cần triển khai mọi thứ xảy ra trong hệ thống phần mềm

Những ví dụ sau có thể không thích hợp để coi là những Domain Events:

• Một vài kỹ thuật (click button, throw exception, ) đã xảy ra và chúng ta muốn ghi lại hoặc xử lý nhưng nó không được miêu tả trong ubiquitous language của lĩnh vực đang xây dựng

• Một số điều đã xảy ra bên ngoài của bounded context Có thể là một Domain Event của hệ thống khác hoặc một bounded context khác biệt

• Request tới hệ thống, chúng ta nên định nghĩa như một Commands hơn là events bởi vì chúng có thể bị từ chối bởi hệ thống

Bắt đầu như thế nào?

Bắt đầu với Domain Events không phải là một thử thách lớn đối với kiến trúc hệ thống Nếu bạn đã đang thiết kế ứng dụng sử dụng Domain-Driven Design (DDD), bạn có thể bắt đầu bởi việc lưu các events cùng nhau với trạng thái ứng dụng hiện tại như một phần trong đó

Khi bạn bắt đầu thêm Domain Events tới ứng dụng bạn có thể quan tâm đến Event Sourcing, nơi mà Domain Events là trung tâm của thông tin Lập trình với events như build clock cơ bản có thể mất thời gian để bắt đầu nhưng việc học thường có giá trị theo thời gian và bạn sẽ nhận thấy ít rắc rối khi phục vụ nhu cầu của những người kinh doanh với dữ liệu Bạn không phải sử dụng Event Sourcing để bắt đầu sử dụng Domain Events

Domain Events và Event Sourcing có liên quan?

Event Sourcing là một architectural pattern, nó được áp dụng bên trong một Bounded Context để cung cấp một nguồn dữ liệu ở thời điểm duy nhất Có nhiều cách hiểu khác nhau về Event Sourcing, nhưng hiểu đơn giản: Event Sourcing là khi bạn sử dụng Domain Events để lưu trữ trạng thái của một Aggregate bên trong một Bounded Context

Sai lầm và cạm bẫy phổ biến

Bắt đầu với Domain Events có thể cảm thấy lúng túng, khó khăn và có một vài điều cần nhớ để luôn đi đúng hướng với mô hình hóa của bạn như vậy Domain Events sẽ mang giá trị thực sự đến thiết kế phần mềm của bạn

Cố gắng mô hình hóa mọi thứ

Domain Model nên là hữa ích với vấn đề mà bạn đang giải quyết Model là

ở đó để bắt buộc các business rule mà bạn có và tốt nhất là kiến trúc chỉ nên cung cấp hỗ trợ tích hợp đủ đơn giản cho bạn có thể kết nối ứng dụng với

hệ thống khác, nghĩa là nó không cần những thứ không liên quan đến cái cốt lõi của business

Một cạm bẫy phổ biến mà các lập trình viên hay mắc phải là cố gắng model mọi thứ liên quan đến vấn đề Đây là nơi mà sự phân biệt giữa Domain Event và các events khác trở nên hữu ích vì nhiều khi các events khác xảy

ra (kỹ thuật hoặc ngoại vi) có thể được coi là event ghi nhật ký mà chúng ta

có thể lưu trữ chỉ cho mục đích phân tích

Không thoát khởi tư duy CRUD

Một trong các sai lầm phổ biến khi bắt đầu với Domain Events và Driven Design nói chung là không đi hết toàn bộ con đường và tìm ra những gì đang thực sự diễn ra trong domain Mọi người thường dễ dàng rơi vào cạm bẫy của việc đặt tên tất cả events: SomethingCreated,

Domain-SomethingUpdated và SomethingDeleted Mặc dù bản thân việc này không phải là vấn đề nhưng nó không tận dụng được sức mạnh ý nghĩa của bối cảnh thực tế mà Domain Event mang lại Bạn đánh mất ý định thực sự của event và việc đọc nhật ký event sau đó sẽ không mang lại nhiều giá trị Domain Events có điểm chung gì với Event Sourcing ? Chắc chắn từ

"event" trong tên của chúng Nhưng ngoài ra, khi nói về kiến trúc và nhà nhà phát triển trong các dự án, tại các hội nghị hoặc đào tạo, tôi thường nghe rằng domain event rất phù hợp với event sourcing và rằng event sourcing là một ý tưởng nguồn của domain events Trong bài viết này tôi mong muốn tóm lược tại sao cá nhân tôi không đồng tình với quan điểm này

Trước tiên tôi sẽ tranh luận tại sao tôi không chia sẻ cách nhìn này, tôi muốn đảm bảo một cách hiểu đầy đủ về domain events và event sourcing

II Cách thức hoạt động của Event Sourcing

Hãy xem xét một ví dụ đơn giản để thực hiện với thông báo giao hàng Trong ví dụ này, chúng ta có nhiều tàu trên biển cả, và chúng ta cần biết họ

đang ở đâu Một cách đơn giản để làm điều này là có một ứng dụng theo dõi với các phương pháp cho phép chúng tôi biết khi nào một con tàu đến hoặc rời cảng

Trong trường hợp này, khi dịch vụ được gọi, nó sẽ tìm thấy con tàu có liên quan và cập nhật vị trí của nó Các đối tượng tàu ghi lại trạng thái đã biết hiện tại của tàu

Còn đối với Event Sourcing thì thêm một bước vào quá trình này Nó sẽ tạo một đối tượng sự kiện( event object) để ghi lại thay đổi và để cập nhật các thay đổi của con tàu

Chỉ nhìn vào quá trình xử lý, đây chỉ là một mức độ gián tiếp không cần thiết Sự khác biệt thú vị là khi chúng ta xem xét những gì vẫn còn tồn tại trong ứng dụng sau một vài thay đổi Hãy tưởng tượng một số thay đổi đơn giản:

The Ship 'King Roy' departs San Francisco The Ship 'Prince Trevor' arrives at Los Angeles The Ship 'King Roy' arrives in Hong Kong Với cách làm bình thường, chúng ta chỉ thấy trạng thái cuối cùng được chụp bởi các đối tượng tàu Tôi sẽ gọi đây là trạng thái ứng dụng Với Event Sourcing, chúng tôi cũng nắm bắt từng sự kiện Nếu chúng ta đang

sử dụng một cửa hàng liên tục, các sự kiện sẽ được duy trì giống như các đối tượng tàu Tôi thấy hữu ích khi nói rằng chúng tôi đang duy trì hai thứ khác nhau là trạng thái ứng dụng và nhật ký sự kiện

Điều rõ ràng nhất mà chúng tôi đã đạt được bằng cách sử dụng event sourcing là giờ đây chúng tôi có nhật ký về tất cả các thay đổi Chúng ta không chỉ có thể thấy vị trí của từng con tàu, mà còn có thể biết nó đã ở đâu Tuy nhiên đây là một lợi ích nhỏ Chúng ta cũng có thể làm điều này bằng cách lưu giữ lịch sử các cảng trong quá khứ trong đối tượng tàu hoặc bằng cách ghi vào tệp nhật ký bất cứ khi nào tàu di chuyển Cả hai điều này

có thể cung cấp cho chúng ta một lịch sử đầy đủ.Nó cho phép ta đảm bảo rằng tất cả các thay đổi đối với các đối tượng miền đều do các đối tượng sự kiện lưu lại Điều này dẫn đến một số cơ sở có thể được xây dựng trên nhật

ký sự kiện:

Dễ dàng rebuild hơn: Chúng tôi có thể loại bỏ hoàn toàn trạng thái ứng dụng và xây dựng lại nó bằng cách chạy lại các sự kiện từ nhật ký sự kiện trên một ứng dụng trống

Truy vấn tạm thời: Chúng tôi có thể xác định trạng thái ứng dụng tại bất kỳ thời điểm nào Thông thường, chúng tôi làm điều này bằng cách bắt đầu với trạng thái trống và chạy lại các sự kiện cho đến một thời điểm hoặc sự kiện

cụ thể Chúng ta có thể tiến xa hơn bằng cách xem xét nhiều dòng thời gian (tương tự như phân nhánh trong hệ thống kiểm soát phiên bản)

Phát lại sự kiện: Nếu chúng tôi thấy một sự kiện trong quá khứ là không chính xác, chúng tôi có thể tính toán hậu quả bằng cách đảo ngược sự kiện

đó và các sự kiện sau đó rồi phát lại sự kiện mới và các sự kiện sau đó

Hoặc thực sự bằng cách loại bỏ trạng thái ứng dụng và phát lại tất cả các sự kiện với sự kiện chính xác theo trình tự.)Kỹ thuật tương tự có thể xử lý các

sự kiện nhận được theo trình tự sai - một vấn đề phổ biến với các hệ thống

giao tiếp bằng thông điệp không đồng bộ

Một ví dụ phổ biến về Event Sourcing là hệ thống kiểm soát phiên bản (version control) Một hệ thống như vậy sử dụng các truy vấn tạm thời khá thường xuyên Subversion sử dụng các bản dựng lại hoàn chỉnh bất cứ khi nào phiên bản có lỗi và cần khôi phục để di chuyển nội dung giữa các tệp kho lưu trữ Còn theo em tìm hiểu thì nó khá hiếm xuất hiện trong ứng dụng của doanh nghiệp ( enterprise application)

III Khả năng ứng dụng

Những ưu điểm chính được liệt kê bên dưới khi sử dụng event sourcing:

• Event được lưu trữ không chỉ mô tả trạng thái hiện tại của đối tượng

mà còn cho thấy lịch sử của quá trình tạo ra nó

• Nó có thể tái xây dựng lại trong bất kì thời điểm nào cho bất kì trạng thái nào trong quá khứ bởi việc chạy lại các event với một mốc thời gian nhất định

• Có thể hiểu được việc sử dụng event sourcing để xử lý processing lỗi của các event trước đó hoặc các event bị trì hoãn

Việc triển khai event sourcing cũng đòi hỏi một khái niệm và công nghệ phức tạp nhất định Các event không được phép thay đổi một khi vẫn tồn tại, trong khi domain logic thường phát triển theo thời gian Vì vậy code phải có khả năng xử lý các event thậm chí là rất cũ

Snapshots cần thiết để có thể xây dựng lại trạng thái dựa trên lượng lớn lịch

sử của các event theo cách thức nào đó

IV Event Sourcing: Xây dựng Event Storage

1 Cấu trúc

Event Storage trong hệ quản trị cơ sở dữ liệu quan hệ (RDBMS) gồm 2 bảng: Event Log và Aggregate

Bảng Event Log:

• Mỗi sự kiện sẽ tương ứng với một bản ghi, trong đó dữ liệu của sự kiện sẽ được lưu ở cột Data Các bản ghi này sẽ được INSERT theo trình tự thời gian diễn ra sự kiện

• Các cột AggregateID, Data và Version là những cột bắt buộc phải có trong bảng Event Log Ngoài ra, tùy vào yêu cầu nghiệp vụ mà bảng Event Log có thể thêm các cột khác, ví dụ: Thời gian xảy ra sự kiện, ID của user tạo ra sự kiện, địa chỉ IP của nơi xảy ra sự kiện,

• Mỗi event trong bảng Event Log được đánh số Version Trong phạm vi của từng AggregateID, số Version là độc nhất và được đánh tăng dần

• Cột AggregateID là foreign key trỏ đến cột AggregateID trong bảng

Aggregate Bảng Aggregate: