Kiến trúc hướng sự kiện (EDA): Tổng quan và Ứng dụng thực tế

Kiến trúc hướng sự kiện (Event-Driven Architecture - EDA) là một hệ thống có khả năng mở rộng cao, được thiết kế để xử lý các hoạt động của người dùng theo thời gian thực trong môi trường phân tán. Đây là một mô hình thiết kế phần mềm cho phép hệ thống tách rời (decouple) các thành phần bằng cách sử dụng các sự kiện, giúp cải thiện đáng kể tính linh hoạt, khả năng mở rộng và độ phản hồi của hệ thống.

Phong cách kiến trúc

Kiến trúc hướng sự kiện chủ yếu sử dụng mô hình publish-subscribe (xuất bản-đăng ký) và mô hình event streaming (luồng sự kiện). Trong kiến trúc này, các hệ thống giao tiếp với nhau một cách không đồng bộ (asynchronously) thông qua một bộ trung gian sự kiện (event broker). Các ứng dụng không cần biết vị trí cụ thể nơi thông tin được xuất bản hay tiêu thụ.

Các sự kiện đại diện cho một thay đổi trạng thái hoặc hành động của người dùng (ví dụ: một đơn hàng được đặt, người dùng đăng ký tài khoản). Sự tách rời này giúp các nhà phát triển dễ dàng cập nhật hoặc thêm tính năng mới mà không làm ảnh hưởng đến toàn bộ hệ thống.

Minh họa Kiến trúc hướng sự kiện

3 thành phần chính của EDA

Hệ thống EDA bao gồm ba thành phần cốt lõi hoạt động tương tác với nhau:

• Event Producer (Nhà sản xuất sự kiện): Đây là ứng dụng, dịch vụ hoặc bất kỳ thành phần nào tạo ra dữ liệu và xuất bản một sự kiện. Producer không cần biết ai sẽ đăng ký sự kiện này hay dữ liệu sẽ được xử lý như thế nào. Điều này cho phép producer xử lý khối lượng sự kiện lớn mà không bị chặn bởi các phía tiêu thụ.

• Event Broker (Trung gian sự kiện): Đây là phần mềm trung gian (middleware) nằm giữa producer và consumer. Vai trò chính của nó là nhận sự kiện từ producer, lưu trữ và định tuyến chúng đến consumer. Việc giao tiếp này hoàn toàn không đồng bộ và định tuyến dựa trên các chủ đề (topics), bộ lọc hàng đợi (queues). Broker đảm bảo sự kiện không bị mất thông qua các kỹ thuật như thử lại (retries), lưu trữ tin nhắn (message persistence), và hàng đợi thư chết (dead-letter queues). Một số ví dụ phổ biến là Apache Kafka, RabbitMQ hay AWS EventBridge.

• Event Consumer (Người tiêu thụ sự kiện): Đây là thành phần đăng ký các sự kiện được xuất bản bởi producer thông qua broker. Consumer sẽ xử lý sự kiện ngay lập tức khi nhận được. Mỗi consumer xử lý các loại sự kiện cụ thể và không cần biết ai đã xuất bản nó. Nhiều phiên bản của consumer có thể tiêu thụ sự kiện song song.

Các mô hình giao tiếp

EDA thường vận hành dựa trên một trong hai mô hình giao tiếp sau:

Mô hình Publish-Subscribe (Xuất bản-Đăng ký)

Trong mô hình này, producer xuất bản sự kiện mà không biết ai sẽ tiêu thụ chúng. Các subscriber (consumer) sẽ tìm kiếm các sự kiện cụ thể và đăng ký để nhận chúng ngay khi chúng có sẵn. Nhờ cấu trúc tách rời này, producer và consumer hoạt động hoàn toàn độc lập.

Mô hình Event Streaming (Luồng sự kiện)

Ở mô hình này, dữ liệu sự kiện được tạo ra và xử lý liên tục theo thời gian thực. Các sự kiện hoạt động như một luồng bản ghi được xử lý, lưu trữ và phân tích ngay khi chúng được tạo ra. Các ứng dụng cần phân tích và giám sát theo thời gian thực thường tận dụng mô hình này.

Khi nào nên sử dụng EDA?

Kiến trúc hướng sự kiện là lựa chọn tuyệt vời khi ứng dụng của bạn cần phản hồi ngay lập tức các hành động của người dùng và xử lý khối lượng sự kiện lớn mà không làm chậm hệ thống. Thay vì để mọi phần của ứng dụng giao tiếp trực tiếp với nhau, mỗi thành phần có thể gửi và lắng nghe các sự kiện riêng biệt.

Việc tách rời các dịch vụ giúp việc cập nhật hoặc thêm tính năng mới trở nên dễ dàng hơn mà không ảnh hưởng đến các phần còn lại. Hệ thống này giúp ứng dụng của bạn trở nên tin cậy và linh hoạt, ngay cả khi lưu lượng truy cập tăng đột biến hoặc một phần nào đó gặp sự cố tạm thời. Nếu bạn cần một hệ thống phản ứng theo thời gian thực, xử lý lưu lượng truy cập lớn một cách mượt mà và cho phép xây dựng, thay đổi dịch vụ mà không phá vỡ toàn bộ cấu trúc, EDA là giải pháp lý tưởng.

Ví dụ thực tế: Ứng dụng giao đồ ăn

Hãy xem xét ví dụ về một ứng dụng giao đồ ăn trực tuyến (như UberEats) nơi khách hàng, nhà hàng và tài xế cần nhận cập nhật theo thời gian thực cùng lúc. Kiến trúc EDA hoạt động hoàn hảo trong trường hợp này, cho phép tất cả các thành phần khác nhau hoạt động độc lập nhưng vẫn đồng bộ hóa dữ liệu.

Sơ đồ luồng ứng dụng giao đồ ăn trực tuyến

Các thành phần chính bao gồm:

• Order Service (Dịch vụ đơn hàng): Khách hàng đặt đơn hàng qua ứng dụng. Dịch vụ đơn hàng xuất bản sự kiện OrderPlaced (Đơn hàng đã đặt) chứa thông tin khách hàng, thanh toán và đơn hàng.
• Restaurant Service (Dịch vụ nhà hàng): Lắng nghe sự kiện OrderPlaced. Khi nhận được, nó thông báo cho nhà hàng chuẩn bị món và cập nhật bảng điều khiển theo dõi theo thời gian thực. Khi đơn hàng sẵn sàng, nó xuất bản sự kiện OrderReady.
• Payment Service (Dịch vụ thanh toán): Cũng lắng nghe sự kiện OrderPlaced để xử lý thanh toán và xuất bản sự kiện PaymentSuccessful.
• Delivery Service (Dịch vụ giao hàng): Lắng nghe sự kiện PaymentSuccessful, tìm kiếm tài xế khả dụng, gửi yêu cầu giao hàng và xuất bản sự kiện DriverAssigned. Sau đó, nó cũng lắng nghe OrderReady để xuất bản OrderOutForDelivery.
• Notification Service (Dịch vụ thông báo): Lắng nghe tất cả các sự kiện trên để gửi cập nhật theo thời gian thực cho khách hàng về trạng thái đơn hàng.

Các thách thức khi áp dụng EDA

Mặc dù EDA mang lại nhiều lợi ích, nó cũng đi kèm với những thách thức nhất định mà các đội ngũ kỹ thuật cần lưu ý:

• Gỡ lỗi và giám sát: Do các thành phần giao tiếp không đồng bộ thông qua sự kiện, việc truy vết luồng dữ liệu trở nên khó khăn, khiến việc kiểm thử (testing) phức tạp hơn.
• Tính nhất quán: Đôi khi các sự kiện có thể đến sai thứ tự, gây ra vấn đề về tính nhất quán dữ liệu nếu không được xử lý đúng cách.
• Sự trùng lặp: Do các vấn đề về mạng hoặc cơ chế thử lại, cùng một sự kiện có thể được nhận nhiều lần. Ứng dụng phải được thiết kế để xử lý các sự kiện trùng lặp một cách uyển chuyển.
• Chi phí vận hành: Bạn cần thiết lập và duy trì các công cụ broker (như Kafka, RabbitMQ), điều này tạo ra gánh nặng vận hành. Nếu hệ thống không được mở rộng đúng cách, hiệu năng có thể bị suy giảm và chi phí vận hành tăng lên.
• Xử lý lỗi: Với giao tiếp không đồng bộ, việc xử lý lỗi là thách thức lớn. Bạn cần cơ chế để thử lại hoặc khắc phục sự cố khi xử lý sự kiện thất bại mà không ảnh hưởng đến các dịch vụ khác.
• Bảo mật và quyền truy cập: Các sự kiện có thể chứa dữ liệu nhạy cảm như thông tin thanh toán. Nếu không được bảo mật kỹ, chúng có thể bị các dịch vụ không có thẩm quyền tiêu thụ.
• Mất mát sự kiện: Do lỗi mạng, cấu hình sai hoặc sự cố hệ thống, sự kiện có thể bị mất mát nếu broker không được cấu hình lưu trữ phù hợp.