事情是这样的。上个月公司突然通知，要把所有业务从阿里云迁到腾讯云。原因是老板的朋友在腾讯云有资源置换，能省下每年十几万的开支。听起来很简单对吧？不就是把代码和数据搬过去，改个域名解析就完事。我当时也是这么想的，还跟同事吹牛说周五搞完周末不加班。
结果从周五下午两点开始，一直到周日凌晨四点，我盯着终端屏幕的眼睛都快瞎了。3台服务器，一台跑Nginx反向代理和前端静态资源，一台跑Node.js业务服务，还有一台是MySQL数据库。真正的生产环境，每天几万活跃用户那种。
先说最坑的第一件事。阿里云的ECS默认安全组策略和腾讯云完全不一样。我在腾讯云开了一台新机器，按照习惯先装好Nginx，配置文件都从旧机器拷过来了，结果curl localhost能返回页面，从浏览器访问就是Connection refused。查了半小时才发现，腾讯云新买的CVM默认安全组只开了22端口和ICMP。我把80和443加进去，页面倒是能打开了，但WebSocket连接全部报错。又翻了一遍文档，发现腾讯云的安全组规则里，WebSocket需要额外放通1000-20000这个端口段，因为它的负载均衡默认会随机分配端口做健康检查。这个细节阿里云文档里压根没提，我踩了个结结实实。
然后是数据库迁移。MySQL 8.0.28版本，数据量大概80G。我一开始图省事，用mysqldump导出再导入。导出用了20分钟，导入的时候直接卡在了一个大表上，等了两个小时没反应。查进程发现是因为腾讯云新机器的磁盘IOPS被限流了，默认的通用型SSD只有2000 IOPS，而阿里云那台是ESSD PL2，IOPS给到了10000。没办法，只能临时升级到高效型SSD，IOPS提到了5000，但还是慢。最后我换了个方案，用XtraBackup做物理备份，先全量备份传到腾讯云，然后做一次增量，最后用binlog追到切换时间点。这个方法靠谱，全量备份加恢复总共花了40分钟，增量用了5分钟。但注意一个坑：XtraBackup 8.0版本和MySQL 8.0的版本必须严格匹配，我用的是Percona XtraBackup 8.0.28，和MySQL版本一致才没报错。网上很多人说用8.0.30备份8.0.28会报”Failed to fetch dictionary”，我亲测确实不行。
最恶心的是Node.js业务服务的迁移。我们的服务用了PM2做进程管理，跑了6个实例。迁移的时候我直接把整个项目目录打包，scp到新机器，npm install重新装依赖。结果启动的时候报错，说某个native模块编译失败。查了日志发现是因为新机器的Node.js版本是18.16.0，而旧机器是16.20.0，bcrypt这个包的二进制文件不兼容。解决方案有两个：要么在目标机器上装build工具重新编译，要么直接用npm rebuild。我选了后者，跑了npm rebuild bcrypt –build-from-source，折腾了十分钟终于编译成功。但这里有个大坑：编译需要gcc和python3，腾讯云默认的镜像里没有装python3，我又apt install python3搞了半天。所以建议迁移前先在新机器上跑一下node -v和python3 –version，把环境对齐。
域名切换那块我以为最简单，改个DNS解析记录就完事。结果阿里云的DNS解析生效后，腾讯云的负载均衡一直报健康检查失败。查了半天发现，腾讯云CLB的健康检查默认用HTTP的80端口，但我们服务走的是HTTPS，Nginx配置里把80端口重定向到了443，健康检查请求被重定向了，腾讯云认为返回码不是200就判定后端异常。解决办法是在Nginx里单独加一个location给健康检查，返回200空响应。配置如下：
“`
location /health {
access_log off;
return 200 “OK”;
add_header Content-Type text/plain;
}
“`
这个坑在阿里云的SLB上不存在，因为阿里云的健康检查默认支持HTTPS。腾讯云需要手动改端口为443，或者像我这样加个健康检查接口。
最后是数据校验。迁移完后我写了个脚本，对比阿里云和腾讯云上MySQL的关键表行数和checksum。跑了三遍，发现有一张订单表的行数差了127条。排查下来是因为迁移过程中，阿里云那边还有新的订单写入，而我做增量备份的时候binlog没完全同步。解决办法是在切换窗口前十分钟，先把阿里云的服务停掉，等所有请求处理完，再做最后一次增量备份和binlog追平。这个时间窗口要算好，我们业务凌晨两点到四点流量最低，我就选了这个时间段，提前通知运维把阿里云的入口流量切到维护页面。
总结几个血泪教训。第一，迁移前一定要在新环境把安全组、IOPS、系统版本、依赖版本全部对齐，不要想当然。第二，数据库迁移别用mysqldump，数据量大就是给自己找罪受，XtraBackup加binlog追平是正解。第三，负载均衡的健康检查配置一定要看文档，不同云厂商的默认行为不一样，别指望它能自动适配。第四，数据校验要跑多轮，不仅看行数，还要看checksum，差一条都不能上线。第五，留足回滚时间，我提前把阿里云的机器保留了一周，万一腾讯云出问题还能切回去。
这次迁移让我对云厂商的差异有了切身体会。表面上看都是ECS、RDS、CLB，但细节坑多到能写一本《云迁移踩坑指南》。下次再有这种活，我一定先做个详细的迁移清单，每个步骤的预期耗时和回滚方案都写清楚。毕竟周末不加班才是打工人的终极追求。
📎 延伸阅读
看完这篇，如果你想：
- 直接拿工具 → 回复”13“，我把跨境获客工具包发给你
- 系统学习 → 点击菜单”AI训练营”，从0开始跑通AI变现