Scaling Logic App Standard for High Throughput Scenarios
Logic Apps 提供了一个强大的平台，可以无缝集成各种服务，包括数据库、消息系统和 PaaS 和 SaaS 产品。此外，它支持各种连接协议，使您能够创建全面的集成解决方案。通过使用其直观的工作流设计器和广泛的连接器，Logic Apps 赋予开发人员高效构建复杂解决方案的能力。此外，它的用户友好的管理和监控能力确保了应用程序生命周期的顺利管理。
一个常见的问题是，Logic Apps 是否能有效地扩展以应对高吞吐量要求的苛刻场景。为了提供一些背景，这里有几个高吞吐量场景的例子：
- 每天，我们在特定时间收到惊人的 100 万张发票。我们的目标是在几个小时内处理所有这些订单。
- 是否可以利用一个 Logic App，在这段时间内动态扩展，使我们能够实现所需的高吞吐量？
- 随后，当不再需要进一步处理时，它应该缩小规模，使我们能够在保持所需吞吐量的同时优化成本。
- 我们的系统不断从事件中心接收事件流，这些事件在一天中的特定时间或随机地出现峰值负载，有时超过每分钟 10K 事件的速率。
事实上，上述问题的答案是肯定的。通过一些容量规划和对 Logic Apps 内部扩展功能的深入理解，实现更高吞吐量的场景变得像构建一个复杂的业务流程的工作流一样简单。
在这篇博客中，我们将深入探讨 Logic Apps 标准的扩展特性，并为设计可扩展的高吞吐量场景的 Logic Apps 提供宝贵的见解。
底层 Logic App 资源的可扩展性
Logic App 在运行工作流时使用两种主要资源 - 存储和计算。
存储
Logic Apps 中的有状态工作流利用存储（表和 blob）在运行时进行持久性数据存储并维护运行历史。此外，队列用于调度目的。单个存储帐户支持大量请求，每个分区最多可达 2K，帐户级别每秒可达 20K 请求（RPS）。超出这些阈值，请求速率将受到限制。有关存储可扩展性限制的更多信息，请参阅此处(https://learn.microsoft.com/en-us/azure/storage/tables/storage-performance-checklist#targets-for-data-operations)。
随着工作流执行速率的增加，需要注意的是，虽然单个存储帐户可以处理相当高的吞吐量，但有可能遇到分区级别限制或帐户级别限制。因此，理解潜在的限制和解决它们的方法变得至关重要，以确保顺畅的运营。
将您的 Logic App 扩展到存储限制
将负载分片到多个工作流
Logic Apps 引擎专门设计用于通过在多个分区之间分配存储事务来最小化分区级别的限制。但是，为了获得更好的分布并减轻分区级别的限制，建议将工作负载分布在两个或多个工作流中，而不是依赖单个工作流
将负载分片到多个存储帐户
为了显著提高吞吐量，可以设置 Logic App 以将其负载分布在多个存储帐户中，最多可达 32 个存储帐户。如果您的应用程序需要高吞吐量，建议使用多个存储帐户而不是依赖一个。一个普遍的指导方针是，每个存储帐户每分钟大约执行 100K 操作，以确定是否需要额外的存储帐户。请注意，虽然这个限制对于大多数情况来说都是一个好的数字，但如果您的工作流操作是计算密集型的（例如处理大量数据的查询操作），那么限制可能低于这个数字，因此在将您的解决方案投入生产之前，进行负载测试并调整您的解决方案总是一个好主意。
请参阅下面的附录，了解如何配置多个存储帐户的说明。
计算
在运行 Logic Apps Standard 时，有三种主要的计算选项需要考虑：WS1、WS3 和 WS3。这些选项提供不同数量的内存和核心计数。此外，如果您决定在 ASEv3（应用程序服务环境版本 3）中运行您的 Logic App，则会有更多的计算选项可供选择。
Logic Apps 的计算基础设施旨在动态扩展，以有效地处理不断增加的负载。动态扩展的决定是根据考虑两个主要因素来确定的。
Trigger 触发器
扩展器分析特定应用程序的工作流中使用的每个触发器，以确定扩展需求。例如，如果存在服务总线触发器并且队列长度持续增长，则扩展器将采取行动添加额外的实例，使其能够处理更多的消息。同样，当工作流中使用请求触发器并且请求延迟呈上升趋势时，将增加实例数量以更有效地分配请求负载。
工作流作业执行延迟
在运行时，工作流操作被分成单独的作业并排队等待执行。调度程序定期轮询作业队列以检索并执行这些作业（有关运行时如何调度和运行作业的更多详细信息，请参阅此文章）。但是，如果没有足够的计算能力来获取这些作业，它们将在队列中停留更长时间，导致执行延迟增加。扩展器将监控并做出扩展决策以控制执行延迟。
除了上述因素，扩展器还考虑最小和最大实例计数器配置以确定是否应该做出扩展决策，例如添加、删除或维持当前实例数量。通常，扩展器每隔大约 15-30 秒做出这些决定。重要的是要考虑上升时间及其对您的 Logic App 扩展速度的影响，以有效地处理峰值负载。例如，如果您的工作负载需要将您的 Logic App 从仅 1 个实例扩展到 100 个实例，仅上升就可能需要大约 25-50 分钟。Logic Apps 扩展与 Azure 函数共享相同的扩展基础设施，您可以在本文中了解更多关于 Azure 函数如何扩展的信息
为了更快地扩展，可以为每个 Logic App 单独配置计算。
每个 Logic App 都可以独立扩展，将负载分布在多个应用程序中可以显著加快扩展速度。例如，与单个应用程序相比，两个应用程序可以在相同的时间范围内扩展到两倍的实例数量。通过将负载分成多个应用程序，您可以有效地增加可扩展性并实现更快的扩展结果。 使用预热实例。如果您的场景需要更快的上升时间，您可能希望考虑使用预热实例。如果您的峰值负载时间是确定的，那么您可以使用自动化任务（详见此处）按计划调整这些预热实例。
请注意，如果您将 Logic App 放置在应用程序服务环境（ASEv3）内，则不可用动态扩展功能。您需要在关联的应用程序服务计划（ASP）上设置扩展规则。常用的扩展规则是使用 CPU 指标并扩展您的 ASP 以保持 VM CPU 在 50-70% 之间。详见此处(https://learn.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-get-started)。
附录 - 使用多个存储帐户配置您的 Logic Apps。
以下步骤可用于使用多个存储帐户配置您的 Logic Apps，以实现更高的可扩展性。
请注意，您需要在创建新的 Logic Apps 之前执行这些配置步骤，并且在创建工作流之后更改这些设置可能会导致数据丢失或无法达到所需的可扩展性水平。
步骤 1：更新 host.json 以指定要使用的存储帐户数量。下面是一个使用 3 个存储帐户的 host.json 文件的示例：
{ "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows", "version": "[1.*, 2.0.0)" }, "extensions": { "workflow": { "Settings": { "Runtime.ScaleUnitsCount": "3" } } } }
需要通过Standard Logic App的高级工具Kudu站点进行修改：
步骤 2：创建 3 个存储帐户并保存相关的连接字符串
步骤 3：使用以下模式将连接字符串添加到应用程序配置中。从 00 到 {存储帐户数量 - 1}：
- CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.ConnectionString
- CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU01.ConnectionString
- CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU02.ConnectionString
步骤 4：使用与 CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.ConnectionString 键相同的连接字符串值更新 AzureWebJobsStorage 配置键
[End]
