在单租户 Azure 逻辑应用中对标准工作流进行基于目标的缩放

适用于:Azure 逻辑应用(标准)

使用单租户 Azure 逻辑应用,可以选择首选的计算资源,并设置标准逻辑应用资源和工作流,以便根据不同的工作负载需求进行动态缩放。 在云计算中,可伸缩性是指如何快速、轻松地增加或减少 IT 解决方案或资源的大小或功能。 虽然可伸缩性是指任何系统处理不断增加的工作量的能力,但术语横向扩展和纵向扩展通常是指数据库和数据

例如,假设你有一个新的应用取得成功,因此需求从一小群客户增长到全球数百万客户。 高效缩放功能是帮助你跟上需求并最大程度地减少故障时间的最重要功能之一。

横向扩展与纵向扩展有何不同?

相对于纵向扩展,横向扩展侧重于可伸缩性帮助你调整和处理数据卷和数组、更改数据卷和转移工作负载模式的方式。 横向缩放(即横向扩展或横向缩减)是指通过使用称为分片的数据分区方法添加更多的数据库,或将大型数据库划分为较小的节点,这种方法可以支持你跨服务器更快、更轻松地进行管理。 纵向缩放(纵向扩展或纵向缩减)是指根据需要增加或减少计算能力或数据库,其方法是更改性能级别或使用弹性数据库池自动调整以适应工作负载需求。 有关可伸缩性的更多概述信息,请参阅纵向扩展与横向扩展

在运行时横向扩展和缩减

单租户 Azure 逻辑应用当前使用基于目标的缩放模型进行横向扩展或缩减,这类似于 Azure Functions。 此模型基于要指定的辅助角色实例的目标数量,并提供更快、更简单、更直观的缩放机制。

下图显示了单租户 Azure 逻辑应用的运行时缩放体系结构中的组件:

Architecture diagram shows runtime scaling components in Standard logic apps.

以前,Azure 逻辑应用使用增量缩放模型,该模型可为每个新实例速率添加或移除最多一个辅助角色实例,并且涉及确定何时进行缩放的复杂决策。 Azure 逻辑应用缩放监视器会根据工作流作业执行延迟投票决定是纵向扩展,还是纵向缩减或保留逻辑应用的当前辅助角色实例数

注意

在运行时,Azure 逻辑应用会将工作流操作划分为单个作业,将这些作业放入队列中,并计划它们以供执行。 Dispacther 会定期轮询作业队列以检索和执行这些作业。 但是,如果计算容量不足以拾取这些作业,它们会长时间留在队列中,从而导致执行延迟增加。 缩放监视器将做出缩放决策,以控制执行延迟。 有关运行时计划和运行作业的详细信息,请参阅在任意位置运行的 Azure 逻辑应用

相比之下,使用基于目标的缩放可以一次纵向扩展到四个辅助角色实例。 缩放监视器会计算跨作业队列处理作业所需的辅助角色实例数,并将此数字返回到缩放控制器,这有助于做出有关缩放的决策。 此外,基于目标的缩放模型还包括可用于微调模型基础动态缩放机制的主机设置,这可能导致更短的横向扩展和横向缩减时间。 借助此功能,可以实现更高的吞吐量,并降低波动的标准逻辑应用工作负载的延迟。

下图显示了缩放组件在基于目标的缩放中如何交互的序列:

Sequence diagram shows scaling process for Standard logic apps.

Azure Functions 主机控制器从 Azure 逻辑应用缩放监视器获取所需的实例数,并使用此数字确定对计算资源的需求。 然后,该过程会将结果传递给缩放控制器,并由缩放控制器随后决定是横向扩展还是横向缩减,以及要添加或移除的实例数。 辅助角色实例分配器会分配或解除分配逻辑应用所需的辅助角色实例数。

缩放计算将使用以下基于目标的公式:

目标实例数 = 目标缩放因子 x(作业队列长度 / 每个实例的目标执行数)

术语 定义
目标缩放因子 一个介于 0.05 到 1.0 之间的数值,用于确定缩放强度。 较高的值会导致更激进的缩放,而较低的数字会导致更保守的缩放。 可以通过使用 Runtime.TargetScaler.TargetScalingFactor 主机设置来更改默认值,如基于目标的缩放中所述
作业队列长度 由 Azure 逻辑应用运行时扩展计算的数值。 如有多个存储帐户,则公式会跨作业队列使用总和。
每个实例的目标执行数 预期计算实例在任何给定时间要处理的最大作业数的数值。 此值的计算方式不同,具体取决于标准逻辑应用使用的是动态并发还是静态并发执行模式:

- 动态并发:Azure 逻辑应用会在运行时确定值,并根据工作流的行为及其当前作业处理状态调整调度程序辅助角色实例的数量

-静态并发:该值是使用逻辑应用资源的 Runtime.TargetScaler.TargetConcurrency 主机设置来设置的固定数字,如基于目标的缩放中所述

动态并发执行模式

在单租户 Azure 逻辑应用中,动态缩放功能可智能地适应手头任务的性质。 例如,在计算密集型工作负载期间,每个实例的并发作业数可能存在限制,这与非计算密集型任务允许更多并发作业的情况相反。 在同时处理这两种类型任务的情况下,为了确保实现最佳缩放性能,动态缩放功能可以无缝调整并自动调整,以根据当前处理的作业类型确定适当的并发级别。

在动态并发执行模式下,Azure 逻辑应用运行时扩展将使用以下公式自动计算每个实例目标执行数的值

每个实例目标执行数 = 作业并发 x(目标 CPU 利用率/实际 CPU 利用率)

术语 定义
作业并发 采样时由单个辅助角色实例处理的作业数。
实际 CPU 使用率 采样时辅助角色实例的处理器使用率百分比。
目标 CPU 利用率 目标并发预期的最大处理器使用率百分比。 可以使用 Runtime.TargetScaler.TargetScalingCPU 主机设置来更改默认值,如基于目标的缩放中所述

静态并发执行模式

虽然动态并发旨在允许辅助角色实例尽可能多地处理工作,同时保持每个辅助角色实例运行正常且延迟较低,但在某些情况下,动态并发执行不适合特定的工作负载需求。 对于这些方案,单租户 Azure 逻辑应用还支持主机级别的静态并发执行,可以将其设置为替代动态并发。

对于这些方案,Runtime.TargetScaler.TargetConcurrency 主机设置可控制每个实例目标执行数的值。 可以使用 Runtime.TargetScaler.TargetConcurrency 主机设置来设置目标最大并发作业轮询的值,如基于目标的缩放中所述

虽然使用静态并发可以控制逻辑应用中的缩放行为,但确定 Runtime.TargetScaler.TargetConcurrency 主机设置的最优值可能会非常困难。 通常,必须通过对逻辑应用工作流进行负载测试的试错过程来确定可接受的值。 即使确定了适用于特定负载配置文件的值,传入触发器请求的数量每天可能也会更改。 这种可变性可能会导致逻辑应用使用不理想的缩放配置运行。

另请参阅