Azure 工作进程间通信答案

【问题标题】：Azure Inter-worker process communicationAzure 工作进程间通信
【发布时间】：2013-09-22 19:16:06
【问题描述】：

我正在移植一个旨在在非 Azure 环境中工作的应用程序。该架构的元素之一是无法扩展的单例，我希望用多个工作进程替换它，这些工作进程为单例当前提供的资源提供服务。

我已经进行了必要的更改来替换单例，并且正在构建通信框架以提供从 UI 服务器到资源工作者的互连，我想知道我是否应该只使用 TCP 绑定WCF 服务或使用 Azure 服务总线是否更有意义。 TCP/WCF 很简单，但并没有解决完整的问题：如何确保只有一个工作人员处理 UI 请求？

通过阅读可用的文档，听起来服务总线可以解决这个问题，但我还没有看到具体的实现示例。我希望这里有人可以帮助和/或为我指明正确的方向。

【问题讨论】：

【解决方案1】：

似乎 Azure 服务总线队列是适合您的解决方案。

可以通过 3 种不同的方式使用 Azure 服务总线：

来自 Windows azure 网站：

服务总线队列提供单向异步队列。发送方将消息发送到服务总线队列，接收方稍后会接收该消息。一个队列只能有一个接收者

【讨论】：

@JohnWollner 您可以在此处找到完整示例：windowsazure.com/en-us/develop/net/how-to-guides/…
@DavideIcardi 如果我想收到来自我正在连接的服务的响应怎么办？例如，如果我想通过将消息排队到我的 EmailSender 辅助角色来发送电子邮件，然后接收并回答电子邮件是否已发送（以及错误描述）。
@UriAbramson 像往常一样，有许多可能的解决方案。一个非常简单的方法是将messageId 传递给worker 角色。 worker角色可以使用这个messageId来写入一些结果信息（可以使用任何存储，比如表存储）。然后客户端可以使用 messageId 作为键来查询该存储。例如，客户端可以每 10 秒检查一次消息是否被处理。
你知道基于推送而不是基于投票的解决方案吗？
@UriAbramson ServiceBus 主题可用于推送式消息。您可以在主题内发送消息，消费者可以为这些消息创建订阅，也许使用过滤器来接收相关消息。 docs.microsoft.com/en-us/azure/service-bus-messaging/…

【解决方案2】：

添加到 Davide 的答案。

另一种选择是使用Windows Azure Queues。它们旨在促进 Web 和辅助角色之间的异步通信。从您的 Web 角色中，您将消息推送到由您的工作角色轮询的队列中。

您的工作人员角色可以"Get" 来自队列的一条或多条消息并处理这些消息。当您从队列中获取消息时，您可以指示队列服务使这些消息在一定时间内对其他调用者不可见（称为message visibility timeout）。这将确保只有工作角色实例才能处理消息。

一旦工作角色完成工作，它可以简单地删除消息。如果处理消息时出错，则在可见性超时期限到期后，消息会自动重新出现在队列中。您可能会发现此链接很有帮助：http://www.windowsazure.com/en-us/develop/net/how-to-guides/queue-service/。

【讨论】：

服务总线队列提供比 Azure 队列更丰富的消息传递语义。请参阅此进行比较：msdn.microsoft.com/en-us/library/windowsazure/hh767287.aspx
我考虑过直接排队，但我的理解是它们仅限于 8K 有效负载，这对于我的应用来说还远远不够。
8K 限制是很久以前的事了。现在是 64K - msdn.microsoft.com/en-us/library/windowsazure/dd179363.aspx.
很高兴知道限制，尽管我上个月参加了一次聚会，他们仍在鞭打 8K
除了很遗憾您被误导之外，我还能说什么。在 +ve 方面，既然您知道增加的限制，如果需要，您有 2 个选项可供选择。

【解决方案3】：

Azure 队列不是为进程间通信而设计的，而是为应用程序间通信而设计的。消息传递延迟很大，无法保证传递时间。 Websockets 或 NetTcpBinding 更适合实时相互通信的应用程序。尽管必须承认，您可以使用 queuez 获得一些免费的东西，尤其是锁定机制。只是我的 2 美分

【讨论】：