Azure WebJobs 有很多 QueueTrigger 不好的做法？
Azure WebJobs with many QueueTrigger bad practice?
目前我正在使用 asp.net 开发 WebApi 项目。我想将所有非时间关键和长时间的 运行 操作移动到 webjobs 中以保持我的 API 快速和简单。
例如创建特定资源时，立即创建（实体状态：created/provisioning）并入队一个新的队列消息。现在 webjob 收到队列中的消息并开始执行配置任务。作业 successfull/failed 后 resource/entity 将更新（状态：completed/failed）。
没什么特别的。但现在我也想将具体化统计数据、报告等部分移动到现在正在计算和计算的作业中。
当我将所有这些时间不重要的任务移动到单独队列中的 Web 作业时，例如：
配置队列
更新统计A
创建报表B
...
一次有那么多队列 (20-50) 是一种不好的做法吗（它们一直都是 polled/checked）。为清楚起见：每条消息一个队列。可悲的是，我没有找到任何 way/example 如何创建多个工作函数来监听同一个队列但使用不同的消息。此外，我没有发现任何关于使用多个队列的信息 good/bad。只有 1-3 个工作功能的示例（图像转换、调整大小...）。
azure服务总线听起来也不错（因为有话题）。我不确定我是否正在使用 webjobs 和存储队列进行正确或良好的处理。我想要的只是从 webapi 中解耦许多非时间关键和长 运行 任务。
谢谢大家！
使用多个队列完全没有问题，每个队列都有一个需要处理的单独消息类型。
有两种方法可以处理来自这些队列的消息：将所有队列监视方法放入一个 web 作业中，或者将每个队列的监视器拆分到它自己单独的 web 作业中。我个人喜欢将您的队列监视器拆分为单独的 Web 作业，因为它使您能够在需要时将 Web 作业移动到单独的 Web 应用程序。例如，假设您有正在监视队列 A、B 和 C 的 Web 作业 A、B 和 C。如果 A 的工作负载一直很重，而 B 和 C 的负载总是很轻，您可以将 A 移动到单独的 Web应用程序在不同的应用程序服务计划上，B 和 C 可以共享一个 Web 应用程序。这是一种微服务方法。
主题在这种情况下没有用。
服务总线是一个很好的方式，你需要保证至少一次和最多一次交付。此外，您可以轻松地拥有一个包含不同消息类型的服务总线队列（如果您想这样做的话）。您通过 BrokeredMessage class 实例在服务总线中发送消息。您可以为每种消息类型创建一个 BaseMessage class、subclass BaseMessage，通过序列化为 JSON（或您想要使用的任何格式）通过 BrokeredMessage 打包消息，然后测试以查看在出列操作期间有什么 subclass 。
目前我正在使用 asp.net 开发 WebApi 项目。我想将所有非时间关键和长时间的 运行 操作移动到 webjobs 中以保持我的 API 快速和简单。
例如创建特定资源时，立即创建（实体状态：created/provisioning）并入队一个新的队列消息。现在 webjob 收到队列中的消息并开始执行配置任务。作业 successfull/failed 后 resource/entity 将更新（状态：completed/failed）。
没什么特别的。但现在我也想将具体化统计数据、报告等部分移动到现在正在计算和计算的作业中。
当我将所有这些时间不重要的任务移动到单独队列中的 Web 作业时，例如：
配置队列 更新统计A 创建报表B ...
一次有那么多队列 (20-50) 是一种不好的做法吗（它们一直都是 polled/checked）。为清楚起见：每条消息一个队列。可悲的是，我没有找到任何 way/example 如何创建多个工作函数来监听同一个队列但使用不同的消息。此外，我没有发现任何关于使用多个队列的信息 good/bad。只有 1-3 个工作功能的示例（图像转换、调整大小...）。
azure服务总线听起来也不错（因为有话题）。我不确定我是否正在使用 webjobs 和存储队列进行正确或良好的处理。我想要的只是从 webapi 中解耦许多非时间关键和长 运行 任务。
谢谢大家！
使用多个队列完全没有问题，每个队列都有一个需要处理的单独消息类型。
有两种方法可以处理来自这些队列的消息：将所有队列监视方法放入一个 web 作业中，或者将每个队列的监视器拆分到它自己单独的 web 作业中。我个人喜欢将您的队列监视器拆分为单独的 Web 作业，因为它使您能够在需要时将 Web 作业移动到单独的 Web 应用程序。例如，假设您有正在监视队列 A、B 和 C 的 Web 作业 A、B 和 C。如果 A 的工作负载一直很重，而 B 和 C 的负载总是很轻，您可以将 A 移动到单独的 Web应用程序在不同的应用程序服务计划上，B 和 C 可以共享一个 Web 应用程序。这是一种微服务方法。
主题在这种情况下没有用。
服务总线是一个很好的方式，你需要保证至少一次和最多一次交付。此外，您可以轻松地拥有一个包含不同消息类型的服务总线队列（如果您想这样做的话）。您通过 BrokeredMessage class 实例在服务总线中发送消息。您可以为每种消息类型创建一个 BaseMessage class、subclass BaseMessage，通过序列化为 JSON（或您想要使用的任何格式）通过 BrokeredMessage 打包消息，然后测试以查看在出列操作期间有什么 subclass 。