服务器迁移到云端教程

结论:服务器迁移到云端的核心不是「搬数据」,而是「可控切换 + 随时可回退」。推荐路径是全量同步 + 增量追平 + DNS 灰度(1% → 10% → 100%),把停机窗口压到分钟级,并保留源站至少 7 天作为回滚底座。

上云迁移最容易翻车的场景是:一次性把数据 rsync 过去,然后直接把域名解析改到新 IP,结果发现配置文件路径不对、时区不一致、文件权限丢失,而老机器已经下线,只能硬着头皮在线修。本文按「评估 → 选型 → 同步 → 验证 → 切换 → 回滚」六段给出完整教程,命令基于 CentOS 7 / Ubuntu 24.04 与 MySQL 8.4,云平台操作以通用流程描述(截至 2026 年主流云厂商均提供对等能力)。

迁移前怎么评估?一张表定下范围和风险

结论:迁移前必须完成资产盘点,输出「系统清单 + 数据量 + 依赖拓扑 + 停机容忍度」四项信息。没盘清楚就动手,等于闭眼开车。

评估项需要确认的内容常见坑
服务器清单IP、角色、配置(CPU/内存/磁盘)、操作系统版本遗忘了角落里的跳板机、定时任务机
应用拓扑Web → 应用 → 数据库 → 缓存 → 存储的调用关系有服务写死了对端内网 IP
数据量文件系统总大小、数据库大小、文件数量(inode)小文件多导致 rsync 极慢
增量速度每日新增数据量(GB/天)增量大于传输带宽,永远追不平
网络源站出口带宽、是否与目标云有专线公网传输 100GB 在 10Mbps 下需 20+ 小时
停机容忍度可接受的中断时长(0 / 5 分钟 / 数小时)业务方口头说「可以随时停」但实际不能
合规域名备案、数据出境、等保要求国内节点必须完成 ICP 备案才能对外服务
特殊依赖加密狗、License 绑定 MAC/IP、特殊内核模块这类应用无法直接迁移,需原厂重新授权

评估阶段的三个必做动作:

  1. 画一张依赖图。把每个服务的上下游写清楚,尤其是「谁连谁」,这是后续分批迁移的依据。
  2. 测一次真实传输速度。用 rsync --dry-run 或直接传 1GB 测速,估算全量同步耗时。
  3. 确认目标云的资源配额。新账号默认有云主机、公网 IP、快照的配额上限,超限会导致创建失败。
bash
# 1) 盘点本机:系统版本、磁盘、监听端口、数据目录大小
cat /etc/os-release
df -hT && df -i
ss -lntup
du -sh /var/www /data /var/lib/mysql 2>/dev/null

# 2) 实测公网传输速度(在目标云主机上起一个临时测速)
iperf3 -s                        # 目标端
iperf3 -c <目标公网IP> -P 4 -t 30 # 源端

# 3) 统计文件数量,小文件多要特殊处理(打包传输)
find /var/www -type f | wc -l

五种迁移策略怎么选?6R 模型一图看懂

结论:先给每个系统选策略,再动手。绝大多数首次上云的项目应该用 Rehost(重新托管,即「平移」),而不是一上来就重构。

策略英文含义适用场景工作量收益
重新托管Rehost(Lift & Shift)原样搬到云主机,不改架构首次上云、时间紧、系统老旧低快,风险小
重新平台Replatform少量改造,如自建 MySQL 换成云 RDS想省运维但不敢大改中省运维成本
重新购买Repurchase换成 SaaS,如自建邮件换成企业邮箱非核心系统低彻底免运维
重构 / 重架构Refactor改成容器化、微服务、Serverless系统需长期演进、有明显瓶颈高弹性与效率
保留Retain暂时留在本地(合规或硬件绑定)加密狗、特殊硬件无规避风险
下线Retire迁移时发现已无人使用,直接关停僵尸系统无直接省钱

选型建议:

  • 第一批迁移选 Rehost:把风险压到最低,先拿到「云上能跑」这个结果。
  • 数据库优先 Replatform:自建 MySQL 迁云 RDS 能省掉 80% 的运维工作量,投入产出比最高。
  • Refactor 放到第二期:等系统在云上稳定运行 1~3 个月,摸清负载特征后再做容器化改造。
  • Retire 别忘做:盘点时经常发现 20% 的机器已经没人用,关掉它们是最快的降本。

数据怎么迁?rsync、DTS 与对象存储三条路

结论:文件用 rsync 增量同步,数据库用 DTS 或主从复制在线追平,大量静态文件用对象存储迁移工具。关键是「先全量、后增量、最后切窗口追平」三步走。

文件迁移:rsync 全量 + 增量

bash
# 目标云主机先创建目录并配置 SSH 免密(源站 → 目标站)
# 第一次:全量同步(不删目标端多余文件,避免误删)
rsync -avzP --numeric-ids --stats \
  -e "ssh -p 22 -i /root/.ssh/migrate_key -o StrictHostKeyChecking=no" \
  /var/www/ root@<目标公网IP>:/var/www/

# 第二次及之后:增量同步(--delete 谨慎使用,务必先 --dry-run)
rsync -avzP --delete --numeric-ids \
  -e "ssh -p 22 -i /root/.ssh/migrate_key" \
  /var/www/ root@<目标公网IP>:/var/www/ --dry-run

# 小文件极多时改用打包流式传输,速度可提升数倍
tar -cf - -C /var/www . | pigz -1 | ssh -i /root/.ssh/migrate_key root@<目标IP> \
  "gzip -d | tar -xf - -C /var/www"

rsync 关键参数说明:

  • -a:归档模式,保留权限、属主、时间戳、软链接,迁移必加。
  • --numeric-ids:保留数字 UID/GID,避免目标机用户 ID 不一致导致属主错乱。
  • -P:显示进度并支持断点续传,大文件必备。
  • -z:压缩传输,带宽紧张时开,CPU 紧张时关(可用 --compress-level=1)。
  • --bwlimit=5000:限速 5000 KB/s,避免打满生产带宽影响线上业务。

数据库迁移:DTS 在线追平

bash
# 方案 A:云厂商 DTS(数据传输服务)—— 推荐,支持不停机
# 控制台操作:创建迁移任务 → 源库只读账号 → 目标库 → 全量迁移 → 增量同步 → 业务切换

# 方案 B:自建 MySQL 主从复制追平(云 RDS 也可作为从库)
# 1) 源库开启 binlog 并创建复制账号
mysql -uroot -p -e "
CREATE USER 'repl'@'%' IDENTIFIED BY '强密码';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
SHOW MASTER STATUS;"

# 2) 导出一致性全量(不锁表,记录 binlog 位点)
mysqldump -uroot -p --single-transaction --master-data=2 \
  --routines --triggers --events --hex-blob \
  --databases appdb > /data/appdb_full.sql

# 3) 传输并导入目标库
rsync -avzP /data/appdb_full.sql root@<目标IP>:/data/
mysql -uroot -p < /data/appdb_full.sql

# 4) 配置增量追平
mysql -uroot -p -e "
CHANGE MASTER TO
  MASTER_HOST='<源库IP>',
  MASTER_USER='repl',
  MASTER_PASSWORD='强密码',
  MASTER_LOG_FILE='mysql-bin.000123',
  MASTER_LOG_POS=456789;
START SLAVE;
SHOW SLAVE STATUS\G"          # 确认 Seconds_Behind_Master 逐步趋近 0

静态资源:对象存储迁移

大量图片、视频、附件建议直接迁到对象存储(OSS / COS / S3),而不是放到云主机磁盘:

  • 用 ossutil / coscli / aws s3 sync 做断点续传的批量上传。
  • 迁移后把应用里的本地路径改为 SDK 直传或 CDN 回源。
  • 注意设置正确的 Content-Type 与缓存头,否则浏览器可能出现下载而非预览。

切换怎么做?DNS 灰度与停机窗口

结论:切换用「低 TTL + 灰度权重 + 观察指标」三步,不要一次性改 A 记录。提前把域名 TTL 降到 60 秒,切换当天先放 1% 流量验证,再逐步放量。

bash
# 1) 切换前 48 小时:把 TTL 降到 60 秒(原 TTL 若是 3600,需等旧记录过期)
dig +short www.example.com A
dig www.example.com +noall +answer          # 关注 ANSWER SECTION 的 TTL

# 2) 用 hosts 文件做单机验证,绕过 DNS(在自己电脑上)
echo "<目标公网IP> www.example.com" | sudo tee -a /etc/hosts
curl -sS -o /dev/null -w 'code=%{http_code} time=%{time_total}s\n' https://www.example.com/

# 3) 切换后持续观察解析是否生效(多地区验证)
for i in 1 2 3 4 5; do dig @119.29.29.29 www.example.com +short; sleep 10; done
for i in 1 2 3 4 5; do dig @223.5.5.5   www.example.com +short; sleep 10; done

灰度的三种实现(按推荐度排序):

  1. 云负载均衡权重:新老机器同时挂载到 LB,按权重 1% → 10% → 50% → 100% 调整,可秒级回退。
  2. DNS 智能解析:按运营商 / 地域把部分线路解析到新 IP,粒度较粗但实现简单。
  3. Nginx 上游权重:在网关层配置 server 新IP weight=1; server 老IP weight=99;,改配置 reload 即可。

切换的四个硬要求:

  • 数据库只写一端。灰度期间绝不能出现新老库双写却不做冲突处理,否则数据会分裂。
  • 会话保持。如果用了本地 Session,灰度切换会导致用户反复登录,切换前先把 Session 改到 Redis。
  • 观察 30 分钟再放量。重点看错误率、P99 延迟、慢查询数、磁盘 IO。
  • 选业务低峰时段。国内业务通常选凌晨 1:00~5:00,跨境电商按目标市场时区选。

回滚预案怎么写?

结论:回滚预案的唯一标准是「源站还在、数据可回、流量能切回」三条同时成立。源站在切换完成后至少保留 7 天,且不删除数据。

触发条件判定方式回滚动作预计耗时
错误率 > 1%网关 5xx 占比监控LB 权重调回 0 / DNS 改回源站 IP1~5 分钟
P99 延迟上升 > 50%APM 或 Nginx 日志同上,再排查慢查询1~5 分钟
数据不一致校验脚本比对行数与 checksum停止写入,反向同步回源库30 分钟以上
关键功能不可用冒烟用例失败立即回滚,不排查1 分钟
云侧故障云厂商状态页 / 控制台告警切回源站,等云侧恢复1~5 分钟
bash
# 回滚前的数据一致性校验脚本(MySQL)
mysql -uroot -p -e "SELECT COUNT(*) AS rows_appdb FROM appdb.orders;" > /tmp/src.txt
mysql -h<目标库> -uroot -p -e "SELECT COUNT(*) FROM appdb.orders;" > /tmp/dst.txt
diff /tmp/src.txt /tmp/dst.txt && echo "行数一致" || echo "不一致,禁止切换"

# 校验表 checksum(精确但慢,建议只对核心表做)
CHECKSUM TABLE appdb.orders, appdb.users;

迁移检查清单表(照着勾选)

阶段检查项状态
评估服务器与依赖拓扑清单已输出☐
评估数据量与增量速度已测量☐
评估停机窗口已与业务方书面确认☐
评估目标云配额、备案、安全组规则已确认☐
准备目标环境已按相同系统版本初始化☐
准备运行环境(Nginx/PHP/JDK/Python)版本一致☐
准备主机名、时区、ulimit、内核参数已对齐☐
数据全量同步已完成并校验文件数一致☐
数据增量追平延迟已趋近 0☐
验证目标环境功能冒烟测试通过☐
验证压测 QPS 与源站持平或更优☐
切换域名 TTL 已提前降到 60 秒☐
切换灰度 1% → 10% → 50% → 100% 分步执行☐
切换每档观察 ≥ 30 分钟且指标正常☐
收尾源站保留 ≥ 7 天且未销毁☐
收尾监控、告警、备份已在云侧重新部署☐
收尾文档更新(IP、架构图、运维手册)☐
bash
# 收尾必查:云侧监控与备份是否真的在工作
systemctl status node_exporter --no-pager
crontab -l | grep -i backup
# 验证备份可恢复(不是只看文件存在!)
mysql -uroot -p testdb < /data/backup/appdb_20260601.sql && echo "恢复验证通过"

常见误区 / 排错提示

  1. 误区:rsync 一次到位就切。业务持续写入时,全量同步完仍有增量差,必须「停止写入 → 最后一次增量 → 切换」,否则丢数据。
  2. 误区:忘记降 TTL。TTL 若为 3600 秒,改解析后最长 1 小时才全网生效,切换当天才降 TTL 来不及,必须提前 48 小时。
  3. 排错:迁移后网站 502。多半是目标机应用进程没起来或端口不对,检查 ss -lntp 与 Nginx upstream 配置里的端口。
  4. 排错:迁移后文件权限报错。rsync 未加 -a 或目标机 UID/GID 不一致,用 --numeric-ids 并在目标机创建同名用户解决。
  5. 误区:切完立刻释放源站。至少保留 7 天,很多问题(如月末报表、定时任务)几天后才暴露。
  6. 排错:云主机访问不了源站内网服务。检查安全组是否放通、是否有 NAT 网关、以及应用配置里是否残留旧内网 IP(用 grep -r 全量搜一遍)。