渐进暴露部署策略
§1摘要与结论
把新版本分阶段、逐步暴露给更大范围的用户与基础设施，而非一次性全量切换；蓝绿以双环境切换、金丝雀以小比例扩量、滚动以实例渐替，均以健康判据驱动推进。
别名：progressive exposure、蓝绿部署、金丝雀发布、滚动更新 | 英文：Progressive Exposure Deployment Strategies | 类型：方法 / pattern
§2局部关系图
§3原理 · 为什么
任何变更都可能引入故障，而一次性全量切换会把故障在瞬间放大到全体用户，且恢复往往需要重装或重建，代价高昂。渐进暴露的立场是：既然无法保证变更无缺陷，就控制它影响的范围与速度，让失败被限制在小范围内并被及早发现，同时保留一条快速的退路。它把发布的风险从全有或全无，变成可调节的连续量，使团队能够依据真实运行证据决定是否继续扩大暴露，而不是仅凭测试环境的结论下注。风险控制与观测能力因此被绑定在一起：没有健康判据，渐进暴露就失去了推进与停止的依据，只会退化为没有方向的慢速全量。因此，选择策略之前必须先具备可观测性，让每一次放量都有可以信赖的判断依据，并让停止条件在开始之前就被明确。
§4机制 · 如何运作
三种典型形态共享逐步扩大暴露的骨架。蓝绿部署维护两套相同环境，一套承载全量流量，新版本在另一套上完成测试后一次性切换流量，出错即切回。金丝雀先把新版本部署到少量基础设施并导入小比例或特定画像的用户，随信心提升逐步扩大比例，直至全量。滚动更新以新实例逐步替换旧实例，更新期间新旧版本并存，替换节奏由允许的不可用与超出副本的约束控制。三者均以健康模型驱动：每一阶段必须通过健康检查才推进，指标异常立即停止并恢复；旧版本通常在稳定后退役，其资源也随之释放。不同形态可叠加使用，例如先以双环境隔离新版，再以小比例导流验证，最后逐步扩展至全量。无论采用哪种形态，推进节奏都应由健康模型而非固定时间表决定：每一阶段先观察关键指标，达到判据才进入下一阶段，出现异常则立即停止并恢复。观察窗口应覆盖不同时区与使用模式，并以小时或天计，使潜伏较深的问题有时间浮现，而不是仅凭瞬时指标判定成功。
§5工程 · 怎么落地
实践中应先评估爆炸半径、回滚语义、资源成本与有状态复杂度，再选择策略，并允许组合使用，例如以两套环境提供快速切换能力、再以金丝雀方式逐级导流。为每个阶段设定观察窗口，使其覆盖不同时区与使用模式，达到小时或天级，而非瞬时判断。对涉及数据结构的变更，预先做兼容新旧版本的数据库展开与收缩，避免应用切换与结构变更相互耦合。用功能开关辅助控制可见性，并让健康监控在阈值被突破时自动停止推进。退役旧版本时遵循安全的下线顺序，先确认无流量再释放资源，避免误伤仍在处理的请求。这些要求使渐进暴露不仅是一种发布方式，更是一套需要治理与工具的工程能力，其可行性取决于观测、路由与数据兼容三项基础是否齐备。选择策略时还应评估其与组织能力的匹配度：流量路由、灰度发布与数据兼容是三项前提，若其中任何一项缺失，渐进暴露都会退化为没有依据的慢速全量。对涉及用户端安装的软件，应认识其升级时机不由服务方完全掌控，需另做兼容与回退设计。
§6权衡卡
各策略的代价不同：蓝绿需要双份环境，资源成本较高；金丝雀需要同时管理多个并发版本，且对安装在用户端、无法控制升级时机的软件效果有限；滚动更新切换非原子、回滚较慢，故障影响会随时间扩散。
成本也不应被忽视：双环境与多版本并存会抬高资源与运维开销，观测与路由能力本身也需要建设投入。
因此渐进暴露更适用于风险敏感、变化频繁且具备成熟监控的服务；对变更稀疏、影响可控的小系统，简单方式反而更经济，策略选择应以实际风险为准。
反例之一是把金丝雀当作 A/B 测试使用——二者技术实现相似但目的不同，金丝雀用于检测故障与回归，A/B 用于验证假设，混用会干扰 A/B 的统计结论。
反例之二是只切换流量却缺乏健康判据，使渐进暴露退化为没有依据的慢速全量。
反例之三是同时开太多并发版本，导致数据与接口兼容组合爆炸，难以推理与测试。
- 有状态与数据库变更是三者共同的难点，必须让结构同时兼容新旧版本。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7案例带
插件 DAG RC5→RC7 升级
一次知识库随上游源码版本升级的级联维护：以三层差异分析把 219 个包收敛为 26 个实质变更包，经编译、运行时、组合三类依赖判定更新 DAG 数据后全量重生成页面，并以静态门控加渲染验证收口。
MCP 四件套选型对比
对四个同类 MCP 服务器做源码级能力与成本对比，并以常驻 token 预算为轴给出分级接入策略的技术选型实战案例。
AI Agent 架构 DAG 复盘
对四个工作日内独立完成三个异构对象 DAG 分析的方法论复盘，总结「采集→建模→生成→门控→交付」可复用管线与关键教训。
§8信源与核验
核验结论：Fowler 页面明确说明，蓝绿部署的名称由 Daniel Terhorst-North 与 Jez Humble 提出，模式本身早已存在，Fowler 仅作介绍 [WEB-032]
§9原始关系清单
展开：本节点的全部原始关系边（7 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 依赖关联 | → MTH-J-06 | 发布与部署解耦 E-531 | 渐进暴露依赖发布与部署解耦 |
| 依据推导 | → ESS-J-04 | 部署即变更管理 E-527 | 渐进暴露依据部署即变更管理 |
| 促成 | → MTH-J-07 | 可回滚性与爆炸半径控制 E-532 | 渐进暴露策略支撑爆炸半径控制 |
| 实现 | ← TEC-G-03 | Azure 架构中心 E-884 | Azure 安全部署落地渐进暴露策略 |
| 实现 | ← TEC-J-01 | Kubernetes 部署编排 E-831 | K8s 滚动更新实现渐进暴露 |
| 实现 | ← TEC-J-03 | 蓝绿部署 E-835 | 双环境整体切换的渐进暴露 |
| 实现 | ← TEC-J-04 | 金丝雀发布 E-837 | 按健康指标逐步扩大流量暴露 |