.net - Azure WebJobs 有很多 QueueTrigger 不好的做法吗？

Question

目前我正在使用 asp.net 开发一个 WebApi 项目。我想将所有非时间关键且长时间运行的操作转移到 webjobs 中，以保持我的 API 快速而简单。

例如，当创建特定资源时，它会立即创建(实体状态:已创建/配置)，并且新的队列消息将入队。现在，Web 作业接收队列上的消息并开始配置任务。作业成功/失败后，资源/实体将被更新(状态:已完成/失败)。

没什么特别的。但现在我还想将具体化统计数据、报告等部分转移到目前即时计算的作业中。

当我将所有这些时间不重要的任务移动到单独队列中的网络作业中时，例如:

配置队列更新统计A创建报表B...

同时拥有这么多队列(20-50)是一种不好的做法吗(它们都会一直被轮询/检查)。为了清楚起见:每条消息一个队列。遗憾的是，我没有找到任何方法/示例如何创建多个作业函数来监听同一队列但具有不同的消息。另外，我没有发现使用多个队列有什么好处/坏处。仅具有 1-3 个工作功能的示例(图像转换、调整大小......)。

Azure 服务总线听起来也不错(因为有主题)。我不确定我使用网络作业和存储队列的方式是否正确或好。我想要的只是将许多非时间关键且长时间运行的任务与 webapi 解耦。

谢谢大家!

Answer 1

使用多个队列完全没有问题，每个队列都有一个需要处理的单独消息类型。

有两种方法可以处理来自这些队列的消息:将所有队列监控方法放入单个 Web 作业中，或者将每个队列的监控器拆分到其自己的单独 Web 作业中。我个人喜欢将队列监视器拆分为单独的 Web 作业，因为它使您能够根据需要将 Web 作业移动到单独的 Web 应用程序。例如，假设您有 WebJobs A、B 和 C 正在监视队列 A、B 和 C。如果 A 的工作负载始终很重，而 B 和 C 的负载始终很轻，您可以将 A 移动到单独的 Web应用程序位于不同的应用程序服务计划上，B 和 C 可以共享一个 Web 应用程序。这是一种微服务方法。

主题在这种情况下没有用处。

服务总线是一个好方法，您需要保证至少一次和最多一次交付。此外，您还可以轻松拥有一个保存不同消息类型的服务总线队列(如果您想采用这种方式)。您可以通过 BrokeredMessage 类实例在服务总线中发送消息。您可以为每种消息类型创建一个 BaseMessage 类、BaseMessage 子类，通过序列化为 JSON(或您想要使用的任何格式)通过 BrokeredMessage 打包消息，然后测试以查看出队操作期间您拥有的子类。