4. 灰度发布概念：灰度发布定义、金丝雀发布、蓝绿部署、滚动更新对比
在策略即代码的审计留痕体系中，灰度发布是触发审计事件的核心场景之一。理解不同发布模式的差异，有助于设计精准的审计日志采集点与留痕策略。本节从定义出发，对比四种主流发布方式。
4.1 灰度发布定义
灰度发布（Canary Release / Gray Release）是一种渐进式的版本上线策略。其核心思想是：让新版本先在一小部分用户或服务器上运行，观察其稳定性与业务指标，确认无误后再逐步扩大范围，直至全量覆盖。
审计留痕关键点： 灰度发布过程中，每一次流量切换、版本回滚、比例调整都应生成不可篡改的审计日志，记录操作人、时间、变更范围、新旧版本标识。
4.2 四种发布模式对比
下表从部署方式、流量切换、回滚速度、审计复杂度四个维度，对比金丝雀发布、蓝绿部署、滚动更新与全量发布（作为基准）。
| 对比维度 | 金丝雀发布 | 蓝绿部署 | 滚动更新 | 全量发布（基准） |
|---|---|---|---|---|
| 部署方式 | 新版本先部署到少量实例（金丝雀） | 同时维护两套完整环境（蓝/绿） | 逐批替换旧实例 | 一次性替换所有实例 |
| 流量切换 | 按比例或按用户标签路由 | 负载均衡器一键切换 | 逐步增加新版本实例权重 | 瞬间全量切换 |
| 回滚速度 | 快（切回旧版本比例） | 极快（切回另一套环境） | 慢（需逐批回退） | 极慢（需全量回滚） |
| 审计复杂度 | 高（需记录比例、用户分组） | 中（记录环境切换事件） | 中（记录批次进度） | 低（记录一次变更） |
| 适用场景 | 功能验证、A/B测试 | 关键业务、要求秒级回滚 | 无状态服务、资源受限 | 低风险、非核心系统 |
审计建议： 金丝雀发布因涉及动态流量比例与用户分组，审计日志字段需额外包含
canary_percent、user_group_id、canary_instance_list，确保可追溯每次灰度决策。
4.3 金丝雀发布详解
金丝雀发布（Canary Release）得名于“矿工带金丝雀检测毒气”的典故。在软件部署中，它是最精细的灰度策略：
- 初始比例： 通常将 1%~5% 的流量导向新版本。
- 监控指标： 错误率、延迟、CPU/内存、业务转化率。
- 自动/手动晋升： 指标稳定则逐步扩大比例，异常则自动回滚。
- 审计留痕： 每次比例调整、用户分组变更、回滚操作均需记录。
常见陷阱： 金丝雀发布若未对用户会话做粘性路由（Sticky Session），可能导致同一用户在多次请求中体验不一致，引发业务投诉。审计日志应记录会话粘性策略的启用状态。
4.4 蓝绿部署详解
蓝绿部署（Blue-Green Deployment）维护两套完全独立的生产环境：
- 蓝环境（Blue）： 当前稳定版本，承载所有流量。
- 绿环境（Green）： 新版本部署就绪，内部验证通过后，通过负载均衡器一键切换流量。
- 回滚： 只需再次切换回蓝环境，秒级完成。
- 审计留痕： 记录环境切换时间、操作人、切换前/后环境状态、健康检查结果。
4.5 滚动更新详解
滚动更新（Rolling Update）是 Kubernetes 等编排平台的默认策略：
- 分批替换： 按批次（如 10% / 批）逐步停止旧实例、启动新实例。
- 最大不可用： 可配置允许同时不可用的最大实例数。
- 回滚： 需反向逐批替换，速度较慢。
- 审计留痕： 记录每批次的开始/结束时间、实例数量、当前进度百分比。
4.6 发布模式流程对比图
下图从流量切换路径角度，对比金丝雀、蓝绿、滚动三种模式的执行流程：
4.7 审计日志字段差异
不同发布模式在审计日志中需要记录的字段存在显著差异。下表列出核心字段：
| 字段 | 金丝雀发布 | 蓝绿部署 | 滚动更新 |
|---|---|---|---|
deploy_mode |
canary | blue_green | rolling |
canary_percent |
5, 10, 50, 100 | N/A | N/A |
user_group_id |
internal_test / vip_users | N/A | N/A |
environment_switch |
N/A | blue→green / green→blue | N/A |
batch_index |
N/A | N/A | 1/10, 2/10, ... |
rollback_trigger |
error_rate > 1% | manual / health_check_fail | manual / batch_fail |
策略即代码实践： 在 CI/CD 流水线中，将上述字段定义为
audit_schema，通过 JSON Schema 或 Protobuf 约束，确保每次发布操作都生成结构一致的审计日志，便于后续审计分析。