3、数据库灰度发布架构
数据库灰度发布的核心挑战在于：流量可以灰度，数据状态难以灰度。应用层的灰度通过负载均衡和实例分组即可实现，但数据库作为有状态层，其 Schema 变更、数据迁移和读写分离策略必须与上游流量协同，才能保证灰度期间的数据一致性与回滚能力。
本章从整体架构出发，依次拆解流量路由层、数据库代理层和应用层的协同机制，帮助学员建立完整的灰度发布技术视图。
3.1 灰度发布整体架构图
下图展示了数据库灰度发布的四层架构：从客户端入口到数据库存储层，每一层都承担特定的灰度路由与隔离职责。
架构要点：灰度发布不是单点改造，而是从入口到存储的端到端协同。流量路由层决定“谁进灰度”，应用层决定“灰度逻辑”，数据库代理层决定“灰度数据落在哪里”，存储层保证“灰度数据可隔离、可回滚”。
3.2 流量路由层
流量路由层是灰度发布的第一道关卡，负责将用户请求按规则分发到不同的应用实例组。常见的路由策略包括：
| 路由策略 | 实现方式 | 适用场景 | 风险等级 |
|---|---|---|---|
| 权重路由 | Nginx / 网关按比例分发（如 5% → 灰度组） | 小流量验证、性能压测 | 低 |
| Header/Cookie 路由 | 根据灰度标识（x-gray-version）路由 | 内部员工、白名单用户 | 低 |
| IP 段路由 | 按客户端 IP 哈希或 CIDR 匹配 | 地域灰度、运营商灰度 | 中 |
| 参数路由 | 根据 URL 参数或请求体字段路由 | 特定功能灰度、A/B 测试 | 中 |
| 全量路由 + 熔断 | 先全量接入，发现异常后熔断回滚 | 紧急修复、快速回退 | 高 |
常见误区：流量路由层只做分发，不做数据隔离判断。灰度请求可能携带不同的数据库上下文（如 tenant_id、gray_flag），这些上下文需要透传到下游代理层，由代理层决定使用哪个数据库目标。不要在路由层硬编码数据库连接信息。
3.3 数据库代理层
数据库代理层（DB Proxy）是灰度发布的核心枢纽。它接收应用层发来的 SQL 请求，根据灰度上下文将请求路由到正确的数据库实例。代理层需要具备以下能力：
- 灰度上下文感知：从 SQL 注释、会话变量或连接属性中提取灰度标识。
- 多目标路由：支持将灰度 SQL 路由到影子库、灰度库或回滚库。
- 读写分离增强：灰度流量可强制走从库或指定实例，避免影响主库。
- SQL 审计与拦截：对灰度期间的 DDL/DML 进行语法校验和风险拦截。
- 动态配置热加载：灰度规则变更无需重启代理进程。
以下是一个典型的代理层灰度路由配置示例：
# db-proxy-gray-route.yaml
gray_rules:
- name: "v2-schema-migration"
match:
session_variable: "gray_version = 'v2'"
target:
write: "mysql-gray-write:3306"
read: "mysql-gray-read:3306"
fallback:
write: "mysql-prod-write:3306"
read: "mysql-prod-read:3306"
audit:
enabled: true
block_ddl: true
block_dml_without_where: true
关键设计：代理层必须提供 fallback 回退路径。当灰度库不可用或 SQL 执行异常时，代理应自动将请求降级到生产库，避免灰度故障影响全部用户。回退逻辑需要配合应用层的重试与超时策略。
3.4 应用层协同
应用层是灰度逻辑的执行者，需要与代理层紧密配合。应用层的主要职责包括：
| 协同维度 | 应用层行为 | 代理层配合 |
|---|---|---|
| 灰度标识传递 | 在数据库连接或 SQL 注释中注入灰度版本号 | 解析标识并路由到对应库 |
| 事务一致性 | 灰度事务内所有 SQL 必须路由到同一目标库 | 提供连接绑定（connection binding） |
| 数据回滚 | 灰度实例记录变更日志，支持反向 SQL 生成 | 提供快照读或时间点恢复接口 |
| 监控与告警 | 上报灰度 SQL 执行耗时、错误率、影响行数 | 暴露代理侧连接池、路由命中率指标 |
| 灰度开关 | 通过配置中心动态开启/关闭灰度逻辑 | 实时更新路由规则 |
应用层与代理层的协同流程可以用下图表示：
协同最佳实践：应用层在发起数据库连接时，通过
SET @gray_version = 'v2' 或 JDBC 连接属性传递灰度标识。代理层解析该标识后，为该连接绑定目标库组，并保证同一事务内的所有 SQL 路由到同一目标。灰度结束后，应用层只需移除灰度标识，流量自动切回生产库，无需重启代理。
3.5 三层协同的灰度发布流程
一次完整的数据库灰度发布，需要三层按以下步骤协同：
- 准备阶段：在数据库存储层创建灰度库或影子库，执行 Schema 变更（如新增字段、修改索引）。
- 配置阶段：在数据库代理层添加灰度路由规则，指定灰度标识与目标库的映射关系。
- 灰度上线：流量路由层将小部分流量（如 5%）导向灰度应用实例组，灰度实例在连接中注入灰度标识。
- 验证阶段：代理层将灰度 SQL 路由到灰度库，同时记录审计日志和性能指标。应用层验证数据正确性和功能完整性。
- 灰度放量：逐步提高灰度流量比例（10% → 50% → 100%），每阶段持续监控代理层错误率和延迟。
- 灰度完成：灰度库数据同步至生产库（或直接切换 Schema），移除代理层灰度规则，清理灰度实例组。
- 回滚预案：若任一阶段发现问题，流量路由层立即将灰度流量切回稳定实例组，代理层将灰度库标记为只读或直接切换 fallback 路径。
回滚注意事项：数据库灰度回滚比应用层回滚更复杂。如果灰度期间执行了 DDL（如新增字段），回滚时需要执行反向 DDL（如删除字段），且必须确认没有灰度数据残留。建议在灰度前对生产库做一次全量快照或使用逻辑备份，确保回滚路径完整。