.net - Windows Azure 基于消息的体系结构

Question

我正在 Windows Azure 上制作基于 Web 的系统，该系统处理来自不同来源(网站或 Web 服务)的订单。我脑海中出现的第一件事是使用 Azure 消息队列从网站和 Web 服务角色到一些实际处理订单的工作角色。

我发现了几篇关于 Azure 消息驱动架构的文章，它们看起来不错 - 我们从客户端获取消息，将其放入队列并在工作线程将读取该消息后响应用户“好的，您的操作已处理”消息并施展所有魔法。 但是这里有一个问题 - 如果我想将消息的处理结果(如果成功则发送订单 ID，否则发送失败原因)作为对客户端的响应，那么我需要等到Worker Role 将处理它。。问题是我没有找到好的/快速/便宜的方法来做到这一点，作为一种可能的方法我可以将消息放入处理队列并检查每个 X 毫秒是否已处理(处理完成后，Worker 会在结果中添加带有 Y Guid 的消息已被处理的信息)。

我不太喜欢这样等待的想法，因为订单处理时间可能从几秒到几分钟，如果每个客户端(同时最多 10-20 个)都将给系统带来额外的负载。检查每个 X 毫秒是否处理了他的请求(主要原因)。此外，考虑到 Azure 表访问率(次要原因)，它会非常昂贵。

您能建议一些实现这一点的好方法吗？我正在寻找诸如桌面应用程序中的事件等待之类的东西，鉴于高度分布，无法使用 Azure 来实现。

Answer 1

您想要做的是从浏览器建立到 Web 服务器的 socket.io 连接，以便您可以立即响应。有一个.NET 的 cometd 库，我从未使用过，http://pokein.codeplex.com/ 。我一直在 Node.js 中完成这一部分，这在 Azure 上可能是可行的，但可能需要一些努力才能运行。 Node 有一个很棒的实现来处理 socket.io 连接。

Web 请求 -> MQ -> Web 服务 -> 处理订单 -> Web 服务器或 MQ 上的 Web 服务 -> Socket.io/comet -> Web 浏览器。随着事件的发生，一切都是实时的。

如果您让用户继续浏览网站，并且只是弹出一条消息，例如“您的订单已处理，请在此处查看结果，准备好后”，结果通常会很好。