Shell脚本如何实现分批回滚策略

wen 实用脚本 2026-07-04 31

Shell脚本实现分批回滚策略：从原理到实战的完整指南

目录导读

为什么需要分批回滚？
分批回滚的核心设计原则
Shell脚本实现分批回滚的完整流程
关键代码段解析
FAQ：常见问题与解答
最佳实践与优化建议

为什么需要分批回滚？

在线上服务部署过程中,全量回滚（一次性回滚所有节点）存在明显风险：

Shell脚本如何实现分批回滚策略

如果回滚脚本有bug,可能导致所有节点同时故障
无法灰度验证回滚后的版本状态
负载均衡器难以平滑切换流量

分批回滚策略通过将服务器划分为多个批次（如10%→30%→60%），逐步执行回滚操作，同时配合健康检查，确保每批回滚成功后继续下一批，从而最大限度降低影响面。

分批回滚的核心设计原则

1 批次划分依据

按服务器数量：例如64台服务器分为16批，每批4台
按权重：根据CPU/内存使用率或流量占比划分
按可用区：先回滚A区，再回滚B区

2 回滚前必要条件

版本快照：需要保存回滚前的应用版本号（如rollback_version.txt）
健康检查脚本：例如check_health.sh，能返回0（正常）或非0（异常）
回滚脚本：如rollback_to_version.sh <VERSION>

3 容错机制

单批次失败后暂停后续回滚,发送告警
支持手动跳过失败批次（需人工确认）

Shell脚本实现分批回滚的完整流程

1 环境准备与变量定义

#!/bin/bash
# 配置区
ROLLBACK_VERSION_FILE="/data/rollback_version.txt"
ALL_SERVERS=("web01" "web02" "web03" "web04" "web05")  
BATCH_SIZE=2  # 每批处理2台
HEALTH_CHECK_CMD="/usr/local/bin/check_app_health.sh"
ROLLBACK_CMD="/usr/local/bin/rollback_app.sh"

2 核心函数实现

# 获取服务器列表并分批
get_server_batches() {
    local servers=("$@")
    local batch_count=$(( (${#servers[@]} + BATCH_SIZE - 1) / BATCH_SIZE ))
    for ((i=0; i<batch_count; i++)); do
        local batch=("${servers[@]:i*BATCH_SIZE:BATCH_SIZE}")
        echo "${batch[@]}"
    done
}
# 执行分批回滚
execute_rollback() {
    local version="$1"
    local batches=($(get_server_batches "${ALL_SERVERS[@]}"))
    for batch in "${batches[@]}"; do
        echo "[$(date)] 开始回滚批次: $batch"
        # 执行回滚操作
        for server in $batch; do
            ssh "$server" "$ROLLBACK_CMD $version" || {
                echo "ERROR: $server 回滚失败"
                return 1
            }
        done
        # 批次健康检查
        for server in $batch; do
            if ! ssh "$server" "$HEALTH_CHECK_CMD"; then
                echo "ERROR: $server 健康检查失败"
                return 1
            fi
        done
        echo "[$(date)] 批次回滚成功: $batch"
    done
}

3 主逻辑控制

# 读取回滚版本
if [[ ! -f "$ROLLBACK_VERSION_FILE" ]]; then
    echo "错误: 未找到回滚版本文件 $ROLLBACK_VERSION_FILE"
    exit 1
fi
ROLLBACK_VERSION=$(cat "$ROLLBACK_VERSION_FILE")
# 开始回滚
echo "开始分批回滚至版本: $ROLLBACK_VERSION"
if execute_rollback "$ROLLBACK_VERSION"; then
    echo "回滚成功"
else
    echo "回滚失败，请检查日志"
    exit 1
fi

关键代码段解析

1 批次生成的优化

使用Bash数组切片可以灵活控制批次大小,如果需要动态调整批次大小（如根据剩余节点数），可以采用：

BATCH_SIZE=$(( $TOTAL_SERVERS / 10 + 1 ))  # 至少10%为一组

2 健康检查的超时处理

在SSH远程执行时,建议加上超时控制：

timeout 30 ssh "$server" "$HEALTH_CHECK_CMD" || {
    echo "超时或失败: $server"
}

3 日志记录与告警

每轮回滚开始/结束时记录时间戳和节点状态：

echo "[$(date +%Y-%m-%d_%H:%M:%S)] 批次 $batch 完成" >> rollback.log

FAQ：常见问题与解答

Q1：如果某一批次部分节点失败，脚本如何处理？
A：脚本会立即终止后续回滚，并输出失败节点信息，生产环境中应配合告警系统（如通过curl发送到webhook），同时保留失败批次的状态，便于人工介入。

Q2：如何在回滚前确认目标版本可用？
A：建议在脚本开头增加验证版本的步骤：

if ! ssh "$FIRST_SERVER" "ls /app/versions/$ROLLBACK_VERSION/"; then
    echo "回滚版本不存在，放弃操作"
    exit 1
fi

Q3：如何与负载均衡器联动？
A：可以在回滚前执行lb_remove_server.sh <SERVER>，回滚完成后执行lb_add_server.sh <SERVER>，确保流量不会打到正在回滚的节点。

Q4：脚本如何支持人工批处理跳过？
A：可以增加用户交互模式：

read -p "是否继续回滚下一批？(y/n): " confirm
if [[ ! "$confirm" =~ ^[Yy]$ ]]; then
    echo "用户中断，退出"
    exit 0
fi

Q5：批量节点数很大时，脚本性能如何？
A：对于1000+的节点，建议使用xargs -P并行执行，

echo "$batch" | xargs -P 4 -I {} ssh {} "$ROLLBACK_CMD $version"

注意控制并行度（-P参数），避免SSH连接风暴。

最佳实践与优化建议

1 增加重试机制

对于偶尔的网络抖动导致的SSH失败,可以设置重试：

for ((retry=1; retry<=3; retry++)); do
    ssh "$server" "$ROLLBACK_CMD $version" && break
    sleep 5
done

2 与CI/CD系统集成

将脚本暴露为可调用命令,输出JSON格式结果：

echo '{"status":"success","failed_nodes":[],"rollback_version":"v2.1.0"}'

便于Jenkins/GitLab CI等工具解析。

3 安全加固

使用ssh-agent或专用密钥，避免明文密码
对回滚版本做MD5校验
限制只有特定用户组才能执行

4 示例化配置文件

将服务器列表从脚本中分离,使用外部配置文件servers.list：

while read -r server; do
    ALL_SERVERS+=("$server")
done < /etc/rollback/servers.list

通过Shell脚本实现分批回滚策略,本质上是一个增量式、可验证、可中断的自动化工序，关键不在于代码有多复杂，而在于容错设计是否完备，建议在开发环境先使用小规模集群（如3-5台）测试完整流程，再推广至生产环境，对于需要处理上千节点的场景，可考虑结合Ansible或SaltStack等批量工具，但Shell脚本作为快速响应手段仍有不可替代的价值。