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

Architecture

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

下载 .fz 文件

完整 FlowZap 代码

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

为什么需要这个工作流？

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.

工作原理

Step 1: Each microservice owns a dedicated database optimized for its access patterns.
Step 2: The User Service uses PostgreSQL for relational data; the Order Service uses MongoDB for document storage.
Step 3: Cross-service data needs are fulfilled through event-driven synchronization via Kafka.
Step 4: When a user updates their profile, a UserUpdated event is published to the event bus.
Step 5: The Order Service consumes the event and updates its denormalized user data.
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	微服务每服务独立数据库架构
Category	Architecture
Steps	6 workflow steps
Format	FlowZap Code (.fz file)