具有许多 QueueTrigger 不良做法的 Azure WebJobs？

Question

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

例如在创建特定资源时，会立即创建（实体状态：created/provisioning），并将新的队列消息入队。现在 webjob 接收到队列上的消息并开始配置任务。作业成功/失败后，资源/实体将被更新（状态：完成/失败）。

没什么特别的。但现在我也想将诸如物化统计、报告等部分移动到现在动态计算和计算的作业中。

当我将所有这些时间不重要的任务移动到单独队列中的 webjobs 中时，例如：

供应队列 更新统计A 创建报告B ...

一次有这么多队列 (20-50) 是一种不好的做法吗（它们都将一直被轮询/检查）。为清楚起见：每条消息一个队列。可悲的是，我没有找到任何方法/示例如何创建多个作业功能，这些作业功能侦听同一队列但具有不同的消息。此外，我没有发现使用许多队列有什么好处/坏处。仅具有 1-3 个作业功能的示例（图像转换、调整大小......）。

天蓝色的服务总线听起来也不错（因为主题）。我不确定我在使用 webjobs 和存储队列时是正确的还是好的方法。我想要的只是将许多非时间关键且长时间运行的任务与 webapi 分离。

谢谢大家！

Answer 1

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

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

主题在这种情况下将无用。

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