微服务拆分精讲 / 第 05 章：数据库拆分
第 05 章：数据库拆分
代码拆分是表面，数据库拆分才是灵魂。数据不独立，微服务就是假的。
5.1 为什么数据库拆分最难
5.1.1 代码与数据的拆分难度对比
代码拆分 数据库拆分
───────── ──────────────
• 接口边界清晰 • 关联查询复杂
• 可以渐进式重构 • 数据迁移风险高
• 失败影响可控 • 一致性保证困难
• 自动化测试支持好 • 历史数据量大
• IDE 支持完善 • 需要双写/同步机制
难度：★★☆☆☆ 难度：★★★★★
5.1.2 数据库拆分面临的挑战
| 挑战 |
说明 |
影响 |
| 跨表 JOIN |
拆分后无法直接 JOIN |
查询方式彻底改变 |
| 分布式事务 |
跨库事务无法用本地事务 |
数据一致性风险 |
| 数据迁移 |
海量数据从旧库迁移到新库 |
停机时间、数据丢失风险 |
| 引用完整性 |
外键约束跨库无法维护 |
需要应用层保证 |
| 全局查询 |
跨库统计报表困难 |
需要额外方案 |
| 数据冗余 |
可能需要冗余部分数据 |
数据同步复杂 |
5.2 数据库拆分策略
5.2.1 三种拆分模式
┌──────────────────────────────────────────────────────────┐
│ 数据库拆分策略 │
├──────────────────────────────────────────────────────────┤
│ │
│ 模式1：共享数据库 (Anti-Pattern) │
│ ┌────────────────────────────────────┐ │
│ │ 共享数据库 │ │
│ │ ┌──────┐ ┌──────┐ ┌──────┐ │ │
│ │ │用户表│ │订单表│ │商品表│ │ │
│ │ └──────┘ └──────┘ └──────┘ │ │
│ └──────────┬─────────────────────────┘ │
│ ┌────┼────┐ │
│ ▼ ▼ ▼ │
│ 用户 订单 商品 │
│ 服务 服务 服务 │
│ │
│ 模式2：Schema 分离 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ user_db │ │ order_db │ │ product_db│ │
│ │ (同一实例) │ │ (同一实例) │ │ (同一实例) │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ ▲ ▲ ▲ │
│ │ │ │ │
│ 用户服务 订单服务 商品服务 │
│ │
│ 模式3：独立数据库 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 用户DB │ │ 订单DB │ │ 商品DB │ │
│ │ (独立实例) │ │ (独立实例) │ │ (独立实例) │ │
│ │ MySQL │ │ MySQL │ │ ES+Redis │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ ▲ ▲ ▲ │
│ │ │ │ │
│ 用户服务 订单服务 商品服务 │
└──────────────────────────────────────────────────────────┘
5.2.2 推荐的渐进式拆分路径
共享数据库 (现状)
│
▼ 阶段1：逻辑分离
Schema 分离 (同一实例)
│
▼ 阶段2：接口化
通过 API 访问 (不再跨库查询)
│
▼ 阶段3：物理分离
独立数据库实例
│
▼ 阶段4：按需选型
不同服务使用不同类型的数据库
5.3 分库分表
5.3.1 分库策略
| 策略 |
说明 |
适用场景 |
| 垂直分库 |
按业务模块拆分数据库 |
微服务化拆分（本章重点） |
| 水平分库 |
同一业务数据按规则分散到多个库 |
单表数据量超大（>5000 万行） |
垂直分库（按业务拆分）
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 原始DB │ ──▶ │ 用户DB │ │ 订单DB │ │ 商品DB │
│ 用户表 │ │ 用户表 │ │ 订单表 │ │ 商品表 │
│ 订单表 │ │ 地址表 │ │ 订单项表 │ │ 分类表 │
│ 商品表 │ │ 认证表 │ │ 支付表 │ │ 库存表 │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
水平分库（按数据拆分）
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 订单DB │ ──▶ │ 订单DB_0 │ │ 订单DB_1 │
│ (全部订单) │ │ (0-999万) │ │(1000-2000万)│
└──────────┘ └──────────┘ └──────────┘
5.3.2 分表策略
| 策略 |
规则 |
优点 |
缺点 |
| Range 分表 |
按范围（如时间、ID区间） |
扩展简单 |
可能数据不均 |
| Hash 分表 |
按字段 Hash 取模 |
数据均匀 |
扩容困难 |
| 一致性 Hash |
Hash 环 |
扩容友好 |
实现复杂 |
Hash 分表示例（按 user_id % 4）
user_id = 1001 → 1001 % 4 = 1 → order_1
user_id = 1002 → 1002 % 4 = 2 → order_2
user_id = 1003 → 1003 % 4 = 3 → order_3
user_id = 1004 → 1004 % 4 = 0 → order_0
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│order_0 │ │order_1 │ │order_2 │ │order_3 │
│id%4=0 │ │id%4=1 │ │id%4=2 │ │id%4=3 │
└─────────┘ └─────────┘ └─────────┘ └─────────┘
5.3.3 分库分表中间件
| 中间件 |
类型 |
特点 |
适用场景 |
| ShardingSphere |
代理/嵌入 |
Apache 顶级项目，生态完善 |
Java 项目首选 |
| MyCat |
代理 |
独立部署，对应用透明 |
传统架构改造 |
| Vitess |
代理 |
YouTube 开源，K8s 原生 |
大规模 MySQL |
| CockroachDB |
分布式DB |
自动分片，兼容 PostgreSQL |
新项目首选 |
| TiDB |
分布式DB |
兼容 MySQL，HTAP |
大数据量场景 |
5.4 数据同步方案
5.4.1 同步方式总览
| 方式 |
时效性 |
复杂度 |
适用场景 |
| CDC（变更数据捕获） |
准实时 |
中 |
数据库拆分后同步 |
| 事件驱动同步 |
准实时 |
中 |
业务事件触发同步 |
| 定时批量同步 |
分钟级 |
低 |
非实时要求的数据 |
| 双写 |
实时 |
高 |
过渡期方案 |
| API 查询 |
实时 |
低 |
查询量少的场景 |
5.4.2 CDC（Change Data Capture）
CDC 通过监听数据库的变更日志（如 MySQL Binlog）来捕获数据变更，是数据库拆分后数据同步的首选方案。
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 源数据库 │ │ Debezium │ │ Kafka │ │ 目标数据库│
│ MySQL │───▶│ (CDC) │───▶│ (消息) │───▶│ 订单DB │
│ │ │ │ │ │ │ │
│ Binlog │ │ 读取 │ │ 传输 │ │ 消费写入 │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
延迟：< 1 秒
可靠性：高（基于日志，不丢数据）
Debezium 配置示例：
{
"name": "mysql-source-connector",
"config": {
"connector.class": "io.debezium.connector.mysql.MySqlConnector",
"database.hostname": "mysql-source",
"database.port": "3306",
"database.user": "cdc_user",
"database.password": "****",
"database.server.id": "1",
"topic.prefix": "dbserver1",
"database.include.list": "user_db",
"table.include.list": "user_db.users,user_db.addresses"
}
}
5.4.3 事件驱动同步
用户服务 订单服务
┌──────────┐ ┌──────────┐
│ │ UserUpdated │ │
│ 修改用户 │─────────────▶│ 更新本地 │
│ 信息 │ (事件) │ 用户快照 │
└──────────┘ └──────────┘
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│ 用户DB │ │ 订单DB │
│ (权威数据) │ │ (冗余数据) │
└──────────┘ └──────────┘
5.5 数据一致性方案
5.5.1 一致性模型对比
| 模型 |
说明 |
一致性级别 |
性能 |
复杂度 |
| 强一致性 |
写入后立即可读 |
最高 |
最低 |
最高 |
| 最终一致性 |
写入后一段时间可读 |
较高 |
较高 |
中 |
| 因果一致性 |
保证因果关系的顺序 |
中 |
中 |
中 |
5.5.2 跨服务查询的解决模式
问题：订单服务需要查询用户信息，但用户数据在用户服务的数据库中。
方案1：API 调用（推荐）
────────────────────────
订单服务 ──API──▶ 用户服务 ──▶ 用户DB
优点：数据自治 缺点：网络开销、延迟
方案2：数据冗余
────────────────────────
订单服务的DB中冗余用户基本信息（userId, userName）
通过事件订阅保持同步
优点：查询快 缺点：数据可能不一致
方案3：CQRS + 物化视图
────────────────────────
写操作：各服务写自己的DB
读操作：查询聚合视图（ES/数据仓库）
优点：查询灵活 缺点：架构复杂
5.5.3 数据冗余的同步策略
┌──────────────┐ ┌──────────────┐
│ 用户服务 │ │ 订单服务 │
│ │ │ │
│ 更新用户 │ │ 查询订单 │
│ 发布事件: │ │ (含用户信息) │
│ UserUpdated │ │ │
└──────┬───────┘ └──────┬───────┘
│ │
▼ │
┌─────────┐ │
│ Kafka │ │
│ Topic │ │
└────┬────┘ │
│ │
▼ │
┌──────────────┐ │
│ 订单服务 │ │
│ 消费事件 │ │
│ 更新本地 │ │
│ 用户快照 │──────────┘
└──────────────┘
最终一致性窗口：通常 < 1 秒
5.6 业务场景：电商平台的数据库拆分实战
5.6.1 拆分前状态
单库（MySQL）
├── user 表 (500 万行)
├── user_address 表 (800 万行)
├── product 表 (200 万行)
├── product_sku 表 (1000 万行)
├── order 表 (2 亿行)
├── order_item 表 (5 亿行)
├── payment 表 (1 亿行)
└── inventory 表 (1000 万行)
5.6.2 拆分步骤
| 步骤 |
操作 |
验证 |
回滚方案 |
| 1 |
创建独立 Schema (user_db, order_db, …) |
Schema 间无直接访问 |
删除 Schema |
| 2 |
应用层代码改造，通过 Service 访问 |
所有跨模块查询改用 API |
代码回滚 |
| 3 |
部署双写逻辑（写旧库 + 写新库） |
数据一致性校验 |
停止双写 |
| 4 |
切换读路径到新库 |
查询结果一致性 |
切回旧库 |
| 5 |
停止写旧库 |
无数据丢失 |
恢复双写 |
| 6 |
物理分离数据库实例 |
独立运行稳定 |
迁移回单实例 |
| 7 |
清理旧表中的冗余数据 |
业务正常 |
备份恢复 |
5.6.3 数据迁移方案
全量迁移 + 增量同步
┌───────────────┐ ┌───────────────┐
│ 源数据库 │ │ 目标数据库 │
│ MySQL │ │ MySQL │
└───────┬───────┘ └───────▲───────┘
│ │
│ 1. 全量迁移 (DataX/Dumper) │
└──────────────────────────────┘
│ │
│ 2. 增量同步 (Debezium CDC) │
└──────────────────────────────┘
│ │
│ 3. 数据校验 (checksum) │
└──────────────────────────────┘
│ │
│ 4. 切换读写 │
└──────────────────────────────┘
5.7 CQRS 模式
5.7.1 命令查询职责分离
CQRS（Command Query Responsibility Segregation）将读写操作分离到不同的模型中：
┌────────────────────────────────────────────────────┐
│ CQRS 架构 │
├────────────────────────────────────────────────────┤
│ │
│ 写侧 (Command) 读侧 (Query) │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ 命令处理器 │ │ 查询处理器 │ │
│ │ │ │ │ │
│ │ Command ──▶ │ │ Query ──▶ │ │
│ │ Handler │ │ Handler │ │
│ └──────┬───────┘ └──────▲───────┘ │
│ │ │ │
│ ▼ │ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ 写数据库 │ ──同步──▶│ 读数据库 │ │
│ │ (MySQL) │ │ (ES/Redis) │ │
│ └──────────────┘ └──────────────┘ │
│ │
│ 特点：模型优化写入 特点：模型优化查询 │
│ 强一致性 高性能 │
└────────────────────────────────────────────────────┘
5.7.2 适用场景
| 场景 |
是否适用 CQRS |
说明 |
| 读写比例严重不均 |
✅ 适用 |
读远多于写，如商品详情页 |
| 复杂查询需求 |
✅ 适用 |
多维度查询，如报表系统 |
| 简单 CRUD |
❌ 不适用 |
增加复杂度无收益 |
| 强一致性要求 |
⚠️ 需评估 |
CQRS 天然是最终一致性 |
⚠️ 注意事项
- 先优化查询再拆库——很多性能问题加索引、优化 SQL 就能解决
- 避免分布式 JOIN——如果两个表经常 JOIN，考虑放在同一个服务
- 保留数据校验脚本——迁移后务必验证数据完整性
- 考虑时区和编码——迁移时注意字符集和时区的一致性
- 备份！备份！备份！——数据库操作前必须有完整的备份
📖 扩展阅读
- Martin Fowler - DatabasePerService — 每个服务独立数据库的权威描述
- Debezium Documentation — CDC 方案的首选工具
- Apache ShardingSphere — 分库分表中间件
- Designing Data-Intensive Applications — Martin Kleppmann — 数据密集型系统设计
- Microservices Patterns Chapter 7 — Chris Richardson — 数据拆分模式
本章小结
| 要点 |
说明 |
| 拆分路径 |
共享库 → Schema 分离 → 接口化 → 独立库 |
| 数据同步 |
CDC (Debezium) 是准实时同步的首选方案 |
| 一致性 |
最终一致性是常态，强一致性需要特殊处理 |
| 查询模式 |
CQRS + 数据冗余解决跨服务查询问题 |
| 迁移策略 |
全量迁移 + 增量同步 + 数据校验 |
📌 下一章：第 06 章：API 网关 — 统一入口、路由、限流和认证授权。