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