事件驱动编排架构

Architecture

事件驱动编排架构图，微服务通过事件协调而无需中央编排器，订单、支付、库存和物流服务相互响应对方的领域事件。该模板模拟去中心化协调模式，每个服务只了解自己的职责并发布事件供其他服务消费。适合偏好服务自治而非集中式工作流控制的团队。

完整 FlowZap 代码

OrderService { # Order Service
n1: circle label:"New Order Received"
n2: rectangle label:"Validate Order"
n3: rectangle label:"Emit OrderCreated Event"
n4: rectangle label:"Listen for PaymentConfirmed"
n5: rectangle label:"Update Order Status"
n6: circle label:"Order Complete"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="Valid"]
n3.handle(bottom) -> EventBus.n7.handle(top) [label="Publish"]
n4.handle(right) -> n5.handle(left) [label="Confirmed"]
n5.handle(right) -> n6.handle(left)
}
EventBus { # Event Bus
n7: rectangle label:"OrderCreated Topic"
n8: rectangle label:"PaymentConfirmed Topic"
n9: rectangle label:"InventoryReserved Topic"
n10: rectangle label:"ShipmentScheduled Topic"
n7.handle(bottom) -> PaymentService.n11.handle(top) [label="Subscribe"]
n8.handle(top) -> OrderService.n4.handle(bottom) [label="Notify"]
n8.handle(bottom) -> InventoryService.n14.handle(top) [label="Subscribe"]
n9.handle(bottom) -> ShippingService.n17.handle(top) [label="Subscribe"]
}
PaymentService { # Payment Service
n11: rectangle label:"Receive OrderCreated"
n12: rectangle label:"Process Payment"
n13: rectangle label:"Emit PaymentConfirmed"
n11.handle(right) -> n12.handle(left) [label="Charge"]
n12.handle(right) -> n13.handle(left) [label="Success"]
n13.handle(top) -> EventBus.n8.handle(bottom) [label="Publish"]
}
InventoryService { # Inventory Service
n14: rectangle label:"Receive PaymentConfirmed"
n15: rectangle label:"Reserve Stock"
n16: rectangle label:"Emit InventoryReserved"
n14.handle(right) -> n15.handle(left) [label="Allocate"]
n15.handle(right) -> n16.handle(left) [label="Reserved"]
n16.handle(top) -> EventBus.n9.handle(bottom) [label="Publish"]
}
ShippingService { # Shipping Service
n17: rectangle label:"Receive InventoryReserved"
n18: rectangle label:"Schedule Shipment"
n19: rectangle label:"Emit ShipmentScheduled"
n17.handle(right) -> n18.handle(left) [label="Plan Route"]
n18.handle(right) -> n19.handle(left) [label="Scheduled"]
n19.handle(top) -> EventBus.n10.handle(bottom) [label="Publish"]
}

为什么需要这个工作流？

Centralized orchestrators become bottlenecks and single points of failure as the number of services grows. Event-driven choreography distributes coordination logic across services, where each service reacts autonomously to events—eliminating the need for a central coordinator and enabling truly independent service deployment.

工作原理

Step 1: The Order Service creates a pending order and publishes an OrderCreated event.
Step 2: The Payment Service subscribes to OrderCreated and processes the payment.
Step 3: On success, a PaymentConfirmed event is published to the event bus.
Step 4: The Inventory Service reacts to PaymentConfirmed by reserving stock.
Step 5: The Shipping Service reacts to InventoryReserved by scheduling shipment.
Step 6: The Order Service listens for saga completion events to update the final order status.

替代方案

Orchestration-based sagas provide better visibility but create a central coordinator dependency. Choreography is harder to debug but more resilient. This template helps teams understand the event flow in a choreographed system.

Key Facts

Template Name	事件驱动编排架构
Category	Architecture
Steps	6 workflow steps
Format	FlowZap Code (.fz file)