4. 版本对齐原则：数据库版本与应用程序版本的对齐策略

在微服务与持续交付的架构中，数据库版本与应用程序版本之间的对齐是迁移成功的关键。版本对齐的核心目标是：确保数据库 Schema 的变更与应用程序代码的发布保持兼容性，并支持灰度发布与安全回滚。本章将深入探讨版本对齐的三大支柱：兼容性策略、灰度发布流程与回滚机制。

4.1 版本对齐的兼容性策略

数据库版本与应用程序版本之间的兼容性分为两类：向前兼容（新数据库兼容旧应用）与向后兼容（旧数据库兼容新应用）。在实际迁移中，通常要求数据库变更同时满足这两种兼容性，以支持零停机发布。

4.2 灰度发布中的版本对齐流程

灰度发布（Canary Release）要求数据库版本与应用版本在多个服务实例间逐步对齐。以下是一个典型的灰度发布流程，包含数据库版本与应用程序版本的协同步骤：

1. 准备过渡 Schema：在数据库中创建新字段或新表，保持旧结构不变。
2. 灰度应用实例：将少量应用实例（如 5%）升级到新版本，新实例读写过渡 Schema。
3. 数据双写与校验：灰度实例同时写入旧字段与新字段，对比数据一致性。
4. 逐步扩大灰度：根据监控指标（错误率、延迟、数据一致性）逐步增加灰度实例比例。
5. 全量切换：当灰度比例达到 100% 后，执行数据库迁移脚本，废弃旧字段。
6. 清理过渡结构：在确认无回滚需求后，删除过渡字段或表。

4.3 回滚机制：数据库版本与应用程序版本的回滚对齐

回滚是版本对齐策略中不可忽视的一环。数据库回滚比应用回滚更复杂，因为数据状态可能已经改变。以下是三种常见的回滚策略：

4.4 版本对齐的自动化工具与脚本示例

为了实现版本对齐的自动化，推荐使用数据库迁移工具（如 Flyway、Liquibase）结合 CI/CD 流水线。以下是一个使用 Flyway 进行版本对齐的迁移脚本示例：

-- V2__add_user_status.sql (迁移脚本)
-- 向前兼容：新字段允许 NULL
ALTER TABLE users ADD COLUMN status VARCHAR(20) DEFAULT 'active';

-- 向后兼容：旧应用读取时忽略该字段
-- 新应用写入时同时更新 status 字段

-- V2__rollback.sql (回滚脚本)
ALTER TABLE users DROP COLUMN status;

在 CI/CD 流水线中，版本对齐的检查逻辑通常包含以下步骤：

• Schema 兼容性检查：使用工具（如 pt-online-schema-change）验证变更是否破坏向前/向后兼容。
• 应用版本映射：在配置中心维护数据库版本与应用程序版本的映射表，确保灰度实例使用正确的数据库版本。
• 自动回滚触发：当监控指标超过阈值时，自动执行回滚脚本并回退应用版本。

4.5 版本对齐的常见陷阱与避坑指南

• 陷阱 1：忽略 NOT NULL 约束 — 添加 NOT NULL 列会导致旧应用插入数据失败。解决方案：先添加允许 NULL 的列，填充默认值后再添加约束。
• 陷阱 2：修改列类型 — 修改列类型（如 VARCHAR→INT）会破坏向前兼容。解决方案：创建新列，双写数据，逐步迁移。
• 陷阱 3：删除未使用的列 — 即使当前无应用使用，回滚后旧应用可能仍需读取。解决方案：标记废弃列，至少保留一个发布周期。
• 陷阱 4：忽略索引变更 — 添加或删除索引会影响查询性能，导致灰度实例响应变慢。解决方案：在灰度前使用 pt-upgrade 测试索引变更对查询计划的影响。