Event-driven architecture là gì? Cách kiến trúc hướng sự kiện hoạt động

Khi một hệ thống có nhiều ứng dụng và dịch vụ cần trao đổi dữ liệu liên tục, việc các thành phần gọi trực tiếp lẫn nhau có thể làm tăng mức độ phụ thuộc và gây khó khăn khi mở rộng. Event-driven architecture là một cách tiếp cận giúp các thành phần giao tiếp thông qua sự kiện, từ đó xử lý dữ liệu linh hoạt và độc lập hơn.

Vậy Event-driven architecture là gì, hoạt động như thế nào và khi nào nên sử dụng kiến trúc này?

Event-driven architecture là gì?

Event-driven architecture (EDA) hay kiến trúc hướng sự kiện là một mô hình kiến trúc phần mềm trong đó các ứng dụng hoặc dịch vụ giao tiếp với nhau thông qua việc tạo, truyền và xử lý các sự kiện (event).

Một event đại diện cho một hành động hoặc sự thay đổi trạng thái đã xảy ra trong hệ thống. Ví dụ:

• Khách hàng vừa đặt một đơn hàng.
• Một giao dịch thanh toán vừa hoàn tất.
• Một tệp vừa được tải lên hệ thống lưu trữ.
• Một cảm biến vừa ghi nhận nhiệt độ mới.
• Một tài khoản vừa được tạo.
• Trạng thái đơn hàng chuyển sang “đang giao”.

Trong EDA, thành phần phát sinh sự kiện không nhất thiết phải biết thành phần nào sẽ xử lý sự kiện đó. Nó chỉ cần phát event vào hệ thống. Các dịch vụ quan tâm có thể nhận event và thực hiện tác vụ tương ứng.

Điểm này giúp giảm sự phụ thuộc trực tiếp giữa các thành phần, cho phép từng dịch vụ phát triển, triển khai và mở rộng tương đối độc lập.

Event là gì trong Event-driven architecture?

Event là thông tin thể hiện rằng một sự việc đã xảy ra.

Điểm cần lưu ý là event thường mô tả một sự kiện trong quá khứ thay vì yêu cầu một dịch vụ phải thực hiện hành động.

Ví dụ:

OrderCreated
→ Đơn hàng đã được tạo.

PaymentCompleted
→ Thanh toán đã hoàn tất.

FileUploaded
→ Tệp đã được tải lên.

Event có thể chỉ chứa thông tin nhận dạng:

Order #12345 đã được tạo

hoặc chứa thêm dữ liệu về trạng thái của sự kiện như:

• mã đơn hàng;
• mã khách hàng;
• danh sách sản phẩm;
• thời gian tạo;
• tổng giá trị đơn hàng.

Các consumer nhận được event sẽ quyết định chúng có cần phản ứng với sự kiện đó hay không.

Các thành phần chính của Event-Driven Architecture (EDA)

Event-Driven Architecture (EDA) dựa trên ba thành phần chính để truyền và xử lý dữ liệu sự kiện trong hệ thống, gồm Event Producer, Event Broker và Event Consumer. Mỗi thành phần đảm nhận một vai trò riêng trong quá trình tạo, phân phối và xử lý event.

Event Producer

Event Producer (hay publisher) là thành phần tạo ra event. Producer có thể là giao diện người dùng, cảm biến, thiết bị IoT, microservice hoặc bất kỳ hệ thống nào có khả năng phát hiện sự thay đổi về trạng thái.

Khi phát hiện thay đổi, producer tạo event và gửi tới các thành phần khác trong hệ thống. Tuy nhiên, producer chỉ chịu trách nhiệm tạo và truyền event, không trực tiếp thực hiện quá trình xử lý event.

Event Broker

Event Broker (hay router) nằm giữa producer và consumer. Thành phần này giúp tách biệt hai phía để producer và consumer không cần thiết lập kết nối trực tiếp với nhau.

Đóng vai trò như một message-oriented middleware, Event Broker tiếp nhận event message, duy trì thứ tự thời gian của các event, cung cấp chúng cho quá trình tiêu thụ và định tuyến event tới consumer phù hợp.

Event Consumer

Event Consumer (hay subscriber) là thành phần chịu trách nhiệm xử lý event.

Consumer lắng nghe các event channel và phản ứng khi một event mà nó quan tâm được phát đi. Sau khi tiếp nhận event, consumer có thể thực hiện các tác vụ như cập nhật database, kích hoạt một quy trình tiếp theo hoặc ghi lại thông tin.

Event được xử lý trong EDA như thế nào?

Quá trình xử lý bắt đầu khi một ứng dụng hoặc service thực hiện hành động mà thành phần khác trong hệ thống cần biết. Lúc này, một event mới được tạo và gửi đến Event Broker.

Broker tiếp nhận event và duy trì thứ tự của event so với những event khác trong cùng luồng. Event Consumer sau đó tiếp nhận message theo thời gian thực hoặc tại một thời điểm phù hợp và xử lý event để kích hoạt hành động tiếp theo.

Event-driven architecture khác Request-Response như thế nào?

Request-Response là mô hình quen thuộc trong nhiều ứng dụng web.

Ví dụ:

Service A → gửi request → Service B → trả response

Service A thường phải biết Service B nằm ở đâu và có thể phải chờ phản hồi trước khi tiếp tục xử lý.

EDA hoạt động khác:

Service A → phát Event → Broker → Service B/C/D

Producer không nhất thiết phải biết consumer nào đang nhận event.

Điều này không có nghĩa EDA thay thế hoàn toàn Request-Response.

Trong thực tế, một ứng dụng có thể sử dụng REST API cho những tác vụ cần phản hồi ngay và sử dụng event cho các quy trình bất đồng bộ phía sau.

Các mô hình phổ biến trong Event-driven architecture

EDA có thể được triển khai theo nhiều pattern khác nhau.

Publish/Subscribe

Trong mô hình Publish/Subscribe (Pub/Sub), producer publish một event vào một topic hoặc channel.

Nhiều subscriber có thể đăng ký nhận cùng loại sự kiện.

Ví dụ:

OrderCreated

được publish vào topic orders.

Payment, Inventory và Notification Service đều có thể subscribe topic này.

Ưu điểm là có thể bổ sung consumer mới mà không cần producer biết consumer đó tồn tại.

Event Streaming

Event Streaming xử lý một luồng event liên tục theo thời gian.

Event có thể được lưu lại trong một event log để nhiều consumer đọc và xử lý độc lập.

Mô hình này thường xuất hiện trong:

• xử lý dữ liệu real-time;
• analytics;
• hệ thống IoT;
• clickstream;
• log processing;
• hệ thống giao dịch;
• data pipeline.

Apache Kafka là một công nghệ phổ biến được sử dụng để xây dựng các hệ thống event streaming.

Tuy nhiên, cần phân biệt:

Kafka là công nghệ hỗ trợ triển khai EDA, không phải bản thân Event-driven architecture.

Event Sourcing

Event Sourcing là pattern trong đó trạng thái của một đối tượng được hình thành dựa trên chuỗi các event đã xảy ra.

Ví dụ tài khoản ngân hàng có các event:

AccountCreated
MoneyDeposited
MoneyWithdrawn

Thay vì chỉ lưu số dư cuối cùng, hệ thống có thể lưu lại lịch sử các event để tái dựng trạng thái.

Event Sourcing có thể được sử dụng trong hệ thống event-driven nhưng Event Sourcing và Event-driven architecture không phải một khái niệm.

Event-driven architecture và Microservices có gì khác nhau?

Event-driven architecture thường xuất hiện cùng Microservices nên hai khái niệm này dễ bị nhầm lẫn.

Microservices Architecture tập trung vào cách chia một ứng dụng lớn thành nhiều dịch vụ nhỏ, tương đối độc lập, mỗi dịch vụ phụ trách một chức năng nghiệp vụ nhất định.

Trong khi đó, Event-driven architecture tập trung vào cách các thành phần giao tiếp và phản ứng với event.

Microservices ≠ Event-driven architecture

nhưng:

Microservices + Event-driven architecture là một cách kết hợp phổ biến để xây dựng các hệ thống phân tán có khả năng mở rộng.

Lợi ích của Event-Driven Architecture

Kiến trúc hướng sự kiện (Event-Driven Architecture – EDA) khai thác các sự kiện nghiệp vụ bằng cách cho phép hệ thống phát hiện tình huống mới, phản ứng theo thời gian thực, tự động hóa việc ra quyết định và tối đa hóa tiềm năng doanh thu. EDA cũng có thể hỗ trợ doanh nghiệp duy trì và thúc đẩy tăng trưởng thông qua những lợi ích sau:

• Khả năng mở rộng (Scalability): EDA cho phép hệ thống mở rộng bằng cách bổ sung thêm các instance của service để xử lý khối lượng công việc ngày càng tăng.
• Nhắn tin bất đồng bộ (Asynchronous messaging): Producer có thể phát event message theo tiến trình riêng mà không phải chờ consumer tiếp nhận, giúp đơn giản hóa quá trình tích hợp và cải thiện trải nghiệm người dùng.
• Linh hoạt và nhanh nhạy (Flexibility and agility): Các service có thể được thêm, loại bỏ hoặc thay đổi độc lập, hỗ trợ tốt cho quy trình phát triển và triển khai theo phương pháp Agile.
• Liên kết lỏng lẻo (Loose coupling): Event producer và consumer tương tác thông qua event thay vì gọi API trực tiếp. Điều này giúp giảm sự phụ thuộc giữa các thành phần và tăng khả năng phục hồi của toàn hệ thống.
• Khả năng phản hồi nhanh (Responsiveness): EDA vốn được thiết kế cho việc xử lý và phản hồi theo thời gian thực, giúp các nhóm chủ động hơn trong việc xử lý tình huống, đồng thời hỗ trợ các hoạt động và quy trình tự động hóa thông minh hơn.

Thách thức của EDA

Bên cạnh những lợi ích đáng kể, kiến trúc hướng sự kiện cũng đặt ra một số thách thức về thiết kế và vận hành mà đội ngũ phát triển cần cân nhắc trước khi triển khai.

Tính nhất quán cuối cùng

Trong EDA, producer có thể phát event mà không cần chờ các thành phần khác xử lý. Vì vậy, tại một thời điểm nhất định, các thành phần khác nhau trong hệ thống có thể tạm thời lưu giữ những trạng thái dữ liệu khác nhau.

Đội ngũ phát triển cần xác định rõ hoạt động nào có thể chấp nhận sự khác biệt dữ liệu tạm thời và hoạt động nào yêu cầu tính nhất quán nghiêm ngặt. Chẳng hạn, giao dịch tài chính thường đòi hỏi mức độ nhất quán cao hơn so với hệ thống đề xuất nội dung.

Thứ tự của event

Ở quy mô lớn, việc đảm bảo các event luôn được xử lý đúng thứ tự là một vấn đề phức tạp.

Ví dụ, nếu khách hàng cập nhật địa chỉ giao hàng rồi ngay sau đó đặt hàng, thứ tự hai event được xử lý có thể quyết định đơn hàng sử dụng địa chỉ mới hay địa chỉ cũ. Vì vậy, đảm bảo đúng trình tự event giữa nhiều consumer phân tán đòi hỏi kiến trúc hệ thống phải được thiết kế cẩn thận.

Backpressure và consumer lag

Khi producer tạo event nhanh hơn tốc độ consumer có thể xử lý, hệ thống cần có cơ chế kiểm soát lượng event tồn đọng.

Backpressure là cơ chế kiểm soát luồng được sử dụng để giải quyết vấn đề này. Một số phương pháp thường được áp dụng gồm rate limiting, mở rộng consumer theo chiều ngang hoặc sử dụng các chiến lược buffering để tạm lưu event.

Khó khăn trong debugging và observability

Trong hệ thống truyền thống, nguồn gốc của lỗi thường tương đối dễ xác định. Với EDA, lỗi xử lý có thể chỉ xuất hiện ở những bước phía sau sau khi event đã đi qua nhiều consumer và cơ chế routing khác nhau.

Điều này khiến quá trình Root Cause Analysis (RCA) trở nên phức tạp hơn, đồng thời làm tăng vai trò của các công cụ observability trong việc theo dõi event và trạng thái của hệ thống.

Idempotency và xử lý event trùng lặp

Sự cố mạng, consumer bị gián đoạn hoặc cơ chế gửi lại có thể khiến cùng một event được xử lý nhiều lần.

Do đó, hệ thống EDA cần được thiết kế để việc xử lý cùng một event nhiều lần không tạo ra kết quả sai. Thuộc tính này được gọi là idempotency.

Các cơ chế phục hồi như Dead Letter Queue (DLQ) và retry policy có thể giúp hệ thống xử lý lỗi tốt hơn, tránh tình trạng event bị mất khi xảy ra sự cố. Nếu không thiết kế những cơ chế này ngay từ đầu, hệ thống có thể phát sinh các vấn đề về tính nhất quán dữ liệu khó phát hiện và xử lý.

Event-Driven Architecture (EDA) được ứng dụng ở đâu?

Event-Driven Architecture (EDA) phù hợp với các doanh nghiệp có môi trường CNTT lớn, phức tạp và cần xử lý sự kiện nhanh chóng. Khi tích hợp nhiều hệ thống sử dụng các nền tảng công nghệ khác nhau, EDA sử dụng cơ chế loose coupling để giảm sự phụ thuộc giữa các thành phần và cải thiện khả năng tương tác.

Trong các hệ thống hoạt động trên nhiều tài khoản hoặc khu vực, cơ chế fan-out còn cho phép phân phối event để xử lý song song mà không cần bổ sung code mới. Nhờ khả năng xử lý với thông lượng cao và độ trễ thấp, EDA có thể được ứng dụng vào nhiều quy trình khác nhau.

Phân tích dữ liệu giao dịch

Ngân hàng và các nền tảng fintech có thể sử dụng EDA để theo dõi dữ liệu giao dịch theo thời gian thực.

Bằng cách kết hợp lịch sử chi tiêu với các hoạt động đang diễn ra, hệ thống có thể phát hiện cơ hội và xây dựng hồ sơ khách hàng chi tiết hơn ngay khi giao dịch phát sinh.

Tối ưu hàng tồn kho

Các nhà bán lẻ lớn có thể ứng dụng kiến trúc hướng sự kiện để giám sát lượng hàng tồn kho tại hàng nghìn địa điểm theo thời gian thực.

Khi một mặt hàng có lợi nhuận cao sắp hết, event tương ứng có thể kích hoạt quy trình bổ sung hàng tự động. Điều này giúp hệ thống phản ứng với sự thay đổi của lượng hàng tồn kho ngay khi sự kiện xảy ra.

Phát hiện hoạt động đáng ngờ

Trong lĩnh vực viễn thông, EDA được sử dụng để liên tục đánh giá hoạt động và mô hình sử dụng.

Khi xuất hiện hành vi tài khoản đáng ngờ hoặc bất thường trên mạng, hệ thống có thể phát hiện và đánh dấu ngay khi chúng phát sinh.

Phân tích thông tin khách hàng

Các tổ chức chăm sóc sức khỏe có thể kết hợp dữ liệu tiếp nhận bệnh nhân, dữ liệu giám sát và dữ liệu lịch sử để xác định những thông tin liên quan theo thời gian thực.

Thông qua các luồng dữ liệu này, hệ thống có thể phát hiện yếu tố rủi ro hoặc khoảng trống trong quá trình chăm sóc khi chúng trở nên cần thiết để xử lý.

Bảo trì dự đoán

Trong lĩnh vực sản xuất, doanh nghiệp có thể sử dụng event stream từ các thiết bị được kết nối để phát hiện sớm những dấu hiệu rủi ro.

Thay vì chờ thiết bị gặp sự cố và dây chuyền sản xuất ngừng hoạt động, hệ thống có thể lên lịch bảo trì trước khi sự cố xảy ra.

Điều chỉnh giá theo thời gian thực

Các hãng hàng không và nền tảng gọi xe có thể sử dụng EDA để phát hiện sự thay đổi của nhu cầu theo thời gian thực.

Dựa trên những tín hiệu đang diễn ra, hệ thống có thể điều chỉnh mức giá trong vài giây để phản ứng với biến động của nhu cầu.

Câu hỏi thường gặp về Event-driven architecture

Event-driven architecture là gì?

Event-driven architecture là kiến trúc phần mềm trong đó các thành phần giao tiếp bằng cách tạo, truyền và xử lý event. Producer phát event khi có sự kiện xảy ra, sau đó một hoặc nhiều consumer nhận và xử lý event tương ứng.

Event trong Event-driven architecture là gì?

Event là thông tin cho biết một hành động hoặc sự thay đổi trạng thái đã xảy ra, chẳng hạn OrderCreated, PaymentCompleted hoặc FileUploaded.

Event-driven architecture có giống Microservices không?

Không. Microservices tập trung vào việc chia ứng dụng thành các dịch vụ nhỏ độc lập, còn EDA tập trung vào cách các thành phần giao tiếp thông qua event. Hai kiến trúc thường được kết hợp với nhau.

Kafka có phải Event-driven architecture không?

Không. Apache Kafka là một nền tảng event streaming có thể được sử dụng để triển khai Event-driven architecture. EDA là mô hình kiến trúc, trong khi Kafka là một công nghệ.

Event-driven architecture có luôn xử lý bất đồng bộ không?

EDA thường sử dụng giao tiếp bất đồng bộ để tách producer khỏi consumer. Tuy nhiên, một hệ thống thực tế có thể kết hợp cả xử lý đồng bộ và bất đồng bộ tùy từng nghiệp vụ.

Khi nào nên sử dụng Event-driven architecture?

EDA phù hợp với hệ thống Microservices, ứng dụng real-time, IoT, streaming data hoặc những workload có nhiều thành phần cần phản ứng độc lập với cùng một sự kiện.

Nhược điểm của Event-driven architecture là gì?

Các thách thức chính gồm quản lý event ordering, duplicate event, eventual consistency, event schema, debugging và observability trong môi trường phân tán.

Kết luận

Event-driven architecture giúp hệ thống chuyển từ mô hình các dịch vụ gọi trực tiếp lẫn nhau sang kiến trúc giao tiếp dựa trên sự kiện. Nhờ đó, producer và consumer có thể hoạt động độc lập hơn, hỗ trợ xử lý bất đồng bộ, mở rộng linh hoạt và phản ứng nhanh trước các thay đổi của hệ thống.

Đối với những ứng dụng Microservices, real-time hoặc workload có lưu lượng biến động, EDA có thể trở thành một thành phần quan trọng của kiến trúc Cloud hiện đại. Tuy nhiên, doanh nghiệp cũng cần cân nhắc các vấn đề về event ordering, consistency, monitoring và quản lý hệ thống phân tán trước khi triển khai.

Để xây dựng nền tảng cho các ứng dụng hiện đại, doanh nghiệp có thể lựa chọn hạ tầng VNPT Cloud nhằm triển khai, vận hành và mở rộng các workload Cloud theo nhu cầu thực tế.