云迁移 6R 策略
6R 迁移策略：Rehost/Replatform/Repurchase/Refactor/Retire/Retain 的决策、执行与 TCO 评估。
前置知识与学习目标
「要不要上云、怎么上云」不是一个问题，而是每个应用各自的问题： 存量系统里既有三年没动过的遗留单体，也有本该下线却没人敢删的僵尸 服务。6R 策略（源自 AWS 迁移框架，业界通用的扩展版本还有 7R——多了 Relocate）给每个应用一个迁移「处方」。
完成本文后，你应当能够：为单个应用判断适用哪个 R；估算迁移的 TCO 与 风险；理解数据迁移与切换验证这两个最难环节。
1. 六个 R 全景
| 策略 | 一句话 | 改动量 | 典型周期 | 适合 |
|---|---|---|---|---|
| Rehost 重新托管 | 原样搬（lift & shift） | 几乎为零 | 天-周 | 快速下机房 |
| Replatform 平台替换 | 小改造换托管件 | 低 | 周 | 想吃托管红利 |
| Repurchase 重新购买 | 换 SaaS 产品 | 中（数据迁移） | 周-月 | 商品化能力 |
| Refactor 重构 | 深度改造上云原生 | 高 | 月-年 | 核心且长生命周期 |
| Retire 退役 | 下线不再需要 | - | - | 僵尸应用 |
| Retain 保留 | 留在原地 | 零 | - | 合规/临退休 |
关键认知：成熟企业的迁移组合是 6R 的混合，而不是全量某一种。 行业普查的常见分布大致是：Rehost 与 Retain 占大头，Refactor 只留给 少数高价值应用——「先整体 Rehost 落地，再按需渐进优化（Replatform/ Refactor）」是风险可控的主流路径。
2. 六个 R 逐个拆解
2.1 Rehost：搬机器，不改代码
把物理机/虚拟机的镜像直接搬到云上（VM 导入工具，如 AWS Application Migration Service、Azure Migrate）。价值在快速结束机房合同；代价是 带着旧架构的缺点上云，前期往往「成本不降反升」。适合大量同质化的 存量系统。
2.2 Replatform：小手术换托管件
改动小但吃到托管红利：自建 MySQL 换 RDS、自建 MQ 换托管队列、 Tomcat 挂到容器平台。代码基本不动，主要是换掉运维重的中间件。 性价比最高的策略之一，适合多数中型应用。
2.3 Repurchase：不迁移，改采购
自建的邮件/CRM/工单系统，改用 SaaS（Salesforce、飞书、Workday）。 迁移的实质变成数据搬家 + 集成改造。判断标准：这个能力是不是 商品化的？商品化的东西自建就是负债。
2.4 Refactor：为云重新设计
把单体改造为微服务、改造为云原生架构，吃弹性伸缩、按量计费、 高可用的全部红利。成本与风险都最高，只值得投给：生命周期长、 业务波动大（弹性收益高）、且属于核心竞争力的应用。通常不是 「迁移前重构」，而是「先 Rehost 上云，再按业务节奏重构」。
2.5 Retire：发现的 10-20% 可以直接删
迁移评估的意外收获：盘点后发现有两位数百分比的应用其实没人用了 （业务下线了但系统还在跑）。直接退役，省下的预算补贴其他迁移。
2.6 Retain：光明正大地不动
因合规（数据必须留在本地）、许可证锁定、即将退役等原因暂不上云。 保留也是决策——把它写进迁移计划并定期复审，而不是无人负责地遗忘。
3. 迁移评估：决定每个应用走哪条 R
3.1 应用画像（评估维度）
| 维度 | 关键问题 | 指向 |
|---|---|---|
| 业务价值 | 还有多少活跃用户/交易？ | 低 -> Retire |
| 技术栈 | 中间件是否可替换为托管？ | 可 -> Replatform |
| 架构耦合 | 与其他系统的接口数量 | 高耦合 -> 先 Retain/Rehost |
| 数据引力 | 数据量与迁移窗口 | TB 级 -> 在线复制方案 |
| 合规约束 | 数据能否出本地/出境 | 不能 -> Retain/托管私有云 |
| 生命周期 | 还有几年寿命？ | < 2 年 -> Rehost 或 Retain |
3.2 TCO：别只比较电费
迁移 TCO 至少要含：计算存储网络费用、迁移工具与专线费、双跑期费用
（新旧环境并行 1-3 个月）、人力投入、上云后的运维组织变化、以及
预留/节省计划的采购策略。只拿「服务器电费 vs 云账单」比较会得出
「上云更贵」或「上云巨省钱」两个都错的结论。稳态负载的长期 TCO
未必低于自建（见 030-PublicCloudPrivateCloudHybridCloud），弹性负载
才有数量级优势。
3.3 风险评估
- 技术风险：OS/中间件版本过老，云平台不再支持 -> 升级先行；
- 数据风险：迁移窗口内的一致性（双写/停写）；
- 组织风险：运维团队技能转型，配合迁移安排培训。
4. 迁移执行：三个最难环节
4.1 分批迁移（Wave 规划）
Wave 1（试点）：低风险、独立的应用，验证流程与工具
Wave 2（主体）：按业务域分批，每批保留回退窗口
Wave 3（攻坚）：强耦合核心系统，待依赖迁完后进行依赖关系决定批次顺序：先迁「被依赖少的」，核心系统放最后。每个 Wave 都要设定明确的成功标准（性能基线、错误率、回退触发条件）。
4.2 数据迁移：最后一公里决定成败
| 方案 | 原理 | 适用 |
|---|---|---|
| 离线搬运 | 停机导出导入/物理设备 | 小数据量、可停机 |
| 在线复制 | CDC 持续同步（如 DMS） | 大数据量、小停机窗口 |
| 双写过渡 | 新旧库同时写再校验 | 高一致性要求（复杂度高） |
数据库迁移的标准姿势是 CDC（变更数据捕获）：先全量复制，再持续追 增量，切换时只需分钟级停写。大文件用离线设备（如 Snowball 类）， 避免走公网既慢又贵。
4.3 切换验证与回退
灰度切流（DNS 权重/LB 权重 1% -> 10% -> 50% -> 100%）
→ 每档观测核心指标：错误率、延迟、业务转化
→ 定义回退触发线（如错误率 > 1% 持续 5 分钟）
→ 回退预案演练过至少一次（没有演练过的回退方案等于没有）切换窗口选择业务低峰，保留旧环境完整运行至少 1-2 周再下线—— 这是你唯一的后悔药。
小结
- 初学者要点：6R 是按应用逐个选的「处方集」；多数企业的现实组合是 Rehost 为主 + Retire/Retain 收尾 + 少数 Refactor；评估看业务价值、 耦合度、合规与生命周期四个硬约束；执行上分 Wave 试点先行、数据 用 CDC 在线复制、灰度切流 + 演练过的回退预案。
- 进阶注意：Rehost 的常见后续是「成本不降反升」，要在上云后跟进
Right-sizing 与托管化改造（见
240-CloudCostOptimization）；TCO 必须 含双跑期与人力，弹性负载才谈得上数量级节省；核心系统的 Refactor 最好按业务节奏分阶段做，避免「大爆炸式重构 + 搬家」双重风险叠加。