我们系统的几个组件具有“长期运行”的操作。它们可能需要几秒钟到几分钟的时间，并且它们的 CPU 使用率会有所不同。例如，报告生成将占用 CPU 几秒钟，但数据收集主要用于等待数据库查询。
我面临两个选择：
（1）Web角色+工作者角色+队列+表。Worker 角色在队列上旋转，获取带有参数的消息，执行工作，使用进度和完成标志更新表。客户端旋转，显示进度，直到标记完成。一个 Web 角色，根据需要扩大工作人员角色的数量。
(2) Web角色+异步方法。让我的长时间运行的操作使用 .NET 4.5 的 async/await 内容，并将控制器操作标记为异步。根据需要扩大 Web 角色的数量。
选项 1 显然要复杂得多，但它的优点是可以让网络角色自由地做网络事情，并在事情开始变得非常繁忙时允许适当的排队。选项 2 更简单，需要更少的角色和存储资源，但如果事情开始变得繁忙，它是否有可能阻塞整个网站？为了简单起见，我强烈倾向于选项 2。有什么特别的理由不这样做吗？如果网站开始变慢，简单地增加 Web 角色实例的数量就可以解决性能问题，对吗？
与大多数架构决策一样，答案只是“取决于”。
在这种情况下，选项 (2) 更容易编码。如果您不希望大规模扩展，那么我会说这很好。
选项 (1) 的主要优势是您有两个用于扩展的旋钮：您的 Web 角色处理 Web 请求，您的工作人员角色处理工作，并且您可以独立于您的 Web 扩展您的工作人员。
但除非你要大规模扩展，否则我不会担心。选项 (2) 可以很好地扩展，只是效率不高。而且，如果您确实开始大规模扩展，您可以（低效地）使用选项（2）扩大规模，并且（可能）使用您的大规模扩展收入来开发选项（1）。
PS你应该使用async这两个选项。
正如斯蒂芬发布的那样，这将是一个“取决于”类型的答案。
在这种情况下，我可能会选择第一个选项，或者介于您拥有 Web 角色、队列和表的选项之间，但创建一个可执行文件，该可执行文件也作为启动可执行文件在您的 Web 角色上运行。
使用选项 2，您将对连接超时、实例重新启动等开放，并且必须通过扩展您的 Web 角色或重写代码来满足对资源的额外需求。
使用选项 1（正如 Stephen 指出的那样），您的工作负载是分开的，您可以独立扩展角色。此外，让队列和工作人员处理工作允许工作人员管理自己的生命周期，并且您可以通过在完成工作之前不移除队列项目来为计划内或计划外的重新启动建立一些弹性（这样它们将重新出现，如果你在中间崩溃）。您还可以更充分地利用角色资源（首先在线程上扩展，然后是附加实例），因为您的轮询机制将控制工作负载，而不是随机访问网站的人。在 Web 端，您可以选择使用等待完成并返回的异步方法，或者您可以返回一个令牌并让客户端轮询工作是否完成，
不过，选项 1.5 可能是最好的起点。如果您尝试从小处着手，那么在您的网络角色上使用后台可执行文件将是最便宜的解决方案。您将需要至少有 2 个 Web 角色以确保 SLA 覆盖，因此此解决方案将让您仅从这两个实例开始，仅此而已。分别构建执行队列轮询和报告（或其他）执行的可执行文件，然后将其配置为 Web 角色的启动任务。这将使您在启动时降低成本，并且这些 exe 的代码是分开的，如果您需要扩展，以后将成为您的工作角色的代码。在这种情况下要注意的最重要的事情是您的可执行文件会处理所有异常，因为如果此进程由于未处理的异常而退出，它将不会重新启动（与工作角色不同，