第3章滚动升级策略

滚动升级策略：让系统在不知不觉中完成蜕变

大家好，我是老赵。今天我们来聊聊滚动升级——这个在交易系统运维里最常用、也最考验功力的策略。

说实话，我刚入行那会儿，对滚动升级的理解特别肤浅。觉得不就是一台一台重启嘛，有什么难的？直到有一次，我在生产环境上搞了个"滚动升级"，结果把整个交易链路给搞断了……嗯，从那以后，我才真正开始认真研究这个策略。

滚动升级的原理：温水煮青蛙式的优雅升级

滚动升级的核心思想很简单：不一次性升级所有节点，而是分批进行。就像换轮胎，你不会把四个轮子同时拆下来，而是一个一个换，保证车始终能开。

在交易系统里，我们通常有多个实例（比如4个、8个、16个）。滚动升级就是先升级其中一部分，等它们稳定运行后，再升级下一批。整个过程，系统始终处于"部分新版本 + 部分旧版本"的状态。

关键点：滚动升级的本质是"灰度"思想——让新版本逐步接管流量，而不是一次性全量切换。

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

批次控制：不是拍脑袋决定的

批次控制是滚动升级里最讲究的地方。分几批？每批几个节点？间隔多久？这些都不是随便定的。

我个人习惯这样设计批次策略：

第一批：1个节点（探路者）——先拿一个节点试试水，看看新版本能不能跑起来。我记得有一次，新版本有个隐藏的bug，第一批就暴露了，只影响了一个节点，要是全量升级……想想都后怕。
第二批：20%-30%的节点——第一批没问题，就扩大范围。这时候要观察业务指标，比如交易延迟、成功率。
第三批及以后：剩余节点——如果一切正常，就加速升级。但别太急，我建议每批之间至少等5-10分钟。

小技巧：对于交易系统这种高敏感业务，我建议采用"1-2-4-8"的指数级批次策略。第一批1个，第二批2个，第三批4个……这样既能快速推进，又不会一下子引入太多风险。

健康检查：你的"安全气囊"

健康检查是滚动升级的命门。没有它，你就是在闭着眼睛开车。

我曾经见过一个团队，滚动升级时只检查了进程是否存活，结果新版本有个内存泄漏，跑了一个小时才爆。嗯，那个晚上他们都没睡成觉。

我建议至少做三层健康检查：

检查层级	检查内容	检查频率	失败处理
L1：基础检查	进程存活、端口监听、CPU/内存	每5秒	立即回滚该节点
L2：业务检查	交易接口响应、数据库连接、消息队列	每30秒	暂停升级，人工介入
L3：数据一致性检查	账务平衡、订单状态、流水完整性	每批升级完成后	全量回滚

这里有个代码片段，是我常用的健康检查脚本框架：

#!/bin/bash
# 滚动升级健康检查脚本

check_l1() {
    # 检查进程
    if ! pgrep -f "trading-engine" &>/dev/null; then
        echo "L1_FAIL: 进程不存在"
        return 1
    fi
    # 检查端口
    if ! ss -tlnp | grep ":8080" &>/dev/null; then
        echo "L1_FAIL: 端口未监听"
        return 1
    fi
    echo "L1_PASS"
    return 0
}

check_l2() {
    # 检查交易接口
    local resp=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/health)
    if [ "$resp" != "200" ]; then
        echo "L2_FAIL: 接口返回 $resp"
        return 1
    fi
    echo "L2_PASS"
    return 0
}

check_l3() {
    # 检查数据一致性（示例：对比新旧节点订单数）
    local old_count=$(mysql -e "SELECT COUNT(*) FROM orders" | tail -1)
    local new_count=$(mysql -h new_node -e "SELECT COUNT(*) FROM orders" | tail -1)
    if [ "$old_count" != "$new_count" ]; then
        echo "L3_FAIL: 订单数不一致"
        return 1
    fi
    echo "L3_PASS"
    return 0
}

# 主流程
for i in {1..3}; do
    echo "=== 第 $i 轮健康检查 ==="
    check_l1 || exit 1
    check_l2 || exit 1
    check_l3 || exit 1
    sleep 10
done
echo "健康检查全部通过"

避坑指南：我曾经犯过一个错误——健康检查只检查了本节点，没检查上下游依赖。结果节点本身是好的，但连不上数据库，导致交易失败。后来我加了一条规则：健康检查必须包含上下游依赖的连通性测试。

滚动升级的优缺点：没有银弹

任何策略都有两面性，滚动升级也不例外。我根据自己的实战经验，总结了一张表：

维度	优点	缺点
可用性	全程不中断服务，用户无感知	升级期间存在新旧版本共存，可能引发兼容性问题
风险控制	问题影响范围小，可随时暂停或回滚	回滚流程复杂，需要同时处理新旧版本
资源消耗	不需要额外资源，利用现有节点	升级时间长，节点越多耗时越长
适用场景	无状态服务、水平扩展的应用	有状态服务、数据库迁移等场景不适用

说白了，滚动升级最适合那种"换零件"的场景——每个节点都是独立的，换掉一个不影响整体。但如果你要改数据库结构、改消息协议，那滚动升级就有点力不从心了。

适用场景：什么时候该用？

我一般这样判断：

适合用：交易系统的网关层、计算引擎、风控服务——这些都是无状态的，每个节点独立处理请求。
谨慎用：会话保持的服务、有本地缓存的服务——升级时要注意会话迁移和缓存预热。
别用：数据库主从切换、消息队列集群升级——这些需要专门的策略，别拿滚动升级硬套。

我的经验：在交易系统里，80%的升级场景都可以用滚动升级搞定。但剩下的20%，比如核心账务系统的升级，我建议用蓝绿部署或者灰度发布。别为了省事而冒险，交易系统的钱可开不得玩笑。

好了，关于滚动升级的原理、批次控制、健康检查以及优缺点，我就讲到这里。记住一句话：滚动升级不是简单的"一台一台重启"，而是一套完整的风险控制体系。下次你在生产环境做滚动升级时，不妨想想我今天说的这些——尤其是那个健康检查的三层架构，真的能帮你省不少心。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

滚动升级策略：让系统在不知不觉中完成蜕变

滚动升级的原理：温水煮青蛙式的优雅升级

批次控制：不是拍脑袋决定的

健康检查：你的"安全气囊"

滚动升级的优缺点：没有银弹

适用场景：什么时候该用？