拉卡拉开放平台

服务换个地方跑，代码没变，但环境全变了。很多迁移后的诡异问题，根源都在这些变了却没被注意的地方。

一、网络出口

新服务器的出口地址与原来不同，如果对方侧有地址限制，请求会被直接拒绝。

• 确认新的出口地址是否已告知相关方；
• 确认是否需要加入白名单；
• 确认出网策略是否放通。

二、时间同步

时间不准会导致一批请求莫名其妙被拒，而且时好时坏，排查成本极高。

迁移后第一件事就应当确认时钟同步正常。

三、凭证部署

四、回调可达

这是迁移后最容易出问题的地方：请求能发出去，但通知收不回来。

1. 确认新地址已更新到配置中；
2. 确认新地址对外可访问；
3. 实际发起一次测试，确认能收到。

第三步不能省：配置看起来对，不代表真的能收到。

五、依赖地址

除了主接口，系统可能还依赖其他地址：时间同步源、日志收集、监控上报、文件存储等。逐一确认连通性，避免部分功能静默失效。

六、日志通路

日志写不出来是最危险的一种迁移后遗症：系统照常运行，但出问题时没有任何线索。

• 确认日志目录存在且有写入权限；
• 确认日志能被正常采集；
• 确认磁盘空间充足。

迁移后的加密观察期

建议在迁移后安排一段时间的高频观察：

保留回退窗口

迁移完成后不要立刻下线旧环境，保留一段时间作为回退通道。这段窗口的存在，能让迁移从一次冒险变成一次可控的变更。

一份迁移检查清单

迁移后常见问题的对照

• 部分请求失败：多为网络出口未放通；
• 请求被批量拒绝：优先查时间同步与凭证；
• 业务正常但状态不更新：查回调可达性；
• 一切正常但查不到记录：查日志通路。

这四条对应关系，能覆盖迁移后大多数现象，值得记在团队的迁移文档里。

迁移也是一次梳理机会

借迁移把依赖关系重新梳理一遍，往往会发现一些早已无人维护、却仍在被调用的东西。清理掉它们，系统的可维护性会明显提升。

文档同步更新

迁移完成后，应当同步更新所有记录了旧地址、旧配置的文档。文档滞后会在下一次变更时造成新的混乱。

迁移的本质是一次受控的环境重建。把所有检查项走一遍，迁移就从赌运气变成了按步骤执行。