把服务器搬到另一台机器上，说起来就是把文件拷过去。真做起来，卡住人的通常是三件事：环境依赖没对齐，数据库之间的数据对不上，域名切换后用户访问时断时续。第一次做腾讯云服务器迁移到另一台服务器的人，大多会碰到漏装组件、数据库没同步、访问短暂中断这几类问题。下面按顺序走一遍流程，并用一个小团队的案例说明每一步要注意什么。
迁移前先把家底盘清楚
动手之前，先把旧服务器的情况摸一遍。多数迁移出问题，往往是某个不起眼的依赖被漏掉了。
盘点资源与依赖
- 记下操作系统版本、内核信息、公网和内网 IP，以及所在地域和可用区。新机器的地域和规格先想清楚，后面很多选择都由它决定。
- 列出正在运行的服务，包括 Web 服务、数据库、定时任务（crontab）和守护进程。定时任务最容易被忽略，因为它平时不出现在页面上。
- 检查 /etc/hosts、系统环境变量和防火墙规则。这些配置往往是多年前某次手动改的，文档里没有，只能看机器本身。
- 确认数据放在哪里，区分系统盘和数据盘，统计总容量和每天的增长速度。增长速度决定了全量同步要多久，也决定了增量同步会积压多少。
确定迁移窗口
迁移一般分成全量同步和增量同步两段。全量同步可以提前做，不影响线上。切换当天只需要同步最后那一小段变化的数据，停机时间能压到几分钟。如果业务有明显的低峰时段，就把切换放在那段时间，出了问题也好收拾。
三种迁移方式怎么选
常见做法大致有三种：
- 自定义镜像迁移：在原服务器上制作自定义镜像，再用它在新地域或新规格下创建实例。系统环境简单、组件统一的时候最省事。
- 快照加数据盘挂载：分别给系统盘和数据盘创建快照，把快照生成的云硬盘挂到新实例上。数据量大、又想尽量保留原始状态时比较合适。
- 应用层同步：用 rsync 同步网站文件，用数据库自带的主从复制或导出导入来同步数据。需要跨账号、跨地域，或者只迁移一部分数据时用这种方式。
三种方式没有绝对的好坏。镜像迁移省事，但原机器上遗留的配置也会一起带过去，包括那些早就不用的东西。应用层同步干净，但步骤多，每一步都可能出错。选哪种，主要看团队更熟悉哪套工具，以及业务能不能接受切换时多花的时间。
案例：一个小电商站的迁移过程
某个做手工饰品的小团队，网站跑在一台 4 核 8G 的腾讯云服务器上。数据库是自建的 MySQL，另外挂了一块 200GB 的数据盘，用来存商品图片和订单导出文件。原机房配置老旧，他们决定把服务迁到另一台新规格的服务器上。
具体做法分四步。第一步，在新服务器上部署同样版本的 Nginx、PHP 和 MySQL，并核对各项扩展是否一致。第二步，用 rsync 把图片目录做一次全量同步，耗时约两个小时。第三步，在数据库上开启主从复制，让新库持续跟随旧库更新。第四步，选在凌晨两点的低峰期，先把旧站点设为只读，等复制延迟归零，再修改域名解析，把记录指向新服务器的公网 IP。整个切换过程中，用户能感知到的中断大约四分钟。
这次迁移里最让人头疼的是 DNS 缓存。部分用户本地的解析记录仍指向旧 IP，所以团队把旧服务器又留了一周，等访问量基本降到零才关机。这段缓冲期帮他们避免了订单丢失。如果只看切换那几分钟，很容易低估这个环节。
切换流量与回滚方案
切换之前就要把回滚步骤写好，不能等出事了再想。比较稳的做法是：
- 提前把 DNS 记录的 TTL 调低到 300 秒，让改动更快生效。TTL 太高的话，回切也会拖很久。
- 保留旧服务器至少一周，数据库保持可读，随时可以切回去。
- 切换后盯住错误日志、响应时间和订单数量。出现异常就立即回切，不要边查边等。
如果域名托管在腾讯云 DNSPod，直接在控制台改记录即可，改动即时生效。回滚时同样只需改回原来的记录，服务器本身不用动。
迁移后的检查清单
- 逐个访问核心页面，登录、下单、支付回调都要走一遍。支付回调最容易漏，因为平时测试很少覆盖它。
- 确认定时任务在新服务器上正常执行，同时检查旧机器上的任务已经停掉，避免两边重复运行，比如同一批订单被发两次通知。
- 核对数据库的记录数和关键表的校验值，确认数据完整。
- 更新安全组和防火墙规则，只开放必要端口，并确认备份策略也已经迁过去。
- 停掉旧服务器上的服务，但在确认无误之前不要急着释放实例。
服务器迁移是一个有先后顺序的过程，前期盘点得越细，切换时越从容。涉及数据库和订单的业务，最好先在测试环境完整演练一遍，再进入正式切换。
