Microsoft AZ-900: 云概念 — 学习指南

By Laurynas Brazys · 24 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

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

云计算通过互联网提供按量计费的 IT 资源，具有快速预配、全球覆盖和内置恢复能力的特点。从本地基础设施迁移到 Azure 会改变技术选型和运营模式：容量规划让位于弹性伸缩，资本采购转变为运营支出，硬件维护成为平台的责任。理解这些概念对于选择合适的服务、构建高可用性架构以及控制成本至关重要。

核心云特性：可伸缩性、弹性、敏捷性和恢复能力

可伸缩性是工作负载通过增加资源来处理增长需求的能力。在 Azure 中，这有两种形式：垂直伸缩（纵向扩展），即选择更大的 VM 规格或更高的 App Service 计划；以及水平伸缩（横向扩展），即通过 Virtual Machine Scale Sets (VMSS)、Azure Kubernetes Service (AKS) 节点池或 App Service 自动伸缩来增加更多实例。当需求下降时，反向伸缩可以减少容量和成本。设计无状态层并将状态外部化（例如，存储到 Azure Cache for Redis 或 Azure SQL Database）可以使水平伸缩变得可预测且快速。弹性是自动化的、策略驱动的伸缩，可持续地使容量与负载保持一致。Azure Monitor 自动伸缩规则、AKS 集群自动伸缩器以及 Azure Functions 或消耗/弹性高级计划等无服务器选项，可以近乎实时地扩展和缩减资源。弹性架构能最大限度地减少空闲容量，非常适合尖峰或季节性工作负载，使支出与使用量精确匹配。敏捷性是团队交付变更的速度。通过 Bicep 或 ARM 模板、GitHub Actions 或 Azure DevOps 管道进行 Azure 资源部署，以及使用 App Service 或 AKS 等资源抽象，可以实现频繁、低风险的发布。通过 RBAC 和策略护栏实现的自助式预配，可以在保持治理的同时减少等待时间。敏捷性是平台和组织实践共同的产物；平台抽象的无差异化繁重工作越多，团队的行动就越快。容错和灾难恢复解决不同范围的故障。容错通过使用可用性集（将 VM 分布在不同容错域/更新域）、可用性区域（区域内物理上分离的数据中心）、负载均衡器和冗余数据路径，来缓解区域内的组件和数据中心故障。灾难恢复通过跨区域复制（GRS/RA-GRS 存储、Azure SQL 活动异地复制、Cosmos DB 多区域写入）和 Azure Site Recovery 等恢复工具，为区域级别的服务中断做好准备。定义明确的 RTO/RPO 目标并测试故障转移，以确保设计满足业务连续性目标。

服务模型与责任共担

云服务模型决定了您管理什么以及 Azure 管理什么。基础设施即服务 (IaaS) 提供原始的计算、存储和网络构建块。您控制来宾操作系统、运行时和应用程序——当您需要自定义镜像、专用中间件或完全控制权时，这是理想的选择。平台即服务 (PaaS) 抽象了操作系统和大部分中间件，提供托管的运行时、数据库和集成服务，使团队可以专注于代码和数据。软件即服务 (SaaS) 提供完整的应用程序，通过浏览器或 API 使用，只需最少的配置，且没有应用程序托管的义务。责任共担模型明确了运营的边界。在 IaaS 中，Azure 管理物理数据中心、主机和 Hypervisor；您负责操作系统补丁、安全强化、应用程序更新、身份和访问以及数据治理。在 PaaS 中，Azure 还管理操作系统和平台中间件；您管理应用程序代码、配置和数据。在 SaaS 中，Azure（或 SaaS 提供商）运营整个技术栈；您管理用户、访问、数据分类和使用配置。在所有模型中，客户始终对身份、权限、端点安全和数据保护策略负责。选择正确的模型会影响可用性目标和成本。部署 Azure 虚拟机是一项 IaaS 任务；Azure App Service 上的 Web API 或 AKS 上的容器体现了 PaaS；Microsoft 365 和 Dynamics 365 属于 SaaS。尽可能优先选择 PaaS 和 SaaS 以加速交付并减轻运营负担，仅为需要操作系统级别控制或有遗留依赖项的工作负载保留 IaaS。

• IaaS
  • 典型 Azure 服务：Azure Virtual Machines、VM Scale Sets、Azure Disks、Virtual Network
  • 您管理的内容：来宾操作系统、补丁、运行时、应用、数据、备份、AV/EDR
  • 何时选择：需要完全的操作系统控制、自定义中间件、直接迁移 (lift-and-shift)
• PaaS
  • 典型 Azure 服务：Azure App Service、Azure SQL Database/Managed Instance、AKS、Azure Functions、Azure Integration Services
  • 您管理的内容：代码/配置、架构、数据、身份和访问
  • 何时选择：加快交付、内置伸缩/高可用性、减少运维
• SaaS
  • 典型 Azure 服务：Microsoft 365、Dynamics 365、Power BI、Azure DevOps Services
  • 您管理的内容：用户、角色、数据使用/配置
  • 何时选择：只需最少管理的完整应用

部署模型与扩展范围

公有云将工作负载部署在微软拥有的数据中心，这些数据中心由多个租户共享，并通过逻辑隔离进行区分。它提供最广泛的服务目录、全球覆盖、快速预配以及纯粹的即用即付模型。私有云为单个组织专用基础设施，通常是出于法规或数据主权的原因，并且可以在 Azure 验证的堆栈（如 Azure Stack Hub 或 Azure Stack HCI）上运行。混合云通过一致的身份、策略和网络连接本地环境与 Azure，从而实现分阶段迁移和数据本地化，同时在适当的场景下利用云的弹性。全局扩展与本地扩展关注的是可用性和性能改进的范围。本地扩展将流量保持在区域内部，使用 Availability Zones、VM Scale Sets、Application Gateway 和 Azure Load Balancer 来增加实例并隔离数据中心故障。全局扩展使用 Azure Front Door（现代化的、基于 anycast 的、带 WAF 的第 7 层全局负载均衡）、Azure Traffic Manager（基于 DNS 的负载均衡）以及地理复制的数据服务（如 Azure SQL geo-replication 或 Cosmos DB 多区域分发）将流量分布到多个区域。多区域主动/主动设计可以改善延迟和弹性，但需要仔细进行数据一致性和成本规划。选择部署模型通常始于合规性和连接性约束，并随着应用程序的生命周期而演变。新的绿地 Web 应用程序通常会部署在公有云 PaaS 上，以追求速度和可扩展性。具有依赖关系的复杂业务线系统可能会以混合模式开始——将某些服务保留在本地，同时将前端和无状态层迁移到 Azure——然后在依赖关系现代化之后完成整个过渡。

• 公有云
  • 所有权/位置：微软拥有的区域
  • 典型访问方式：Internet/VPN/ExpressRoute
  • 用例：弹性扩展、全球覆盖、快速创新
  • Azure 示例：大多数 Azure 服务、Azure Front Door、Azure App Service
• 私有云
  • 所有权/位置：客户专用基础设施（本地或托管）
  • 典型访问方式：专用网络
  • 用例：主权、隔离的工作负载、严格的合规性
  • Azure 示例：Azure Stack Hub、Azure Stack HCI、AKS on HCI
• 混合云
  • 所有权/位置：本地与 Azure 的混合
  • 典型访问方式：Site-to-site VPN 或 ExpressRoute
  • 用例：分阶段迁移、数据本地化、旧系统集成
  • Azure 示例：Azure VPN Gateway、ExpressRoute、Azure Arc

成本模型：CapEx 与 OpEx、消费定价、即用即付和预留容量

本地采购通常是资本支出（CapEx）：前期一次性大额购买服务器、存储和网络设备，并在数年内进行折旧。Azure 将此模型转变为运营支出（OpEx）：服务根据实际消耗量（如 CPU 秒数、GB-月、事务数）进行计量和计费，将支出转移到价值实现之时。这种基于消耗的定价减少了过度预配，并将成本与使用模式挂钩。即用即付模式最大化了灵活性：可以随时启动和停止资源，无需长期承诺。对于稳定状态的工作负载，Azure 提供基于预留的折扣，例如 Reserved Virtual Machine Instances、Azure SQL Database reserved capacity、Cosmos DB RU/s reservations 和 Storage reserved capacity。一年或三年的承诺可以带来显著的成本节省，同时还可以选择性地启用实例大小灵活性和跨订阅的共享范围。补充选项包括 Azure Savings Plans for Compute（它将折扣率应用于符合条件的计算服务）和 Spot VMs（用于可中断的、批处理类型的工作负载，可享受大幅折扣）。有效的成本治理需要将正确的商业模型与工程控制相结合。Autoscale 可以减少空闲容量；无服务器层在空闲时消除基础设施；Azure Hybrid Benefit 可以应用现有的 Windows Server 和 SQL Server 许可证；开发/测试定价可以降低非生产环境的支出。Azure Cost Management + Billing 提供预算、异常检测和成本分配功能，以实现持续优化。

• 即用即付
  • 承诺：无
  • 与 PAYG 相比的典型折扣：0%
  • 灵活性：最大灵活性；随时启动/停止
  • 最适合：不可预测或短期工作负载
• Reserved VM Instances / 预留容量
  • 承诺：1 年或 3 年
  • 与 PAYG 相比的典型折扣：最高约 72%（使用 Azure Hybrid Benefit）
  • 灵活性：范围可共享；允许交换；提前取消有费用
  • 最适合：稳定的 24x7 计算、数据库、Cosmos DB
• Savings Plan for Compute
  • 承诺：1 年或 3 年的支出承诺
  • 与 PAYG 相比的典型折扣：最高约 65%
  • 灵活性：适用于 VMs、AKS、Functions Premium、App Service
  • 最适合：实例类型可变的混合计算负载
• Spot VMs
  • 承诺：无（取决于容量）
  • 与 PAYG 相比的典型折扣：最高约 90%
  • 灵活性：可能被逐出；无 SLA
  • 最适合：批处理、无状态、CI、渲染作业

实践问题：PeakGear Retail：兼顾成本控制与弹性的季节性伸缩

场景： PeakGear Retail 运营一个电子商务网站，该网站有可预测的月末和节假日流量高峰。公司希望从本地虚拟机迁移到 Azure，以降低资本支出，为 Web 层维持 99.99% 的可用性目标，并实施一个恢复时间目标 (RTO) 为四小时、恢复点目标 (RPO) 为 15 分钟的灾难恢复计划。身份认证必须通过 Microsoft Entra ID 与现有用户集成。

挑战： 设计一个 Azure 架构和成本模型，该模型能够为流量激增提供弹性伸缩、区域级容错、跨区域灾难恢复和简化的运维，同时在非高峰时段最大限度地降低成本。

推荐方法：

1. 使用 Premium v3 计划将 Web API 和店面部署在 Azure App Service (PaaS) 上，以获得内置的自动缩放、托管的平台补丁和区域冗余选项。
2. 将两个或更多 App Service 实例置于 Azure Front Door Standard/Premium 之后，用于全局任播入口、SSL 终止、WAF 和基于路径的路由；根据需要启用健康探测和会话亲和性。
3. 在主区域使用具有区域冗余的 Azure SQL Database Business Critical；配置到配对的次要区域的活动异地复制，以实现 15 分钟的 RPO 目标。
4. 使用带 RA-GRS 的 Azure Storage 存储静态内容；前端使用 Azure CDN from Microsoft 来分流带宽并改善延迟。
5. 基于 CPU、请求数和队列深度实施自动缩放规则，以便在高峰期横向扩展，在平稳期横向缩减；对于后台作业，使用 Azure Functions Consumption 或 Elastic Premium 计划。
6. 通过为 App Service 计划启用区域冗余（多区域）或在支持的情况下将实例分布到多个可用区来实现 99.99% 的 Web 层可用性。
7. 初期采用即用即付模式以获得灵活性；对于 30 天后确定的稳定基线容量，为 App Service 计划购买 1 年期预留实例（通过涵盖 App Service 的 Savings Plan for Compute）并为 SQL Database 购买预留容量，以降低日常运行成本。
8. 集成 Microsoft Entra ID 进行用户和管理员访问控制；应用内置角色和条件访问策略，遵循最小权限原则；将机密信息保护在 Azure Key Vault 中，并由 App Service 和部署管道引用。
9. 定义并测试灾难恢复 (DR) 操作手册：将 SQL 故障转移到次要区域，更新 Front Door 源站优先级以激活次要区域，并在四小时的 RTO 内验证应用程序的健康状况。
10. 实施 Azure Monitor 和 Log Analytics 以集中管理指标、跟踪和日志；配置警报和仪表板；设置 Azure Cost Management 预算和异常警报，以持续优化支出。

Azure 基本原理： PaaS 服务（App Service 和 Azure SQL Database）在责任共担模型下，最大限度地提高了敏捷性，并减轻了操作系统和平台的维护负担，同时通过自动缩放实现了弹性。区域冗余部署和多区域复制提供了区域内的容错能力和跨区域的灾难恢复能力，满足了既定的 RPO/RTO 要求。Front Door 提供了全局入口、基于健康状况的路由和 WAF 保护。初期采用即用即付模式在迁移期间保持了灵活性；为测量出的基线容量承诺预留容量或 Savings Plan 可降低稳定使用量的成本，而自动缩放则削减了非高峰时段的开销。Microsoft Entra ID 集中了身份和访问控制，而 Azure Monitor 与 Cost Management 则保持了运维和财务的可见性。

所有领域 · Azure 架构与全球基础设施 →

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

浏览 Microsoft →