事件驱动发布-订阅架构

Architecture

事件驱动发布-订阅架构图，展示 Kafka 或 RabbitMQ 消息代理、事件序列化、主题分区、向多个消费者的扇出交付以及死信队列错误处理。该模板模拟了生产者和消费者通过消息代理完全解耦的基础异步消息传递模式。对于构建松耦合、可扩展的事件驱动系统的架构师至关重要。

下载 .fz 文件

完整 FlowZap 代码

Producer { # Event Producer
n1: circle label:"Business Action"
n2: rectangle label:"Create Domain Event"
n3: rectangle label:"Serialize Event"
n4: rectangle label:"Publish to Topic"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="OrderCreated"]
n3.handle(right) -> n4.handle(left) [label="Avro/JSON"]
n4.handle(bottom) -> Broker.n5.handle(top) [label="Produce"]
}
Broker { # Message Broker (Kafka/RabbitMQ)
n5: rectangle label:"Receive Event"
n6: rectangle label:"Partition by Key"
n7: rectangle label:"Persist to Log"
n8: rectangle label:"Fan-Out to Subscribers"
n9: rectangle label:"Dead Letter Queue"
n5.handle(right) -> n6.handle(left)
n6.handle(right) -> n7.handle(left) [label="Append"]
n7.handle(right) -> n8.handle(left) [label="Notify"]
n8.handle(bottom) -> Consumers.n10.handle(top) [label="Deliver"]
n9.handle(bottom) -> Consumers.n17.handle(top) [label="Failed Events"]
}
Consumers { # Event Consumers
n10: rectangle label:"Inventory Consumer"
n11: rectangle label:"Update Stock Level"
n12: rectangle label:"Notification Consumer"
n13: rectangle label:"Send Order Email"
n14: rectangle label:"Analytics Consumer"
n15: rectangle label:"Update Dashboard"
n16: diamond label:"Processing OK?"
n17: rectangle label:"Retry Handler"
n10.handle(right) -> n16.handle(left)
n16.handle(right) -> n11.handle(left) [label="Yes"]
n16.handle(bottom) -> n17.handle(top) [label="No"]
n17.handle(top) -> Broker.n9.handle(bottom) [label="DLQ"]
n12.handle(right) -> n13.handle(left) [label="Email"]
n14.handle(right) -> n15.handle(left) [label="Aggregate"]
}

为什么需要这个工作流？

Synchronous request-response communication between microservices creates tight coupling, cascading failures, and latency chains. The publish-subscribe pattern decouples producers from consumers through a message broker, enabling independent scaling, temporal decoupling, and resilient event processing with built-in retry mechanisms.

工作原理

Step 1: A business action triggers the creation of a domain event in the producer service.
Step 2: The event is serialized (Avro or JSON) and published to a topic on the message broker.
Step 3: The broker partitions events by key for ordered processing and persists them to a log.
Step 4: Multiple consumers subscribe to the topic and process events independently.
Step 5: Failed events are routed to a dead letter queue after exceeding retry thresholds.
Step 6: Operations teams monitor DLQ depth and investigate failed events through a dashboard.

替代方案

Synchronous HTTP calls are simpler but create coupling. Point-to-point queues limit fan-out. Managed services like AWS SNS/SQS or Google Pub/Sub reduce operational overhead. This template visualizes the complete pub/sub lifecycle including error handling.

Key Facts

Template Name	事件驱动发布-订阅架构
Category	Architecture
Steps	6 workflow steps
Format	FlowZap Code (.fz file)