我想到了一个场景，Windows 8 应用程序将充当服务器，接收来自不同客户端（其他 Windows 8 应用程序或 Excel Web 应用程序）的消息。这些消息需要以低延迟（大多数情况下小于 1 秒）到达。我正在考虑许多不同的解决方案。我肯定需要某种服务器骨干来进行匹配（将消息路由到适当的设备）。我试着在
Azure 移动服务。源会将消息发送到 Azure，Azure 会将它们作为推送通知发送到适当的“服务器”设备。问题是这里的延迟不是很好。
Azure 移动服务（或简单的 Web API 站点等更简单的东西）仅用于匹配：实际发送消息将建立在每个客户端都具有与服务器应用程序的 Web 套接字连接的情况下。在这里，我们的延迟非常低，但我担心连接问题。从数据保护的角度来看，服务器不会存储任何消息这一事实更好，但会使灾难恢复和处理服务器应用程序在后台的时刻变得更加困难。
Azure 服务总线。应该为此制作（服务器订阅客户端消息的提要），但我认为需要为每个服务器创建一个新队列（然后客户端必须了解该队列的名称，所以有些需要像选项 2 中那样进行配对）
你会推荐什么？
提前致谢！
我之前一直在开发类似的东西，我建议你使用 Windows Azure Mobile 解决方案构建这个解决方案，尤其是它现在支持 Node JS NPM。
对于客户端，我还建议您使用 SignalR 构建它，它专为实时应用程序需要来自服务器端的大量事务的情况而设计。
您还可以在以下链接中找到有关如何集成它们的更多详细信息：http: //hhaggan.wordpress.com/2013/07/12/signalr-node-js/
我希望这些对你有帮助，如果你还需要什么，请告诉我。
经过一番思考，阅读了您的回复（以及 msdn 论坛上的其他回复）并分析了我的场景、查询模式和我更熟悉的技术，我决定如下：
SQL Azure 上的统一 Web Api 模型（在一种情况下甚至可能返回 OData IQueryable）将处理消息发送和匹配。
将消息转发到 Windows 8 集线器应用程序将通过 SignalR 和 Web 套接字完成。这两个链接向我展示了如何处理进入后台 ( http://msdn.microsoft.com/nl-be/windows/apps/jj662740.aspx ) 或失去连接 ( http://msdn.microsoft.com ) 的应用程序/nl-be/windows/apps/jj710180） - 我仍然想支持失去连接的几分钟，在此期间服务器将累积消息并发送所有未收到的消息（一段时间后比赛将被视为结束并且数据库将被清理 - 我不确定我是否会以编程方式或使用工作线程上的工作流来处理这个问题。此时它似乎很简单，可以以编程方式处理）。
如果我在匹配期间需要推送通知，我可以在 Web Api 中实现它们（这比在移动服务中需要更多的工作）： http: //www.codeproject.com/Articles/506733/Windows-8-Notifications-Push -Notifications-via-Win
所以它更像是解决方案 2。如果我遇到任何并发症，我会及时通知你。我最初可能需要更多代码来通过移动服务进行设置，但我认为一旦按照基本教程设置基础知识，我将能够以更无缝的方式扩展解决方案。我什至可以尝试使用 Entity Framework 6，以实现全异步并最大限度地减少 node.js 的吞吐量开销（但我并不期待任何严重的负载）。