蓝绿部署
§1摘要与结论
蓝绿部署维护两套尽可能相同、均可承担全量负载的生产环境，任一时刻仅一套承载流量；新版本在另一套环境验证通过后整体切换流量，异常时切回原环境实现快速回滚。
别名：blue-green deployment、蓝绿发布、蓝绿切换、流量切换发布、red-black deployment | 英文：Blue-Green Deployment | 类型：技术 / pattern
§2局部关系图
§3原理 · 为什么
用环境隔离换取发布的可逆性。两套并行环境让新版本先在不影响用户的环境中完成最终测试，确认无误后再一次性把流量切过去；由于旧版本仍完整保留，出问题时可以立即把流量切回，把回滚从「重新部署」简化为「改路由」。这使发布风险从「在唯一的生产环境上冒险」变成「在可随时退回的候选环境上验证」。隔离还带来额外好处：切换前后两套环境可作为容灾演练对象，也便于在切换前用小比例测试流量提前暴露问题。其判据是切换是否整体、回退是否即时，而非部署过程是否复杂；部署本身可以很慢，只要切换与回退足够快，风险就被压在了可控窗口内。这一判断标准也解释了为何部署速度本身不是蓝绿的关键指标：只要两套环境等价且切换可靠，慢部署与快回滚可以并存而不冲突。
§4机制 · 如何运作
通过路由器、负载均衡或 DNS 把入口流量在两套环境之间切换。切换前 green 环境部署新版本并做最终验证，可选以极小比例生产流量做探测；切换通常是一次整体的路由变更。回滚是把路由指回 blue，影响窗口缩小到从发现问题到切回之间，且爆炸半径受导向新环境的流量规模约束。最大难点在有状态层：数据库 schema 必须在切换期间同时兼容新旧两版，通常先把 schema 变更与应用升级分离，在兼容前提下做数据库重构，确认存在回滚点后再部署新版应用，稳定后移除对旧版的支持。该模式与热备机理相同，可在每次发布中演练容灾。部分实现不追求两套独立基础设施，而是在同一批资源上以重启实现切换，隔离性因此弱于真正的双环境。当两套环境共享同一入口标识时，还可借助 DNS 缓存与连接保持等细节保证切换的平滑，避免瞬时流量错乱。
§5工程 · 怎么落地
先保证两套环境尽可能等价，减少「只在 green 复现」的偏差；把环境创建、部署、验证与流量切换都脚本化，避免手工操作引入错误。切换前确认新环境已预热、依赖就绪、监控就位。数据库变更遵循先扩展后收缩的兼容流程，并为切换前后的数据写入建立明确回滚路径。明确切换与回退的判据和负责人，尽量用健康指标驱动而非临场判断。注意识别不适合蓝绿的部分：共享同一数据库或同一故障域的两套「环境」在真实故障中会一起失效，需核对隔离是否真实。切换后应在一段观察窗口内保留旧环境，确认稳定后再退役，避免过早释放退路；同时应及时收缩已无用的兼容代码与旧环境资源，防止过渡态固化为长期负担。还应记录每次切换的时间、版本与健康结果，形成可回溯的发布台账，为事后复盘与审计提供依据。
§6权衡卡
蓝绿让回滚最快、隔离最好，但资源成本约为双份，且新环境需预先具备承担全量负载的能力。
对成本敏感或变更频繁的系统，维持两套全量环境可能不经济，此时渐进暴露式方案往往更合适；而在合规或数据敏感场景，双环境的资源与数据复制还会带来额外治理成本。
总体而言，蓝绿适合变更不极端频繁、且对回滚速度要求高的服务，其价值取决于切换与回退能否真的以自动化和可验证的方式兑现——若切换依赖手工步骤或缺乏健康判据，双环境的成本换来的可逆性会大打折扣。
若无法承担双份资源，则应转向渐进暴露，以更小代价获得相近的风险控制。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7冲突 / 对比表
| 对照维度 | 蓝绿部署 | 金丝雀发布 |
|---|---|---|
| 定位 / 依据层 | 蓝绿部署 · Blue-Green Deployment | 金丝雀发布 · Canary Release |
| 核心定义（原文） | 蓝绿部署维护两套尽可能相同、均可承担全量负载的生产环境，任一时刻仅一套承载流量；新版本在另一套环境验证通过后整体切换流量，异常时切回原环境实现快速回滚。 | 金丝雀发布先把新版本部署到不接用户或仅接少量用户的基础设施上，再按健康指标逐步放大流量与用户比例直至全量，从而把新版本故障的爆炸半径限制在受影响的小范围内。 |
| 首条机制断言（原文） | 用环境隔离换取发布的可逆性。 | 用受控的渐进暴露替代一次性全量风险。 |
| 对照关系 | 整体切换与逐步导流的取舍对照（对照） | 同一条 对照 边的另一端 |
| 典型反例（原文） | 蓝绿让回滚最快、隔离最好，但资源成本约为双份，且新环境需预先具备承担全量负载的能力。 | 金丝雀把爆炸半径压到最小并支持自动回滚，代价是需要同时管理多个并发版本、依赖成熟的流量治理与监控能力，实现与观测成本较高。 |
| 处置要点（原文） | 先保证两套环境尽可能等价，减少「只在 green 复现」的偏差；把环境创建、部署、验证与流量切换都脚本化，避免手工操作引入错误。 | 先建立可观测性基础——没有可信的健康指标，渐进暴露就失去推进与止损的依据。 |
§8案例带
插件 DAG RC5→RC7 升级
一次知识库随上游源码版本升级的级联维护：以三层差异分析把 219 个包收敛为 26 个实质变更包，经编译、运行时、组合三类依赖判定更新 DAG 数据后全量重生成页面，并以静态门控加渲染验证收口。
AI Agent 架构 DAG 复盘
对四个工作日内独立完成三个异构对象 DAG 分析的方法论复盘，总结「采集→建模→生成→门控→交付」可复用管线与关键教训。
§9信源与核验
核验结论：Fowler 页面明确：蓝绿部署名称由 Daniel Terhorst-North 与 Jez Humble 提出，模式本身早已存在，Fowler 仅作介绍 [WEB-032]
核验结论：schema 变更是蓝绿最大难点：应把 schema 变更与应用升级分离，先做兼容新旧版本的数据库重构（expand），验证有回滚点后再部署新版应用，稳定后收缩（contract） [WEB-032]
§10原始关系清单
展开：本节点的全部原始关系边（5 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 组合 | ← TEC-J-01 | Kubernetes 部署编排 E-847 | 编排层支撑蓝绿双环境编排 |
| 对照 | → TEC-J-04 | 金丝雀发布 E-845 | 整体切换与逐步导流的取舍对照 |
| 促成 | ← TEC-J-02 | 不可变基础设施实现 E-843 | 不可变制品使整体切换可行 |
| 实现 | → MTH-J-05 | 渐进暴露部署策略 E-835 | 双环境整体切换的渐进暴露 |
| 实现 | → MTH-J-07 | 可回滚性与爆炸半径控制 E-836 | 切回旧环境实现即时回滚 |