Azure 逻辑应用的限制和配置参考

对于消耗型逻辑应用工作流，同一设置控制工作流可以运行的最大天数，并控制在存储中保留运行历史记录的最大天数。

• 对于多租户 Azure 逻辑应用，90 天默认限制与最大限制相同。 只能减小此值。

例如，假设你将保留期限制从 90 天减少到 30 天。 将从运行历史记录中移除 60 天的运行。 如果将保持期从 30 天增至 60 天，则已经保留了 20 天的运行将在运行历史记录中继续保留 40 天。

门户

1. 在 Azure 门户搜索框中，在设计器中打开逻辑应用工作流。

2. 在逻辑应用菜单中，选择“工作流设置”。

3. 在“运行时选项”下，从“运行历史记录保留天数”列表中选择“自定义”。

4. 拖动滑块更改所需的天数。

5. 完成后，在“工作流设置”工具栏上选择“保存”。

ARM 模板

如果使用 Azure 资源管理器模板，此设置将显示为工作流资源定义中的属性，如 Microsoft.Logic 工作流模板参考中所述：

{
   "name": "{logic-app-name}",
   "type": "Microsoft.Logic/workflows",
   "___location": "{Azure-region}",
   "apiVersion": "2019-05-01",
   "properties": {
      "definition": {},
      "parameters": {},
      "runtimeConfiguration": {
         "lifetime": {
            "unit": "day",
            "count": {number-of-days}
         }
      }
   }
}

对于标准型逻辑应用工作流，可以降低或增加 90 天的默认限制，但需要将以下设置及其值添加到逻辑应用资源或项目：

• 名为 Workflows.RuntimeConfiguration.RetentionInDays 的应用设置

• 名为 Runtime.FlowMaintenanceJob.RetentionCooldownInterval 的主机设置

默认情况下，名为 Workflows.RuntimeConfiguration.RetentionInDays 的应用设置设置为保留 90 天的数据。 名为 Runtime.FlowMaintenanceJob.RetentionCooldownInterval 的主机设置设置为每 7 天检查一次要删除的旧数据。 如果保留这些默认值，可能会看到 长达 97 天的数据。 例如，假设 Azure 逻辑应用在第 X 天检查并删除早于 X 天 - 90 天的数据，则等待 7 天，然后再次运行。 此行为会导致数据在作业再次运行之前保留 97 天。 但是，如果将间隔设置为 1 天，但将保留天数保留为默认值，则删除旧数据的最大延迟为 90+1 天。

门户

1. 按照以下步骤添加名为 Workflows.RuntimeConfiguration.RetentionInDays 的应用设置，并将该值设置为要保留工作流运行历史记录的天数。

2. 按照以下步骤添加名为 Runtime.FlowMaintenanceJob.RetentionCooldownInterval 的主机设置，并将值设置为天数，作为检查和删除不想保留的运行历史记录之间的间隔。

Visual Studio Code

1. 按照以下步骤添加名为 Workflows.RuntimeConfiguration.RetentionInDays 的应用设置，并将该值设置为要保留工作流运行历史记录的天数。

2. 按照以下步骤添加名为 Runtime.FlowMaintenanceJob.RetentionCooldownInterval 的主机设置，并将值设置为天数，作为检查和删除不想保留的运行历史记录之间的间隔。

在单租户 Azure 逻辑应用中，标准逻辑应用资源使用存储和计算作为主要资源来运行工作流。

存储

单租户 Azure 逻辑应用中的有状态工作流在运行时使用 Azure 表存储进行持久性数据存储、使用 Azure Blob 存储维护工作流运行历史记录，并使用 Azure 队列存储进行计划。 例如，单个存储帐户可处理大量请求，速率高达每分区 2,000 个请求，存储帐户级别的每秒请求数为 20,000。 虽然单个存储帐户可以处理相当高的吞吐量，但如果超出这些阈值，请求速率可能会受到限制，并且工作流在工作流执行速率增加时可能会遇到分区级别限制或帐户级别限制。 若要确保工作流操作顺畅，请务必了解可能的限制和解决这些限制的方法。

有关各种 Azure 存储服务的缩放目标和限制的详细信息，请查看以下文档：

• 表存储的缩放目标
• 表存储的数据操作目标
• Blob 存储的缩放目标
• 队列存储的缩放目标

根据存储限制缩放逻辑应用

以下建议适用于缩放标准逻辑应用工作流：

• 跨多个工作流共享工作负载。

  单租户 Azure 逻辑应用跨多个分区分配存储事务，从而最大程度地减少分区级别限制。 但是，为了改进分配和缓解分区级别限制，请跨多个工作流分配工作负载，而不是依赖单个工作流。

• 跨多个存储帐户共享工作负载。

  如果工作流需要高吞吐量，可通过跨多个存储帐户分配工作负载来显著增加吞吐量，而不是依赖单个存储帐户。 可设置标准逻辑应用资源，使其最多使用 32 个存储帐户（这是限制）。 要确定所需的存储帐户数，请遵循一般准则，即每个存储帐户每分钟约 100,000 次操作。 虽然此估计值适用于大多数场景，但如果工作流操作计算量很大，则使用的操作执行数可能会较低，例如处理大型数据数组的查询操作。 在生产中使用之前，请确保先执行负载测试和优化解决方案。

  要启用多个存储帐户，请在创建标准逻辑应用之前执行以下步骤。 否则，如果在创建后更改设置，可能会遇到数据丢失或未实现必要的可伸缩性。

  1. 创建要使用的存储帐户。 保存每个存储帐户的连接字符串。

  2. 查找并打开标准逻辑应用，然后编辑逻辑应用的主机设置（host.json文件）以包含以下extensions对象，其中包含具有 workflow 设置的 settings 和 对象：

     "extensions": {
         "workflow": {
             "settings": {
                 "Runtime.ScaleUnitsCount": "<storage-accounts-number>"
             }
         }
     }
     

     以下示例将3指定为存储帐户数：

     {
         "version": "2.0",
         "extensionBundle": {
             "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
             "version": "[1.*, 2.0.0)"
         },
         "extensions": {
             "workflow": {
                 "settings": {
                     "Runtime.ScaleUnitsCount": "3"
                 }
             }
         }
     }
     

  3. 使用以下语法（其中第一个存储帐户数为 ，最大为减 1 的存储帐户数），以添加名为 < 的应用设置和相应的存储帐户连接字符串，例如：

     应用设置名称	值
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.ConnectionString	<connection-string-1>
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU01.ConnectionString	<connection-string-2>
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU02.ConnectionString	<connection-string-3>

     重要

     当你有敏感信息（例如包含用户名和密码的连接字符串）时，请确保使用可用的最安全身份验证流。 例如，在标准逻辑应用工作流中，不支持 securestring 和 secureobject 等安全数据类型。 Microsoft 建议尽量使用托管标识对 Azure 资源访问进行身份验证，并分配具有最低所需特权的角色。

     如果此功能不可用，请务必通过其他措施（例如可与应用设置一起使用的 Azure 密钥保管库）保护连接字符串。 然后，可以直接引用安全字符串，例如连接字符串和密钥。 与 ARM 模板类似，在部署时可以定义环境变量，可以在逻辑应用工作流定义中定义应用设置。 然后，可以捕获动态生成的基础结构值，例如连接终结点、存储字符串等。 有关详细信息，请参阅Microsoft 标识平台的应用程序类型。

  4. 在逻辑应用的应用程序配置设置中，使用 CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.ConnectionString 设置中的相同连接字符串更新 AzureWebJobsStorage 设置值。

计算

标准逻辑应用使用可用的计算计划之一运行（这些计划提供不同级别的虚拟 CPU 和内存），或者使用提供更多计算选项的应用服务环境 v3 运行。

单租户 Azure 逻辑应用动态缩放，以有效处理增加的负载。 逻辑应用使用以下主要因素确定是否缩放。

• 触发器

  为了确定缩放要求，缩放程序会分析在逻辑应用中启动每个工作流的触发器。 例如，对于具有服务总线触发器的工作流，如果队列长度持续增长，缩放程序会采取措施添加辅助角色实例，从而可以处理更多消息。 同样，对于具有请求触发器的工作流，如果请求延迟出现上升趋势，缩放器会增加辅助角色实例数，以更有效地分配请求负载。 有关辅助角色实例的详细信息，请参阅Azure 逻辑应用（标准） - 运行时深入探讨。

• 工作流作业执行延迟

  在运行时，工作流操作分为排队执行的各个作业。 作业调度程序定期轮询作业队列以检索和执行这些作业。 但是，如果计算容量不足以拾取这些作业，它们会长时间留在队列中，从而导致执行延迟增加。 缩放程序会监视这种情况，并做出缩放决策，以控制执行延迟。 有关运行时如何计划和运行作业的详细信息，请参阅Azure 逻辑应用（标准）- 运行时深入探讨。

  缩放程序还考虑最小和最大辅助角色实例计数器配置，以确定是做出缩放决策（例如添加、删除）还是维护当前辅助角色实例数。 通常，缩放程序按大约 15-30 秒的间隔做出这些决策。 因此，请考虑此上升时间及其对逻辑应用缩放速度的影响，以有效处理峰值负载。 例如，如果工作负荷需要将逻辑应用从 1 个辅助角色实例缩放到 100 个辅助角色实例，则仅上升可能需要 25-50 分钟。 单租户 Azure 逻辑应用缩放共享相同的Azure Functions 缩放基础结构。

配置逻辑应用计算以加快缩放速度

• 跨多个逻辑应用共享工作负荷。

  每个逻辑应用可以独立缩放，因此跨多个逻辑应用分配工作负荷可以显著加快缩放速度。 例如，两个逻辑应用可以扩展到与单个逻辑应用相同的时间范围内工作器实例数的两倍。 通过跨多个应用拆分工作负荷，可以有效地将可伸缩性相乘，并实现更快的缩放结果。

• 使用预热实例。

  如果场景需要更短的上升时间，请考虑使用预热实例。 如果峰值负载时间是确定性的，可以使用自动化任务按计划调整这些预热实例。 有关详细信息，请参阅通过创建自动化任务来管理 Azure 资源和监视成本（预览版）。

多租户 Azure 逻辑应用对每 5 分钟运行的操作数具有默认限制。 要将此默认值提高到最大值，可以启用处于预览阶段的高吞吐量模式。 或者，跨多个逻辑应用和工作流分配工作负荷，而不是依赖于单个逻辑应用和工作流。

在门户中启用高吞吐量

1. 在 Azure 门户的逻辑应用菜单中，选择“设置”下的“工作流设置”。

2. 在“运行时选项”>“高吞吐量”下，将设置更改为“启用”。

   

在资源管理器模板中启用高吞吐量

若要在用于部署逻辑应用的 ARM 模板中启用此设置，请在逻辑应用的资源定义的 properties 对象中，添加 runtimeConfiguration 对象，并将 operationOptions 属性设置为 OptimizedForHighThroughput：

{
   <template-properties>
   "resources": [
      // Start logic app resource definition
      {
         "properties": {
            <logic-app-resource-definition-properties>,
            <logic-app-workflow-definition>,
            <more-logic-app-resource-definition-properties>,
            "runtimeConfiguration": {
               "operationOptions": "OptimizedForHighThroughput"
            }
         },
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "___location": "[parameters('LogicAppLocation')]",
         "tags": {},
         "apiVersion": "2016-06-01",
         "dependsOn": [
         ]
      }
      // End logic app resource definition
   ],
   "outputs": {}
}

有关逻辑应用资源定义的详细信息，请查看概述：使用 Azure 资源管理器模板自动完成 Azure 逻辑应用的部署。