10

我正在为一个将呈现用户活动（登录、照片等）的实时更新（如 Facebook）的项目确定架构选项。其中两个主要的 UI 组件是一个自动更新滚动区域，其中将列出新的通知（照片等），以及一个工具栏，该工具栏将使用更新的消息计数等内容进行更新。

这方面的竞争者是基于 Jabber/Comet/XMPP 和 WebSocket 技术。

彗星营地：

WebSockets 阵营：

由于现有的基础架构是 Microsoft 堆栈，因此我宁愿不将基于 Java 的服务器引入其中。说到这里，就留下了（非常吸引人的）WebSync（彗星）和SuperWebSocket（WebSockets）。然而，Pokein 的 DLL 集成也相当无缝地集成到 .Net 项目中。

.Net 是否有更真实的生产级 WebSocket 计划？在 Microsoft 堆栈上采用 WebSockets 是否为时过早，我应该支持 Kazing 之类的东西吗？

我仍在等待关于我们当前用户群的浏览器类型和版本的报告（检查 HTML5 兼容性）。我怀疑这个数字会很低（老用户群）。如果是这样的话，彗星选项将是赢家。

还有哪些需要考虑的事情？

看看一些 .Net 计划，如 Sockets.IO 等，我认为这可能还处于起步阶段，无法应用于大规模生产系统。

我可以从使用过上述任何技术和产品的任何人那里获得一些意见吗？

谢谢。

更新

我仍在寻找一些在生产级别上可靠的优质 WebSocket 服务器。在最近找到 XSockets 和 SignalR 之后，我将它们添加到了 Websockets 阵营。然而，此时仍有两个主要竞争者。这可能只是因为他们拥有非常出色的营销团队、可供开发人员使用的优质材料——API 和视频。许多其他实现似乎仍处于新生阶段，其中给出了仅与少数客户端连接的示例。虽然这演示了该技术，但这些演示没有大量有效载荷/负载容量数据支持。Kaazing 和 LightStreamer 确实满足以下要求。

XSockets 有一些很好的例子，但同样缺少一些真正的生产指标。

SignalR 似乎还没有在真正的生产环境中经过测试。横向扩展解决方案正在开发中，但似乎还不稳定。期待看到这个项目在未来的表现如何。

主要要求是：

  1. 能够实现回退技术（如果 HTML5/WebSockets 不可用）
  2. 高并发连接数和每秒消息数
  3. 可扩展 - 能够为更大的流量需求添加额外的服务器/节点
4

5 回答 5

3

WebSync v4 除了根据需要回退到长轮询/回调轮询之外，还使用 ​​WebSockets。WebSync 中的 WebSockets 也都在标准 HTTP 端口上，因此路由器/文件防火墙/等不会有任何问题。

在“正常”系统上，您应该看到 ~20k 并发（每个节点）和 ~100k 消息/秒。不过，这些都是非常粗略的数字，因为它在很大程度上取决于您的系统和您发送的消息类型等。我们已经看到高达 50k 用户（每个节点）和（在不同的测试中）300k 消息/秒.

（免责声明：我为 Frozen Mountain 工作）

于 2012-11-28T20:24:05.760 回答
1

看来您选择了可用的最稳定的 Comet 实现。它们看起来都很稳定，每个节点能够承载十到十万甚至更多的用户。

那么，下一个可能是什么？例如，PokeIn将通过VisualJS.NET托管 Web 应用程序的所有方面；视频 1 ,视频 2

这也显示了该库的内置功能以及您可以执行的各种操作。

此外，最新版本支持对客户端和服务器之间的消息进行 Base64 序列化，因此网络包上不再有裸 JSON 消息。

更新：PokeIn 2.0 具有内置的 WebSockets 支持。

于 2012-02-16T19:58:20.200 回答
1

原因包括。上面已经说过的那些，我会使用 WebSockets。

如果您使用 WebSockets，您可能还会考虑 Autobahn WebSockets，这是一种支持 Windows 的高性能 WS 服务器，它在 IOCP（I/O 完成端口）之上运行。

如果您想扩展到大连接数（数十万），后者很重要。

免责声明：我是 Autobahn WebSockets 的作者。基础技术是 OSS。我们目前正在准备一个商业产品，一个作为虚拟设备（在 VMware/sphere 上运行）提供的实时消息传递中心......完全集成的、加固的设备。后者还允许您使用普通的旧 HTTP/POST 通过集线器推送通知。它有一个 REST API，允许您分派到通过 WS 连接的客户端。如果您对私人 Beta 测试感兴趣，请与我联系..

于 2012-02-16T10:16:18.887 回答
0

与传统彗星解决方案相比，使用 WebSockets 获得的性能提升在多个数量级范围内；我肯定会选择 WebSockets 阵营。这是传统彗星供应商对这两种技术的比较，测得 WebSockets 的优势超过 150 倍（50,000 个用户时为 700 毫秒对 3 毫秒）。

代表 Kaazing 的几点说明：

微软完全支持 Kaazing 作为服务器平台。此外，正如您所注意到的，Kaazing 支持各种客户端库和技术，包括 Microsoft 堆栈：.NET 和 Silverlight，我们的许多客户都乐于使用。

此外，Kaazing 在 WebSockets 之上提供了丰富的业务协议，允许您直接在客户端代码中“说”XMPP。

关于浏览器支持： Kaazing 提供了非常好的 WebSocket 仿真，支持所有的浏览器，包括旧浏览器，一直到 IE6。您可以在此博客文章中了解更多信息。

成熟度方面：Kaazing WebSocket 网关自 2009 年开始出货，在金融、物流、游戏、零售等多个行业拥有大量高端客户；非常成熟的平台，提供一流的支持。

于 2012-02-15T19:51:49.303 回答
0

SignalR获胜。

现在产品已经成熟，实施起来很容易。从本质上讲，它提供了那些 $every thou$ 和 $every $ 包的成本，但没有营销资金来展示一些非常酷的实现。

从技术角度来看，您可以使用 SignalR 完成相同的事情。如果您的技术人员另有建议，他们可能不知道如何在负载平衡的环境中（甚至自己）实现 SignalR。

于 2013-10-03T16:49:59.573 回答