第2章蓝绿部署策略

2. 蓝绿部署策略：零宕机升级的经典方案

聊到零宕机升级，蓝绿部署是我最先想拿出来讲的方案。为什么？因为它思路简单，效果却出奇的好。说白了，就是准备两套一模一样的环境，一套跑着老版本（蓝），一套部署新版本（绿），然后通过切换流量来完成升级。

我在2018年负责一个期货交易系统的升级时，第一次大规模使用蓝绿部署。当时团队里有人担心两套环境成本太高，结果上线当天晚上，新版本出了个隐蔽的内存泄漏问题——嗯，要不是有蓝环境随时能切回去，那晚我们怕是要集体通宵了。

2.1 蓝绿部署原理

蓝绿部署的核心思想，我习惯用一句话概括：用空间换时间，用冗余换安全。

具体来说，整个流程是这样的：

准备阶段：维护两套完全相同的生产环境，分别称为蓝环境和绿环境
运行阶段：当前所有流量都指向其中一个环境（比如蓝环境）
部署阶段：在另一个空闲环境（绿环境）上部署新版本，并进行验证
切换阶段：验证通过后，将流量从蓝环境切换到绿环境
回滚阶段：如果新版本有问题，立即将流量切回蓝环境

核心要点：任何时候，只有一个环境在承接生产流量。另一个环境要么是待命的旧版本，要么是待验证的新版本。

我画了一张流程图，帮你直观理解这个过程：

2.2 蓝绿部署在交易系统中的实现

交易系统对可用性的要求极高，蓝绿部署在这里的实现有一些特殊之处。我结合一个实际案例来讲。

2.2.1 环境准备

首先，两套环境必须做到配置完全一致。包括：

应用服务器配置（JVM参数、线程池大小等）
中间件配置（消息队列、缓存集群等）
网络配置（防火墙规则、路由策略等）
监控配置（指标采集、告警阈值等）

我的经验：我建议用基础设施即代码（IaC）工具来管理环境配置，比如Terraform或Ansible。手动配置两套环境？别开玩笑了，出错的概率太高了。

2.2.2 数据库兼容性

交易系统的数据库迁移是个大问题。蓝绿部署要求两个版本都能访问同一个数据库，这意味着：

数据库变更必须向后兼容
新版本只能添加字段或表，不能删除或修改已有结构
数据迁移脚本要设计成可逆的

-- 兼容性数据库迁移示例
-- 添加新字段，而不是修改旧字段
ALTER TABLE orders ADD COLUMN new_status VARCHAR(20);
-- 不要这样做：ALTER TABLE orders MODIFY COLUMN status VARCHAR(20);

-- 添加新索引，不影响旧版本查询
CREATE INDEX idx_orders_new_status ON orders(new_status);

我曾经遇到过一个坑：团队在数据库迁移时直接修改了字段类型，结果蓝环境还在跑老代码，一查询就报类型转换异常。嗯，那次回滚花了整整40分钟——因为要恢复数据库结构。

2.2.3 流量切换策略

交易系统的流量切换不能简单粗暴地一刀切。我推荐灰度切换的方式：

内部验证：先让内部员工流量走绿环境
小比例放量：切1%-5%的真实用户流量到绿环境
观察期：监控各项指标，至少观察15-30分钟
逐步切换：25% → 50% → 75% → 100%

注意：交易系统涉及资金，切换过程中要确保事务一致性。如果一个交易请求在蓝环境开始处理，但被路由到绿环境完成，可能会造成数据不一致。我建议在负载均衡层面做会话保持（sticky session）。

2.2.4 代码示例：Nginx蓝绿切换配置

# nginx蓝绿部署配置示例
upstream blue_server {
    server 10.0.1.10:8080 weight=100;
    server 10.0.1.11:8080 weight=100;
}

upstream green_server {
    server 10.0.2.10:8080 weight=100;
    server 10.0.2.11:8080 weight=100;
}

# 默认指向蓝环境
map $cookie_deploy_env $backend {
    default blue_server;
    ~*green green_server;
}

server {
    listen 443 ssl;
    server_name trade.example.com;
    
    location / {
        proxy_pass http://$backend;
        # 会话保持
        proxy_cookie_path / "/; HttpOnly; Secure";
    }
}

2.3 蓝绿部署的优缺点与适用场景

任何技术方案都有两面性。蓝绿部署虽然好用，但也不是万能的。

2.3.1 优点

优点	说明
零宕机切换	切换瞬间完成，用户无感知
快速回滚	发现问题直接切回旧环境，秒级恢复
全量验证	新版本可以在生产环境全量测试，不受流量限制
风险隔离	新旧环境完全隔离，互不影响
运维简单	逻辑清晰，团队容易理解和执行

2.3.2 缺点

缺点	说明
成本翻倍	需要两倍的生产环境资源
数据库兼容性要求高	所有变更必须向后兼容，限制了数据库优化
状态同步复杂	如果应用有本地状态，切换时可能丢失
长时间占用资源	验证期间两套环境同时运行，资源利用率低
不适合频繁发布	每次发布都要重新部署整个环境，适合低频大版本

2.3.3 适用场景

根据我的经验，蓝绿部署最适合以下场景：

核心交易系统：对可用性要求达到99.99%以上的系统
大版本升级：涉及重大架构变更或数据库迁移的版本
监管合规要求高：需要完整审计和回滚能力的场景
团队运维能力一般：蓝绿部署操作简单，容错性好

不适合的场景：如果你的系统每天发布多次，或者资源预算非常紧张，蓝绿部署可能不是最佳选择。这时候可以考虑滚动更新或金丝雀发布。

2.4 避坑指南

最后，分享几个我在实战中踩过的坑：

缓存预热：切换后绿环境缓存是空的，瞬间的缓存穿透可能把数据库打挂。我建议在切换前先预热缓存。
连接池耗尽：旧环境的连接池不会立即释放，新环境又新建连接，数据库连接数可能翻倍。要提前规划好连接池上限。
定时任务冲突：两套环境同时运行，定时任务可能重复执行。我习惯在环境变量中加一个标识，只有生产环境才执行定时任务。
监控告警双倍：两套环境都会产生告警，要做好告警过滤，避免运维人员被淹没在告警中。

蓝绿部署是我个人非常推崇的一种升级策略。它不花哨，但足够可靠。在交易系统这种"稳字当头"的场景里，简单可靠往往比花里胡哨更重要。

📚 课程目录

2. 蓝绿部署策略：零宕机升级的经典方案

2.1 蓝绿部署原理

2.2 蓝绿部署在交易系统中的实现

2.2.1 环境准备

2.2.2 数据库兼容性

2.2.3 流量切换策略

2.2.4 代码示例：Nginx蓝绿切换配置

2.3 蓝绿部署的优缺点与适用场景

2.3.1 优点

2.3.2 缺点

2.3.3 适用场景

2.4 避坑指南