📚 课程目录第2章蓝绿发布基础

2、蓝绿发布基础：蓝绿部署原理、流量切换机制、回滚策略

蓝绿发布（Blue-Green Deployment）是一种零停机或接近零停机的应用发布策略。其核心思想是维护两套完全独立的生产环境——蓝环境（当前运行稳定版本）与绿环境（待发布新版本），通过流量网关的瞬间切换实现版本更新。本章将深入剖析蓝绿部署的底层原理、流量切换的工程实现以及回滚策略的设计要点。

2.1 蓝绿部署原理

蓝绿部署并非简单的“多部署一套副本”，而是要求两套环境在基础设施层面完全隔离，各自拥有独立的计算资源、数据库实例（或读写分离）、缓存集群与配置中心。部署架构如下图所示：

蓝绿部署的关键约束条件包括：

约束维度	要求	常见实现方式
环境隔离	两套环境在计算、网络、存储层面完全独立	独立 Kubernetes Namespace / 独立 VPC / 独立物理机池
数据兼容	新版本必须兼容旧版本的数据库 schema 与缓存结构	向前兼容的数据库迁移、双写策略、读写分离
配置一致	除版本差异外，两套环境的配置参数应保持一致	配置中心统一管理、环境变量模板化
资源对等	蓝绿环境的计算资源规格与数量应保持一致	HPA 配置相同、Pod 资源 request/limit 一致

实践提示： 数据库兼容性是蓝绿部署最大的技术债。建议在绿环境部署前，先运行数据库迁移脚本的 dry-run 模式，并利用自动化测试验证 schema 变更不会破坏蓝环境的查询路径。

2.2 流量切换机制

流量切换是蓝绿发布的核心动作，决定了从“蓝环境承载100%流量”到“绿环境承载100%流量”的过渡方式。根据切换的粒度与风险控制需求，主流切换机制分为以下三种：

2.2.1 瞬时切换（Cut-Over）

通过修改负载均衡器或网关的路由规则，将流量从蓝环境瞬间全部指向绿环境。切换时间通常在秒级以内。

优点： 操作简单、切换速度快、用户感知最小。
缺点： 一旦绿环境存在未发现的缺陷，影响范围立即覆盖全部用户。
适用场景： 内部工具、低风险前端静态资源发布、经过充分预演的后端服务。

2.2.2 灰度切换（Canary-Based Switch）

将流量按比例逐步从蓝环境迁移到绿环境，例如先切 5% → 20% → 50% → 100%，每个阶段观察一段时间。

优点： 风险可控，可在早期发现问题并快速回滚。
缺点： 切换周期较长，需要流量管理平台支持细粒度权重路由。
适用场景： 核心交易链路、涉及数据写操作的服务、高并发生产环境。

2.2.3 会话保持切换（Sticky Session Switch）

在切换过程中，通过 Cookie 或 Header 将已建立会话的用户固定在蓝环境，新用户或新会话路由到绿环境，逐步完成迁移。

优点： 避免切换过程中用户会话中断，体验平滑。
缺点： 实现复杂度高，需要网关支持会话亲和性；切换周期可能较长。
适用场景： 有状态服务、WebSocket 长连接、购物车等强会话场景。

工程实现参考： 在 Kubernetes 环境中，灰度切换通常通过 Service Mesh（如 Istio）的 VirtualService 权重路由实现。以下是一个 Istio 流量权重配置示例：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp-vs
spec:
  hosts:
  - myapp.example.com
  http:
  - route:
    - destination:
        host: myapp-blue
        subset: v1
      weight: 80
    - destination:
        host: myapp-green
        subset: v2
      weight: 20

2.3 回滚策略

回滚是蓝绿发布的安。由于蓝环境在切换后仍保留完整的基础设施与数据状态，回滚操作本质上是一次“反向切换”——将流量从绿环境切回蓝环境。但回滚并非简单的流量反转，需要根据数据状态与切换时长制定分级策略。

2.3.1 即时回滚（Immediate Rollback）

在流量切换后的短时间内（通常 5~15 分钟），绿环境尚未产生大量业务数据变更，此时可直接将流量切回蓝环境。

条件： 绿环境未执行数据写操作，或写操作已通过双写机制同步到蓝环境。
操作： 在网关/负载均衡器上将流量权重从绿环境 100% 改回蓝环境 100%。
风险： 极低，用户几乎无感知。

2.3.2 数据补偿回滚（Compensation Rollback）

如果绿环境已经运行较长时间（如数小时），产生了大量业务数据，直接切回蓝环境会导致数据丢失或不一致。此时需要执行数据补偿流程。

步骤：
1. 停止绿环境的新流量接入，允许存量请求处理完成（优雅关闭）。
2. 执行数据回滚脚本：将绿环境写入的数据回退到蓝环境可接受的状态（如删除新增记录、还原被修改的字段）。
3. 验证蓝环境的数据完整性。
4. 将流量切回蓝环境。
风险： 中等，数据补偿脚本需要提前编写并经过充分测试。

2.3.3 全量重建回滚（Full Rebuild Rollback）

当绿环境的数据变更无法通过简单脚本回退，或蓝环境的基础设施已被回收时，需要从备份中重建蓝环境。

步骤：
1. 从最近的数据库快照恢复蓝环境的数据层。
2. 重新部署蓝环境的应用版本（v1.0）。
3. 执行数据增量同步，将绿环境未丢失的数据导入蓝环境。
4. 验证后切换流量。
风险： 较高，恢复时间目标（RTO）可能达到小时级。

回滚策略	RTO（恢复时间目标）	RPO（恢复点目标）	适用条件
即时回滚	< 1 分钟	零数据丢失	切换后 15 分钟内，无数据写操作
数据补偿回滚	5~30 分钟	分钟级数据丢失	有数据变更但可脚本化回退
全量重建回滚	1~4 小时	小时级数据丢失	蓝环境已回收或数据变更不可逆

关键提醒： 回滚策略必须在发布前以 Runbook 形式文档化，并经过至少一次演练。不要在生产故障发生时再临时设计回滚步骤。建议在 CI/CD 流水线中内置回滚按钮，一键触发预定义的回滚流程。

2.4 蓝绿发布与门禁系统的关系

在《自助服务实现蓝绿发布门禁》课程中，蓝绿发布基础是门禁策略的底层支撑。门禁系统需要感知当前蓝绿环境的状态，并在以下环节实施安全控制：

部署前门禁： 检查绿环境是否已通过自动化测试、安全扫描、性能基准测试。
切换前门禁： 验证蓝绿环境的数据库兼容性、配置一致性、健康检查状态。
切换后门禁： 监控绿环境的错误率、延迟、业务指标，触发自动回滚或人工审批。
回滚门禁： 确保回滚操作不会导致数据损坏，验证蓝环境仍处于可用状态。