跳到主要内容

蓝绿发布、灰度发布、滚动发布的详细介绍

当有新需求开发完，也测试完了后，肯定是要上线的。而上线就会涉及到风险，要考虑到用户在使用过程中，怎么保证不影响用户的体验，也就是要尽量实现无损发布。

还有因为测试环境和生产环境肯定是有不同的，就是如果上线了后，新的服务出现了问题，就要求能够快速的回滚到之前的版本。而这关于新旧服务的替换以及回滚操作，考虑的因素就比较多了。

所以针对以上的问题，业内有三种常用的成熟方案，包括：蓝绿发布、灰度发布、滚动发布。

一、蓝绿发布（Blue-Green Deployment）​

1. 核心原理​

生产环境中，用户首先用app发送请求，接着经过网关，然后路由到对应的服务中执行，而正在提供运行的服务可以标记为绿色。

表关系

而已经完成了新需求的开发，并且也经过了测试，准备发布生产环境的新服务，就可以标记成蓝色了

表关系

当蓝色部分的服务经过不断地测试，修改，达到了标准后，就会将用户请求从原有的绿色服务切换到蓝色的服务了

表关系

切换后，原有的绿色服务虽然不再接收请求了，但并不会销毁，而是蓝绿系统都会运行，如果蓝色部分出现问题了，就会快速切回绿色部分。

等蓝色服务运行一段时间后，确定真的是没有问题了，就会将原有绿色服务销毁，并将运行的蓝色部分变成绿色部分，等再有新的需求，就会再次循环这个过程了。

表关系

2. 详细流程​

  1. 环境搭建： 创建两个完全一致的生产环境（例如相同的服务器配置、网络设置和数据库）。

  2. 新版本部署与测试： 在绿色环境中部署新版本，进行功能、性能及兼容性测试。

  3. 流量切换： 通过负载均衡器（如Nginx或云服务LB）将流量从蓝色环境切换至绿色环境。

  4. 旧环境处理： 切换成功后，蓝色环境可保留为备份或清理资源，以应对可能的回滚需求。

3. 优缺点​

  • 优点：

    • 快速回滚： 若新版本异常，可立即切回旧环境。
    • 零停机时间： 用户无感知切换。

  • 缺点：

    • 资源消耗高： 需双倍资源支持两套环境。
    • 数据一致性挑战： 需处理跨环境数据库同步问题。

4. 适用场景​

  • 对系统稳定性要求极高的场景（如金融交易系统）。

  • 需要快速回滚能力的关键业务。

二、灰度发布（Gray Release）与金丝雀发布（Canary Deployment）​

1. 核心原理​

首先生产环境上有着正在提供功能的生产服务，而已经完成了新需求的开发，并且也经过了测试，准备发布生产环境的新服务就是 灰度服务。

表关系

当灰度服务上线后，给这两套服务分配不同的流量，90% 的请求流量还是执行旧的服务，而 10% 的请求执行新的服务。并一直观察新服务运行的情况，判断没有问题后，再依次的加大新服务和减小旧服务流量请求，直到所有的请求都在新服务上执行。

表关系

这样的好处是当新服务发生问题时，只会发生在小比例的请求上。

2. 详细流程​

  • 流量分流： 通过负载均衡器或网关（如Rainbond）按权重分配流量。

  • 监控与反馈： 收集新版本的性能指标（响应时间、错误率）及用户行为数据。

  • 决策调整：

    • 若数据达标，逐步增加新版本流量权重。
    • 若异常，立即回滚并修复。

3. 优缺点​

  • 优点：

    • 风险可控： 问题影响范围小。
    • 用户反馈及时： 基于真实场景验证功能。

  • 缺点：

    • 技术复杂度高： 需支持流量控制和监控工具。
    • 样本量限制： 初期可能无法覆盖所有场景。

4. 适用场景​

  • 用户体验敏感的C端产品（如社交、电商平台）。
  • 新功能试水或架构升级验证，例如企业微信灰度接入DeepSeek-R1大模型。

三、滚动发布（Rolling Deployment）​

1. 核心原理​

通过逐步替换旧版本实例为新版本实例，每次更新部分节点并验证，直至全量完成。例如，在10个实例的集群中，每次替换1-2个实例。

前面说的蓝绿发布和灰度发布的缺点是依旧需要两套环境，成本比较高。所以考虑到成本问题就有了第三种方案，叫 滚动发布。

它适用在有多个服务实例的情况下，每次只升级一小部分服务，用新服务代替旧服务。当观察没有问题后，会再循环这个过程，一直到新版本把旧的版本都替换掉。

表关系

这种方案的优点是只需要一套环境。但因为是逐步滚动发布的，所有当有问题想回滚到初始版本时，就比较麻烦，而且它是新服务逐步替代旧服务的过程，所以相比前两种方案来说，它是属于 有损发布。

2. 详细流程​

  1. 分批替换： 从旧集群中按比例（如20%）逐步替换实例为新版本。

  2. 健康检查： 通过Kubernetes Probe等机制验证新实例运行状态。

  3. 流量分配： 负载均衡器将请求逐步导向新实例。

  4. 完成替换： 循环直至所有旧实例被替换。

3. 优缺点​

  • 优点：

    • 资源高效： 无需额外完整环境。
    • 风险分散： 问题可能被限制在部分实例。

  • 缺点：

    • 发布周期长： 大规模集群耗时显著。
    • 回滚困难： 需逆向操作，可能影响用户体验

4. 适用场景​

  • 资源有限的中小型系统。
  • 对服务中断有一定容忍度的非核心业务。

四、对比与选型建议​

策略资源消耗回滚速度风险控制适用场景
蓝绿发布高快（秒级）低高稳定性需求的核心业务
滚动发布低慢（分钟级）中资源有限的中小型系统
灰度/金丝雀发布中中等高需逐步验证的用户敏感型业务