信创迁移前最值得投入的一件事，就是先把应用依赖彻底梳理清楚；否则迁移本身只是搬家，依赖没理顺，搬完才是麻烦的开始。
你可能会遇到这样的场景：应用在原有Linux环境上跑得好好的，迁移到国产操作系统后，一启动就报缺少动态库；数据库换成了国产数据库，代码里却还写死着旧的JDBC连接串，这些表面是环境差异，根子都在依赖清单不透明，与其等迁移后四处救火，不如把依赖梳理前置，让每个应用、每段代码、每个配置文件都在搬迁前现出原形。
信创迁移前做应用依赖梳理，到底要理清什么？
很多人问信创迁移前需要准备什么,第一件事就是把应用依赖整理成一份可执行的清单，而不是靠脑子记，应用依赖梳理不是画一张架构图那么简单，一个应用在运行时要依赖什么，通常分为三个层面：代码依赖、运行时依赖、环境配置依赖，三者缺一不可。
代码依赖：你引用了谁，谁引用了你
代码依赖是应用在源码层面用到的第三方库、框架、模块以及内部服务接口，比如一个Java应用依赖了Spring Boot、MyBatis、某个内部RPC框架；一个Python应用依赖了requests、Flask、Pandas等，梳理代码依赖时，静态分析最直接，以Java为例，JDK自带的jdeps可以分析JAR包之间的依赖关系；Python项目可以通过pipdeptree生成依赖树；Node.js项目用npm ls就能看到完整的依赖层次，这些工具都是免费且准确的，适合在迁移前快速拿到一份“依赖图谱”。
运行时依赖：代码跑起来才会暴露的问题
有些依赖是静态分析看不见的,比如程序通过反射加载的类、JNI调用的本地库、通过命令行调用的外部进程，或者在运行期动态生成的临时文件路径，这类依赖一旦遗漏，迁移后轻则功能缺失，重则直接崩溃。
动态追踪在这里更有效,在测试环境完整跑一遍核心业务场景，同时用strace或lsof跟踪进程的系统调用和文件打开记录，能把隐藏的运行时依赖挖出来，对于Java应用，可以借助jcmd或链路追踪工具（如SkyWalking）记录调用链，看看每次请求到底访问了哪些外部资源。
环境配置依赖：写死的一切都要改
环境配置依赖包括IP地址、端口、数据库连接串、消息队列topic、文件系统路径、环境变量等，很多老应用喜欢把配置写死在properties或YAML文件里，梳理这一步，最简单的方法是全局搜索：把代码仓库下所有配置文件里出现的IP、URL、端口都拉出来，逐项标出它的用途。
你很可能发现大量硬编码的内网地址和localhost，甚至还有密文密码，这些都要在迁移前改造成外部配置项，否则到了新环境就是一颗颗定时炸弹，应用依赖分析怎么做？本质上就是静与动结合，把上面三类信息都收集起来，再核对一遍。
可行的依赖梳理方法：静态、动态、配置核对三招
明确要理清什么之后,具体执行靠三招：静态扫描、动态追踪、配置核对，三招结合，依赖覆盖率能达到近年来的最佳实践水平，下面用一个表格快速对比：
| 方法 | 侧重点 | 优势 | 短处 |
|---|---|---|---|
| 静态扫描 | 代码与库依赖 | 速度快、覆盖全、可自动化 | 发现不了运行时动态加载的依赖 |
| 动态追踪 | 运行时调用链与访问端口 | 贴近真实场景 | 需要搭建测试环境并执行典型用例 |
| 配置核对 | 环境变量与写死项 | 能发现隐性依赖 | 依赖人工检查，需要细查上下文 |
静态分析：从代码和二进制里抠出依赖树
选择静态分析工具,主要看语言生态，Java项目优先用jdeps和mvn dependency:tree；C/C++项目用ldd查看可执行文件的动态库依赖；Python项目用pipdeptree；Node.js用npm ls，如果你有比较复杂的微服务架构，可以用企业级架构分析工具（比如Structure101）做整体依赖可视化。
操作路径：在CI流程里加一个阶段，跑一遍依赖扫描，生成依赖清单并入库，这个动作要在迁移前至少一个月就持续做，保证不是某个时点的快照，而是动态更新的。
动态追踪：在运行现场捕获真实调用链
动态追踪的姿势可以这样：先在迁移前的测试环境中把应用完整部署起来，然后模拟真实用户行为（登录、下单、查询、导出等），同时开启监控，Linux下可以用strace -f -e trace=file,process,network记录进程所有文件访问和网络连接，也可以配合lsof查看端口占用情况。
对Java应用,更推荐用SkyWalking或Zipkin这类链路追踪工具，把一次请求经过的所有服务、数据库、缓存都记录下来，这样就能知道哪个服务依赖了哪个中间件，端口都开在哪里，相比静态分析，动态追踪给出的依赖关系是经过实际调用验证的，可信度更高。
配置清单核对：把环境依赖和隐性依赖挖出来
配置核对虽然看起来无聊,却是最容易被忽略的环节，不要只看配置文件，还要看启动脚本（start.sh、Dockerfile）、CI/CD pipeline里设置的环境变量，以及Nginx、Tomcat等中间件的配置。
具体做法：把迁移涉及的每台机器上，应用安装目录下的所有.properties、.yml、.xml、.conf文件都收集起来，用脚本提取其中的host、port、jdbc、redis等关键字，生成一个“环境依赖检查表”，迁移到新环境时，每个参数都要对照这张表去配置，漏一项都不行。
信创迁移依赖关系梳理工具怎么选？给一个对比视角
你可能会纠结：用开源工具自己搭，还是直接买商业工具？这取决于团队规模和迁移范围。行业共识是，小范围单应用优先用开源免费工具，大范围多系统交叉依赖时，商业工具的图形化分析能力能省下不少返工时间。
- 开源方案：jdeps、mvn dependency:tree、pipdeptree、npm ls、ldd、strace，再加一个可视化工具如Graphviz输出依赖图，零成本，但需要自己拼装，且更擅长代码依赖分析。
- 商业方案：例如Sparx Enterprise Architect、JArchitect等，支持从代码仓库自动构建调用关系，甚至能分析Java、C++等混合架构，价格通常按年订阅，适合预算充足、系统关系复杂的信创项目。
| 维度 | 开源组合 | 商业工具 |
|---|---|---|
| 成本 | 免费 | 按年订阅，成本较高 |
| 学习曲线 | 需要熟悉多种命令 | 图形化界面，上手相对快 |
| 分析范围 | 偏代码依赖 | 代码与运行依赖兼顾 |
| 适用场景 | 中小规模、单体或少量服务 | 几十个微服务、强依赖关系网 |
无论选哪种,输出都要是结构化的清单，不只是依赖图，依赖图好看，但真正指导迁移决策的是表格：每一项依赖的名称、版本、来源、迁移目标环境中的对应物、是否需替换。
从梳理到落地的四步操作路径
有方法还得有顺序,这里给出一套可直接照做的路径：
-
第一步：盘点资产。 列出所有要迁移的应用系统，标注技术栈（语言、框架、中间件），并确认各自负责人，这一步不用太细，但系统列表一个都不能缺。
-
第二步：逐系统静态扫描。 按前文提到的工具，把每个系统的代码依赖生成清单，重点标记出不活跃的旧库和已经停止维护的开源组件，它们在迁移时往往会被新环境淘汰。
-
第三步：搭建预迁移环境做动态验证。 别直接在生产环境上测，用一个独立环境部署一套完整应用，跑一遍核心业务流程，同时用跟踪工具记录调用链，最终汇总成一份“运行依赖表”，包含服务间调用、外部访问、端口依赖等。
-
第四步：配置基线化。 把扫描到的硬编码配置统一抽离到配置中心，或写成环境变量模板，这样迁移到新环境时，只需替换一套配置，应用代码不用动。
完成这四步,你已经为一整个信创迁移成本评估打好了基础，没有依赖清单，成本评估就是拍脑袋；有了清单，你才知道哪些组件要直接替换，哪些可以保留，哪些需要二次开发。
依赖梳理的辛苦是暂时的,但它换来的安稳是长期的，把应用依赖摸透，信创迁移才真正从“玄学”变成了“工程”，迁移前做到依赖可见，迁移中才能做到风险可控，迁移后才能真正安心跑业务。
关于信创迁移应用依赖梳理，还有哪些疑问？
信创迁移时，应用依赖梳理需要花多长时间？
没有固定标准，取决于系统数量和技术栈复杂度，一个几十个微服务的中型系统，用开源工具组合做一轮静态扫描加配置核对，通常一到两周能完成，如果涉及动态追踪和业务场景验证，要再加一到两周，相比迁移后因依赖缺失导致的故障排查，这个时间成本可以忽略不计。
梳理出来的依赖清单，应该在什么层面使用？
三个层面，第一，技术迁移方案的编写依据；第二，测试用例的设计基础；第三，验收标准中兼容性列表的参照，迁移后，这份清单还可以作为日常运维的配置基线，依赖梳理不应是一次性作业，而应随着应用迭代持续更新。
如果发现某个依赖在信创环境下没有替代品，怎么办？
先确认这个依赖是不是真在运行时被调用，有些库只是被引入，并未使用，可以通过静态分析调用链验证，如果确实需要，可以在应用层抽象接口，用适配器模式替换为兼容实现；或者保留旧环境作为过渡，通过网关转发部分请求，最核心的原则是：不要为了迁移而强行舍弃功能，而是要有缓冲方案。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/738313.html
