发布策略​

发布策略 ​让发布"可控、可观察、可回滚" 发布的两难 ​快速迭代 ←──────────→ 风险可控 ↑ ↑ 按需发布 全量+人工审批发布策

发布策略 ​让发布"可控、可观察、可回滚"

发布的两难 ​快速迭代 ←──────────→ 风险可控

↑ ↑

按需发布 全量+人工审批发布策略 = 在两者之间找平衡。

主流策略对比 ​策略风险复杂度回滚速度适用重启发布高低慢内部工具滚动更新中低中普通业务蓝绿部署低中秒级关键业务金丝雀低高中高流量A/B 测试低高中功能实验影子流量极低高N/A验证新版本1. 滚动更新（Rolling Update） ​逐步替换旧实例：

[v1][v1][v1][v1] → [v1][v1][v1][v2] → ... → [v2][v2][v2][v2]优：简单、资源不翻倍缺：新旧版本并存有兼容性问题、回滚慢

K8s 默认就是这种策略。

2. 蓝绿部署（Blue-Green） ​两套环境，切换流量：

路由器 ──→ [蓝 v1] (生产)

[绿 v2] (待命)

切换：

路由器 ──→ [蓝 v1] (待命)

[绿 v2] (生产)优：

秒级回滚（切回去就行）没有版本并存缺：

资源翻倍数据库 schema 变更需小心3. 金丝雀发布（Canary） ​少量流量验证：

99% → [v1]

1% → [v2] 监控

↓

10% → [v2] 监控

50% → [v2] 监控

100% → [v2]关键：基于指标自动晋级 / 回滚（错误率、延迟、业务指标）。

工具：

Argo Rollouts（K8s）Flagger（K8s）Spinnaker云原生（AWS CodeDeploy、Azure Deployment Slots）4. 特性开关（Feature Flags） ​代码已发布，但功能开关控制：

typescriptif (await flags.isEnabled('new-checkout', userId)) {

return newCheckout()

}

return oldCheckout()好处：

发布 ≠ 启用，解耦可以按用户/区域/灰度比例开出问题秒关，不需要回滚部署支持 A/B 测试工具：

LaunchDarkly（商业）Unleash（开源）Flagsmith（开源/SaaS）自建（Redis + 配置中心）5. 影子流量（Shadow / Mirror） ​把生产流量复制一份给新版本，不影响用户：

用户 ──→ [v1] ──→ 用户

│

└─复制──→ [v2] (响应丢弃)用途：性能验证、新算法对比

数据库变更与发布 ​铁律：数据库变更必须前向兼容，分两步走。

错误： ​1. 改代码同时删字段 → 旧版本崩正确： ​Step 1: 加新字段（旧代码继续用旧字段）

Step 2: 双写新旧字段

Step 3: 全量回填新字段

Step 4: 切读到新字段

Step 5: 停止写旧字段

Step 6: 删除旧字段（确认无引用）回滚策略 ​类型方式时间蓝绿切流量秒级金丝雀停止晋级 + 缩回分钟滚动反向部署数分钟Feature Flag关闭开关秒级数据库极困难小时-永远原则：

✅ 始终保留前一版本镜像✅ 一键回滚命令准备好❌ 不靠"修一下再发布"作为回滚SLO 驱动的自动回滚 ​yaml# Argo Rollouts canary 示例

spec:

strategy:

canary:

steps:

- setWeight: 5

- pause: { duration: 5m }

- analysis:

templates:

- templateName: error-rate

args:

- name: threshold

value: "0.01" # 错误率 > 1% 自动回滚

- setWeight: 25

- pause: { duration: 10m }

- setWeight: 100发布窗口与频率 ​反模式：周五下午发布、攒一个月发一次

推荐：

越频繁越好（小批量）工作日早上 / 上午发重大变更避开高峰有"代码冻结期"（如双十一）检查清单（每次发布） ​[ ] 通过所有测试与质量门禁[ ] 已在 staging 验证[ ] 数据库变更前向兼容[ ] 关键变更有 Feature Flag[ ] 监控告警准备好[ ] 回滚方案明确[ ] On-Call 人员在线[ ] 选择合适时间窗口[ ] 通知相关团队[ ] 上线后 30 分钟密切观察反模式 ​反模式风险解决周五大版本发布周末出问题没人小批量周一到周四没有灰度直接全量影响所有用户金丝雀 / Feature Flag数据库改完再改代码死锁、崩溃前向兼容、双写没有回滚预案出事手忙脚乱演练回滚靠"hotfix 再发"回滚雪上加霜真正的回滚机制关键决策 ​问题推荐用哪种策略？普通业务滚动；关键业务蓝绿 + Feature Flag灰度多久？至少覆盖一个完整业务周期（白天 + 晚上）自动晋级 vs 人工？有完善监控 → 自动；否则人工出问题先回滚还是先排查？永远先回滚，再慢慢分析