Tweet
Khi Event-Driven Architecture cần một "nhạc trưởng": Mediator Topology
Trong nhiều hệ thống tự động hóa hiện đại, không phải mọi sự kiện đều đơn giản đến mức chỉ cần nhận sự kiện rồi xử lý ngay. Có những quy trình gồm nhiều bước, có bước chạy song song, có bước phải chờ bước khác hoàn thành. Đây là lúc Mediator Topology phát huy tác dụng.
Hãy lấy ví dụ quen thuộc trong DevOps và Cloud Automation: triển khai một máy ảo (VM) mới. Quy trình này thường bao gồm nhiều bước như cấp phát tài nguyên, đặt trước địa chỉ IP, tạo máy ảo và cấu hình hệ điều hành. Một số bước có thể thực hiện đồng thời, trong khi một số bước bắt buộc phải thực hiện theo thứ tự. Chẳng hạn, không thể cấu hình hệ điều hành nếu máy ảo chưa được tạo xong.
Trong kiến trúc Mediator Topology, có bốn thành phần chính:
Event Queue là nơi tiếp nhận các sự kiện ban đầu (initial events). Đây thường là message queue hoặc hệ thống hàng đợi sự kiện.
Event Mediator đóng vai trò trung tâm điều phối. Thành phần này không trực tiếp xử lý nghiệp vụ mà chỉ biết quy trình cần thực hiện gồm những bước nào, bước nào chạy song song và bước nào phải chờ.
Event Channel là các kênh truyền tải sự kiện xử lý (processing events) từ Mediator đến các bộ xử lý tương ứng. Chúng thường được triển khai bằng message queue hoặc event stream.
Event Processor là các thành phần thực hiện nghiệp vụ cụ thể. Mỗi processor nên độc lập, tự chứa (self-contained), liên kết lỏng lẻo (loosely coupled) và chỉ đảm nhiệm một nhiệm vụ duy nhất.
Điểm quan trọng của mô hình này là sự phân biệt giữa:
Quay lại ví dụ triển khai VM.
Hệ thống nhận được sự kiện "VM Requested". Event Queue chuyển sự kiện này đến Event Mediator. Mediator biết rằng trước tiên cần cấp phát tài nguyên và đặt trước địa chỉ IP. Do đó nó gửi đồng thời hai processing events đến:
Hai processor này hoạt động song song để thực hiện việc đặt trước tài nguyên và địa chỉ IP.
Khi nhận được các phản hồi như:
Mediator biết rằng các điều kiện tiên quyết đã hoàn tất và tiếp tục gửi sự kiện đến VM Provisioning Processor để tạo máy ảo.
Sau khi nhận phản hồi "VM Provisioned", Mediator mới kích hoạt bước cuối cùng là cấu hình hệ điều hành.
Quá trình tiếp tục cho đến khi toàn bộ workflow hoàn thành.
Điểm mạnh lớn nhất của Mediator Topology là khả năng orchestration. Thay vì để các service tự gọi lẫn nhau tạo thành một mạng lưới phụ thuộc phức tạp, toàn bộ luồng xử lý được điều phối tập trung bởi Mediator. Điều này giúp dễ quản lý workflow, theo dõi trạng thái xử lý và xây dựng các quy trình tự động hóa phức tạp trong Cloud, DevOps, Infrastructure Automation hay IT Service Provisioning.
Nếu Broker Topology giống như một hệ thống phát thanh nơi các thành phần tự lắng nghe và phản ứng với sự kiện, thì Mediator Topology giống như một dàn nhạc có nhạc trưởng, nơi mọi hoạt động đều được điều phối theo một kịch bản đã định trước.
Đây cũng là nền tảng kiến trúc xuất hiện rất nhiều trong các công cụ Workflow Engine hiện đại như Camunda, Temporal, Netflix Conductor, AWS Step Functions và nhiều nền tảng Orchestration trong môi trường Cloud Native.
Trong nhiều hệ thống tự động hóa hiện đại, không phải mọi sự kiện đều đơn giản đến mức chỉ cần nhận sự kiện rồi xử lý ngay. Có những quy trình gồm nhiều bước, có bước chạy song song, có bước phải chờ bước khác hoàn thành. Đây là lúc Mediator Topology phát huy tác dụng.
Hãy lấy ví dụ quen thuộc trong DevOps và Cloud Automation: triển khai một máy ảo (VM) mới. Quy trình này thường bao gồm nhiều bước như cấp phát tài nguyên, đặt trước địa chỉ IP, tạo máy ảo và cấu hình hệ điều hành. Một số bước có thể thực hiện đồng thời, trong khi một số bước bắt buộc phải thực hiện theo thứ tự. Chẳng hạn, không thể cấu hình hệ điều hành nếu máy ảo chưa được tạo xong.
Trong kiến trúc Mediator Topology, có bốn thành phần chính:
Event Queue là nơi tiếp nhận các sự kiện ban đầu (initial events). Đây thường là message queue hoặc hệ thống hàng đợi sự kiện.
Event Mediator đóng vai trò trung tâm điều phối. Thành phần này không trực tiếp xử lý nghiệp vụ mà chỉ biết quy trình cần thực hiện gồm những bước nào, bước nào chạy song song và bước nào phải chờ.
Event Channel là các kênh truyền tải sự kiện xử lý (processing events) từ Mediator đến các bộ xử lý tương ứng. Chúng thường được triển khai bằng message queue hoặc event stream.
Event Processor là các thành phần thực hiện nghiệp vụ cụ thể. Mỗi processor nên độc lập, tự chứa (self-contained), liên kết lỏng lẻo (loosely coupled) và chỉ đảm nhiệm một nhiệm vụ duy nhất.
Điểm quan trọng của mô hình này là sự phân biệt giữa:
- Initial Event: sự kiện khởi đầu quy trình.
- Processing Event: các sự kiện trung gian được Mediator tạo ra để điều phối các bước xử lý.
Quay lại ví dụ triển khai VM.
Hệ thống nhận được sự kiện "VM Requested". Event Queue chuyển sự kiện này đến Event Mediator. Mediator biết rằng trước tiên cần cấp phát tài nguyên và đặt trước địa chỉ IP. Do đó nó gửi đồng thời hai processing events đến:
- VM Resource Allocation Processor
- IPAM Processor
Hai processor này hoạt động song song để thực hiện việc đặt trước tài nguyên và địa chỉ IP.
Khi nhận được các phản hồi như:
- "VM Resources Allocated"
- "IP Address Reserved"
Mediator biết rằng các điều kiện tiên quyết đã hoàn tất và tiếp tục gửi sự kiện đến VM Provisioning Processor để tạo máy ảo.
Sau khi nhận phản hồi "VM Provisioned", Mediator mới kích hoạt bước cuối cùng là cấu hình hệ điều hành.
Quá trình tiếp tục cho đến khi toàn bộ workflow hoàn thành.
Điểm mạnh lớn nhất của Mediator Topology là khả năng orchestration. Thay vì để các service tự gọi lẫn nhau tạo thành một mạng lưới phụ thuộc phức tạp, toàn bộ luồng xử lý được điều phối tập trung bởi Mediator. Điều này giúp dễ quản lý workflow, theo dõi trạng thái xử lý và xây dựng các quy trình tự động hóa phức tạp trong Cloud, DevOps, Infrastructure Automation hay IT Service Provisioning.
Nếu Broker Topology giống như một hệ thống phát thanh nơi các thành phần tự lắng nghe và phản ứng với sự kiện, thì Mediator Topology giống như một dàn nhạc có nhạc trưởng, nơi mọi hoạt động đều được điều phối theo một kịch bản đã định trước.
Đây cũng là nền tảng kiến trúc xuất hiện rất nhiều trong các công cụ Workflow Engine hiện đại như Camunda, Temporal, Netflix Conductor, AWS Step Functions và nhiều nền tảng Orchestration trong môi trường Cloud Native.
Attached Files