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

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

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

• 在 ISE 中，可调高或调低 90 天的默认限制。

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

门户

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

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

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

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

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

ARM 模板

如果使用 Azure 资源管理器模板，则此设置将显示为工作流资源定义中的属性。

{
   "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 Blob 存储在运行时持久保存数据存储，以及维护运行历史记录。 这些工作流还使用 Azure 队列进行计划。 单个存储帐户可实现大量请求，每个分区的速率高达 2K，帐户级别每秒请求数为 20K。 超出这些阈值后，请求速率会受到限制。 有关存储可伸缩性限制，请参阅数据操作的目标。

虽然单个存储帐户可以处理相当高的吞吐量，但因为工作流执行速率增加，可能会遇到分区级别限制或帐户级别限制。 要确保操作顺畅，请确保了解可能的限制和解决这些限制的方法。

跨多个工作流共享工作负荷

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

跨多个存储帐户共享工作负荷

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

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

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

2. 查找并打开标准逻辑应用，然后编辑逻辑应用的主机设置（host.json文件）以包含以下extensions对象，其中包含具有 Runtime.ScaleUnitsCount设置的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. 使用以下语法（其中第一个存储帐户数为00，最大为减 1 的存储帐户数，例如：）编辑逻辑应用的应用程序配置设置 (local.settings.json)，以添加名为 cloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU0<storage-account-number>ConnectionString的应用设置和相应的存储帐户连接字符串

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

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

计算

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

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

• 触发器

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

• 工作流作业执行延迟

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

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

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

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

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

• 使用预热实例。

  如果场景需要更短的上升时间，请考虑使用预热实例。 如果峰值负载时间是确定性的，可以使用自动化任务按计划调整这些预热实例。

多租户 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 逻辑应用的部署。