Kiến trúc microservice là một mẫu kiến trúc cấu trúc một ứng dụng như một tập hợp các dịch vụ nhỏ, được liên kết lỏng lẻo, hoạt động cùng nhau để đạt được mục tiêu chung. Vì microservice hoạt động độc lập nên chúng có thể được thêm, xóa hoặc nâng cấp mà không can thiệp vào các ứng dụng khác.
Tính linh hoạt này rất có lợi, cho phép triển khai và thử nghiệm dễ dàng hơn, tăng năng suất và cải thiện khả năng mở rộng. Nhưng để hoạt động như một ứng dụng gắn kết, các vi dịch vụ chạy độc lập phải được liên kết bằng phương thức giao tiếp liền mạch.
Rất may, các dịch vụ vi mô hướng đến sự kiện cho phép giao tiếp theo thời gian thực, cho phép sử dụng dữ liệu dưới dạng sự kiện trước khi chúng được yêu cầu.
Kiến trúc hướng sự kiện (Event-driven architecture - EDA) là một phương pháp thiết kế hệ thống được xây dựng để ghi lại, truyền tải và xử lý các sự kiện thông qua một kiến trúc tách rời. Điều này có nghĩa là các hệ thống không cần biết về nhau để chia sẻ thông tin và hoàn thành nhiệm vụ. Kiến trúc này thay thế kiến trúc “request/response” truyền thống, nơi các dịch vụ sẽ phải đợi phản hồi trước khi chúng có thể chuyển sang tác vụ tiếp theo. Luồng của kiến trúc hướng sự kiện được điều hành bởi các sự kiện và nó được thiết kế để phản hồi chúng hoặc thực hiện một số hành động để phản hồi lại một sự kiện.
Tuy nhiên, có những mối nguy hiểm từ nó. Nếu chúng ta sử dụng nó một cách bừa bãi, chúng ta có nguy cơ biến ứng dụng của mình thành một đống mã hỗn độn và khó kiểm soát. Nói cách khác, mã nên được liên kết với nhau được tách ra và sẽ rất khó để theo dõi luồng đi của nó (giống như câu lệnh goto), để hiểu nó và lý do về nó. Chúng ta nên giữ cho việc sử dụng event giới hạn trong các tình huống được xác định rõ ràng. Có ba trường hợp để sử dụng các event trong một ứng dụng microservice:
1. ĐỂ TÁCH CÁC THÀNH PHẦN
Khi Component A thực hiện logic cần kích hoạt logic của Component B, thay vì gọi nó trực tiếp, chúng ta có thể kích hoạt một event gửi đến event dispatcher. Component B sẽ lắng nghe event cụ thể đó trong dispatcher và sẽ hành động bất cứ khi nào event xảy ra.
Điều này có nghĩa là cả A và B sẽ tùy thuộc vào event và event dispatcher, chúng không hề biết và phụ thuộc lẫn nhau nhau (decoupled).
2. ĐỂ THỰC HIỆN CÁC TÁC VỤ ASYNC
Đôi khi chúng ta có một số logic mà chúng ta muốn thực hiện, nhưng có thể mất một khoảng thời gian để thực hiện và chúng ta không muốn người dùng chờ nó kết thúc. Trong trường hợp này, ta sẽ để cho logic được chạy asyn và response về cho user là request của anh ta đang được execute.
3. ĐỂ LƯU VẾT CÁC THAY ĐỔI (AUDIT LOG)
Theo cách lưu trữ dữ liệu truyền thống, chúng ta có các entity lưu giữ một số dữ liệu. Khi dữ liệu trong các entity đó thay đổi, chúng ta chỉ cần cập nhật một row của table trong DB để phản ánh các giá trị mới.
Sau khi khởi tạo dự án mới của bạn từ template trên bạn sẽ có cấu trúc project như sau:
Inventory micro service bao gồm các entities sau :
Entity: PriceSale
Inventory bao gồm các api sau:
Tạo các consumer trong Clean mico service để lắng nghe sự thay đổi thông điệp từ các queue:
Tính linh hoạt này rất có lợi, cho phép triển khai và thử nghiệm dễ dàng hơn, tăng năng suất và cải thiện khả năng mở rộng. Nhưng để hoạt động như một ứng dụng gắn kết, các vi dịch vụ chạy độc lập phải được liên kết bằng phương thức giao tiếp liền mạch.
Rất may, các dịch vụ vi mô hướng đến sự kiện cho phép giao tiếp theo thời gian thực, cho phép sử dụng dữ liệu dưới dạng sự kiện trước khi chúng được yêu cầu.
Kiến trúc hướng sự kiện (Event-driven architecture - EDA) là một phương pháp thiết kế hệ thống được xây dựng để ghi lại, truyền tải và xử lý các sự kiện thông qua một kiến trúc tách rời. Điều này có nghĩa là các hệ thống không cần biết về nhau để chia sẻ thông tin và hoàn thành nhiệm vụ. Kiến trúc này thay thế kiến trúc “request/response” truyền thống, nơi các dịch vụ sẽ phải đợi phản hồi trước khi chúng có thể chuyển sang tác vụ tiếp theo. Luồng của kiến trúc hướng sự kiện được điều hành bởi các sự kiện và nó được thiết kế để phản hồi chúng hoặc thực hiện một số hành động để phản hồi lại một sự kiện.
Tuy nhiên, có những mối nguy hiểm từ nó. Nếu chúng ta sử dụng nó một cách bừa bãi, chúng ta có nguy cơ biến ứng dụng của mình thành một đống mã hỗn độn và khó kiểm soát. Nói cách khác, mã nên được liên kết với nhau được tách ra và sẽ rất khó để theo dõi luồng đi của nó (giống như câu lệnh goto), để hiểu nó và lý do về nó. Chúng ta nên giữ cho việc sử dụng event giới hạn trong các tình huống được xác định rõ ràng. Có ba trường hợp để sử dụng các event trong một ứng dụng microservice:
- Để tách các thành phần
- Để thực hiện các tác vụ đồng bộ hóa dữ liệu
- Để lưu vết các thay đổi (audit log)
1. ĐỂ TÁCH CÁC THÀNH PHẦN
Khi Component A thực hiện logic cần kích hoạt logic của Component B, thay vì gọi nó trực tiếp, chúng ta có thể kích hoạt một event gửi đến event dispatcher. Component B sẽ lắng nghe event cụ thể đó trong dispatcher và sẽ hành động bất cứ khi nào event xảy ra.
Điều này có nghĩa là cả A và B sẽ tùy thuộc vào event và event dispatcher, chúng không hề biết và phụ thuộc lẫn nhau nhau (decoupled).
2. ĐỂ THỰC HIỆN CÁC TÁC VỤ ASYNC
Đôi khi chúng ta có một số logic mà chúng ta muốn thực hiện, nhưng có thể mất một khoảng thời gian để thực hiện và chúng ta không muốn người dùng chờ nó kết thúc. Trong trường hợp này, ta sẽ để cho logic được chạy asyn và response về cho user là request của anh ta đang được execute.
3. ĐỂ LƯU VẾT CÁC THAY ĐỔI (AUDIT LOG)
Theo cách lưu trữ dữ liệu truyền thống, chúng ta có các entity lưu giữ một số dữ liệu. Khi dữ liệu trong các entity đó thay đổi, chúng ta chỉ cần cập nhật một row của table trong DB để phản ánh các giá trị mới.
4.SỬ DỤNG EVEN DRIVEN TRONG THỰC TIỄN TRIỂN KHAI
Trong ứng dụng microservice các service hoạt động độc lập không phụ thuộc lẫn nhau. Lúc này các even đóng một vai trò quan trọng khi nó thực hiện đồng bộ hóa data giữa các service theo thời gian thực và nó còn đóng cả vai trò trong việc thực hiện audit log các entities của chính nó.
Đầu tiên hãy tải template "SC.Microservice.Template" từ nuget.
Entity: Product
Entity: Warehouse
Entity: PriceSale
+ Tạo product:
Sau khi Product được tạo và lưu trữ vào database của Inventory. Một thông điệp được gửi đi tới queue "CreateProductQueue"
+ Tạo bản ghi giá cho product:
Sau khi bản ghi giá cho product được tạo và lưu trữ vào database của Inventory. Một thông điệp được gửi tới queue "EditProductPriceQueue".
+ Tạo bản ghi số lượng cho product:
Sau khi bản ghi số lượng cho product được tạo và lưu trữ vào database của Inventory. Một thông điệp được gửi tới queue "EditProductQuantityQueue".
Config Eventbus:
Clean microservice bao gồm các entities sau:
+ CreateProductQueue
+ EditProductPriceQueue
+ EditProductQuantityQueue
Chạy solution:
Tạo Sản phẩm: "Mã hàng PT001" từ Inventory Api
Kết quả :
Thực thi api : get product trên micro service Clean
Kết quả:
Như vậy sau khi bản ghi product "Mã hàng PT001" được tạo từ Inventory đã được đồng bộ sang Clean.
Đồng thời trên Clean micro service cũng đã cấu hình Audit log cho Entity : Product
Lúc này bất cứ thay đổi nào đến từ Enitity Product đều được cập nhật chi tiết vào các entity Audit:
Nhận xét
Đăng nhận xét