微服务每服务独立数据库架构
Architecture
每服务独立数据库架构图,每个微服务拥有其专用数据存储,通过 Kafka 进行事件驱动同步以实现跨服务数据一致性。该模板展示了微服务数据隔离的核心原则,展示 PostgreSQL 和 MongoDB 如何在多语言持久化策略中共存。对于在保持最终一致性的同时强制服务自治的架构师至关重要。
Architecture
事件驱动编排架构图,微服务通过事件协调而无需中央编排器,订单、支付、库存和物流服务相互响应对方的领域事件。该模板模拟去中心化协调模式,每个服务只了解自己的职责并发布事件供其他服务消费。适合偏好服务自治而非集中式工作流控制的团队。
OrderService { # Order Service
n1: circle label:"New Order Received"
n2: rectangle label:"Validate Order"
n3: rectangle label:"Emit OrderCreated Event"
n17: rectangle label:"Receive Payment Confirmation"
n18: rectangle label:"Update Order Status"
n19: circle label:"Order Complete"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="Valid"]
n3.handle(bottom) -> EventBus.n4.handle(top) [label="Publish"]
n17.handle(right) -> n18.handle(left) [label="Confirmed"]
n18.handle(right) -> n19.handle(left)
}
EventBus { # Event Bus
n4: rectangle label:"OrderCreated Topic"
n8: rectangle label:"PaymentConfirmed Topic"
n12: rectangle label:"InventoryReserved Topic"
n16: rectangle label:"ShipmentScheduled Topic"
n4.handle(bottom) -> PaymentService.n5.handle(top) [label="Subscribe"]
n8.handle(top) -> OrderService.n17.handle(bottom) [label="Notify"]
n8.handle(bottom) -> InventoryService.n9.handle(top) [label="Subscribe"]
n12.handle(bottom) -> ShippingService.n13.handle(top) [label="Subscribe"]
}
PaymentService { # Payment Service
n5: rectangle label:"Receive OrderCreated"
n6: rectangle label:"Process Payment"
n7: rectangle label:"Emit PaymentConfirmed"
n5.handle(right) -> n6.handle(left) [label="Charge"]
n6.handle(right) -> n7.handle(left) [label="Success"]
n7.handle(top) -> EventBus.n8.handle(bottom) [label="Publish"]
}
InventoryService { # Inventory Service
n9: rectangle label:"Receive PaymentConfirmed"
n10: rectangle label:"Reserve Stock"
n11: rectangle label:"Emit InventoryReserved"
n9.handle(right) -> n10.handle(left) [label="Allocate"]
n10.handle(right) -> n11.handle(left) [label="Reserved"]
n11.handle(top) -> EventBus.n12.handle(bottom) [label="Publish"]
}
ShippingService { # Shipping Service
n13: rectangle label:"Receive InventoryReserved"
n14: rectangle label:"Schedule Shipment"
n15: rectangle label:"Emit ShipmentScheduled"
n13.handle(right) -> n14.handle(left) [label="Plan Route"]
n14.handle(right) -> n15.handle(left) [label="Scheduled"]
n15.handle(top) -> EventBus.n16.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.
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.
| Template Name | 事件驱动编排架构 |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Architecture
每服务独立数据库架构图,每个微服务拥有其专用数据存储,通过 Kafka 进行事件驱动同步以实现跨服务数据一致性。该模板展示了微服务数据隔离的核心原则,展示 PostgreSQL 和 MongoDB 如何在多语言持久化策略中共存。对于在保持最终一致性的同时强制服务自治的架构师至关重要。
Architecture
Saga 编舞架构图,订单、支付和库存服务通过领域事件协调而无需中央编排器,每个服务发布和订阅驱动事务前进或触发补偿的事件。该模板模拟去中心化的 Saga 方法,服务自主响应事件,减少单点故障但增加了跟踪 Saga 状态的复杂性。适合偏好服务自治而非集中控制的团队。
Architecture
事件驱动智能体AI架构,用Kafka/PubSub主题替换中央编排器:智能体订阅、响应并发布新事件。这使多智能体系统与经过验证的微服务编舞保持一致,适合实时、高吞吐量系统和"智能体网格"配置。
Architecture
使用Kafka风格事件代理的事件驱动智能体网格架构。多个智能体订阅主题(订单、警报、分析),独立处理事件,并将结果发布回总线。最适合实时事件处理和解耦服务架构。
Architecture
微服务 API 网关架构图,展示请求路由、JWT 身份验证、速率限制、服务发现以及跨分布式后端服务的响应聚合。该模板模拟微服务生态系统中所有客户端流量的入口点,在请求到达内部服务之前执行安全策略。适合设计具有集中式横切关注点的可扩展 API 基础设施的平台工程师。
Architecture
Backend-for-Frontend 架构图,为 Web 和移动客户端提供独立的 BFF 层,每层针对其特定平台优化 API 响应,同时共享通用后端微服务。该模板展示如何通过按客户端类型定制数据聚合和负载优化来避免一刀切的 API。推荐给从共享微服务后端服务多个前端平台的团队。