4. Azure迁移目标选型
迁移到 Azure 时，最先要回答的问题不是“用哪个服务”，而是“这个工作负载应该落在哪一层抽象上”。Azure 的目标平台大致可分为四层：IaaS（虚拟机）、PaaS（应用服务、Azure SQL 等托管服务）、容器（AKS、Container Apps）和无服务器（Functions、Logic Apps）。抽象层级越高，Azure 承担的运维责任越多，团队的控制粒度越少，但交付速度和弹性通常越好。选型的本质，是在控制力、运维负担、成本和改造工作量之间做权衡。
四类目标平台的核心差异
IaaS（Azure 虚拟机）提供最接近本地数据中心的形态。操作系统、中间件、运行时、补丁、扩缩容策略都由团队自己管理。它适合三类场景：一是依赖特定 OS 版本或内核模块的遗留系统；二是需要安装无法容器化的商业软件；三是迁移时间窗口极短、希望先“平移”再优化的系统。IaaS 的迁移改造量最小，但运维成本最高，弹性也最弱——虚拟机扩缩容需要分钟级，且要自行设计可用性集或可用区。
PaaS（Azure App Service、Azure SQL Database、Azure Cache for Redis 等）把 OS 和运行时交给 Azure 管理，团队只负责应用代码和配置。App Service 支持自动缩放、部署槽交换、内置 TLS 和身份集成；Azure SQL 提供自动备份、高可用和智能调优。PaaS 适合标准 Web 应用、API 和关系型数据库，前提是应用不依赖被托管服务屏蔽的底层能力（如自定义注册表项、特定文件系统路径、SQL Server 的某些高级特性）。
容器（AKS、Azure Container Apps）在可移植性和托管程度之间取得平衡。AKS 提供完整的 Kubernetes 控制面，适合已有 K8s 技能栈、需要复杂调度或服务网格的团队；Container Apps 则进一步隐藏了 K8s 细节，按请求和事件自动伸缩，适合微服务和后台任务。容器的关键价值是“一次构建、多处运行”，但需要团队具备镜像管理、健康探针和网络策略能力。
无服务器（Azure Functions、Logic Apps）把基础设施完全隐藏，按执行次数和资源消耗计费。Functions 适合事件驱动、短时、突发型任务，例如文件上传触发处理、队列消息消费、定时清理；Logic Apps 适合以连接器为主的集成编排。无服务器的冷启动和单次执行时长限制是必须评估的约束，长时间运行或高并发持续负载往往并不经济。
成本与运维的量化判断
成本不能只看单价。以一台 4 vCPU、16 GB 的虚拟机为例，若按 East US 的 D4s v5 预留一年实例估算，计算成本约每月 140 美元；同样的应用若改用 App Service P1v3 计划，约每月 130 美元，但省去了 OS 补丁、监控代理和扩缩容脚本的维护人力。若该应用每天只有 8 小时有流量，改用 Functions 按执行计费，在每天 50 万次调用、平均 200 ms、128 MB 内存的假设下，月成本可能降到 20～40 美元区间。这些数字是用于说明量级差异的示例估算，实际应以 Azure 定价计算器按区域、承诺折扣和流量重新核算。
运维负担的差异更值得关注。IaaS 需要团队负责补丁窗口、磁盘加密、备份验证和可用性设计；PaaS 把这些转为平台能力，但要求应用遵循 12-Factor 原则，不把状态写在本地磁盘；容器需要额外的镜像仓库、漏洞扫描和集群升级策略；无服务器则要求把逻辑拆成幂等、短时的函数，并接受冷启动带来的延迟抖动。选型时建议先列出“团队当前具备的能力”，再匹配平台，而不是先选平台再补能力。
迁移与现代化改造的取舍策略
常见的取舍路径有六种：Rehost（原样搬到虚拟机）、Replatform（少量改造，如从自建 SQL Server 迁到 Azure SQL）、Refactor（重构为 PaaS 或容器）、Rearchitect（重新设计为无服务器或微服务）、Rebuild（重写）、Retire/Retain（下线或保留）。取舍的核心不是“越现代越好”，而是看三个变量：业务变更频率、团队工程能力、迁移时间窗口。
一个可操作的判断顺序是：先问“这个系统未来 12 个月是否会有频繁功能迭代”。如果几乎不变，Rehost 到虚拟机最稳妥，把预算留给真正需要现代化的系统；如果每年有多次版本发布，且团队已具备 CI/CD 能力，优先 Replatform 到 App Service 或 Azure SQL，用最小改造换取托管收益；如果系统本身要拆分为多个服务、且团队有容器经验，再考虑 AKS 或 Container Apps；只有当负载是事件驱动、突发明显、且能接受冷启动时，才把 Functions 作为首选。
一个取舍示例
假设有一个内部订单查询系统，当前跑在本地 Windows Server + SQL Server 上，日均请求 3 万次，峰值集中在工作日上午，未来一年只做少量报表调整。按上述顺序：变更频率低，排除 Rearchitect；团队没有 K8s 经验，排除容器；负载不是事件驱动，排除无服务器。最终选择 Replatform：Web 层迁到 App Service，数据库迁到 Azure SQL Database，用 Azure Migrate 做评估、Data Migration Assistant 检查兼容性。这样既避免了虚拟机的补丁运维，又不需要重写代码，迁移窗口可控制在一次周末停机内。
反过来，如果同一个系统计划在半年内拆出独立的库存服务和通知服务，且团队已经在用 Docker，那么更合理的路径是先把 Web 层容器化到 Container Apps，数据库仍用 Azure SQL，等拆分稳定后再评估是否把通知逻辑改为 Functions。选型不是一次性的，而是随业务节奏分阶段推进。
最后，无论选择哪一层平台，都应在迁移前明确回滚方案：保留源端只读副本、记录 DNS 切换点、准备数据库反向同步或快照恢复路径。目标平台选型决定了迁移后的运维模式，而回滚能力决定了迁移过程本身是否可控。