欢迎使用 FlowZap,快速、清晰、掌控的绘图应用。

微服务每服务独立数据库架构

Architecture

每服务独立数据库架构图,每个微服务拥有其专用数据存储,通过 Kafka 进行事件驱动同步以实现跨服务数据一致性。该模板展示了微服务数据隔离的核心原则,展示 PostgreSQL 和 MongoDB 如何在多语言持久化策略中共存。对于在保持最终一致性的同时强制服务自治的架构师至关重要。

完整 FlowZap 代码

Gateway { # API Gateway
n1: circle label:"Client Request"
n2: rectangle label:"Route to Service"
n15: rectangle label:"Aggregate Responses"
n16: circle label:"Return to Client"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> UserService.n3.handle(top) [label="User Data"]
n2.handle(bottom) -> OrderService.n7.handle(top) [label="Order Data"]
n15.handle(right) -> n16.handle(left)
}
UserService { # User Service
n3: rectangle label:"Handle User Request"
n4: rectangle label:"Query User DB"
n5: rectangle label:"User PostgreSQL"
n6: rectangle label:"Return User Data"
n3.handle(right) -> n4.handle(left)
n4.handle(right) -> n5.handle(left) [label="SELECT"]
n5.handle(right) -> n6.handle(left) [label="Result"]
n6.handle(top) -> Gateway.n15.handle(bottom) [label="User JSON"]
}
OrderService { # Order Service
n7: rectangle label:"Handle Order Request"
n8: rectangle label:"Query Order DB"
n9: rectangle label:"Order MongoDB"
n10: rectangle label:"Return Order Data"
n7.handle(right) -> n8.handle(left)
n8.handle(right) -> n9.handle(left) [label="find()"]
n9.handle(right) -> n10.handle(left) [label="Documents"]
n10.handle(top) -> Gateway.n15.handle(bottom) [label="Order JSON"]
}
EventBus { # Event Bus (Kafka)
n11: rectangle label:"Publish Domain Event"
n12: rectangle label:"Event Topic"
n13: rectangle label:"Consume Event"
n14: rectangle label:"Sync Read Model"
n11.handle(right) -> n12.handle(left) [label="UserUpdated"]
n12.handle(right) -> n13.handle(left) [label="Subscribe"]
n13.handle(right) -> n14.handle(left) [label="Update Denormalized"]
}

为什么需要这个工作流?

Sharing a single database across microservices creates tight coupling, schema change conflicts, and performance bottlenecks that defeat the purpose of microservices. The database-per-service pattern ensures each service owns its data, enabling independent deployment, technology-appropriate storage choices, and fault isolation.

工作原理

  1. Step 1: Each microservice owns a dedicated database optimized for its access patterns.
  2. Step 2: The User Service uses PostgreSQL for relational data; the Order Service uses MongoDB for document storage.
  3. Step 3: Cross-service data needs are fulfilled through event-driven synchronization via Kafka.
  4. Step 4: When a user updates their profile, a UserUpdated event is published to the event bus.
  5. Step 5: The Order Service consumes the event and updates its denormalized user data.
  6. Step 6: The API Gateway aggregates responses from multiple services for client queries.

替代方案

Shared databases are simpler but create deployment coupling and single points of failure. Database-per-service with synchronous API calls creates latency chains. This template shows the event-driven approach that balances autonomy with data consistency.

Key Facts

Template Name微服务每服务独立数据库架构
CategoryArchitecture
Steps6 workflow steps
FormatFlowZap Code (.fz file)

相关模板

事件驱动发布-订阅架构

Architecture

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

事件驱动编排架构

Architecture

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

AI原生事件驱动Kafka架构

Architecture

事件驱动智能体AI架构,用Kafka/PubSub主题替换中央编排器:智能体订阅、响应并发布新事件。这使多智能体系统与经过验证的微服务编舞保持一致,适合实时、高吞吐量系统和"智能体网格"配置。

AI编排 - 事件驱动网格(Kafka优先)

Architecture

使用Kafka风格事件代理的事件驱动智能体网格架构。多个智能体订阅主题(订单、警报、分析),独立处理事件,并将结果发布回总线。最适合实时事件处理和解耦服务架构。

微服务 API 网关架构

Architecture

微服务 API 网关架构图,展示请求路由、JWT 身份验证、速率限制、服务发现以及跨分布式后端服务的响应聚合。该模板模拟微服务生态系统中所有客户端流量的入口点,在请求到达内部服务之前执行安全策略。适合设计具有集中式横切关注点的可扩展 API 基础设施的平台工程师。

微服务 Backend-for-Frontend (BFF) 架构

Architecture

Backend-for-Frontend 架构图,为 Web 和移动客户端提供独立的 BFF 层,每层针对其特定平台优化 API 响应,同时共享通用后端微服务。该模板展示如何通过按客户端类型定制数据聚合和负载优化来避免一刀切的 API。推荐给从共享微服务后端服务多个前端平台的团队。

返回所有模板