3. 全量回滚实现：原理、脚本与优劣分析

全量回滚，说白了就是把整个应用或服务一次性恢复到上一个已知的稳定版本。它不是只改几个文件，而是把整个发布单元——包括二进制、配置文件、依赖库、甚至数据库 schema——整体替换回去。

我在早期做运维时，总觉得全量回滚太粗暴。后来线上出过一次事故，补丁把核心模块的接口签名改了，但依赖方没同步更新。增量回滚根本救不回来，最后只能全量回。嗯，从那以后，我每个项目都会把全量回滚脚本准备好。

全量回滚的原理

全量回滚的核心逻辑其实很简单：用旧版本的整体替换新版本的整体。它依赖两个前提：

• 版本包完整性：每次发布前，必须把完整的发布包（包括所有依赖）归档到制品库，并打上版本标签。
• 部署路径隔离：新旧版本部署在不同目录，通过软链接或负载均衡切换流量。

我习惯用「蓝绿部署」的思路来理解全量回滚。蓝环境跑旧版本，绿环境跑新版本。一旦绿环境出问题，直接把流量切回蓝环境。这就是全量回滚的典型场景。

这里有个容易被忽略的点：数据库回滚。如果补丁包含了数据库 schema 变更，全量回滚时必须同时回滚数据库。我曾经见过一个团队，应用回滚成功了，但数据库表结构还是新的，结果应用启动就报字段不存在的错误。所以，全量回滚一定要把「数据层回滚」纳入脚本。

全量回滚脚本编写

写全量回滚脚本，我个人的原则是：幂等、可重试、有日志。你想想看，回滚时通常都是紧急情况，脚本如果跑一半挂了，或者重复执行会出问题，那真是雪上加霜。

下面是一个我常用的全量回滚脚本模板，适用于 Linux 环境下的 Java 应用。它做了几件事：

• 从制品库拉取旧版本包
• 备份当前版本（万一回滚后还要再切回来）
• 停止应用、替换包、启动应用
• 健康检查并输出结果

#!/bin/bash
# ============================================
# 全量回滚脚本 - rollback_full.sh
# 用法: ./rollback_full.sh <app_name> <target_version>
# 示例: ./rollback_full.sh order-service v1.2.0
# ============================================

set -euo pipefail

APP_NAME="${1:?应用名称不能为空}"
TARGET_VERSION="${2:?目标版本不能为空}"
ROLLBACK_DIR="/data/rollback/${APP_NAME}"
DEPLOY_DIR="/data/app/${APP_NAME}"
BACKUP_DIR="/data/backup/${APP_NAME}/$(date +%Y%m%d_%H%M%S)"
ARTIFACT_URL="http://artifactory.internal/releases/${APP_NAME}/${TARGET_VERSION}/${APP_NAME}-${TARGET_VERSION}.tar.gz"
LOG_FILE="/var/log/rollback/${APP_NAME}_rollback_$(date +%Y%m%d_%H%M%S).log"

# 初始化日志
mkdir -p "$(dirname "${LOG_FILE}")"
exec > >(tee -a "${LOG_FILE}") 2>&1

echo "[$(date '+%Y-%m-%d %H:%M:%S')] 开始全量回滚: ${APP_NAME} -> ${TARGET_VERSION}"

# 1. 下载旧版本包
echo "[步骤 1/6] 下载旧版本包: ${ARTIFACT_URL}"
mkdir -p "${ROLLBACK_DIR}"
curl -s -o "${ROLLBACK_DIR}/${APP_NAME}-${TARGET_VERSION}.tar.gz" "${ARTIFACT_URL}"
if [ $? -ne 0 ]; then
    echo "[错误] 下载失败，请检查制品库连接和版本号"
    exit 1
fi

# 2. 备份当前版本
echo "[步骤 2/6] 备份当前版本到: ${BACKUP_DIR}"
if [ -d "${DEPLOY_DIR}" ]; then
    mkdir -p "${BACKUP_DIR}"
    cp -r "${DEPLOY_DIR}" "${BACKUP_DIR}/"
    echo "当前版本已备份"
fi

# 3. 停止应用
echo "[步骤 3/6] 停止应用: ${APP_NAME}"
if systemctl is-active --quiet "${APP_NAME}"; then
    systemctl stop "${APP_NAME}"
    sleep 3
    echo "应用已停止"
else
    echo "应用未运行，跳过停止步骤"
fi

# 4. 替换部署目录
echo "[步骤 4/6] 替换部署目录"
rm -rf "${DEPLOY_DIR}"
mkdir -p "${DEPLOY_DIR}"
tar -xzf "${ROLLBACK_DIR}/${APP_NAME}-${TARGET_VERSION}.tar.gz" -C "${DEPLOY_DIR}"
echo "旧版本包已部署到: ${DEPLOY_DIR}"

# 5. 启动应用
echo "[步骤 5/6] 启动应用: ${APP_NAME}"
systemctl start "${APP_NAME}"
sleep 5

# 6. 健康检查
echo "[步骤 6/6] 执行健康检查"
HEALTH_URL="http://localhost:8080/health"
for i in {1..6}; do
    HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "${HEALTH_URL}" || echo "000")
    if [ "${HTTP_CODE}" = "200" ]; then
        echo "健康检查通过 (HTTP 200)"
        echo "[$(date '+%Y-%m-%d %H:%M:%S')] 全量回滚成功完成"
        exit 0
    fi
    echo "等待应用启动... (${i}/6)"
    sleep 5
done

echo "[警告] 健康检查未通过，请手动检查应用状态"
exit 1

全量回滚的优缺点分析

全量回滚不是银弹。我把它和增量回滚放在一起对比，你就能看清楚了。

对比维度	全量回滚	增量回滚
回滚粒度	整个应用/服务	单个文件或模块
执行速度	较慢（需下载完整包、重启进程）	较快（只替换差异文件）
依赖一致性	高（所有依赖一起回滚）	低（可能遗留依赖冲突）
数据库兼容性	需额外处理 schema 回滚	通常不涉及数据库变更
适用场景	重大故障、接口不兼容、核心模块异常	小范围 bug 修复、配置变更
风险等级	中（操作简单但影响面大）	低（影响面小但可能不彻底）

全量回滚的优点很明显：

• 彻底性：整个环境回到上一个稳定状态，不会遗留任何新版本的碎片
• 简单可靠：逻辑清晰，脚本容易维护，出错的概率低
• 适合紧急故障：当线上服务大面积不可用时，全量回滚是最快的止损手段

但缺点也不容忽视：

• 回滚时间长：下载大包、重启服务、健康检查，一套流程走下来可能要 5-10 分钟
• 流量损失大：回滚期间服务不可用，对用户体验影响明显
• 数据库回滚复杂：如果补丁改了数据库结构，全量回滚需要额外执行 SQL 回滚脚本，而且不能保证数据不丢失

所以，我的建议是：全量回滚作为兜底方案，平时就要演练。不要等到线上出事了才第一次跑这个脚本。每个月做一次混沌工程，把全量回滚纳入演练科目，确保脚本在真实环境下能跑通。