阿里云迁移前先查什么？数据库、域名和费用别漏

企业上云已经不是要不要做的问题，难点在于怎么做得稳。不少团队做阿里云迁移时只想着把服务器搬过去，做到一半才发现网络割接出了问题、数据对不上、账单超出预期，最后不得不返工。下面按迁移的实际顺序，讲讲每个阶段该查什么，以及容易踩的坑。

迁移前先盘点家底

很多项目出问题，根子在于没人说得清老系统之间是怎么连在一起的。开工前至少要整理三类信息：

盘点完成后，可以用阿里云提供的迁移评估工具扫描主机和数据库，得到规格建议和成本预估。评估结果只能当参考。最终规格还要靠压测数据来定，别直接照着推荐值下单。

常见的迁移方式大致分三类，选哪一种，主要看业务能承受多少改动。

整体迁移（Lift and Shift）：应用基本原样搬到云上。改动最小，周期最短，但云上的弹性和托管能力用得不多。
重构迁移（Re-platform）：例如把自建 MySQL 换成云数据库 RDS，把自建缓存换成 Redis 托管服务，应用代码基本不动。这类改动通常只涉及连接配置和少量驱动调整，但仍要完整测一遍。
重写迁移（Refactor）：把单体应用拆成微服务，引入容器或 Serverless。收益最大，投入和风险也最高，适合已经有明确改造计划的团队。

很多团队采用两步走：先用整体迁移尽快上云，拿到弹性和运维上的好处，再按优先级逐步重构。这样不会一次性改动过大，出了问题也更容易定位。

一家中型连锁零售企业原来由本地机房的三十多台服务器支撑，包括订单、库存、会员和报表四大模块。迁移分三个阶段进行。

团队先搬了报表和内部管理后台。这两类系统对实时性要求不高，出了问题影响有限。这一阶段主要用来练手：熟悉 VPC 网络规划、安全组配置，以及跨地域访问的细节，同时验证备份和回滚脚本能不能真正跑通。

库存和订单数据库是整个项目里最难的部分。团队用数据传输服务 DTS 先做全量拷贝，选在业务低峰期完成，之后持续同步增量数据。切换前两周，每天核对一次数据差异，重点看主键、时间戳和金额字段是否一致。最终切换窗口控制在四十分钟以内。

应用层通过负载均衡的权重配置，先把 5% 的流量导到阿里云，盯住错误率和响应时间，没有问题再逐步加到 100%。原机房保留两周作为回退通道，确认没有异常才正式下线。

这个案例里的做法可以直接参考：先迁低风险系统积累经验，数据库迁移要有可度量的一致性校验，灰度切换比一次性切换更容易控制风险。

云上费用最容易在第一个月账单出来时才被发现。迁移前，建议把原机房的硬件折旧、机房租用、网络线路和运维人力摊到每月，和云上的预估放在一起比较。云上计费要分清按量付费和包年包月：长期稳定运行的服务适合包月，波动大或临时使用的资源适合按量。

上线当天就配置预算告警，不要等月底。按量计费的实例如果长期闲置，费用会悄悄涨上去，而且很难从账单上直接看出是哪台机器。

域名要列出所有解析记录，包括 A 记录、CNAME、内网解析和子域名。切换前一两天把 DNS 记录的 TTL 调低，真正切换时生效更快，回退也更快。证书要确认是否绑定了旧 IP 或旧负载均衡，到期日也要记下来，避免切换后出现证书报错。

数据库除了数据本身，还要检查存储过程、触发器、用户和权限是否都已迁过去。数据量大时，全量同步的耗时要提前测一次，别等到切换窗口才发现拷贝跑不完。

上线只是第一步。接下来要用云监控建立核心指标的基线，用弹性伸缩应对流量高峰，并定期检查预留实例和节省计划是否还适用。团队对云环境熟悉之后，再推进容器化和服务拆分，会顺利得多。