Lập trình hướng sự kiện là gì năm 2024
Event-driven Architecture (EDA - Kiến trúc hướng sự kiện) là một kiến trúc phần mềm mà ở đó ta chú trọng vào việc tạo và sử dụng các events (sự kiện). Show
Một event sẽ biểu diễn một hành động có mục đích nào đó. Thông thường, các sự kiện có thể tương ứng với việc tạo hoặc thay đổi state của một vài entities. Ví dụ: khi ta mua một sản phẩm nào đó trên các trang e-commerce thì đó cũng là một event. Khách hàng gửi review về một sản phẩm nhận được đó cũng là một event. Event không bao giờ xảy raMột trong những đặc trưng của events đó là chúng không hề giao tiếp với các đối tượng sử dụng chúng. Event "chỉ xảy ra" mà thôi. Tuy vậy đó là là một yếu tố khiến event trở nên "rất mạnh" - thực tế là event sẽ chuyển thành một record bao hàm các thông tin liên quan đến sự kiện vừa xảy ra, cũng như các emiiters và quan trọng nhất đó là nó tách biệt hoàn toàn đối với handlers. Sự thật là event producers không hề biết đến sự tồn tại của event consumers. Một record chỉ bao hàm các thông tin liên quan đến sự kiện vừa xảy ra mà thôi. Như ở ví dụ kể trên về việc mua đồ trên trang e-commerce, event mua đồ có thể được mô tả bằng JSON object như sau:
Chú ý rằng: trong thực tế records và events là hai thuật ngữ có thể dùng thay thế cho nhau. Ví dụ: thuật ngữ "event" được sử dụng để nói về "record" của sự kiện đó. Ứng dụng của chúng ta tạo ra một event, tuy nhiên nó không hề biết Ai sẽ xử lí event đó, khi nào, Ở đâu và Xử lí như thế nào. Bản thân event producer chỉ đảm bảo cung cấp đủ thông tin để event consumer có thể xử lí event mà thôi. Do đó các thông tin khác, ví dụ như thông tin về Channelling EventsNếu event producers và event consumer không hề biết gì về nhau, vậy thì chúng sẽ giao tiếp với nhau bằng cách nào ? Events thường được lưu trữ ở một nơi được gọi là log (Đôi khi thuật ngữ ledger có thể được sử dụng). Logs là một dạng cấu trúc dữ liệu append-only bậc thấp, log là nơi mà producer sẽ lưu các events để sau đó các consumer có thể truy cập và lấy về các events. Mọi thao tác với log đều do brokers - một middleware nằm ở giữa producers và consumers đảm nhận. Khi một event được publish thì tất cả mọi đối tượng đều có thể sử dụng event đó. Khi triển khai event-driven systems, chúng ta thường sử dụng thuật ngữ stream để chỉ một hoặc nhiều logs. Log là một thuật ngữ mang tính chất "vật lý" khi nó sử dụng các file để lưu trữ, còn stream mang tính logic khi nó là một chuỗi các events. Mối liên hệ giữa producers, consumers và streams có thể được mô tả như mô hình dưới đây
Decoupling thông qua bất đồng bộ và tổng quát hoáQuay trở về điểm khởi đầu, Tại sao EDA giúp các thành phần trong hệ thống giảm phụ thuộc vào nhau ? Một định nghĩa đơn giản về độ phụ thuộc đó là mức độ một component làm ảnh hưởng đến các components khác. Một ví dụ tiêu biểu đó là khi một service gọi một REST API khác và chờ kết quả trả về từ API đó, nếu trong trường hợp REST API kia gặp trục chặc và không trả về kết quả được thì service gọi đến API sẽ phải dừng mọi xử lí phía sau lời gọi API đó. Ta nói rằng các components là tightly coupled nếu chúng phụ thuộc chặt chẽ vào nhau và loosely coupled trong trường hợp ngược lại.
EDA không phải là "viên đạn bạc" hay "một liều thuốc tiên" giúp ta có thể tách bạch các components ra khỏi nhau hoàn toàn. Trên thực tế khi producer và consumer không phụ thuộc vào nhau nữa thì chúng lại phụ thuộc vào broker, dẫn đến một điểm lỗi mới đó chính là broker, nên broker phải đảm bảo hiệu năng cao cũng như tính chịu lỗi tốt. Các hình thứ xử lí eventCó thể phân ra thành 3 nhóm chính như dưới đây: Xử lí event rời rạc (Discrete event processing)Ví dụ như khi post một bài đăng lên mạng xã hội. Một trong số đặc trưng của việc xử lí event rời rạc đó là sự hiện diện của một event không hề liên quan đến các events khác và hoàn toàn có thể được xử lí độc lập. Event stream processingXử lí các event theo luồng, có tính đến thứ tự của các events, khi mà event hiện tại có liên quan đến event trong quá khứ. Một ví dụ tiêu biểu đó là các events thay đổi lên business entity. Các events này sẽ được xử lí theo một thứ tự nhất định, sau đó sẽ lưu business entity data vào trong database. Consumer cũng cần tránh tình trạng đồng thời thay đổi lên cùng một record của database khiến cho dữ liệu không được nhất quán. Complex event processingComplex event processing (CEP) định danh và đưa ra các event pattern phức tạp dựa trên một chuỗi các event đơn giản. Ta lấy ví dụ về CEP cho việc theo dõi nhiệt độ và khói từ các cảm biến để phát hiện xem có xảy ra hoả hoạn hay không. Dữ liệu về nhiệt độ ở một thời điểm có thể không mang quá nhiều ý nghĩa nhưng với một "cụm nhiệt độ" cũng với tỉ lệ thay đổi nhiệt độ thì ta hoàn toàn có thể phán đoán được rằng liệu có đang xảy ra hoả hoạn hay không. Khi nào thì sử dụng EDA (Event Driven Architecture)Có một vài use-cases tiêu biểu như sau:
Lợi ích của EDA
Nhược điểm của EDA
Những điều cần lưu ýEDA không hoàn hảo 100%, cũng như các công cụ khác, nó cũng có nhược điểm riêng. Dưới đây là những nhược điểm của EDA mà các developers cũng như architecture nên chú ý khi thiết kế cũng như triển khai hệ thống hướng sự kiện (event-driven system).
Tổng kếtKiến trúc microservices là một mảnh ghép cho quá trình xây dựng một hệ thống dễ dàng bảo trì, mở rộng hơn. Microservice thực sự tuyệt khi đứng ở phương diện tách các components khỏi nhau nhưng nó cũng có rất nhiều vấn đề nổi cộm. Việc chia nhỏ hệ thống từ "monolith" thành "microservice" có thể khiến chúng ta quay lại đúng nới chúng ta bắt đầu, đó chính là vấn đề "distributed monolith" - các monolith phân tán. Để hoàn thành mảnh ghép dang dở và giải quyết vấn đề phụ thuộc lẫn nhau giữa các components, chúng ta tìm kiếm đến kiến trúc hướng sự kiện - event-driven architecture. EDA là một công cụ tốt để phân tách các components trong hệ thống bằng cách mô hình hoá sự tương tác giữa chúng thông qua việc sử dụng các khái niệm producers, consumers, events, streams. Event mô tả một điều gì đó vừa mới xảy ra, nó được sinh ra và xử lí một cách bất đồng bộ bởi các components không hề biết gì về nhau. EDA cho phép các components hoạt động độc lập với nhau. Bản thân EDA không phải là hoàn hảo, nhưng nó đem lại nhiều lợi ích hơn là vấn đề. Do đó EDA có thể được xem như một thành phần không thể thiếu của bất cứ hệ thống microservices thành công nào. |