背景与挑战
客户是华东区域的零售集团，线下 600 余家门店，线上有自营商城与多个第三方平台店铺。IT 系统在自建机房运行了八年，机房合同到期后房东不再续租，留给迁移的时间只有 6 个月，且不能影响门店营业和大促。
最麻烦的三件事：一是 ERP 跑在 Oracle 上，有大量存储过程；二是门店 POS 通过固定 IP 白名单访问总部接口，改动涉及 600 家门店的配置；三是原有架构文档严重过期，实际依赖关系没人能完整说清。
核心难点与解法
依赖不清
- 部署轻量采集脚本，连续 30 天记录全部主机连接关系
- 扫描所有配置文件，找出 214 处硬编码 IP
- 对 38 套系统的负责人逐个访谈，补齐人工流程依赖
- 最终还原出 7 条此前完全未被记录的隐藏调用链
Oracle ERP
- 评估后选择 Rehost 到 RDS for Oracle（BYOL），不做异构改造
- 理由：6 个月工期做不完 PL/SQL 转换，且 ERP 两年内计划整体换代
- 用 DMS + RMAN 组合完成数据迁移，全量后接 CDC 增量
- 上云后单独立项，两年内逐步迁往 PostgreSQL
门店 IP 白名单
- 在 AWS 侧配置固定 EIP 池，与原机房出口 IP 一一对应
- 通过 Direct Connect 保留一段过渡期的双向可达
- 门店侧改造分三批，用灰度域名逐步切换
- 保留原 IP 转发 60 天，覆盖长尾未升级门店
实施过程
-
01
第 1-4 周：评估与规划
资产盘点、依赖采集、TCO 测算、6R 策略定档，输出 8 个波次的迁移计划。
交付物：评估报告、依赖拓扑图、波次计划、TCO 对比
4 周
-
02
第 5-9 周：着陆区与网络
多账号结构、Transit Gateway 网络中枢、Direct Connect 专线打通、安全基线落地。
交付物：Landing Zone、专线双链路、IaC 代码库
5 周
-
03
第 10-13 周：试点波次
选内部办公与报表系统做试点，完整走一遍流程，沉淀 Runbook 与验证清单。
交付物：试点上线、标准 Runbook、改进项 23 条
4 周
-
04
第 14-20 周：批量迁移
每两周一个波次，先非核心后核心。每波次两次演练，第二次由客户团队主导。
交付物：6 个波次上线、演练记录
7 周
-
05
第 21-22 周：核心系统切换
ERP、订单、会员系统在同一窗口切换（强耦合，无法分开）。实际停机 1 小时 47 分。
交付物：核心系统上线、数据校验报告
2 周
-
06
第 23-24 周：优化与交接
Right Sizing、购买 Savings Plans、监控完善、运维交接与培训。
交付物：优化报告、运维手册、培训完成
2 周
架构升级点
| 系统 | 迁移前 | 迁移后 | 收益 |
|---|---|---|---|
| 核心 ERP | 单台物理机 + 冷备 | RDS for Oracle 多可用区 | 从小时级恢复到分钟级切换 |
| 订单中心 | 4 台物理机负载均衡 | EKS + HPA 弹性伸缩 | 大促无需提前扩容 |
| 会员系统 | MySQL 主从 | Aurora MySQL + 2 只读副本 | 读吞吐提升，报表不再压主库 |
| 商品图片 | 自建 Nginx + 本地磁盘 | S3 + CloudFront | 带宽成本降 64%，加载速度提升 |
| 数据报表 | 凌晨跑批，早上 9 点出 | Athena + QuickSight | 数据延迟从 T+1 降到小时级 |
| 备份 | 本地磁带 + 人工换带 | AWS Backup 跨区域自动 | 恢复演练首次通过 |
六个月这个时间我们内部一开始觉得不可能。真正做下来发现，关键是前面那一个月的评估做得够细。后面每个波次都按计划走，反而是最不惊心动魄的一个大项目。
上云之后
项目结束后客户续签了托管服务，上云后经历了两次大促。ERP 的异构迁移作为后续阶段单独立项。
技术栈
- EC2
- RDS for Oracle
- Aurora MySQL
- EKS
- S3
- Transit Gateway
- Direct Connect
- AWS MGN
- DMS
- CloudFront
- WAF