Azure Resource Graph（ARG）专为快速、大规模的Azure资源查询而设计。 由于 ARG 会异步为数据编制索引，因此请务必了解何时应直接查询 ARG，何时应转而查询拥有该资源的资源提供程序 (RP)，因为它才是该资源状态的权威来源。 本文解释了ARG如何融入Azure控制层，何时使用混合ARG+RP查询策略，以及如何在RP、ARG的查询API和获取/列表API之间选择。
ARG如何融入Azure控制平面
资源控制平面包含三个部分：
Azure 资源管理器 （ARM） - ARG 的请求网关。 ARM 将请求路由到 ARG，无需单独调用每个资源提供者。
资源提供程序 （例如计算资源提供程序或 CRP）-资源状态的真相来源。 直接调用资源提供者的 API 会返回 高度一致的数据。
Azure Resource Graph （ARG） - 基于控制平面数据的异步索引，专为跨大型资源集进行高吞吐量、可缩放的查询而构建。 ARG 是接近实时的；由于支持该 API 的系统具有分布式特性，它遵循最终一致性模型。 它比真实数据源晚了一小段时间，有时如果后台出现故障，会更久。
ARG 通过两种机制保持同步：来自 ARM 和资源提供程序的异步更改通知，以及定期执行的一致性校验，用于补上通知遗漏的任何更改。
注释
ARG 牺牲强一致性，以换取可扩展性和吞吐量。 资源提供程序 API 以吞吐量为代价来换取某一时点的正确性。 请选择符合您业务需求的选项。
对于关键场景，使用混合查询策略
在数据新鲜度和可靠性重要的情况下，采用混合策略：查询ARG以实现规模化，并在检测到数据新度问题、索引延迟或延迟升高，或在基于资源状态采取关键操作前，退回到资源提供者API。 此方法可一次性避免两种故障模式 - 始终直接调用 RP 的成本，以及处理过时 ARG 数据的风险（例如，重启或取消预配基于过时状态的资源）。
常见场景
资源创建后立即轮询 - 某些工作流在创建资源后的 1-2 秒内轮询资源 -例如，等待 provisioningState 到达最终状态，或等待某些属性出现在响应中。 由于ARG索引可能不完整，创建后不久发出的查询即使资源存在，仍可能返回 404 Not Found 。 采用混合策略以避免假阴性：如果在写入后 ARG 立即返回“未找到”，则在将其视为错误之前，应先回退到资源提供程序进行确认。
在破坏性操作前验证状态——如果你的工作流程使用ARG来识别某个操作的候选资源，而该操作是破坏性的（删除、重启、停用），就不要直接对ARG结果采取行动。 后端延迟可能会使ARG对资源的视图过时。 当最终的行为无法撤销时，这种风险尤为显著。
Important
使用ARG构建候选列表，然后在执行破坏性操作前，立即对资源提供者进行强一致性检查。
ARG最终一致性处理指南
仅在不可逆行动前进行验证，而非每次投票。 在执行可能影响客户或具有破坏性的工作流之前，增加一道二级资源提供程序检查，而不是针对每个 ARG 查询都进行此检查。 对每次轮询都进行验证，就失去了使用 ARG 的意义，还可能在大规模场景下触发限流。 模式是：信任ARG进行识别和规模化，在做出不可逆的事之前先向真实来源核实。
提示
如果按您的业务规模进行验证可能会引发限流方面的顾虑，请在触及限制之前联系 Azure。 支持此模式的配额增加是可支持的、预期的请求，而不是边缘情况。
如果你的场景允许，请在后续的 ARG 查询之间添加等待时间。 如果有，使用指数倒退：从第一次重试前几秒开始，每次尝试（例如2秒→4秒→8秒→16秒......）逐渐增加等待时间，最多达到几分钟。 一旦达到该上限，就不要再继续增加，而是要么按该上限间隔继续轮询，要么回退到资源提供程序 API。
对于高频轮询，请考虑使用 ARG Get/List API。 请参阅 本节 ，里面有更多关于如何用 Get/List API 设置后备。
API 的比较
请使用这个表格来确定哪个API适合你的场景。
| 功能 / 特点 | 资源提供者API（例如：CRP） | ARG 查询 API | ARG 获取/列出 API |
|---|---|---|---|
| 它是什么 | 直接调用资源提供者自身的API（例如VM/VMSS API）以查询资源和库存。 | Azure Resource Graph 的批量查询 API，可通过 Azure 门户中的 Resource Graph Explorer、Azure PowerShell、Azure CLI、SDK 和 REST API 获得。 | 使用现有的控制平面 Get/List API，并附加 useResourceGraph=true 参数，使调用经由 ARG 后端路由。 通过 Azure REST API 和部分 SDK 提供。 |
| 引用 | 通过Azure services查找资源提供者 |
使用 REST API 运行 Azure Resource Graph 查询，REST API 使用POST /providers/Microsoft.ResourceGraph/resources |
ARG GET/LIST API 利用现有的控制平面 GET API，将标志 useResourceGraph=true 附加到这些 API 上，从而无缝地将调用路由到该后端。 |
| 最适用于 | • 对控制平面 API 发起的小规模、临时性或不频繁的查询。 • 需要直接来自真实来源的强烈一致数据的情景。 • 在进行破坏性或不可逆操作（删除、重启、停用）前的最终检查。 • ARG 数据过时时的后备方案。 |
• 租户级批量查询，可跨多个租户、订阅、资源组或管理组进行联接，适用于复杂分析场景。 • 扫描或轮询大量资源（数千+）以获取状态。 |
• 查找范围涵盖单个订阅或资源组的完整获取/列表API表面。 • 高并发、高吞吐量轮询场景。 |
| 限速配额 | 因资源和操作而异，通常低于 ARG 限制。 举例：VMSS 虚拟机的 GET 在资源层面是每分钟 36 次呼叫，订阅层面为 2,000 次呼叫。 | 每5秒15次查询。 可以根据具体情况提出。 | 与 ARM 限制保持一致 - 每分钟/每个订阅/每个调用方最多 4,000 次查询。 这是一个软限额，可以根据需要提高。 |
| 一致性级别 | 非常一致 - 这是真相的根源。 | 遵循最终一致性模型。 数据在ARG后端被索引，延迟为几分钟，通常不到1分钟。 | 遵循最终一致性模型。 数据在ARG后端被索引，延迟为几分钟，通常不到1分钟。 |
| Availability | 控制平面 API 本身不提供 SLA，但通过它们管理的资源则提供 SLA——例如，Azure 虚拟机的 SLA 为 99.9% 或更高，具体取决于冗余选项。 | 没有公开的SLA。 | 没有公开的SLA。 |
| 产品生命周期阶段 | 正式发布 (GA) | 正式发布 (GA) | 正式发布 (GA) |
| 定价 | 可免费拨打。 通过这些API创建或管理的资源（虚拟机、存储等）会产生标准的Azure费用。 | 免费 | 免费 |
注释
限速限制因资源类型和操作而异。 上述数值仅为示例（其中资源提供程序列以 VMSS 为例）——请根据你的具体资源类型和区域查看当前限制，而不要将这些数值视为固定不变的常量。
混合回退模式和 Get/List API 都有助于确保你获取到当前最准确的资源状态，而不会因数据新鲜度的短暂空档而受阻。