3. 本地资产发现与依赖关系分析

迁移项目最容易出问题的地方，往往不是目标端配置，而是对本地现状了解不足。一个看似独立的 Web 应用，可能依赖三台虚拟机上的中间件、两个 SQL Server 实例和一个文件共享；如果只迁移了 Web 服务器，上线后必然出现连接失败。因此，在动手迁移之前，必须完成三件事：发现（有哪些服务器、应用、数据库）、分组（哪些资产属于同一个业务系统）、依赖映射（它们之间如何通信）。本节围绕 Azure Migrate 与 Azure App Service Migration Assistant 两类工具，说明如何把本地资产盘清楚。

一、发现阶段：先建立资产清单

Azure Migrate 的发现能力分为无代理（Agentless）和基于代理（Agent-based）两种模式。无代理模式通过 vCenter Server 或 Hyper-V 主机读取虚拟机清单，适合 VMware/Hyper-V 环境，部署成本低，能采集 CPU、内存、磁盘、网络等性能计数器；基于代理模式则在每台服务器上安装 Mobility Service 代理，可以采集更细的进程、TCP 连接和依赖数据，适合物理机或跨虚拟化平台的环境。

以 VMware 环境为例，典型操作流程如下：在 Azure 门户创建 Migrate 项目，选择“发现”并指定设备类型为 VMware，下载 OVA 设备模板并在 vCenter 中部署。设备启动后，在配置管理器中填入 vCenter 地址与只读账号，随后启动发现。发现完成后，门户中会出现“已发现的服务器”列表，包含机器名、操作系统、IP、CPU/内存利用率和磁盘数量。

对于应用层，Azure Migrate 的“应用发现”功能（基于 Appliance 的软件清单）可以列出服务器上安装的应用程序、版本和端口。对于 IIS 站点，App Service Migration Assistant 是更直接的工具：它安装在 Windows Server 上，扫描本机 IIS 站点，输出每个站点的绑定、应用程序池、.NET 版本、数据库连接字符串和内容大小，并给出是否可迁移到 App Service 的评估结论。

二、分组：把资产归入业务系统

发现得到的是一张扁平的服务器清单，而迁移需要的是“业务系统”视角。分组的依据通常有三类：一是应用归属，例如同一套 ERP 的前端、应用服务器和数据库；二是网络位置，例如同一子网或同一安全组内的资产；三是依赖关系，即通过连接数据自动聚类。Azure Migrate 支持基于依赖可视化的自动分组，也允许手动创建组并命名，例如“订单系统-生产”“订单系统-测试”。

分组时要注意区分环境。生产、测试、开发环境往往共用相似的机器名，如果混入同一组，评估结果会被测试机的低负载拉低，导致目标规格选型偏小。建议在组名中显式标注环境，并在评估时分别创建评估任务。

三、依赖映射：看清通信方向与端口

依赖映射是本节的核心。Azure Migrate 的依赖可视化基于 Mobility Service 代理采集的 TCP 连接数据，默认展示服务器之间的入站和出站连接，包括目标 IP、端口和进程名。实际操作中，在“发现”完成后为需要分析的服务器安装代理，等待约 1 小时数据汇聚，然后在“依赖关系”视图中按组查看拓扑。

解读依赖图时，重点关注三类连接：数据库连接（如 1433、3306、1521 端口），决定数据库迁移的先后顺序；中间件连接（如 5672、6379、8080），决定是否需要重建消息队列或缓存；文件共享连接（如 445 端口），决定是否需要迁移到 Azure Files 或 Blob。下图展示了一个典型三层应用的依赖关系与迁移映射。

依赖图给出的是“谁连谁”，但还需要结合端口和进程判断连接性质。例如，8080 端口可能是应用服务，也可能是某个管理控制台；445 端口可能是业务文件共享，也可能只是系统管理共享。建议在依赖视图中逐条核对进程名，必要时与开发或运维人员确认，避免把临时连接误判为持久依赖。

四、从依赖到迁移顺序

依赖映射的直接产出是迁移批次。基本原则是：被依赖方先迁移，依赖方后迁移。以上图为例，SQL Server 和文件服务器处于依赖链末端，应优先迁移或至少先完成数据同步；应用服务器依赖数据库和文件共享，排在第二；Web 服务器依赖应用服务器，最后迁移。如果数据库迁移周期较长，也可以先迁移 Web 和应用层，通过混合连接（如 Azure VPN 或 ExpressRoute）暂时回连本地数据库，待数据库就绪后再切换。

对于 App Service Migration Assistant 扫描出的 IIS 站点，还需要关注其评估报告中的“就绪状态”。报告会标记出不受支持的配置，例如自定义 COM 组件、Windows 身份验证、注册表依赖或本地文件路径写入。这些项目无法直接迁移到 App Service，需要改造或改用 VM/容器承载。把这类结论回填到分组和依赖图中，才能形成一份可执行的迁移清单。

五、发现与依赖分析的交付物

完成本节工作后，应至少产出三份可核对的材料：一是资产清单，包含机器名、IP、操作系统、角色、所属业务系统和环境；二是依赖矩阵，以“源资产—目标资产—端口—进程—连接性质”为字段，逐条记录确认后的依赖；三是迁移分组表，把资产按业务系统和迁移批次归类，并标注目标 Azure 服务与迁移工具。下表给出一个简化的依赖矩阵示例。

需要强调的是，发现和依赖分析不是一次性动作。在迁移执行过程中，随着部分系统切换，依赖关系会发生变化，例如原本回连本地数据库的应用改为连接 Azure SQL，此时依赖图应同步更新。把依赖矩阵作为活文档维护，才能支撑后续的割接验证和回滚决策。