蓝绿部署、金丝雀发布、滚动发布有什么区别？灰度发布怎么做？

简化版

这些都是「怎么把新版本安全地发布到线上、尽量不影响用户、出问题能快速回滚」的发布策略，区别在「怎么切换流量、影响范围多大、回滚多快」：① 蓝绿部署（Blue-Green）——准备两套完全相同的环境（蓝=旧版、绿=新版），新版部署到绿环境、测试通过后一次性把全部流量从蓝切到绿；出问题切回蓝即可（回滚极快）；缺点是要双倍资源。② 金丝雀发布（Canary）——新版先只给一小部分用户/流量（如 5%），观察没问题再逐步扩大（5%→20%→50%→100%）；像「金丝雀试毒」，用小范围试错、控制爆炸半径；出问题只影响那一小部分。③ 滚动发布（Rolling）——逐批替换实例（一次换几个：v1 停一部分、起 v2，再换下一批），不用双倍资源，但发布过程中新旧版本并存。④ 灰度发布——通常是金丝雀的泛称/延伸，指「按一定规则（比例、用户标签、地域）让部分用户先用新版」，逐步放量。核心区别：蓝绿=整体切换（快但费资源）、金丝雀/灰度=按比例逐步放量（控制风险）、滚动=逐批替换（省资源但新旧并存）。

详细版

四种发布策略对比：

策略	怎么做	资源	回滚	影响范围
蓝绿部署	两套环境，一次性全量切换	双倍	极快（切回旧）	切换瞬间全量
金丝雀发布	先小流量，逐步放量	少量额外	快（撤掉金丝雀）	逐步扩大（先小）
滚动发布	逐批替换实例	无额外	较慢（逐批回滚）	逐批（新旧并存）
灰度发布	按规则让部分用户先用（金丝雀泛称）	少量	快	按规则控制

蓝绿部署：
  [蓝环境 v1] ←100%流量        部署v2到绿→测试
  [绿环境 v2]                   →一次性切流量→
  [蓝环境 v1]                   [绿环境 v2] ←100%流量（切换完成）
  出问题→切回蓝（秒级回滚）

金丝雀/灰度：
  v1 ←95%    v2 ←5%     观察OK→   v1 ←80%   v2 ←20%   →...→ v2 ←100%
  出问题→把 5% 切回 v1（只影响这 5%）

滚动发布（4个实例）：
  [v1][v1][v1][v1] → [v2][v1][v1][v1] → [v2][v2][v1][v1] → ... → [v2][v2][v2][v2]
  逐批替换，过程中新旧并存

⚠️ 选择发布策略的核心是权衡「资源成本、回滚速度、风险控制」三者：蓝绿部署回滚最快（切回旧环境秒级）、但要双倍资源（两套环境同时在跑），适合「不能容忍长时间故障、资源充足、要求快速回滚」的关键系统。金丝雀/灰度****风险控制最好（新版先给一小撮用户，出问题爆炸半径小），适合「新功能不确定、要小范围验证」的场景，但发布周期长（要逐步放量观察）。滚动发布****最省资源（不用双倍环境、逐批替换）、是 K8s 的默认策略，但发布过程中新旧版本并存（要保证新旧版本兼容，尤其数据库/接口的兼容性）。实践中常组合使用：比如「金丝雀 + 滚动」——先金丝雀验证一小部分，通过后再滚动全量替换。还有一个隐藏前提：要能快速回滚（新版本要向后兼容，别做不可逆的数据库变更）。

完整版教学

一、为什么需要发布策略

先理解「安全发布」的诉求：

发布新版本的风险：
  直接把线上全部换成新版（"一刀切"发布）：
    如果新版有 bug → 全部用户立刻受影响 → 大故障
    回滚也慢（要重新部署旧版）

想要的（安全发布的目标）：
  ① 尽量不影响用户（发布过程用户无感或影响小）
  ② 控制风险（出问题只影响小范围，不是全量）
  ③ 快速回滚（发现问题能立刻退回旧版）
  ④ 可观察（发布过程能监控新版表现）

所以需要"发布策略"——不是简单粗暴地全量替换，
  而是有控制、可回滚、可观察地发布

不同策略在"资源、速度、风险控制"上各有侧重：
  蓝绿：快速回滚（双倍资源）
  金丝雀/灰度：风险控制（小范围试错）
  滚动：省资源（逐批替换）

发布策略要解决「安全发布」——直接全量替换（一刀切）的风险是「新版有 bug 全部用户立刻受影响、回滚慢」。安全发布的目标：尽量不影响用户、控制风险（出问题只影响小范围）、快速回滚、可观察。所以需要「有控制、可回滚、可观察」的发布策略，不同策略在「资源、速度、风险控制」上各有侧重。理解「一刀切发布风险(新版 bug 全部受影响+回滚慢)、安全发布目标:不影响用户/控制风险/快速回滚/可观察、需要有控制可回滚的发布策略」，就理解了为什么需要发布策略。

二、蓝绿部署：整体切换

蓝绿部署——两套环境、一次性切换：

蓝绿部署（Blue-Green Deployment）：
  准备两套完全相同的生产环境：
    蓝环境（Blue）：当前运行的旧版本 v1（100% 流量）
    绿环境（Green）：闲置或用来部署新版本

  发布流程：
    1. 把新版本 v2 部署到绿环境
    2. 在绿环境测试、验证（此时绿环境不接生产流量）
    3. 验证通过 → 把流量从蓝一次性切到绿（改路由/负载均衡）
       → 此刻用户全部走 v2
    4. 蓝环境保留一段时间（作为回滚备份）
    5. 稳定后，蓝环境可用于下次发布（角色互换）

回滚：
  发现 v2 有问题 → 把流量切回蓝环境（v1）
  → 秒级回滚（蓝环境一直在跑，切路由即可）

优点：
  ① 回滚极快（切回旧环境）
  ② 发布干净（切换瞬间完成，不是新旧混合）
  ③ 可在绿环境充分测试再切
缺点：
  ① 双倍资源（两套环境同时存在）
  ② 切换瞬间是全量（如果 v2 有问题，切过去全量受影响，
     但能立刻切回）

蓝绿部署——两套完全相同的环境（蓝=旧 v1 接 100% 流量、绿=部署新 v2），流程：部署 v2 到绿环境 → 绿环境测试验证（不接生产流量）→ 一次性把流量从蓝切到绿（改路由）→ 蓝环境保留作回滚备份。回滚：切回蓝环境秒级（蓝一直在跑）。优点：回滚极快、发布干净（切换瞬间完成）、可充分测试再切；缺点：双倍资源、切换瞬间全量（v2 有问题全量受影响但能立刻切回）。理解「蓝绿:两套环境(蓝旧绿新)、部署 v2 到绿测试→一次性切流量到绿→蓝保留回滚;回滚切回蓝秒级;优点回滚快发布干净、缺点双倍资源+切换瞬间全量」，就掌握了蓝绿部署。

三、金丝雀发布：小范围试错

金丝雀发布——先小流量、逐步放量：

金丝雀发布（Canary Release）：
  名字来源：矿工带金丝雀下矿，金丝雀对毒气敏感、先出事 → 预警
  → 用一小部分（金丝雀）先试，出问题先在小范围暴露

发布流程（逐步放量）：
  1. 新版 v2 先只接一小部分流量（如 5%）
     大部分（95%）还是 v1
  2. 观察 v2 的表现（监控错误率、延迟、业务指标）
  3. 没问题 → 逐步扩大 v2 的流量比例：5% → 20% → 50% → 100%
     每一步都观察
  4. 直到 v2 接管全部流量、v1 下线

回滚：
  某一步发现 v2 有问题 → 把这部分流量切回 v1
  → 只影响那一小部分用户（爆炸半径小）

优点：
  ① 风险控制最好——新版先小范围验证，出问题影响小
  ② 渐进式——每步观察，有问题及时止损
  ③ 用真实流量验证（比测试环境更真实）
缺点：
  ① 发布周期长（要逐步放量、逐步观察）
  ② 新旧版本并存期间要兼容
  ③ 需要精细的流量控制（按比例路由）

怎么分流量：
  按比例（5% 流量到 v2）、按用户标签（内部员工先用）、
  按地域（某地区先用）等

金丝雀发布（矿工带金丝雀试毒预警）——新版先只接一小部分流量（5%），观察没问题再逐步放量（5%→20%→50%→100%，每步观察），直到 v2 接管全部。回滚：某步发现问题切回 v1，只影响那一小部分（爆炸半径小）。优点：风险控制最好（小范围验证）、渐进式（每步观察及时止损）、真实流量验证；缺点：发布周期长、新旧并存要兼容、需精细流量控制。分流量方式：按比例/按用户标签/按地域。理解「金丝雀:新版先小流量(5%)观察→逐步放量(5→20→50→100%)每步观察;回滚切回 v1 只影响小部分(爆炸半径小);优点风险控制最好+渐进+真实流量、缺点周期长+要兼容;分流量按比例/标签/地域」，就掌握了金丝雀发布。

四、滚动发布：逐批替换

滚动发布——逐批替换实例，K8s 默认：

滚动发布（Rolling Update）：
  逐批替换实例，不用双倍环境
  假设有 4 个实例都是 v1：
    [v1][v1][v1][v1]
  发布过程（逐批换）：
    停 1 个 v1、起 1 个 v2：[v2][v1][v1][v1]
    再换一批：              [v2][v2][v1][v1]
    继续：                  [v2][v2][v2][v1]
    完成：                  [v2][v2][v2][v2]
  → 一批批地把 v1 换成 v2，直到全部替换

K8s 的默认策略就是滚动更新：
  maxSurge（最多多起几个新的）、maxUnavailable（最多几个不可用）
  控制替换的节奏

优点：
  ① 无额外资源（不用双倍环境，就在原有实例上逐批换）
  ② 平滑（一批批换，不是一刀切）
缺点：
  ① 发布过程中新旧版本并存（v1 和 v2 同时在跑）
     → 要保证新旧兼容（接口、数据库结构兼容）
  ② 回滚较慢（要逐批换回 v1）
  ③ 发布过程中有一段时间容量下降（有实例在替换）

滚动 vs 蓝绿：
  滚动：省资源、新旧并存、逐批
  蓝绿：双倍资源、整体切换、回滚快

滚动发布（K8s 默认）——逐批替换实例（4 个 v1 实例：停 1 个 v1 起 1 个 v2 → 逐批换 → 全部 v2），不用双倍环境。K8s 用 maxSurge/maxUnavailable 控制节奏。优点：无额外资源（原实例逐批换）、平滑；缺点：发布过程新旧版本并存（要保证兼容）、回滚较慢（逐批换回）、发布中容量下降。滚动 vs 蓝绿：滚动省资源/新旧并存/逐批、蓝绿双倍资源/整体切换/回滚快。理解「滚动:逐批替换实例(停 v1 起 v2 逐批)、K8s 默认(maxSurge/maxUnavailable);优点无额外资源+平滑、缺点新旧并存要兼容+回滚慢+容量下降;vs 蓝绿省资源但新旧并存」，就掌握了滚动发布。

五、灰度发布与流量控制

灰度发布——金丝雀的泛称，按规则放量：

灰度发布（Gray Release）：
  通常是金丝雀发布的泛称/延伸——
  "让一部分用户先用新版，逐步扩大到全部"

  和金丝雀的关系：
    金丝雀通常指"按比例小流量试错"
    灰度是更泛的说法，强调"按规则逐步放量"
    → 二者概念高度重叠，实践中常混用

灰度的分流规则（比金丝雀更强调"按规则"）：
  ① 按比例：5% 流量到新版
  ② 按用户标签：内部员工、白名单用户、VIP 先用
  ③ 按地域：某个城市/地区先用
  ④ 按设备/客户端版本：某版本 App 先用
  ⑤ 按请求特征：带某个 header 的走新版

实现（微服务里怎么控制流量）：
  ① 网关/负载均衡按规则路由（比例、header、用户标签）
  ② 服务网格（Istio）的流量管理（VirtualService 按权重/规则）
  ③ 注册中心 + 元数据（灰度标签）+ 路由规则
     （如 Nacos 的灰度、Dubbo 的路由规则、Spring Cloud 的灰度）

所以灰度发布 = 按规则让部分用户先用新版、逐步放量、精细控制风险
  是金丝雀思想的具体落地（强调分流规则和流量控制）

灰度发布（金丝雀的泛称/延伸）——「让一部分用户先用新版、逐步扩大」。和金丝雀高度重叠（金丝雀强调「按比例小流量」、灰度强调「按规则逐步放量」，实践常混用）。分流规则：按比例、按用户标签（内部员工/白名单/VIP）、按地域、按设备/客户端版本、按请求特征（header）。实现：网关/负载均衡按规则路由、服务网格（Istio）流量管理、注册中心+灰度标签+路由规则（Nacos/Dubbo/Spring Cloud 灰度）。理解「灰度发布(金丝雀泛称):让部分用户先用逐步放量、分流规则按比例/用户标签/地域/设备/header、实现靠网关路由/Istio/注册中心灰度标签」，就掌握了灰度发布。

六、选择与组合

总结怎么选、以及组合使用：

选择（按需求）：
  要求快速回滚、资源充足、关键系统 → 蓝绿部署
  新功能不确定、要小范围验证、控制风险 → 金丝雀/灰度
  省资源、能接受新旧并存、常规发布 → 滚动发布（K8s 默认）
  按人群/地域精细放量 → 灰度发布（按规则）

组合使用（实践常见）：
  金丝雀 + 滚动：
    先金丝雀验证一小部分（小流量观察）
    通过后再滚动全量替换（省资源地铺开）
  蓝绿 + 金丝雀：
    绿环境先接一小部分流量（金丝雀式验证）
    再逐步全量切换

三个关键前提（任何策略都要）：
  ① 可回滚——新版本要向后兼容，别做不可逆的变更
     （尤其数据库：加字段兼容、别删字段/改类型）
  ② 可观察——发布过程要监控（错误率、延迟、业务指标）
     才能判断"新版好不好、要不要继续/回滚"
  ③ 新旧兼容——滚动/金丝雀期间新旧并存，接口和数据要兼容

一句话：
  蓝绿=整体切换（快但费资源）、金丝雀/灰度=按比例/规则逐步放量
  （控制风险）、滚动=逐批替换（省资源但新旧并存）；
  实践常组合，前提是可回滚+可观察+新旧兼容

选择（按需求）：快速回滚/资源充足/关键系统→蓝绿；新功能不确定/小范围验证→金丝雀/灰度；省资源/常规发布→滚动（K8s 默认）；按人群/地域精细放量→灰度。组合使用：金丝雀+滚动（先金丝雀验证再滚动全量）、蓝绿+金丝雀。三个关键前提（任何策略都要）：① 可回滚（新版向后兼容、别做不可逆变更，尤其数据库加字段别删改）、② 可观察（监控错误率/延迟/业务指标判断好坏）、③ 新旧兼容（滚动/金丝雀期间并存要兼容）。理解「选择:快速回滚用蓝绿、小范围验证用金丝雀、省资源用滚动、按规则放量用灰度;组合金丝雀+滚动;三前提:可回滚(向后兼容别不可逆)+可观察(监控)+新旧兼容」，就掌握了选择和组合。

记忆钩子：「发布策略权衡资源/回滚速度/风险控制:①蓝绿部署(两套环境蓝旧绿新、部署 v2 到绿测试→一次性切流量、回滚切回蓝秒级;优点回滚快发布干净、缺点双倍资源+切换全量)②金丝雀发布(新版先小流量 5%观察→逐步放量 5→20→50→100%、回滚切回 v1 只影响小部分爆炸半径小;风险控制最好但周期长)③滚动发布(逐批替换实例、K8s 默认;省资源但新旧并存要兼容+回滚慢)④灰度发布(金丝雀泛称、按规则放量:比例/用户标签/地域/header、靠网关/Istio/注册中心灰度标签);组合金丝雀+滚动;三前提:可回滚(向后兼容)+可观察(监控)+新旧兼容」。

七、常见误区与追问

• 误区：蓝绿部署和金丝雀发布一样。 不一样——蓝绿是「两套环境、一次性全量切换」（切换瞬间全量走新版，回滚切回旧环境）；金丝雀是「先小流量、逐步放量」（新版先给一小部分用户、观察后逐步扩大）；蓝绿整体切换、金丝雀渐进放量，风险控制方式不同。
• 误区：滚动发布不用管新旧版本兼容。 要管——滚动发布过程中新旧版本并存（部分实例是 v1、部分是 v2 同时在跑），所以接口、数据库结构必须新旧兼容；否则新旧版本交互会出错；这是滚动发布（和金丝雀）的一个重要前提。
• 误区：蓝绿部署没有风险。 蓝绿切换瞬间是全量的——如果新版 v2 有问题，切过去后全量用户立刻受影响（只是能快速切回蓝环境回滚）；它的优势是回滚快，不是风险小；要小范围验证控制风险应该用金丝雀/灰度。
• 误区：有了发布策略就能随便发。 任何发布策略都有前提——① 可回滚（新版本要向后兼容，别做不可逆的数据库变更如删字段、改类型）；② 可观察（要监控错误率、延迟、业务指标才能判断新版好坏）；否则发布策略再好，出问题也回滚不了、或发现不了问题。
• 追问：蓝绿部署和滚动发布怎么选？ 蓝绿：要求快速回滚（切回旧环境秒级）、资源充足（能承受双倍环境）、关键系统不能容忍长故障；滚动：省资源（不用双倍环境、逐批替换、K8s 默认）、能接受发布过程中新旧版本并存和短暂容量下降；蓝绿回滚快但费资源、滚动省资源但回滚慢且新旧并存。
• 追问：金丝雀发布怎么控制流量（让 5% 走新版）？ 通过流量路由——① 网关/负载均衡按权重路由（95% 到 v1、5% 到 v2）；② 服务网格 Istio 的 VirtualService 按权重或规则分流；③ 注册中心 + 灰度标签 + 路由规则（如 Nacos/Dubbo/Spring Cloud 的灰度，给实例打标签、按规则路由）；分流规则可以是比例、用户标签、地域、请求 header 等。
• 追问：为什么发布前要保证「向后兼容」和「可回滚」？ 因为发布可能失败要回滚——如果新版本做了不可逆的变更（如数据库删了字段、改了字段类型），回滚到旧版本时旧代码可能读不到数据或报错，就回滚不了了；所以数据库变更要向后兼容（只加字段、不删不改），保证新旧版本都能正常工作，这样新版出问题才能安全回滚到旧版；这是所有发布策略的隐藏前提。

八、加强记忆

蓝绿部署、金丝雀发布、滚动发布、灰度发布都是「安全发布新版本」的策略，权衡「资源成本、回滚速度、风险控制」。① 蓝绿部署（Blue-Green）——两套相同环境（蓝=旧 v1 接 100% 流量、绿=部署新 v2），部署 v2 到绿测试通过后一次性把全部流量切到绿，出问题切回蓝秒级回滚；优点回滚快、发布干净，缺点双倍资源、切换瞬间全量。② 金丝雀发布（Canary）——新版先只接一小部分流量（5%）观察，没问题再逐步放量（5%→20%→50%→100%），出问题只影响那一小部分（爆炸半径小）；风险控制最好但周期长、新旧并存要兼容。③ 滚动发布（Rolling）——逐批替换实例（K8s 默认），省资源但新旧版本并存要兼容、回滚较慢。④ 灰度发布——金丝雀的泛称，按规则（比例/用户标签/地域/header）让部分用户先用、逐步放量，靠网关/Istio/注册中心灰度标签实现。选择：快速回滚用蓝绿、小范围验证用金丝雀/灰度、省资源用滚动；实践常组合（金丝雀+滚动）。三个前提：可回滚（新版向后兼容、别做不可逆的数据库变更）、可观察（监控错误率/延迟/业务指标）、新旧兼容。一句话「蓝绿=两套环境整体切换(回滚快但双倍资源)、金丝雀=先小流量逐步放量(风险控制最好爆炸半径小)、滚动=逐批替换(省资源但新旧并存 K8s 默认)、灰度=按规则放量(金丝雀泛称);选择看快速回滚/小范围验证/省资源;前提可回滚+可观察+新旧兼容」。