一、迁移前的准备工作
1. 先模拟和测试
不要直接在目标服务器上开干。先在测试环境完整搭建一遍，包括 K8s 集群、EMQX、数据库、反向代理、证书等所有组件。搭建过程中遇到问题及时记录，形成文档，正式迁移时照着文档执行即可。
模拟搭建时必须做完以下测试：
- 压力测试（连接数、数据量、集群间通讯等）
- 大小消息响应速度测试
- 持续性测试，观察内存和 CPU 是否持续上涨
- 检查是否有内部通信走了公网流量
- 模拟服务器彻底宕机后重启，验证各程序能否自动拉起、集群能否自动恢复，确保不会到了紧急情况下还要手动介入
2. 清理旧服务器
迁移是清理历史包袱的好时机：
- 清理用不到的域名、过期证书
- 清理不再维护的旧程序、测试程序
- 关闭所有对外开放端口，仅开放必需的端口号
旧服务器长期运行后往往积累了大量历史残留，直接原样照搬只会把问题也带过去。
3. 记录关键基线数据
迁移前记录旧服务器的关键运行指标，便于迁移后对比判断是否有设备连不上或数据丢失：
- MQTT 在线连接数、每秒消息数、订阅主题数量
- 各服务 CPU、内存占用情况
这些数据是迁移后快速判断“是否正常”的参考基准。
4. 统一用 Docker 或 K8s 管理
建议所有非临时性程序都放在 Docker 或 K8s 中运行。好处有三：
- 安全隔离：各服务独立运行，互不影响
- 统一管理：程序和数据集中存放，日后再次迁移时不会因为“东一点西一点”而遗漏
- 自动恢复：配合健康检查和重启策略，服务宕机后可自动拉起
5. 做好回滚预案
迁移前必须确保能够快速回退。保留旧服务器至少到迁移验证通过后再释放。一旦新环境出现严重问题，切回旧环境不应超过几分钟。
6. 提前告知用户和内部同事
明确告知销售同事：迁移对用户的影响几乎可以忽略（设备会自动重连）。避免内部一出问题就往“是不是迁移服务器导致的”上靠，防止不必要的恐慌和排查成本。
7. 注意旧服务器升级的“政策坑”
某些旧服务器升级或续费后会走新政策。例如阿里云和腾讯云，以前不会限制上行带宽，但升级下行带宽后反而把上行限制到 30M，导致服务器卡顿。当时就因为这个排查了很久才发现是平台政策变更——花钱反向升级。
迁移时如果涉及旧服务器续费或临时升级，建议先查清当前的带宽政策。
二、迁移过程中
1. 逐步切换负载均衡
不要一次性把所有流量切到新服务器。先调整 DNS 负载均衡的权重，让新服务器承接小部分流量，观察一段时间无异常后再逐步增加。
三、迁移后要做的事
1. 对比迁移前后各项指标
对照迁移前记录的基线数据，逐一核对：
- MQTT 在线连接数是否接近
- 消息吞吐量是否正常
- 各服务 CPU、内存占用是否在预期范围内
如有明显差距，排查是否有设备连不上或服务异常。
2. 实施节点疏散
先迁移的服务器往往会承接大量连接。迁移完成后需做节点疏散，避免单节点压力过大：调整 DNS 负载均衡权重，逐步将连接分摊到其他节点；必要时踢出长连接用户让其重连，自然分配到其他节点。
3. 持续监控
迁移完成后持续观察公网流量、CPU 和内存上涨情况，确认没有隐藏问题。
4. 保留旧服务器一段时间
迁移完成后也需要保留旧服务器一段时间，以防某些东西忘记迁移或者少了一些数据。要注意旧服务器必须关机，这样某些服务没有迁移就能够被动的发现。
四、踩过的坑总结
- 反向升级：服务器升级配置后反而触发新带宽政策，上行被限制，花钱反向升级，越升级越卡。
- 内部服务走公网：旧环境长期积累的配置问题，多个服务间用了公网通信，浪费带宽且不稳定。
- 遗漏小服务：没放进容器的脚本和临时程序容易被忘掉，迁移后才发现功能缺失。
- 人心慌慌：迁移期间什么小问题都会被怀疑跟迁移有关，提前统一口径能省很多事。