业务迁移到新机器想要不中断，核心策略是“先并行、再切换、后回收”，用灰度切换替代停机搬迁，把回滚方案提前写好。
做迁移最怕的不是技术难题，而是“以为切完了，结果旧机器上还跑着定时任务”，我这几年帮不少团队收拾过迁移烂摊子，总结下来，所有中断事故都源于三个疏忽：没梳理清依赖、没校验数据一致性、没留好回滚路，下面按迁移的完整流程拆开讲,每一步都有可以直接照做的操作。
业务迁移到新机器如何避免中断，先想清楚再动手
迁移的第一步不是买机器，而是画图，打开终端，把当前机器上的所有服务列出来，别凭记忆,用命令查：
- 查监听端口：
netstat -tlnp或ss -tlnp，看看哪些服务在跑 - 查定时任务：
crontab -l，重点看有没有跑批任务、备份脚本、日志清理 - 查环境变量：
env，有些应用依赖全局变量，换机器后容易忽略 - 查域名解析：
dig或nslookup，弄清楚当前机器绑定了哪些域名
把这些信息整理成一张依赖关系图，标出应用、数据库、缓存、消息队列之间的调用关系。如果你不清楚某个服务为什么存在，那就先别动它。
接下来明确迁移目标，换更高配置的机器、换机房、还是从物理机迁到云主机，策略完全不同，换配置简单，换机房要考虑网络延迟，上云要考虑安全组和VPC网络，同时评估业务峰值时段，电商类业务避开大促，账务类业务避开月末结账,这是行业共识。
服务器迁移不停机方案：蓝绿部署、滚动迁移还是双写同步
想要业务不感知中断，有三种主流做法，按业务形态选择,没有万能方案。
蓝绿部署，适合单机或小集群业务
搭一套跟旧环境配置几乎一致的新环境（绿环境），把代码、配置、依赖全装好，然后旧环境（蓝环境）继续服务，新环境先做内部验证，验证通过后,通过负载均衡器或DNS加权把流量切到新环境。
- 切换速度：秒级
- 回滚方式：再切回蓝环境
- 前提条件：需要两套资源并存一段时间
这里的细节是，DNS切换有TTL缓存，提前把TTL从3600调低到300秒，给切换留出缓冲时间，如果用了Nginx或SLB，直接改上游服务器列表就行,比DNS更可控。
滚动迁移，适合多节点集群
业务本身有多台机器在跑，那就一台一台迁，先拿一台新机器加入集群，观察它的CPU、内存、错误率表现正常后，再摘掉一台旧机器，如此往复,直到全部替换。
- 切换时间：完全无感知
- 回滚方式：把新机器从集群摘掉，旧机器重新接回
- 前提条件：集群本身有冗余能力，单台故障不影响整体
滚动迁移看起来很平滑，但有个坑：如果集群里跑了有状态服务（比如WebSocket长连接、定时任务调度），直接加节点可能导致任务重复执行，建议先把调度器或会话共享方案处理好,再做滚动。
双写同步再加延迟切换，适合数据库迁移
数据库迁移是中断事故的高发区，应用同时往旧库和新库写数据，旧库作为主库继续读，新库实时同步，观察一两天确认数据一致，再把读写流量切到新库，业内专家指出，双写期间务必在应用层加日志，记录每一次写入的返回状态，一旦发现新库写入失败,立刻报警。
三种方案对比如下：
| 策略 | 适用场景 | 中断时长 | 实施复杂度 | 典型成本 |
|---|---|---|---|---|
| 蓝绿部署 | 单机/小集群 | 秒级 | 中 | 两套资源费用 |
| 滚动迁移 | 多节点集群 | 零 | 中高 | 逐步替换，成本可控 |
| 双写同步 | 数据库迁移 | 分钟级 | 高 | 额外开发量较大 |
业务系统迁移到新服务器注意事项：备份、域名和回滚
备份要当作“没有备份”来对待
很多人备份就是打个tar包扔在机器上，真出事才发现文件损坏、或者改漏了数据目录,正确的做法是：
- 应用目录全量打包，排除日志和缓存目录（比如
/var/log、/tmp） - 数据库用工具做物理备份或逻辑备份，并保存binlog或WAL日志文件
- 备份文件至少放到两台机器上，或者传一份到对象存储
备份之后一定要做一次恢复演练，不验证的备份等于没备份,这句是我在每一次事故复盘里都要强调的。
域名和证书：提前部署，切换时别慌
- 新机器上提前申请好SSL证书，别等切了流量才发现证书没装
- 检查应用配置文件里的域名/IP清单，很多微服务配置了固定的注册中心地址，换机器后必须同步修改
- 内部搞一套hosts解析或者在内网DNS配好测试域名，先用测试域名跑通新环境
回滚方案要提前写成文档
回滚不是靠记忆，是看文档,写清楚：
- 回滚第一步做什么（通常是切回旧负载均衡）
- 数据如何处理（是否有增量数据需要同步回旧库）
- 哪些外部接口需要重新调用（比如第三方回调地址变更）
- 回滚后的验证命令快照
数据库迁移到新机器怎么保证数据一致性
数据库迁移的核心问题就一个：如何保证新库的数据和旧库一模一样，并且在切换瞬间不丢数据。
看数据量决定备份方式
- 数据量在百GB以内：用
mysqldump或pg_dump逻辑备份，操作简单，可读性好 - 数据量在TB级别：用物理备份工具，MySQL用
xtrabackup，PostgreSQL用pg_basebackup，速度比逻辑导出快数倍 - 数据量在百GB以下但要保持持续增量：先做全量备份，再配置主从同步，追平后逐步切换
校验数据：数行数只是入门
只对比行数远远不够，行数一致不代表数据没损坏,建议：
- 用
pt-table-checksum工具（Percona出品）逐行校验MySQL数据一致性 - PostgreSQL可对比逻辑复制或块级校验，至少对比主键和关键字段的MD5值
- 手工抽样验证核心业务表，比如订单表、用户余额表、流水表,抽样比例不应低于5%
- 校验完成后，记录旧库和新库的最终一致点（binlog位置或LSN编号）
切换时机的细节：追平再切，别急着抢时间
- 频繁写入的业务，必须等到新库的同步延迟归零后再切换
- 切换前停写或切只读，确认无新写入后，快速改应用连接串
- 切换后保留旧库实例运行至少48小时，期间如果新库出问题，还能回退
千万不要做完同步就直接关机旧机器，我见过不止一次，切换当天没事，第三天凌晨发现新库的某个存储过程没有迁移过去，旧库早就关了,只能翻备份。
迁移服务器大概需要多少钱：自己动手还是请人代劳
很多人在迁移前最关心的就是成本,大致是这几块：
硬件/云资源费用
自建机房要一次性买服务器、交换机、机柜空间，还要考虑机房托管电费和带宽费用，用云服务器则按年或按量付费，弹性更好，据统计，中小规模业务上云后的总体持有成本通常比自建低,原因是不用养冗余的硬件和专门维护机房。
人力成本：最大的隐性支出
运维团队自己迁移，主要花的是工时，一个业务系统完整迁移，包括备份、同步、校验、切换、观察，往往要投入2-5人天，如果是核心交易系统,还要加上加班和反复测试的时间。
请外部服务商迁移，市场报价从几千元到数万元不等，小规模单机迁移几千元就能谈下来，涉及多套系统、数据库双写、跨机房同步的，报价往往2万起，北京、上海这类一线城市的服务商报价会略高，但远程迁移做得好的团队跟地域关系不大，真正影响价格的是你的数据量和业务复杂度,不是物理距离。
迁移期间的隐性成本
切换窗口内业务降级或暂停造成的收入损失，这部分成本很多团队没有提前计算，选择在业务低谷期迁移,本身就是省钱的方式。
迁移后的验证与收尾：确认新机器能扛事再放手
切换完成不等于迁移完成,我建议按照以下清单逐项验证：
功能完整性验证
- 核心交易链路：下单、支付、回调，完整走一遍
- 登录鉴权：SSO（单点登录）流程是否正常
- 定时任务：观察一个完整执行周期，确认没有重复执行或漏跑
- 消息队列：生产消费正常，积压量在合理范围
- 日志链路：应用日志、访问日志都能正常落盘并接入采集系统
监控和告警覆盖
- 新机器的CPU、内存、磁盘、网络监控是否已接入
- 关键应用指标（错误率、响应时间、QPS）是否有了告警阈值
- 数据库连接数、慢查询数量是否在预期范围
流量放量节奏
- 先切5%的流量，观察30分钟
- 确认无异常后切到30%
- 稳定运行一天后再切到100%
- 全量切换后，至少保持新环境运行1-2周，再回收旧机器
业务迁移这件事的本质是风险控制，把并行切换、数据校验、灰度放量这三件事做到位，中断自然可以避免，别指望一次性完美切换,要指望每一步都有退路。
业务迁移常见问题解答
业务迁移到新机器一般需要多长时间？
取决于业务复杂度和数据量，小规模单机业务，准备充足的话几小时内就能完成切换；涉及多套系统、TB级数据量的迁移，通常需要1-2周进行准备和演练，真正切换只占用分钟级窗口,大头在准备环节。
迁移到新机器后旧机器怎么处理？
建议保留1-2周，确认新环境稳定、无数据回写需求后再回收，如果过渡期存在双写，旧机器上的新增数据要回流或明确丢弃，避免后期发现数据不一致，直接格式化重装要谨慎,等业务稳定运行满一个月再做物理处置更稳妥。
数据库迁移和应用程序迁移能同时进行吗？
可以但不推荐，应用和数据库同时切换，出问题后很难定位是应用配置错误还是数据同步滞后，排查范围成倍扩大，推荐分两步：先迁移数据库，应用层只改连接串指向新库；验证通过后再迁移应用本身,每一步都能快速回滚。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/626395.html
