Trong các hệ thống hiện đại có quy mô lớn và tính thời gian thực cao, mô hình yêu cầu - phản hồi (Request-Response) đồng bộ truyền thống thường gây ra tình trạng nghẽn cổ chai và phụ thuộc lẫn nhau giữa các dịch vụ. Kiến trúc Hướng Sự kiện (Event-Driven Architecture - EDA) thay đổi hoàn toàn cách các dịch vụ giao tiếp bằng cách dựa trên các sự kiện phát sinh thay vì gọi trực tiếp lẫn nhau.
Dưới đây là cẩm nang toàn diện về kiến trúc hướng sự kiện và thiết kế hệ thống bất đồng bộ thực chiến.
Dưới đây là cẩm nang toàn diện về kiến trúc hướng sự kiện và thiết kế hệ thống bất đồng bộ thực chiến.
1. Các Khái Niệm Cốt Lõi Của Kiến Trúc Hướng Sự Kiện
Để vận hành một hệ thống EDA thành công, cần nắm vững ba thành phần nền tảng:- Event (Sự kiện): Một trạng thái hoặc sự thay đổi đáng chú ý đã xảy ra trong hệ thống (ví dụ: OrderCreated, PaymentProcessed, UserSignedUp). Sự kiện mang tính bất biến (immutable) và chỉ phản ánh quá khứ.
- Event Producer (Bên phát sự kiện): Thành phần phát ra sự kiện khi có nghiệp vụ hoàn tất mà không cần quan tâm ai sẽ xử lý sự kiện đó (Decoupling tuyệt đối).
- Event Consumer (Bên tiêu thụ sự kiện): Các dịch vụ lắng nghe và xử lý sự kiện theo nhu cầu riêng của mình (ví dụ: khi nhận được sự kiện OrderCreated, dịch vụ Kho sẽ trừ hàng và dịch vụ Giao hàng sẽ tạo vận đơn).
2. Các Mô Hình Phân Phối Sự Kiện (Event Messaging Patterns)
Tùy thuộc vào bài toán kinh doanh, kiến trúc sư có thể lựa chọn mô hình phân phối sự kiện phù hợp:- Pub/Sub (Publish-Subscribe): Một sự kiện được phát ra có thể được gửi đến nhiều Consumer khác nhau cùng lúc. Thích hợp cho việc thông báo trạng thái đồng thời tới nhiều phân hệ phụ trợ.
- Event Sourcing: Thay vì lưu trữ trạng thái hiện tại của một thực thể (như số dư tài khoản hay giỏ hàng), hệ thống lưu trữ toàn bộ chuỗi các sự kiện đã xảy ra theo thời gian. Điều này giúp dễ dàng tái hiện lại trạng thái hệ thống tại bất kỳ thời điểm nào trong quá khứ và hỗ trợ kiểm toán (Auditing) cực kỳ hiệu quả.