1. Azure虚拟化计算平台总览

Azure 的虚拟化计算平台并不是单一产品，而是一组从物理主机、虚拟化层、虚拟机规格、托管计算服务到平台级高可用能力的组合。理解这套平台，关键不是记住服务名称，而是先建立一条判断主线：哪些能力由你负责，哪些能力由 Azure 负责。这条主线决定了 IaaS 与 PaaS 的边界，也决定了后续高可用业务平台工程的设计方式。

一、IaaS 与 PaaS 的边界：责任划分决定架构选择

在 Azure 中，IaaS 的典型代表是虚拟机（Virtual Machine, VM）与虚拟机规模集（VMSS）。你获得的是操作系统及以上的控制权：可以安装运行时、配置中间件、调整内核参数、部署代理、定义磁盘与网络。Azure 负责物理主机、虚拟化层、宿主机网络与底层存储的可用性。PaaS 的典型代表是 Azure App Service、Azure Functions、Azure Container Apps、Azure Kubernetes Service（AKS 的控制面）等。你交付的是应用包、容器镜像或函数代码，平台负责操作系统补丁、运行时版本、实例调度、负载均衡与部分伸缩能力。

边界并不是“谁更高级”，而是控制权与运维责任的交换。例如，同样运行一个 Web API：

• 用 VM 部署：你需要自己处理 OS 补丁、IIS/Nginx 配置、证书轮换、实例健康检查、跨可用区部署与负载均衡后端池。
• 用 App Service 部署：你只需提供代码或容器，平台处理实例健康、TLS 终止、自动缩放规则触发后的实例增减；但你不能修改底层 OS 内核，也不能随意安装系统级驱动。
• 用 AKS 部署：控制面由 Azure 托管，节点池仍属于你管理的计算资源；你获得容器编排能力，同时承担节点镜像升级、Pod 资源请求与限制、网络插件选择等责任。

因此，选择 IaaS 还是 PaaS，应先回答三个问题：是否需要操作系统级控制？是否愿意承担补丁与运行时升级？高可用目标是否要求跨区域主动-主动？如果答案偏向“需要控制且能承担运维”，IaaS 更合适；如果偏向“快速交付且接受平台约束”，PaaS 更合适。

二、计算资源谱系：从单台 VM 到平台级计算

Azure 计算资源可以按“抽象层级”和“伸缩单位”两个维度理解。抽象层级从低到高大致为：物理主机 → 虚拟机 → 虚拟机规模集 → 容器实例/容器应用 → 托管应用平台 → 无服务器函数。伸缩单位则从“单实例”逐步变为“实例组”“副本集”“事件驱动实例”。

在 VM 层面，规格族决定了资源画像：B 系列适合突发型轻负载，D 系列适合通用计算，E 系列适合内存密集型，F 系列适合计算密集型，N 系列带 GPU。选择规格时不能只看 vCPU 和内存，还要看磁盘吞吐上限、网络带宽、临时盘类型、是否支持 Premium SSD、是否支持加速网络。例如，一个日志聚合服务需要高网络吞吐和稳定磁盘 IO，若只按 vCPU 数量选型，可能在高峰期出现网络或磁盘瓶颈。

在平台层面，AKS 把计算资源组织为节点池，Pod 是调度单位；App Service 把计算资源组织为应用服务计划，实例是伸缩单位；Functions 把计算资源组织为消费计划或 Premium 计划，执行单元是函数调用。理解这些“伸缩单位”的差异，才能正确设置高可用与容量策略。

三、高可用业务平台工程的整体架构

高可用不是“多开一台 VM”，而是从业务目标反推技术设计。一个可落地的高可用平台通常包含五层：接入层、计算层、数据层、平台服务层、运维层。接入层负责流量分发与 TLS 终止，常见组合是 Application Gateway 或 Front Door 加 WAF；计算层承载业务进程，可以是 VMSS、App Service 实例或 AKS Pod；数据层决定持久化与复制策略，如 Azure SQL 的异地复制、Storage 的 LRS/ZRS/GRS；平台服务层提供密钥、配置、消息与缓存；运维层负责监控、告警、备份与演练。

以“订单查询 API”为例，假设业务要求 RTO ≤ 15 分钟、RPO ≤ 5 分钟。若选择 VMSS + Azure SQL，则需要在两个可用区部署 VMSS 实例，SQL 使用区域冗余配置并开启自动故障转移；若选择 App Service + Azure SQL，则 App Service 计划至少三实例并开启区域冗余，SQL 同样区域冗余。两种方案都能满足目标，但前者需要你维护 OS 补丁与实例健康脚本，后者由平台处理实例健康与部分升级。这里的关键判断依据是：团队是否具备持续维护 OS 与中间件的能力。

四、学习路线：从资源认知到平台工程

本课程后续内容将沿着“资源 → 可用性 → 伸缩 → 网络 → 数据 → 自动化 → 可观测 → 容灾”的路径展开。建议的学习顺序是：

1. 先掌握 VM、VMSS、可用区、可用性集的基本概念与选型方法，能独立完成一台 VM 的规格选择与磁盘配置。
2. 再理解负载均衡、Application Gateway、Front Door 的流量路径与健康探测机制，能画出请求从客户端到后端的完整链路。
3. 然后进入 AKS 与 App Service 的托管计算模型，理解 Pod、节点池、部署槽、自动缩放规则的实际行为。
4. 接着学习数据层高可用：Azure SQL 的故障转移组、Storage 的冗余选项、Cosmos DB 的多区域写入。
5. 最后把监控、备份、IaC 与故障演练串起来，形成可复现的高可用平台工程闭环。

总结来说，Azure 虚拟化计算平台的核心不是“选哪个服务”，而是“在控制权、运维成本与可用性目标之间找到平衡”。IaaS 给你更大的控制面，PaaS 给你更快的交付速度；计算资源谱系决定了你的伸缩与故障隔离粒度；高可用平台工程则要求你把 SLA、RTO/RPO、冗余设计、容量策略与可观测能力串成一条可验证的链路。掌握这条主线，后续每一章的具体技术才有落点。