3、遗留系统分析：识别遗留系统、评估依赖关系、确定迁移范围
说实话，很多团队一上来就急着动手迁移，结果往往搞得一团糟。我见过最夸张的一个项目，迁移到一半发现核心数据库的存储过程根本没法在容器里跑——嗯，这就是典型的「先开枪后瞄准」。
遗留系统分析，说白了就是给你的老系统做一次全面体检。你得先搞清楚它到底有多老、依赖了什么、哪些能动哪些不能动。我个人习惯把这个阶段分成三步走：识别、评估、定范围。咱们一个一个聊。
3.1 识别遗留系统：别把「老」和「烂」混为一谈
什么样的系统算遗留系统？很多人觉得「代码写于十年前」就算。其实不然。我遇到过一套2008年用Java写的ERP系统，代码结构清晰、测试覆盖率高，跑得比某些新项目还稳。反倒是有些去年刚上线的微服务，依赖混乱、文档全无，那才是真正的「遗留」。
我个人判断遗留系统，主要看这几个维度：
- 技术栈是否过时：比如还在用Java 8以下、Python 2.x、或者.NET Framework 4.x这种官方已经停止维护的版本
- 是否依赖物理机或特定硬件：比如绑定了某个网卡的MAC地址、依赖串口加密狗
- 文档和知识是否流失：原开发团队已经解散，没人说得清业务逻辑
- 构建和部署是否手工化：还在用FTP上传war包、手动修改配置文件
核心判断标准：一个系统如果无法通过「修改一行配置 + 重新部署」来完成环境切换，那它大概率就是遗留系统。
我记得有一次帮一个金融客户做评估，他们有个核心交易系统，部署文档写了整整200页。我翻了一遍发现，里面居然有「请确保服务器在每天下午3点前重启，否则内存泄漏会导致宕机」这种操作。嗯，这种系统不改不行。
3.2 评估依赖关系：画一张「谁依赖谁」的地图
识别出遗留系统之后，下一步就是搞清楚它到底依赖了什么。这一步做不好，迁移的时候就会各种「惊喜」。
我建议你从三个层面去梳理依赖：
3.2.1 运行时依赖
说白了就是系统跑起来需要什么。包括：
- 操作系统版本和内核参数：比如某些老系统只认CentOS 6，换了7就报错
- 中间件和运行时：Tomcat 7、JBoss 4、IIS 6这些老版本
- 数据库和连接方式：Oracle 11g、SQL Server 2008，甚至还有用ODBC直连的
- 外部服务和API：比如调用了某个内网的SOAP接口，或者依赖一个已经废弃的第三方SDK
小技巧：我个人习惯用 lsof 和 netstat 在生产环境上跑一轮，看看系统启动后到底打开了哪些端口、连接了哪些IP。这比看文档靠谱多了。
3.2.2 构建和部署依赖
这部分容易被忽略，但坑最多。我曾经遇到一个项目，代码里引了一个内部私有的Maven仓库，但那个仓库的服务器早在两年前就下线了。结果迁移的时候一编译就报错，折腾了三天才找到替代方案。
你需要梳理：
- 构建工具和版本（Maven 2、Ant、Makefile）
- 私有仓库和镜像源
- CI/CD流水线的配置（Jenkins pipeline、GitLab CI）
- 配置文件中的硬编码路径和IP
3.2.3 数据依赖
这个最要命。很多遗留系统的数据模型和业务逻辑是深度耦合的。比如：
- 存储过程里直接写了文件路径
- 定时任务通过
xp_cmdshell调用操作系统命令 - 数据库触发器里调用了外部WebService
我建议你用一个表格来记录这些依赖关系：
| 依赖类型 | 具体内容 | 是否可替换 | 迁移风险 |
|---|---|---|---|
| 运行时 | JDK 1.7 + Tomcat 7 | 是（升级到JDK 11） | 中 |
| 构建 | 内部Maven仓库（已下线） | 否（需找替代） | 高 |
| 数据 | 存储过程调用 curl |
是（改为HTTP调用） | 低 |
3.3 确定迁移范围：不是所有东西都值得搬
做完依赖分析，你心里应该有个底了。接下来就是决定「哪些搬、哪些留、哪些扔」。这一步很考验经验，因为技术上的可行性是一回事，业务上的必要性是另一回事。
我一般把系统分成四类：
- 直接迁移：技术栈新、依赖清晰、文档齐全。直接打包成镜像，改改配置就能跑。
- 改造后迁移：需要做一些适配工作，比如升级JDK版本、替换过时的库、解耦硬编码依赖。
- 保留不动：系统太老、依赖太深、或者即将被替换。强行迁移风险大于收益。
- 废弃重建：业务逻辑已经没人懂了，或者有更好的替代方案。不如直接重写。
注意：我曾经犯过一个错误——把一套运行了12年的报表系统强行容器化。结果发现它依赖一个只能在Windows Server 2003上跑的COM组件。折腾了两周，最后还是放弃了。所以，该放弃的时候就放弃，别死磕。
确定迁移范围时，我建议你问自己三个问题：
- 这个系统迁移后能带来什么价值？（性能提升？运维简化？成本降低？）
- 迁移的成本和风险是否可控？（时间、人力、业务中断）
- 有没有更简单的替代方案？（比如直接买SaaS服务）
嗯，到这里，遗留系统分析这部分就差不多了。你想想看，其实核心就三件事：识别出哪些是真正的遗留系统、画清楚依赖关系图、然后理性地决定迁移范围。别贪多，也别怕难。我见过太多团队一上来就想「全量迁移」，结果半年过去了还在原地打转。
下一章咱们聊聊具体的迁移策略——是「绞杀者模式」还是「蓝绿部署」，到时候再细说。