微服务架构设计模式 ：数据库拆分模式

微服务架构设计模式 第四部分：数据篇

数据库拆分模式

在微服务架构中，数据层的设计与划分是最具挑战性的部分之一。
不同于单体应用只依赖一个数据库，微服务常常需要根据 服务边界 来拆分数据库，以实现服务的自治。

---

1 每服务独立数据库

核心思想

• 每个服务维护自己的数据库（schema 或 instance）。
• 服务之间 不共享数据库表，而是通过 API 或事件 来交互。

架构示意

+------------------+       +------------------+
|  User Service    | --->  |  user_db         |
+------------------+       +------------------+

+------------------+       +------------------+
|  Order Service   | --->  |  order_db        |
+------------------+       +------------------+

优点

✅ 服务自治：数据库 schema 由服务团队自己管理，不依赖其他团队。
✅ 降低耦合：一个服务的数据库变更不会影响到其他服务。
✅ 高可扩展性：可针对不同数据库类型做优化（如用户服务用 MySQL，日志服务用 MongoDB）。

缺点

❌ 跨服务查询复杂：不能直接用 SQL Join，需要 API 或消息机制。
❌ 数据一致性难：涉及分布式事务时，需要用 Saga/事件驱动来保证最终一致性。

示例：Spring Boot + MySQL（订单服务）

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/order_db
    username: root
    password: root
    driver-class-name: com.mysql.cj.jdbc.Driver
  jpa:
    hibernate:
      ddl-auto: update
    show-sql: true

OrderRepository.java

@Repository
public interface OrderRepository extends JpaRepository<Order, Long> {
}

➡️ 这里的 order-service 只操作自己的 order_db，不会直接访问 user_db。

---

2 共享数据库的利弊

在某些情况下，多个服务可能仍然共享一个数据库实例甚至 schema。

架构示意

+------------------+      
|  User Service    |      
+------------------+      
        |
        v
   +-------------+
   | shared_db   |
   +-------------+
        ^
        |
+------------------+      
|  Order Service   |      
+------------------+

优点

✅ 开发简单：跨服务直接用 SQL Join 即可。
✅ 数据一致性好：ACID 事务天然保证。
✅ 更适合传统迁移：单体拆分初期可快速过渡。

缺点

❌ 服务耦合严重：schema 变更可能影响多个服务。
❌ 难以实现真正的独立部署：数据库成了单点瓶颈。
❌ 难以做到多技术栈（不同服务可能需要不同存储引擎）。

---

3 迁移策略与最佳实践

• 短期过渡：单体拆分初期，可以接受共享数据库，但要明确未来目标是 独立数据库。
• 领域驱动设计（DDD）：以 聚合根 为界，划分服务和数据库边界。
• 跨服务数据访问：用 API 或事件（Kafka、RabbitMQ）替代直接 SQL Join。
• 一致性保证：采用 Saga 模式 或 补偿事务。

---

4 总结

• 每服务独立数据库 → 高自治 & 可扩展，但一致性和查询复杂度更高。

• 共享数据库 → 短期见效快，但长期阻碍服务独立性和扩展性。

• 推荐策略：

  • 核心业务 → 独立数据库，保证服务自治。
  • 过渡/边缘业务 → 可短期共享，但应逐步解耦。