我希望下面解释我的问题。
我有一个工作角色，它在一个while（true）循环中运行。此工作程序将消息从队列中取出并进行处理。它永远不会完成，只是不断检查队列和处理消息。
这一直有效，直到我收到一条消息，要求我做一些需要时间的事情。一个示例可能是从服务请求信息。假设我们说这个请求需要10秒钟。现在我的worker角色正在我的while循环中间等待这个响应。与此同时，消息队列正在填满。
我想要的是一种解决方案，可以阻止或减轻这种情况的发生。
我当前的现实世界解决方案是我有一个辅助角色，它使用任务并行库来创建许多并行运行并从队列中获取的消息处理器。但是，如果运行我的消息处理器的所有线程都在等待服务时，可能会发生此问题。
我知道我应该使用异步请求服务，但还有其他一些例子，其中async无济于事。我宁愿不深入细节。
所以我现在的计划是修改我当前的架构并创建一个消息处理服务。因此，我将使用当前解决方案中的消息队列，并仅使用辅助角色将工作委派给我的Web服务（异步）。
此工作者角色现在不会遇到线程等待某事的情况。
但我对此并不满意。如果使用任务并行库创建多个队列处理器的工作者角色不够快，该怎么办？我不认为CPU会施加压力，因为减慢将是检索消息并将其发送到Web服务，这两者都不是CPU密集型的。
所以我需要更多队列处理器，这些队列处理器必须根据我的队列繁忙程度产生队列处理器的实例来创建。因此，当队列中包含大量项目时，Azure将创建一个新实例来帮助我处理它们。
我对这个解决方案没有信心。我觉得这应该更容易。为什么我现在要创建一个Web服务来使用从worker角色发送的消息，而worker角色又根据我的消息队列进行缩放。
我的解决方案是否有意义还是有替代方案？
答案 0 :(得分：2)
看看你需要扩展的原因
假设我们说这个请求需要10秒钟。现在我的worker角色正在我的while循环中间等待这个响应。与此同时，消息队列正在填满。
问题不在于工作人员需要很长时间，而是队列被备份 - 这正是Azure提供包括队列大小的扩展选项的原因。
此外，如果您的服务是CPU密集型的，那么扩展只会将问题分散到多个实例上 - 在您遇到同样的瓶颈之前，这只是时间问题。
最终，您需要决定多长时间，然后确定队列是否会更快地处理更多帮助（缩小）或更多肌肉（扩大规模），或两者兼而有之。