Windows Azure角色间通信

Question

我想创建一个Azure应用程序，它执行以下操作：

• 向用户显示一个MVC 4网站（网络角色），其中显示了一系列命令。
• 当用户选择命令时，它将广播给所有工作人员角色。
• 辅助角色处理任务，存储结果并通知Web角色
• Web角色显示工作者角色的组合结果

从我一直阅读的内容来看，似乎有两种方法：Windows Azure Service Bus或使用Queues。每个辅助角色还将结果存储在数据库中。

服务总线似乎更适合其发布/订阅模型，因此所有工作者角色将获得相同的命令并且大致相同的时间。队列似乎更容易使用。

在开发时，服务总线是否可以在本地与仿真器一起使用？我正在使用免费试用版，但在开发过程中无法持续保留应用程序。此外，在使用队列时，如何通知Web角色处理完成？

Answer 1

我同意。 ServiceBus是此消息传递要求的更好选择。你可以通过一些努力对队列做同样的事情。但是，您将编写大量代码来实现ServiceBus已经为您提供的功能。

没有ServiceBus的本地模拟器，就像Azure Strorage服务（队列/表/ blob）一样。但是，在开发环境中本地运行时，您仍可以使用ServiceBus在角色之间进行消息传递。

至于您关于通知Web角色处理完成的最后一个问题，有几种方法可以到这里。只是一些想法（不详尽的清单）......

1. 表存储，其中Web角色可以定期检查工作单元的状态。
2. 完成工作的另一个ServiceBus队列/主题。
3. 内部端点。你必须有逻辑来知道它是否只是来自工人角色N的更新，或者是否表明所有工人角色的已完成工作单元。

Answer 2

我同意Rick的回答，但也会考虑以下事项：

如果您选择Service Bus Topic方法，那么当每个辅助角色联机时，它将需要生成对该主题的订阅。您需要考虑其中一个工作人员出现故障并被回收的订阅维护，或者为什么订阅可能出现在那里的任何原因。

告诉所有工人完成的网络角色很有趣。 Rick提供的选项很好，但你需要在这里考虑一些事情。这意味着Web角色需要知道有多少工作人员或其他一些机制来决定何时完成报告。您可能有五个工作者角色接收消息并开始工作的情况，然后其中一个开始重复失败处理。其他四个报告完成，但现在网络角色正在等待第五个。你等了多久才能回复？你能继续吗？如果你刚刚告诉系统缩小规模，而网络角色认为有5个，现在只有4个。这些是你需要考虑的事情，它们都取决于你的要求。

Answer 3

根据您的问题，您可以使用任一队列服务并获得良好的结果。但是他们每个人都要克服不同的挑战和优势。

服务总线队列的一些优点是它提供了具有持久连接的阻塞接收（最多100个连接），它可以监视消息是否完成，并且它可以发送更大的消息（256KB）。

存储队列相对于服务总线解决方案的一些优点是它稍微快一些（如果15毫秒对您很重要），您可以使用单个存储系统（因为您可能会使用Storage for blob和table服务） ，以及简单的自动缩放。如果需要根据负载自动扩展工作者角色，则通过存储队列传递请求会使自动扩展变得微不足道 - 您只需在比例选项卡下的Azure云服务UI中设置自动扩展。

可以在此处找到两个azure队列服务的更深入比较：http://msdn.microsoft.com/en-us/library/hh767287.aspx

  

此外，在使用队列时，如何通知Web角色处理已完成？

对于Azure存储队列解决方案，我编写了一个可以提供帮助的库：https://github.com/brentrossen/AzureDistributedService。 它提供了一个代理层，便于从Web角色到工作者角色以及通过存储队列进行RPC样式通信。