什么是 Azure 资源管理器？
Azure 资源管理器是 Azure 的部署和管理服务。 它提供了一个管理层，用于在 Azure 帐户中创建、更新和删除资源。 部署后，可以使用访问控制、锁和标记等管理功能来保护和组织资源。
若要了解 Azure 资源管理器模板（ARM 模板），请参阅 ARM 模板概述。 若要了解 Bicep，请参阅 Bicep 概述。
一致的管理层
在你通过 Azure API、工具或 SDK 发送请求时，资源管理器会收到该请求。 它会在将该请求转发到相应的 Azure 服务之前先对它进行身份验证和授权。 由于所有请求是通过同一个 API 处理的，因此在所有不同的工具中会看到一致的结果和功能。
下图演示了 Azure 资源管理器在处理 Azure 请求时发挥的作用。
在门户中提供的所有功能也可以通过 PowerShell、Azure CLI、REST API 和客户端 SDK 来提供。 最初通过 API 发布的功能将在初次发布后的 180 天内在门户中提供。
重要
到 2023 年秋季，Azure 资源管理器将仅支持传输层安全性 (TLS) 1.2 或更高版本。 有关详细信息，请参阅迁移到适用于 Azure 资源管理器的 TLS 1.2。
术语
如果不熟悉 Azure 资源管理器，则可能不熟悉某些术语。
- 资源 - 可通过 Azure 获取的可管理项。 资源的示例包括虚拟机、存储帐户、Web 应用、数据库和虚拟网络。 资源组、订阅、管理组和标记也是资源的示例。
- 资源组 — 一个容器，用于保存 Azure 解决方案的相关资源。 资源组包括你想要作为一个组进行管理的那些资源。 根据最适合组织的情况来决定哪些资源属于哪个资源组。 请参阅什么是资源组？。
- 资源提供程序 - 提供 Azure 资源的服务。 例如，
Microsoft.Compute就是一个常见的资源提供程序，它提供虚拟机资源。Microsoft.Storage也是一个常见的资源提供程序。 请参阅资源提供程序和类型。 - 声明性语法 - 一种语法，允许声明“以下是我想要创建的项目”，而不需要编写一系列编程命令来进行创建。 ARM 模板和 Bicep 文件是声明性语法的示例。 在这些文件中，可以定义要部署到 Azure 的基础结构的属性。
- ARM 模板 - 一个 JavaScript 对象表示法 (JSON) 文件，用于定义一个或多个要部署到资源组、订阅、管理组或租户的资源。 使用模板能够以一致方式反复部署资源。 请参阅模板部署概述。
- Bicep 文件 - 以声明方式部署 Azure 资源的文件。 Bicep 是一种语言，旨在为 Azure 中的基础结构即代码解决方案提供最佳创作体验。 请参阅 Bicep 概述。
- 扩展资源 - 是扩展另一资源的功能的资源。 例如，角色分配就是一种扩展资源类型。 可将角色分配应用于任何其他资源以指定访问权限。 请参阅扩展资源。
有关 Azure 术语的更多定义，请参阅 Azure 基本概念。
使用资源管理器的优势
使用资源管理器可以：
通过声明性模板而非脚本来管理基础结构。
以组的形式部署、管理和监视解决方案的所有资源，而不是单独处理这些资源。
在整个开发生命周期内重复部署解决方案，并确保以一致的状态部署资源。
定义各资源之间的依赖关系，使其按正确的顺序进行部署。
将访问控制应用于所有服务，因为 Azure 基于角色的访问控制 (Azure RBAC) 原本已集成到管理平台。
将标记应用到资源，以逻辑方式组织订阅中的所有资源。
通过查看一组共享相同标记的资源的成本来理清组织的帐单。
了解范围
Azure 提供四个级别的管理范围：管理组、订阅、资源组和资源。 下图显示了这些层的一个示例。
将在上述任何级别的作用域中应用管理设置。 所选的级别确定应用设置的广泛程度。 较低级别继承较高级别的设置。 例如，将策略应用于订阅时，该策略将应用于订阅中的所有资源组和资源。 在资源组上应用策略时，该策略将应用于该资源组及其所有资源。 但是，其他资源组没有该策略分配。
有关管理标识和访问的详细信息，请参阅 Microsoft Entra ID。
可以将模板部署到租户、管理组、订阅或资源组。
什么是资源组？
资源组是用于管理 Azure 解决方案相关资源的容器。 通过使用资源组，可以协调对相关资源的更改。 例如，可以将更新部署到资源组，并确信资源将以协同方式进行更新。 或者，完成解决方案后，可以删除资源组并知晓所有资源都已删除。
定义资源组时，需要考虑以下几个重要因素：
资源组中的所有资源应该具有相同的生命周期。 一起部署、更新和删除这些资源。 如果某个资源（例如服务器）需要采用不同的部署周期，则它应在另一个资源组中。
每个资源只能存在于一个资源组中。
随时可以在资源组添加或删除资源。
可以将资源从一个资源组移到另一个组。 有关详细信息，请参阅将资源移到新资源组或订阅。
资源组中的资源可以位于与资源组不同的区域，但我们建议使用相同的位置。 请参阅我应该为资源组使用哪个位置？
可以对资源组应用标记。 资源组中的资源不会继承这些标记。
资源可以连接到其他资源组中的资源。 以下情况很常见：两个资源相关，但不具有相同的生命周期。 例如，一个连接到其他资源组中数据库的 Web 应用。
删除一个资源组时，该资源组中的所有资源也会被删除。 如需了解 Azure 资源管理器如何编排这些删除，请参阅 Azure 资源管理器资源组和资源删除。
最多可在每个资源组中部署 800 个资源类型实例。 某些资源类型不受 800 个实例限制的约束。 有关详细信息，请参阅资源组限制。
要创建资源组，可使用门户、PowerShell、Azure CLI 或 ARM 模板。
我应该为资源组使用哪个位置？
创建资源组时，需要提供该资源组的位置。
你可能想知道，“为什么资源组需要一个位置？ 另外，如果资源的位置和资源组不同，那为什么资源组的位置很重要呢？
” 资源组存储有关资源的元数据。 当指定资源组的位置时，也就指定了元数据的存储位置。 出于合规性原因，可能需要确保数据存储在某一特定区域。
为了确保资源组的状态一致性，所有控制平面操作都通过资源组的位置进行路由。 选择资源组位置时，建议选择靠近控制操作发源的位置。 通常，此位置最靠近当前位置。 此路由要求仅适用于资源组的控制平面操作。 它不会影响发送到应用程序的请求。
如果资源组的区域暂时不可用，则可能无法更新资源组中的资源，因为元数据不可用。 其他区域中的资源仍将按预期运行，但你可能无法更新它们。 此条件也可能适用于 Azure DNS、Azure DNS 专用区域、Azure 流量管理器和 Azure Front Door 等全局资源。 可以通过 Azure Resource Graph 资源表的类型列表查看哪些类型的元数据由 Azure 资源管理器管理。
为了减少区域性服务中断的影响，建议在资源组所在的同一区域中查找资源。 当资源组的区域不可用时，Azure 资源管理器可能无法更新资源的元数据，并且可能会阻止写入调用。 通过将资源和资源组区域并置，可以降低区域不可用的风险，因为你的资源和元数据位于同一区域，而不是在多个区域中。
Azure 资源管理器的复原能力
Azure 资源管理器服务旨在实现复原能力和持续可用性。 REST API 中的资源管理器和控制平面操作（发送到 management.chinacloudapi.cn 的请求）具有以下特性：
跨区域分布。 Azure 资源管理器在每个 Azure 区域中都有一个单独的实例，这意味着一个区域中 Azure 资源管理器实例的故障不会影响其他区域中 Azure 资源管理器或其他 Azure 服务的可用性。 尽管 Azure 资源管理器分布在各个区域，但某些服务是区域性服务。 这种区别意味着，虽然控制平面操作的初始处理是有弹性的，但请求在转发到服务时可能容易受到区域中断的影响。
在具有多个可用性区域的位置上跨可用性区域（以及区域）分布。 这样的分布可确保当某个 Azure 区域丢失一个或多个区域时，Azure 资源管理器可以故障转移到另一个区域或另一个 Azure 区域，以继续为资源提供控制平面功能。
不依赖于单个逻辑数据中心。
从未因维护活动而停机。
这种复原能力适用于通过资源管理器接收请求的服务。 例如，Key Vault 可以利用这种复原能力。
解决并发操作
当两个或两个以上操作尝试同时更新同一资源时，Azure 资源管理器会检测到冲突，并只允许一项操作成功完成。 Azure 资源管理器将阻止其他操作并返回错误。
并发资源更新可能会导致意外结果。 此解决方法可确保更新具有确定性和可靠性。 了解资源的状态，并避免任何不一致或数据丢失。
假设你有两个请求（A 和 B）尝试同时更新同一资源。 如果请求 A 在请求 B 之前完成，则请求 A 成功，请求 B 失败。 请求 B 返回 409 错误。 获得此错误代码后，可以获取资源的更新状态，并确定是否要重新发送请求 B。
后续步骤
若要了解在 Azure 服务中应用的限制，请参阅 Azure 订阅和服务限制、配额和约束。
若要了解有关移动资源的信息，请参阅将资源移到新资源组或订阅。
若要了解如何标记资源，请参阅使用标记来组织 Azure 资源。
若要了解如何锁定资源，请参阅锁定资源以防止意外更改。