如何使用标准 Azure 逻辑应用的无状态工作流可靠地处理 Azure 服务总线消息

Posted

技术标签:

【中文标题】如何使用标准 Azure 逻辑应用的无状态工作流可靠地处理 Azure 服务总线消息【英文标题】:How do you reliably process Azure Service Bus messages using a stateless workflow with Standard Azure Logic Apps 【发布时间】:2021-12-01 03:32:21 【问题描述】:

我们有一个具有无状态工作流的标准逻辑应用。对于 Azure 服务总线,触发器是“当消息在队列中可用时”,下一步是 For each 循环。由于限制,这种组合似乎存在缺陷,并导致两个问题。

    无状态触发器似乎只允许自动完成,因此出现错误时所有消息都会丢失。 无状态触发器似乎不允许配置批处理,因此任何大于 100 的批处理都会导致以下错误。

无效的模板。无法处理“line”行和“column”列的操作“For_each”的模板语言表达式:“操作“For_each”的 foreach 项目数超出限制:最大“100”和实际“messageCount” '.'。

我在这里遗漏了什么,还是有状态工作流是处理 Azure 服务总线消息的唯一可靠方法?

[编辑] - 使用 host.json 文件中的extensions.serviceBus.prefetchCount 配置可以limit the number of messages that are read from the queue in a batch,但由于“for each”控制操作的限制,最大数量将是 100。在使用 I1V2 ASP 的 ASE 负载下,我们观察到每个工作流执行抓取 66 条消息并花费约 4 秒(工作流进行一些转换并进行 HTTP POST)。

[编辑] - 2021 年 10 月,Microsoft 发布了 peek lock 触发器和使用内置连接器完成消息的功能。这个问题不再相关。

【问题讨论】:

【参考方案1】:

我们在本地环境中进行了测试,以下陈述基于我们的分析。

    无状态触发器似乎只允许自动完成,因此出现错误时所有消息都会丢失。

根据Azure documentation,服务总线队列支持2个触发器

    在队列中收到消息时(自动完成) 在队列中收到消息时(窥视锁定)

在基于消费的逻辑应用中,您可以在逻辑设计器中选择上述任一触发器

这里是截图供参考:

如果您使用标准计划逻辑应用程序,而不管有状态或无状态工作流程,您将拥有以下服务总线队列触发器When a message is received in a queue 并且它没有任何选项来确认它是自动完成还是偷看-锁。

这是供参考的屏幕截图:

    无状态触发器似乎不允许配置批处理,因此任何大于 100 的批处理都会导致以下结果 错误。

无效的模板。无法处理“line”行和“column”列的操作“For_each”的模板语言表达式:“数字 超出操作“For_each”的 foreach 项目限制:最大“100” 和实际的“messageCount”。

根据 Azure documentation , For_each loop 在逻辑应用程序中默认仅支持 100 个项目,如果您使用的是无状态工作流。如果您使用有状态的工作流程,它支持 1,00,000 个项目。

【讨论】:

您大部分都重复了这个问题,但没有提供任何解决方案。

以上是关于如何使用标准 Azure 逻辑应用的无状态工作流可靠地处理 Azure 服务总线消息的主要内容,如果未能解决你的问题,请参考以下文章

Azure 为连接到 CosmosDB 的标准逻辑应用生成 URL

Azure 逻辑应用返回多个响应

从 Azure 函数获取 401 时,Azure 逻辑应用停止执行

是否可以通过门户为 Logic App(标准)定义参数?

如何使用逻辑应用修改 Azure 分析服务角色?

Azure Logic App Standard - 从未触发服务总线触发器