1. 迁移架构总览：数据库迁移的背景、核心挑战、服务边界与版本对齐的概念
1.1 数据库迁移的背景与驱动力
在微服务架构与持续交付成为主流的今天，数据库迁移不再是偶发的运维动作，而是贯穿软件生命周期的常态化操作。迁移的驱动力主要来自以下四个维度：
| 驱动力 | 典型场景 | 迁移频率 |
|---|---|---|
| 业务演进 | 新增功能需要扩展表结构、添加索引或拆分字段 | 高（每次迭代） |
| 技术升级 | 数据库版本升级、存储引擎更换、云原生迁移 | 中（季度/半年） |
| 架构重构 | 单体拆分为微服务、分库分表、读写分离 | 低（年度/里程碑） |
| 合规与治理 | 数据脱敏、字段加密、审计日志追加 | 中（按合规周期） |
实践观察： 在日均发布超过 10 次的中大型团队中，数据库迁移脚本的提交频率已接近应用代码的 1/3。迁移不再是"大爆炸"式项目，而是"小步快跑"的日常操作。
1.2 核心挑战：为什么数据库迁移如此困难？
数据库迁移的复杂性远高于应用代码变更，其核心挑战可归纳为以下五点：
- 状态持久性 — 数据库是有状态的，迁移失败可能导致数据丢失或不一致，回滚成本极高。
- 服务耦合 — 多个微服务共享同一数据库实例时，一个服务的迁移可能影响其他服务的查询与写入。
- 版本漂移 — 不同环境的数据库 schema 版本不一致，导致迁移脚本执行顺序错乱或重复执行。
- 零停机要求 — 生产环境迁移必须在服务不中断的前提下完成，对迁移策略提出极高要求。
- 团队协作摩擦 — 多个团队同时修改同一数据库，schema 变更冲突频繁发生。
常见误区： 将数据库迁移视为"一次性脚本任务"，缺乏版本管理和回滚预案。据统计，超过 60% 的生产事故与未经验证的数据库迁移直接相关。
1.3 服务边界：数据库归属与所有权模型
在微服务架构中，数据库的服务边界决定了哪个团队拥有对特定表或 schema 的修改权限。清晰的服务边界是避免迁移冲突的前提。
核心原则： 每个微服务应拥有自己的数据库或 schema，其他服务只能通过 API 访问数据，不能直接操作其数据库。
常见的服务边界模型有三种：
| 模型 | 描述 | 适用场景 | 迁移风险 |
|---|---|---|---|
| 数据库级隔离 | 每个服务拥有独立数据库实例 | 大型团队、独立部署 | 低 |
| Schema 级隔离 | 共享数据库实例，但每个服务使用独立 schema | 中型团队、资源受限 | 中 |
| 表级隔离 | 共享数据库和 schema，通过表名前缀区分归属 | 小型团队、快速原型 | 高 |
1.4 版本对齐：迁移脚本与应用程序的协同
版本对齐是指数据库 schema 的版本与部署的应用代码版本保持一致的演进节奏。当应用代码新增功能需要新的表或字段时，数据库迁移脚本必须与代码同时发布，且执行顺序正确。
版本对齐的核心要素包括：
- 迁移脚本版本化 — 每个迁移文件使用时间戳或序列号命名，确保全局唯一且有序。
- 幂等性保障 — 同一迁移脚本在相同状态下多次执行结果一致，避免重复执行导致错误。
- 向前兼容 — 新版本的 schema 必须兼容旧版本的应用代码，支持灰度发布和回滚。
- 向后兼容 — 旧版本的 schema 必须能被新版本的应用代码正确读取（通常通过视图或默认值实现）。
版本对齐黄金法则： 数据库迁移脚本与应用代码应同时提交、同时构建、同时部署。任何一方滞后都会导致运行时错误。
1.5 迁移架构全景图
将服务边界与版本对齐两个概念融合，就构成了完整的数据库迁移架构。下图展示了从代码提交到生产部署的全链路：
1.6 本章小结
数据库迁移架构的核心在于服务边界与版本对齐两个概念的有机结合。服务边界解决了"谁可以改什么"的权限问题，版本对齐解决了"什么时候改"的时序问题。两者缺一不可：
- 只有服务边界没有版本对齐 → 各团队各自为政，schema 版本混乱，部署时冲突频发。
- 只有版本对齐没有服务边界 → 迁移脚本集中管理，但团队间耦合严重，变更效率低下。