深入 Logic Apps Standard：了解用于存储扩展的 Compute Units (CU)

抱歉，我需要您提供要翻译的正文内容（即文章的文本）。目前只看到源链接，若您把文章的文字粘贴在这里，我就可以按照要求把它翻译成简体中文并保留原有的格式、代码块和链接。谢谢！

介绍

当您的 Logic App Standard 工作流在数量和复杂性上增长时，Azure 通过 计算单元 (CU) 提供强大的水平扩展机制。本文解释了 CU 架构如何使 Logic Apps 在多个存储帐户之间分配存储负载，同时保持数据一致性和路由完整性。

为什么存储扩展很重要

单个 Azure 存储帐户有固有的限制：

注意： 超过这些阈值会触发请求限流。

当 Logic App 处理成千上万的运行，每次运行包含数十个操作时，单个存储帐户很快就会成为瓶颈。

来自 Microsoft 的指导

• ≈ 100 K 每分钟每个存储帐户的操作执行 是评估是否需要额外存储的推荐阈值。
• 计算密集型工作流操作 可能会显著降低此阈值，因此请密切监控使用情况。

什么是计算单元？

计算单元（也称为 Scale Units）是 Azure Logic Apps 用于水平存储扩展的机制。与其将所有工作流执行数据都压在单个存储帐户上，Logic Apps 可以将负载分散到最多 32 个存储帐户（CU00 至 CU31）。

如何配置

在 host.json 文件中添加 Runtime.ScaleUnitsCount 设置：

{
  "runtime": {
    "scaleUnitsCount": 4   // Number of compute units (1‑32)
  }
}

• 将 4 替换为所需的计算单元数量（最小 1，最大 32）。
• 该值决定运行时将配置并使用多少个存储帐户。

Source: …

单存储架构

在最简化的部署中，所有工作流使用同一个存储账户：

Logic App → CU00 (Master) → Single Storage Account

使用单一存储账户时：

• 所有工作流定义、运行记录和操作都位于同一个存储账户中。
• 该存储账户使用 CU00 后缀。
• 该配置适用于低至中等工作负载。

可扩展存储架构

当 Logic App 必须处理高容量工作流时，它可以通过使用多个存储帐户——每个计算单元对应一个——来横向扩展。这使得能够在多个存储端点之间并行读取和写入。

Logic App → CU00 (Master) → Storage Account 1
         → CU01           → Storage Account 2
         → CU02           → Storage Account 3
         → …              → …
         → CU31           → Storage Account 32

每个计算单元 (CU) 对应一个专用的存储帐户，使 Logic App 能够将负载分配到最多 32 个存储端点。

CU 路由工作原理

关键在于 Run ID。每次工作流运行都会带有一个 CU 后缀，用于标识其操作数据所在的存储账户：

08584345852018133305811297792-CU00
08584345852018133305811297793-CU01
08584345852018133305711297794-CU02

路由步骤

1. 从 Run ID 中提取 CU 后缀（例如 -CU01）。
2. 查找 Logic App + CU 组合对应的存储账户映射。
3. 查询相应的存储账户以获取操作数据。

这样，当您请求运行详情时，系统就能准确知道要查询哪个存储账户。

表在 CU 之间的分布

并非所有表的分布方式相同。区别如下所示：

两种不同的分配机制

1. 工作流表（ScaleUnit 字段）

• 当您部署新工作流时，Logic Apps 会将其分配到 计算单元 (CU)。
• 从开发者的角度看是非确定性的——您无法指定“将此工作流放在 CU02”。
• 在部署时决定——工作流一添加，Logic Apps 就会挑选一个 CU。
• 该分配信息存储在工作流的元数据中（flows 表的 ScaleUnit 列）。

工作流的 flows、runs 和 histories 表均位于分配的 CU 所对应的存储账户中。

2. 操作表（RunId‑CUXX 后缀）

操作表是 按运行 分布的，而不是按工作流分布。每一次运行执行都会获得自己的 CU，这在 RunId 后缀中有所体现：

08584345852018133305811297792-CU01
08584345852115148130432249577-CU00

后果

• 单个工作流的操作可能分布在 多个 CU 存储账户 中。
• 在任意日期，您可能会看到同一工作流的操作表出现在 CU00、CU01、CU02 等不同的 CU 中。

每个存储账户会创建自己的带日期戳的操作表，例如：

{WFIdentifier}20250114T000000Zactions

示例：分布式操作

对于 ScaleUnit = CU00 的工作流，运行可能跨不同的计算单元 (CUs) 执行：

Workflow: MyWorkflow (ScaleUnit = CU00)

Run 1 → RunId‑CU00 → actions stored in Storage Account CU00
Run 2 → RunId‑CU01 → actions stored in Storage Account CU01
Run 3 → RunId‑CU02 → actions stored in Storage Account CU02

因此，虽然工作流定义位于 CU00，但其 操作数据 可以分散在任何已配置的计算单元中，从而实现存储 I/O 的真正水平扩展。

Source: …

元数据（flows、runs、histories） → CU00 存储

运行

示例（2025年1月14日）

在此日期，工作流可能在三个不同的存储账户中拥有操作表：

• CU00: flow{LAIdentifier}{WFIdentifier}20250114T000000Zactions
• CU01: flow{LAIdentifier}{WFIdentifier}20250114T000000Zactions
• CU02: flow{LAIdentifier}{WFIdentifier}20250114T000000Zactions

这意味着

• 应用级元数据保持集中 – 基础表仍然位于 CU00（主库）。
• 工作流元数据有归属 – flows、runs 和 histories 存在于工作流分配的 CU 中。
• 操作真正分布式 – 操作数据根据运行执行情况分布在多个 CU 中。
• 查询复杂度提升 – 为检索某日期范围内的所有操作，可能需要查询多个存储账户。

为什么这很重要

对于高吞吐量工作流

如果一个 Logic App 每天处理数千次运行，每次运行可能会执行数十个操作。若不进行 CU 分配：

• 单个存储账户会成为瓶颈。
• 表分区限制会限制性能。
• 随着表变大，查询延迟会增加。

进行 CU 分配后：

• 写入操作会分散到多个端点。
• 每个存储账户只承担一小部分负载。
• 查询可以直接指向相应的存储账户。

对于运行历史查询

在构建查询运行历史的工具（例如导出实用程序或监控仪表板）时，必须考虑 CU 路由：

1. 解析 Run ID 以提取 CU 后缀。
2. 解析该 CU 对应的正确存储账户。
3. 对 CU 特定的存储进行操作数据查询。

忽略 CU 路由将导致操作数据缺失。

配置规模单元

要启用多个存储帐户，请在 host.json 中添加以下内容：

{
  "extensions": {
    "workflow": {
      "settings": {
        "Runtime.ScaleUnitsCount": 4
      }
    }
  }
}

这告诉 Logic Apps 使用四个存储帐户（CU00‑CU03）。您必须预配额外的存储帐户并配置它们的连接字符串或托管身份访问。

身份验证选项

• 在应用设置中的连接字符串。
• 托管身份 (推荐用于生产环境)。

摘要

• Compute Units (CUs) 使 Logic Apps Standard 能够水平扩展存储。
• CU00 是保存应用级基础表的主单元。
• Workflow tables（flows、runs、histories）位于 ScaleUnit 字段指示的 CU 中。
• Action tables 按运行使用 RunId‑CUXX 后缀进行分片。
• 单个工作流的操作可以跨多个存储帐户。
• 在 host.json 中通过 Runtime.ScaleUnitsCount 配置 CU 的数量（最大 32）。
• 阈值指导： 每个存储帐户约 100 K 次操作执行/分钟。

了解此架构在以下情境中至关重要：

• 为 Logic Apps 构建工具。
• 编程方式查询运行历史。
• 排查高并发工作流的性能问题。

References

• Scaling Logic App Standard for high‑throughput scenarios – Microsoft Tech Community

本文是 “Inside Logic Apps Standard” 系列的一部分，探讨 Azure Logic Apps Standard 架构的内部工作原理。