Microsoft AZ-900: Azure 架构与全球基础设施 — 学习指南

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

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

Azure 的全球架构旨在以规模化的方式提供具有弹性、高性能和合规性的云服务。理解地理位置、区域和可用区的物理布局，以及管理组、订阅、资源组和资源的逻辑层次结构，是可靠设计和治理的基础。由 Azure Resource Manager 提供的控制平面，结合声明式模板，可以实现与组织策略和安全要求一致的可重复部署。此领域的设计决策直接影响可用性目标、数据驻留义务以及全球用户体验。选择正确的冗余模型、计算复合 SLA 以及选择 Azure Front Door、Traffic Manager 和 Azure CDN 等全局路由服务，是实现业务连续性、合规性和性能目标的核心。

地理位置、区域、可用区和区域对

Azure 地理位置是保留数据驻留和合规性边界的已定义区域集合。示例包括美国、欧洲、英国、澳大利亚和加拿大，以及具有独特合规性和连接模型的主权云。必须保留在特定管辖区内的工作负载应部署到属于目标地理位置的区域中，以确保法规遵从和数据驻留。一个区域是一组部署在延迟定义的边界内，并通过专用的低延迟网络连接的数据中心。并非所有服务或功能在每个区域都可用，因此应在规划初期验证容量和功能可用性。支持可用区的区域提供三个或更多物理上独立的数据中心区域，它们拥有独立的电源、冷却和网络。区域冗余服务 (ZRS) 和跨区域构建的体系结构可以防范数据中心级别的故障，同时保持区域内的低延迟访问。每个 Azure 区域都与同一地理位置内的另一个区域配对，形成一个区域对（例如，North Europe 与 West Europe，East US 与 West US）。区域对可以在发生大范围中断时实现优先恢复、错开平台更新以及为某些服务进行数据复制。Azure Storage 的异地冗余选项 (GRS/GZRS) 会将数据异步复制到配对区域；当需要对辅助区域进行读取访问时，请使用 RA-GRS 或 RA-GZRS，以便在发生中断或计划内故障转移时允许从辅助终结点进行读取。对于既需要区域内高可用性又需要跨区域灾难恢复的关键任务工作负载，应将区域冗余与区域对复制相结合。平衡延迟、弹性和合规性会形成一种常见模式：在主区域中跨多个区域部署活动工作负载，并通过将数据复制到配对区域并提供故障转移路径来防范区域性灾难。定期验证故障转移运行手册以及 DNS 或前端路由行为，以确保满足恢复目标。

• 地理位置
  • 范围：多区域边界
  • 主要优势：数据驻留和合规性
  • 典型用途：法规遵从（例如，欧盟数据）
• 区域
  • 范围：单个都会区
  • 主要优势：对服务的低延迟访问
  • 典型用途：主要部署位置
• 可用区
  • 范围：区域内不同的数据中心
  • 主要优势：数据中心级别的故障隔离
  • 典型用途：区域内高可用性
• 区域对
  • 范围：同一地理位置中的两个区域
  • 主要优势：协调的恢复和更新
  • 典型用途：跨区域灾难恢复

资源组织与治理：管理组、订阅、资源组和资源

Azure 的管理层次结构支持大规模的策略、访问和成本控制。管理组位于订阅之上，允许您集中应用 Azure Policy 和基于角色的访问控制 (RBAC)，其继承性会级联到子管理组和订阅。这是按公司部门、环境层级（生产、非生产）或法规边界进行分段，同时保持统一护栏的正确结构。订阅是管理、计费和配额的边界。它们非常适合隔离业务单元、环境或应用程序的成本和访问权限。使用一致的订阅设计来分离生产和非生产环境，并强制执行限制和预算。对于拥有多个部门和分散管理模式的组织，为每个部门分配一个或多个订阅，并将它们置于特定于部门的管理组下，以实现清晰的策略和 RBAC 继承。资源组是共享生命周期的资源的逻辑容器。它们支持原子化部署、一致的标记以及删除或锁定等生命周期操作。将一同部署、更新和停用的资源（例如 Web 层及其监控组件）分组。使用标签来推动跨资源和组的成本分摊/成本展示、所有权、环境和合规性属性。锁（ReadOnly、CanNotDelete）在资源或组范围增加了防止意外删除的保护。资源是已部署的服务实例（虚拟机、App Service 计划、存储帐户）。RBAC 范围（管理组、订阅、资源组、资源）允许在需要的地方精确授予最小权限访问。对于多部门部署，保留单个 Microsoft Entra ID 租户，除非有强烈的合规性或自治要求需要多个租户；订阅和管理组通常能提供足够的分离，且管理开销要小得多。

• 管理组 (Management Group)
  • 主要目的：组织范围的治理
  • 应用的控制：RBAC、策略、蓝图（通过策略 + 模板）
  • 常见模式：按部门/法规进行分段
• 订阅 (Subscription)
  • 主要目的：计费和配额边界
  • 应用的控制：预算、RBAC、策略
  • 常见模式：按业务单元或按环境隔离
• 资源组 (Resource Group)
  • 主要目的：生命周期边界
  • 应用的控制：锁、标签、RBAC
  • 常见模式：按应用程序或工作负载单元
• 资源 (Resource)
  • 主要目的：服务实例
  • 应用的控制：实例级 RBAC、标签
  • 常见模式：单个服务组件

Azure Resource Manager 和模板

Azure Resource Manager (ARM) 是一个控制平面，通过一致的 API 和基于角色的模型来部署、更新和删除 Azure 资源。ARM 在部署时提供幂等操作、依赖项管理、标记和策略强制执行，从而能够将平台治理嵌入到每个变更中。声明式的 ARM 模板以 JSON 格式描述您环境的期望状态，并支持参数、变量、条件和模块化的链接模板。它们支持跨环境和订阅进行可重复、版本控制的部署。为了获得简化的编写体验，Bicep 提供了一种简洁的语法，可以转译为 ARM 模板，同时保留相同的部署引擎和优势。将模板存储在源代码控制中，将其打包为模板规范以供共享，并将其集成到 CI/CD 管道中，以确保无漂移、可审计的基础设施变更。敏感值（如管理员密码或连接字符串）绝不应嵌入模板中。使用带有 Key Vault 引用的 secureString/secureObject 参数，以便 ARM 在部署时检索机密，而不会在日志中暴露它们。将模板与托管标识相结合，以消除自动化中的硬编码凭据。这种方法在降低风险的同时，为大规模、多订阅的部署保留了完全的自动化能力。

• 幂等部署
  • ARM/模板支持：是
  • 结果：安全、可重复的变更
• 部署时强制执行策略
  • ARM/模板支持：是
  • 结果：将护栏内置于管道中
• 模块化组合
  • ARM/模板支持：链接模块 / Bicep 模块
  • 结果：可重用性和标准化
• 机密处理
  • ARM/模板支持：Key Vault 引用
  • 结果：代码或日志中无机密

可用性、SLA、复合 SLA 与服务生命周期

Azure 为正式发布 (GA) 的服务发布提供财务支持的服务级别协议 (SLA)。对于虚拟机，可用性取决于部署拓扑：使用 Premium SSD 存储的单个 VM 的 SLA 为 99.9%；可用性集中的两个或更多 VM 的 SLA 为 99.95%；跨可用性区域部署的两个或更多 VM 可实现 99.99% 的 SLA。平台服务（例如，Azure SQL Database 或 App Service）有其自身的 SLA，这些 SLA 可能会因层级或冗余选项而异。通过选择适当的冗余模型和服务层级，使架构与目标 SLA 保持一致。当一个解决方案依赖于多个服务时，如果应用的所有组件都是正常运行所必需的，则复合 SLA 是各个独立 SLA 的乘积。例如，如果一个 Web 应用 (99.95%) 依赖于一个数据库 (99.99%)，则复合可用性约为 0.9995 × 0.9999 = 99.94%。在任何层级增加冗余——例如跨区域部署、在负载均衡器后添加多个实例，或使用异地冗余数据存储——都能提高有效可用性。相反，增加串行依赖会降低复合 SLA，应有明确的功能价值来证明其合理性。服务生命周期状态会影响可靠性保证。公共预览功能旨在收集反馈，可能仅限于某些区域或存在功能差距；它们通常不带 SLA，不建议用于生产环境的关键路径。正式发布 (GA) 的功能已为生产环境准备就绪，并受 SLA 保护。应跟踪产品路线图和区域推出计划，以避免在生产设计中（尤其是在合规敏感的环境中）无意中依赖预览功能。灾难恢复目标（如 RPO 和 RTO）是对 SLA 的补充，并指导设计选择，如跨区域或跨地域复制、备份频率和故障转移编排。定期验证故障转移过程，以确保测得的恢复性能与业务目标一致，并确保 DNS、证书和身份依赖项也能按预期恢复。

• 单个 VM (Premium SSD)
  • 参考 SLA：99.9%
  • 说明：用于非关键工作负载或容错能力强的应用
• 可用性集中的 2+ 个 VM
  • 参考 SLA：99.95%
  • 说明：防止机架/故障域故障
• 跨可用性区域的 2+ 个 VM
  • 参考 SLA：99.99%
  • 说明：防止数据中心级别的故障
• 公共预览功能
  • 参考 SLA：无财务 SLA
  • 说明：用于评估；避免在关键路径上使用
• GA 功能（取决于服务层级）
  • 参考 SLA：有 SLA 支持
  • 说明：检查特定于层级和区域的 SLA

全局路由与内容分发：Azure Front Door、Traffic Manager 和 Azure CDN

全局用户体验取决于智能路由、内容邻近性和快速故障转移。Azure Front Door 是一个全局性的、任播 (anycast) 的第 7 层反向代理，具备 Web 应用程序防火墙 (WAF)、TLS 终止、基于 URL/路径的路由、会话亲和性以及来自边缘的健康探测功能。它通过拆分 TCP (split-TCP) 和协议优化来加速动态内容，并提供源站之间近乎即时的故障转移。Front Door 是主动-主动或主动-被动多区域 Web 应用程序和 API 的理想选择，尤其是在需要边缘性能和集中式安全性的场景中。Azure Traffic Manager 是一个基于 DNS 的流量分发服务，它使用优先级、加权、性能（延迟）、地理位置、子网或多值等策略将客户端定向到最佳终结点。由于它在 DNS 层运行，因此支持非 HTTP 终结点（例如 TCP 服务）和混合场景，但故障转移速度受 DNS TTL 和客户端缓存的限制。Traffic Manager 不代理流量或加速内容；它只是用选定的终结点来响应 DNS 查询。Azure CDN 在边缘接入点缓存静态内容，以减少延迟并为源站减负。它非常适合大型静态资产，如图像、视频、脚本和下载文件。虽然 CDN 减少了可缓存内容的往返次数，但它不是一个具备健康检查能力的动态源站全局负载均衡器；应将其与 Front Door 或 Traffic Manager 结合使用，以实现多源站故障转移或动态路由逻辑。许多架构会将用于静态资产缓存的 CDN 和用于动态流量与安全的 Front Door 部署在同一个应用程序的前端。

• Azure Front Door (Std/Prm)
  • 层级/机制：第 7 层任播代理
  • 主要用例：全局负载均衡、边缘安全、加速
  • 路由方法：优先级、加权；基于路径/主机的规则
  • 健康探测：边缘 POP 探测
  • 故障转移速度：秒级（近乎即时）
  • 动态加速：是
  • 静态缓存：是（基于规则）
  • WAF 可用性：是（集成）
  • 典型模式：Front Door 位于多区域 Web 应用/API 前端
• Azure Traffic Manager
  • 层级/机制：基于 DNS 的策略
  • 主要用例：跨区域 DNS 路由；非 HTTP 终结点
  • 路由方法：优先级、加权、性能、地理位置、子网、多值
  • 健康探测：全局终结点探测
  • 故障转移速度：受 TTL 限制（数十秒到数分钟）
  • 动态加速：否
  • 静态缓存：否
  • WAF 可用性：不适用
  • 典型模式：为 HTTP 和非 HTTP 服务提供 DNS 导向
• Azure CDN
  • 层级/机制：边缘缓存网络
  • 主要用例：静态内容卸载和延迟降低
  • 路由方法：不适用（缓存规则）
  • 健康探测：不适用（可选的源组故障转移）
  • 故障转移速度：不适用（基于缓存）
  • 动态加速：否（缓存之外不支持）
  • 静态缓存：是
  • WAF 可用性：通过 Front Door Premium 或独立的 WAF
  • 典型模式：CDN 用于静态资产 + Front Door/Traffic Manager 用于源站

实践问题：为 IronPeak Manufacturing 设计一个高可用、合规且具备全球性能的 Web 平台

场景： IronPeak Manufacturing 在欧洲和北美开展业务，正在将其客户和合作伙伴门户整合到 Azure 上。该平台必须满足 Web 层 99.99% 的可用性要求，将欧盟客户数据保留在欧盟境内，提供跨区域的快速故障转移，并在全球范围内实现快速的页面加载。团队希望实现完全自动化的部署，并且在代码或日志中不出现任何明文密钥。

挑战： 在欧盟实现数据驻留的同时，达成区域内高可用性和跨区域灾难恢复；为动态流量提供全球加速和故障转移；以及实现跨订阅的可重复、安全部署。

推荐方法：

1. 选择欧洲地理区域，并在一个有可用区（Availability Zones）的区域（例如，West Europe）部署主工作负载，使用两个或更多跨可用区分布的 VM scale set 实例或 App Service 实例。
2. 使用服务的原生复制功能，启用到配对区域（North Europe）的跨区域灾难恢复：对 Storage 使用 RA-GZRS，对数据库使用异地复制（如果可用）；配置自动化的故障转移运行手册。
3. 使用 Azure Front Door Standard/Premium 作为应用的前端，以实现全球 HTTPS 终止、WAF、边缘健康探测、在 West Europe（主区域）和 North Europe（备用区域）之间基于优先级的故障转移，以及基于路径的路由规则。
4. 使用与相同源站集成的 Azure CDN 缓存静态资产（图片、脚本、下载文件），以减少延迟并分流；验证缓存规则和 TTL。
5. 为欧盟和北美部门定义管理组；将生产和非生产订阅分别置于其下，应用 Azure Policy 进行数据驻留、标记和允许位置的策略管理。
6. 实施存储在源代码管理中并作为模板规范发布的 ARM/Bicep 模板；参数化区域、SKU 和扩展；在部署时使用托管标识从 Azure Key Vault 引用密钥。
7. 设定 SLA 并测试复合可用性：Front Door 后面的两个跨可用区分布的实例，目标是为应用层实现 99.99% 的可用性；每季度验证端到端的故障转移演练、DNS、证书和身份依赖项。
8. 使用 Application Insights 和 Azure Monitor 检测平台；配置 Front Door 健康探测和警报；根据遥测数据调整自动缩放和缓存策略。

Azure 基本原理： 此设计将欧盟数据保留在欧洲地理区域内，同时通过可用区（Availability Zones）提供区域内故障隔离，并通过配对区域实现跨区域灾难恢复。Azure Front Door 为动态流量提供全球加速和健康感知故障转移，而 Azure CDN 则通过卸载静态内容来提升性能。带有 Key Vault 引用的 ARM/Bicep 模板可跨订阅和区域提供可重复、安全的部署。所选拓扑与已发布的 SLA 对齐，以满足 Web 层 99.99% 的目标，同时在管理组和订阅级别应用策略，以最小的运营开销强制实施治理。

← 云概念 · 所有领域 · 计算与应用服务 →

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

浏览 Microsoft →