2、迁移评估框架：应用画像、依赖关系梳理、迁移可行性评估（7R模型）
说实话，很多团队做多云迁移，第一步就栽了。
他们上来就问：“我们用哪个工具？AWS还是Azure？”
我通常会拦住他们。先别急。你连自己要搬的东西长什么样都没搞清楚，谈什么工具？
这一章，我们就聊聊迁移前必须做的三件事：应用画像、依赖关系梳理、迁移可行性评估。这三步走扎实了，后面的路才走得稳。
2.1 应用画像：搞清楚你的“家底”
应用画像，说白了就是给你的每个应用做个体检。
我见过最典型的翻车案例：某团队迁移一个“轻量级”Web应用，结果发现它背后挂着20TB的日志数据。嗯，迁移计划直接重做。
画像要画哪些维度？我列个清单：
- 资源消耗：CPU、内存、磁盘IO、网络带宽。别只看峰值，要看P99分位值。
- 运行时特征：是有状态还是无状态？是实时交互还是批处理？
- 技术栈：语言、框架、中间件、数据库。注意版本号，差一个minor版本都可能出问题。
- 数据量级：存量数据多大？日增量多少？数据冷热分层情况如何？
- SLA要求：可用性几个9？RTO/RPO是多少？
核心原则：画像不是一次性的。我建议在迁移前至少做两轮——第一轮粗筛，第二轮针对高风险应用做深度扫描。
举个例子。我之前帮一家金融科技公司做评估，他们有个核心交易系统。粗筛时只看到CPU利用率30%，觉得挺轻松。结果深度扫描发现，这个系统每秒钟有2000次数据库写操作，而且对延迟极其敏感。这种应用，你直接lift-and-shift到公有云，大概率会出问题。
2.2 依赖关系梳理：别让“隐形线”绊倒你
应用画像做完了，你以为就完了？
远远没有。你还要搞清楚：这个应用跟谁说话？
依赖关系梳理，是迁移评估里最容易被低估的环节。我曾经见过一个团队，迁移一个看起来完全独立的报表系统。结果上线后，整个公司的订单系统挂了。为什么？因为那个报表系统偷偷调用了订单系统的内部API——没人知道，文档里也没写。
梳理依赖关系，我一般分三步走：
- 网络层面：抓流量，看这个应用访问了哪些IP、端口、域名。工具可以用tcpdump、Wireshark，或者服务网格的流量监控。
- 代码层面：扫描源码，找出所有的RPC调用、消息队列订阅、数据库连接串。别信文档，信代码。
- 运行时层面：在测试环境模拟流量，观察实际调用链。这一步能发现很多“幽灵依赖”——那些只在特定条件下才触发的调用。
| 依赖类型 | 典型例子 | 迁移影响 |
|---|---|---|
| 强依赖 | 数据库、核心API | 必须同步迁移，否则系统不可用 |
| 弱依赖 | 日志收集、监控告警 | 可异步迁移，短期降级可接受 |
| 外部依赖 | 第三方SaaS、公共DNS | 需确认迁移后网络可达性 |
注意：我曾经遇到过一个案例，应用依赖了一个内部DNS解析，迁移后新环境DNS配置没同步，结果所有服务发现都挂了。所以，依赖梳理一定要包含基础设施层面的依赖——DNS、负载均衡、证书、NTP，一个都不能少。
2.3 迁移可行性评估：7R模型帮你做决策
画像有了，依赖清楚了。接下来就是关键问题：这个应用，到底怎么搬？
业界有个成熟的框架叫7R模型。我每次做评估，都会拿这个模型过一遍。
7R分别是：
- Rehost（重新托管）：也叫“lift-and-shift”。直接搬，不改代码。适合那些技术栈老旧、但运行稳定的应用。我个人的经验是，这类迁移最快，但长期来看成本可能最高——因为你没利用云原生的弹性优势。
- Replatform（平台重构）：做少量修改，比如换数据库版本、改中间件配置。适合那些需要一点云优化、但不想大改的应用。
- Refactor（重构）：大规模修改代码，比如拆成微服务、改用容器化部署。适合那些需要长期演进的核心业务系统。
- Repurchase（重新购买）：干脆不用自研了，直接买SaaS产品。比如把自建的CRM换成Salesforce。这个选项经常被技术团队忽略，但其实商业上往往更划算。
- Retire（退役）：评估后发现这个应用没人用了，直接下线。我见过不少企业，迁移过程中发现30%的应用其实是僵尸系统。嗯，省下来的迁移成本够买一辆车了。
- Retain（保留）：暂时不动。原因可能是合规要求、技术债务太高、或者迁移窗口排不开。保留不是放弃，而是择机再动。
- Relocate（重新部署）：在云之间迁移整个基础设施栈，比如从VMware搬到AWS原生环境。这个选项比较新，适合那些已经虚拟化、但想进一步云原生的场景。
我的建议：别试图给每个应用只选一个R。实际项目中，一个应用的不同模块可能适用不同的R。比如，前端无状态服务可以Rehost，后端数据库可能需要Replatform，而某些老旧模块直接Retire。灵活一点，别死板。
评估可行性时，我还会问三个问题：
- 技术可行性：目标云平台是否支持当前的技术栈？有没有兼容性问题？
- 成本可行性：迁移后的运营成本是否在预算内？别忘了考虑数据传输费、API调用费这些隐性成本。
- 时间可行性：迁移窗口够不够？业务团队能不能接受停机时间？
举个例子。我之前评估过一个ERP系统，技术栈是Oracle数据库+WebLogic中间件。Rehost到云上，Oracle的授权费会暴涨。Replatform换成云原生数据库，又需要大量改造代码。最后我们选了Repurchase——直接买了云上的SaaS版ERP。虽然功能上有些差异，但总成本降低了40%。
你看，迁移评估不是技术选择题，而是商业决策题。
好了，这一章的内容就到这里。画像、依赖、7R评估，这三板斧砍下去，你的迁移路径基本就清晰了。下一章，我们会聊聊具体的迁移策略设计——怎么排优先级、怎么定节奏、怎么控制风险。
到时候见。