如何使用标准 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