Tweet
Broker Topology trong Event-Driven Architecture: Khi hệ thống không cần "nhạc trưởng"
Trong các bài trước, chúng ta đã tìm hiểu Mediator Topology, nơi mọi luồng xử lý đều được điều phối bởi một thành phần trung tâm (Event Mediator). Tuy nhiên, không phải hệ thống Event-Driven nào cũng cần một "nhạc trưởng".
Đó là lúc Broker Topology phát huy tác dụng.
Broker Topology khác với Mediator Topology ở chỗ không tồn tại một thành phần trung tâm chịu trách nhiệm điều phối toàn bộ quy trình xử lý. Thay vào đó, các sự kiện (events) tự nhiên nối tiếp nhau thông qua một Message Broker, thường được triển khai dưới dạng Message Queue như Kafka, RabbitMQ, NATS hoặc ActiveMQ.
Khi một sự kiện xuất hiện, nó được gửi vào broker. Một event processor phù hợp sẽ nhận sự kiện đó, thực hiện phần công việc của mình rồi phát sinh một sự kiện mới. Sự kiện mới tiếp tục được broker chuyển cho processor tiếp theo. Quá trình này tạo thành một chuỗi xử lý liên tục cho đến khi hoàn thành nghiệp vụ.
Điểm quan trọng là sau khi xử lý xong một event, processor không còn tham gia vào quy trình đó nữa. Nó chỉ biết công việc của mình và không cần biết toàn bộ luồng nghiệp vụ phía sau.
Một ví dụ dễ hình dung là chạy tiếp sức (relay race).
Mỗi vận động viên chỉ chạy một đoạn đường của mình rồi chuyền gậy cho người kế tiếp. Không ai cần biết toàn bộ cuộc đua diễn ra như thế nào, họ chỉ cần hoàn thành phần việc được giao. Trong Broker Topology, "cây gậy tiếp sức" chính là event.
Ví dụ trong quy trình triển khai máy ảo (VM Provisioning):
Toàn bộ quy trình diễn ra mà không cần một bộ điều phối trung tâm.
Đây là mô hình rất phổ biến trong các hệ thống:
Ưu điểm lớn nhất của Broker Topology là khả năng mở rộng độc lập, giảm sự phụ thuộc giữa các dịch vụ (loose coupling) và tăng khả năng chịu lỗi của hệ thống. Tuy nhiên, đổi lại việc theo dõi luồng xử lý và troubleshooting sẽ phức tạp hơn vì không có thành phần nào nắm toàn bộ workflow. Ôn tập nhanh
Vai trò của Event Channel trong Event-Driven Architecture là gì?
Đáp án đúng:
a. Phân phối sự kiện từ Event Emitters đến Event Consumers
Event Channel đóng vai trò là "đường dẫn giao thông" giúp các sự kiện được truyền từ nơi phát sinh (Producer/Emitter) đến nơi xử lý (Consumer/Processor), tạo nên nền tảng cho toàn bộ kiến trúc Event-Driven hoạt động hiệu quả.
Trong thế giới DevOps, Automation và Cloud-Native ngày nay, hiểu rõ sự khác biệt giữa Mediator Topology và Broker Topology là bước đầu tiên để thiết kế các hệ thống phân tán có khả năng mở rộng và tự động hóa ở quy mô lớn.
Trong các bài trước, chúng ta đã tìm hiểu Mediator Topology, nơi mọi luồng xử lý đều được điều phối bởi một thành phần trung tâm (Event Mediator). Tuy nhiên, không phải hệ thống Event-Driven nào cũng cần một "nhạc trưởng".
Đó là lúc Broker Topology phát huy tác dụng.
Broker Topology khác với Mediator Topology ở chỗ không tồn tại một thành phần trung tâm chịu trách nhiệm điều phối toàn bộ quy trình xử lý. Thay vào đó, các sự kiện (events) tự nhiên nối tiếp nhau thông qua một Message Broker, thường được triển khai dưới dạng Message Queue như Kafka, RabbitMQ, NATS hoặc ActiveMQ.
Khi một sự kiện xuất hiện, nó được gửi vào broker. Một event processor phù hợp sẽ nhận sự kiện đó, thực hiện phần công việc của mình rồi phát sinh một sự kiện mới. Sự kiện mới tiếp tục được broker chuyển cho processor tiếp theo. Quá trình này tạo thành một chuỗi xử lý liên tục cho đến khi hoàn thành nghiệp vụ.
Điểm quan trọng là sau khi xử lý xong một event, processor không còn tham gia vào quy trình đó nữa. Nó chỉ biết công việc của mình và không cần biết toàn bộ luồng nghiệp vụ phía sau.
Một ví dụ dễ hình dung là chạy tiếp sức (relay race).
Mỗi vận động viên chỉ chạy một đoạn đường của mình rồi chuyền gậy cho người kế tiếp. Không ai cần biết toàn bộ cuộc đua diễn ra như thế nào, họ chỉ cần hoàn thành phần việc được giao. Trong Broker Topology, "cây gậy tiếp sức" chính là event.
Ví dụ trong quy trình triển khai máy ảo (VM Provisioning):
- Event "VM Requested" được gửi vào broker.
- Resource Allocation Processor nhận event và cấp phát tài nguyên.
- Sau khi hoàn thành, processor phát sinh event "VM Resources Allocated".
- Broker chuyển event này cho IPAM Processor.
- IPAM Processor cấp phát địa chỉ IP và phát sinh event "IP Address Reserved".
- Event tiếp tục được chuyển đến các processor khác để triển khai VM, cấu hình hệ điều hành và hoàn tất hệ thống.
Toàn bộ quy trình diễn ra mà không cần một bộ điều phối trung tâm.
Đây là mô hình rất phổ biến trong các hệ thống:
- Microservices
- Cloud-native applications
- Kubernetes Operators
- CI/CD Pipelines
- Infrastructure Automation
- Large-scale Event Streaming Platforms
Ưu điểm lớn nhất của Broker Topology là khả năng mở rộng độc lập, giảm sự phụ thuộc giữa các dịch vụ (loose coupling) và tăng khả năng chịu lỗi của hệ thống. Tuy nhiên, đổi lại việc theo dõi luồng xử lý và troubleshooting sẽ phức tạp hơn vì không có thành phần nào nắm toàn bộ workflow. Ôn tập nhanh
Vai trò của Event Channel trong Event-Driven Architecture là gì?
Đáp án đúng:
a. Phân phối sự kiện từ Event Emitters đến Event Consumers
Event Channel đóng vai trò là "đường dẫn giao thông" giúp các sự kiện được truyền từ nơi phát sinh (Producer/Emitter) đến nơi xử lý (Consumer/Processor), tạo nên nền tảng cho toàn bộ kiến trúc Event-Driven hoạt động hiệu quả.
Trong thế giới DevOps, Automation và Cloud-Native ngày nay, hiểu rõ sự khác biệt giữa Mediator Topology và Broker Topology là bước đầu tiên để thiết kế các hệ thống phân tán có khả năng mở rộng và tự động hóa ở quy mô lớn.
Attached Files