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