Microsoft AZ-305: 迁移与现代化 — 学习指南

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

属于 Microsoft Azure Solutions Architect Expert AZ-305 — 学习指南. 使用经过验证的答案练习： Microsoft 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Azure 上的迁移与现代化结合了发现驱动的规划、合适的数据移动工具、特定于工作负载的迁移服务、混合管理以及成本优化。其目标是在不影响可靠性、安全性或运营的前提下，满足价值实现时间的要求。首先，进行基于事实的清单盘点和依赖关系映射，建立基于性能的规模估算和 TCO 分析，选择在提升云原生能力的同时干扰最小的迁移策略，并通过许可和预留优化来保障商业案例的成功。Azure 提供了一个集成套件——用于发现、评估和编排的 Azure Migrate；用于工作负载迁移的 Azure Database Migration Service 和 App Service Migration Assistant；用于离线批量传输的 Azure Data Box 和 Import/Export；用于混合治理的 Azure Arc；以及诸如容器、无服务器和 API 优先重构等现代化路径。

发现、评估和工作负载迁移

Azure Migrate 是迁移项目的控制平面。部署 Azure Migrate 设备以无代理方式发现 VMware、Hyper-V 和物理服务器，或者在需要更深层次元数据（如进程、端口）时使用代理。发现过程会收集硬件、操作系统、性能计数器和依赖关系数据，以建立准确的评估。依赖关系可视化对于工作负载分组和规划迁移批次至关重要，这有助于保持东西向流量的局部性和应用分层结构。

服务器评估会输出就绪性（操作系统支持、驱动程序、代理）、基于性能的规模调整（vCPU/RAM/IOPS/吞吐量）以及与虚拟机系列、磁盘和预留相对应的月度成本估算。Azure Migrate 的迁移目标可以是 Azure VM 或 Azure VMware Solution。对于 Web 工作负载，Azure Migrate 包含一项 Web 应用评估功能，用于评估要迁移到 Azure App Service 的 IIS 站点，并标记出不支持的功能，例如 ISAPI 筛选器、GAC 依赖或旧版 .NET 框架。对于数据库，Azure Migrate 将评估工作联合至 Azure Database Migration Service (DMS)，由 DMS 测试 SKU 兼容性并确定所需的修复措施（如数据类型、T-SQL 外围应用、排序规则、功能对等性）。

服务器的迁移编排使用 Azure Migrate: Server Migration 功能，将 VMware、Hyper-V 或物理服务器以持续复制的方式迁移到 Azure，并支持恢复点和计划内切换。在最终切换之前，您可以向隔离的 VNet 中运行测试迁移，以验证启动、应用启动和连接性。对于托管在 IIS 上的 Web 应用程序，Azure App Service Migration Assistant 会执行就绪性评估，并且能够将 ASP.NET 或 PHP 站点打包并部署到 App Service，根据需要重写配置，并揭示依赖关系差距（例如 Windows 特有的 COM 组件、计算机级别的驱动程序、GAC 程序集）。它最适合将 Windows IIS 工作负载迁移到 Windows 上的 App Service。

Azure Database Migration Service 提供在线（停机时间最短）和离线（一次性）两种迁移方式：

• 在线迁移：建立从源到目标的持续变更数据捕获，允许您并行进行验证和修复，并在一个短暂的中断窗口期内完成切换。适用于无法承受长时间停机的任务关键型数据库。
• 离线迁移：执行一次性的批量加载（备份/还原、BACPAC 或导出/导入），中断时间较长，但可以最大限度地降低复杂性和成本。

支持的源/目标模式包括：SQL Server 到 Azure SQL Database 或 Azure SQL Managed Instance，SQL Server 到 Azure VM 上的 SQL Server，MySQL 到 Azure Database for MySQL，PostgreSQL 到 Azure Database for PostgreSQL，以及 MongoDB 到 Azure Cosmos DB (MongoDB API)。DMS 能够评估兼容性，编排架构和数据移动，并能自动执行迁移后的验证任务。

批量数据传输选项

当网络带宽、数据引力或合规性要求阻碍在线复制时，可以利用 Azure 的离线传输产品。

Azure Data Box 系列：

• Data Box Disk：寄送给您的加密固态硬盘；每个订单最多支持约 35 TB 数据，适用于重视便携性的分支机构或实验室规模的种子数据传输。
• Data Box：一款坚固耐用的加密设备，可用容量约 100 TB；专为数据中心搬迁或持续同步前的初始大规模种子数据传输而设计。
• Data Box Heavy：一款托盘式设备，提供约 1 PB 的可用容量；是进行数百 TB 到 PB 级别迁移（如存档、媒体库或文件共享）的理想选择。

所有设备都使用硬件加密、监管链物流，并在返回后自动将数据引入到选定的 Azure Storage 帐户中。它们通常用于初始种子数据传输（之后通过 AzCopy、Storage Mover 预览版或供应商工具进行持续的增量复制）、一次性存档，或在有出口限制的情况下进行区域间数据移动。

Azure Import/Export 服务使用您自己的、经过 BitLocker 加密的 SATA HDD/SSD 介质。WAImportExport 工具用于准备驱动器、生成日志文件和清单文件、验证数据和文件夹映射，并写入加密密钥。寄送工作流程如下：

1. 在门户中创建一个导入（或导出）作业，并指定目标（或源）存储帐户和容器。
2. 使用 WAImportExport 工具准备并加密驱动器，然后生成驱动器组的 CSV 文件。
3. 使用经批准的承运商将介质寄送到作业中指定的微软数据中心，并提供跟踪详细信息。
4. 微软将数据直接引入您的存储帐户（或从其中导出），更新作业状态，然后将介质寄回。 当您手头已有驱动器、需要精确控制设备链，或者数据量与 Data Box 设备相比不大时，Import/Export 是最佳选择。

策略、许可和成本优化

根据时间、风险和现代化目标选择迁移策略：

• 平移（重新托管）：最快的途径，代码改动最少。适用于稳定、低风险的虚拟机，或作为优化前的过渡阶段。可与 Azure Migrate 复制功能结合使用，并立即应用治理护栏。
• 重构平台（平移和优化）：通过少量更改迁移到托管服务——例如将 Windows IIS 迁移到 App Service，将 SQL Server 迁移到 Azure SQL Managed Instance。无需完全重新设计即可减少运维开销并获得 PaaS 的可靠性。
• 重新架构（重构）：分解单体应用，在 AKS 上采用微服务、事件驱动的管道或领域驱动的限界上下文。投入精力更大，但与云原生的弹性和规模保持一致。
• 替换：采用 SaaS 来淘汰那些不具差异化优势的自定义工作负载（如 CRM、HRIS），从而缩小攻击面和 TCO。

通过许可和预留为业务案例提供支持：

• Azure 混合权益 (AHB) 允许您利用现有的、包含软件保障 (Software Assurance) 的许可证。对于 Azure VM 或 Azure Dedicated Host 上的 Windows Server，AHB 免除了 Windows 许可证成本，您只需支付基础计算费率。对于 SQL Server，可将 AHB 应用于 Azure SQL Database、Azure SQL Managed Instance 或 Azure VM 上的 SQL，以降低 SQL 许可费用。对于 Linux，AHB 支持符合条件的 Red Hat Enterprise Linux 和 SUSE Linux Enterprise 订阅，在运行经批准的 BYOS 镜像时可免除操作系统软件费用。务必验证许可证移动性和核心数。
• Azure 预留实例 (RI) 和预留容量 通过 1 年或 3 年的承诺来匹配稳态计算负载。三年期可获得更高的折扣；一年期则提供更大的灵活性。可将预留范围限定在单个订阅（实现权益的紧密对齐）或共享范围（在计费上下文中的多个订阅间应用以最大化利用率）。您可以随时交换预留以更改区域、VM 系列或期限；允许取消，但需支付提前终止费，且退款受 Azure 年度上限的限制。利用 VM 系列内的实例大小灵活性来吸收需求波动。 AHB 与预留相结合，通常可比即用即付模式节省 50–80% 的成本，从而能够将节省的成本再投资于现代化改造。

混合管理与现代化模式

Azure Arc 将 Azure 治理扩展到本地和多云环境。已启用 Arc 的服务器通过代理来载入 Windows 和 Linux 计算机，将其投射为 Azure 资源，从而支持 Azure Policy 来宾配置、Update Management、Defender for Cloud 以及基于扩展的工具（Key Vault 证书、Dependency agent）。已启用 Arc 的 Kubernetes 将符合 CNCF 规范的集群附加到 Azure，以实现基于 GitOps 的配置 (Flux)、Azure Policy for Kubernetes 以及扩展生命周期管理（Open Service Mesh、Azure Monitor for containers）。已启用 Arc 的 SQL Server 可清点任何位置的实例，呈现支持终止和 SKU 建议，强制执行安全基线，并与 Defender for SQL 集成。对于边缘或断开连接的环境，Arc 带来了一致的治理控制平面，而工作负载则保留在原位。

现代化模式应分层应用到迁移计划中：

• 容器化：将现有的 .NET/Java 应用打包到容器中，并在 Azure Kubernetes Service (AKS) 或 App Service for Containers 上运行。Azure Migrate: App Containerization 可以分析 IIS 或 Java 应用，创建 Dockerfiles，并发布到 Azure Container Registry，从而在不重写代码的情况下加速现代化进程。对于具有服务网格和 CI/CD 的复杂、可扩展的微服务，请使用 AKS；对于较简单的 Web 工作负载，请使用 App Service for Containers。
• 无服务器迁移：将调度程序、批处理任务和集成粘合代码卸载到 Azure Functions 和 Logic Apps 中，以消除服务器管理。Durable Functions 增加了工作流和状态管理；Event Grid 和 Service Bus 提供事件驱动和解耦能力，以减少背压并改善故障隔离。
• API 优先转型：通过 Azure API Management 暴露内部功能，并提供产品、版本控制、限制和 OAuth2/OpenID Connect 卸载功能。这将 API 合约与后端分离，支持合作伙伴和移动渠道，并强制执行集中式安全策略。结合 Backend for Frontend 模式和 DevSecOps 来标准化治理和测试。 在现代化改造期间，使用蓝/绿或金丝雀部署切换以及功能标志来降低风险。来自 Azure Monitor 和 Application Insights 的遥测数据应用于驱动性能、容量和扩展规则的迭代调优。

实际问题场景

Adobe Inc. 必须将其一系列本地 IIS Web 应用、SQL Server 数据库和 600 TB 的媒体资产迁移到 Azure，同时最大限度地减少停机时间，并为容器优先的未来做好准备。

分步方法：

1. 使用 Azure Migrate 进行发现和评估 部署 Azure Migrate 设备以清点 VMware VM 和 IIS 站点。使用依赖关系映射对应用层进行分组，并识别共享数据库。运行基于性能的 VM 大小调整和 App Service 就绪性评估。选择该服务是因为它在单一平面中集中了发现、成本估算、依赖关系洞察和迁移编排。

2. 按工作负载对迁移策略进行分类 首先将有状态的应用层重托管 (Rehost) 到 Azure VM 以降低时间线风险，将迁移助手显示高度就绪的无状态 Web 层重平台 (Re-platform) 到 Azure App Service，并为高流量门户规划重构 (Re-architect) 到 AKS 的工作流。这种混合策略平衡了速度（直接迁移）与运营收益（App Service）以及长期可扩展性（AKS）。

3. 使用 Azure Database Migration Service 迁移数据库 对面向客户的 SQL Server 后端使用在线迁移至 Azure SQL Managed Instance，以保留 SQL Agent 作业、跨数据库查询，并实现近乎零的停机时间。在计划的周末窗口期内，对内部业务线数据库使用离线迁移。选择 DMS 是因为它提供了基于 CDC 的最小停机时间路径、模式验证和编排式切换。

4. 使用 Azure Data Box 和 Import/Export 移动媒体资产 为最初的 600 TB 种子数据订购多个 Azure Data Box 设备（每个 100 TB）以传输到 Blob Storage，然后通过 ExpressRoute 进行增量同步。对于两个拥有较小存档的远程工作室，使用 Azure Import/Export 配合现有的加密 SSD 和 WAImportExport 工具。Data Box 快速安全地解决了批量传输问题；Import/Export 则利用了边缘站点已采购的磁盘。

5. 使用 App Service Migration Assistant 切换 Web 工作负载并进行测试迁移 对于标记为兼容的 IIS 站点，使用 Migration Assistant 进行打包、转换配置并部署到 App Service。将测试迁移执行到预演槽位，成功后执行交换操作。该工具减少了手动修复工作，并加速了部署的一致性。

6. 引入现代化模式 使用 Azure Migrate: App Containerization 对选定服务进行容器化，将镜像推送到 Azure Container Registry，并通过 Azure Arc-enabled Kubernetes 以 GitOps 方式部署到 AKS，以实现开发/测试/生产环境的一致配置。使用 Azure API Management 作为所有公共 API 的前端，以标准化限制、OAuth2 和合作伙伴载入流程。这为微服务和 API 优先渠道奠定了基础，同时保持了治理。

7. 通过 Azure Arc 启用混合治理 在迁移之前、期间和之后，使用 Azure Arc 载入剩余的本地服务器和非 AKS 的 Kubernetes 集群，以应用 Azure Policy、收集清单并标准化安全基线。Arc 带来了跨混合环境的单一控制平面，确保了漂移检测和合规性。

8. 通过 Azure Hybrid Benefit 和预留实例优化成本 将 Azure Hybrid Benefit 应用于 Windows Server 和 SQL Server 以降低软件成本。为稳态的 VM 和 Managed Instance SKU 购买 3 年期 Reserved Instances；使用共享范围以最大化跨订阅的覆盖率，并在使用模式变化时交换预留。这保留了商业案例的价值，并为现代化冲刺提供了资金。

为何选择这些服务：Azure Migrate 和 DMS 通过数据驱动的规划和低停机时间执行来最小化风险；App Service Migration Assistant 加速了成熟的 IIS 迁移；Data Box 和 Import/Export 解决了数据引力问题；Azure Arc 在混合云和多云环境中提供了一致的治理；AKS、Functions 和 API Management 实现了面向未来的云原生演进，而不会阻碍当前的迁移目标。

← 监控、成本优化与运维 · 所有领域 · Well-Architected 框架与设计原则 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Microsoft →