我知道有许多第三方流媒体组件提供商（Kaazing、Lightstreamer、WebSync），但是，我想知道使用第三方提供商与本土提供商相比的一般优势是什么。
我正在考虑的场景是，用户有大约 100 个实体的 Web 显示，其中属性的更新速度高达每秒 3 次更新。我可以创建一个相对简单的 JavaScript 组件，它每秒 3 次轮询服务器以获取更新，根据收到的结果动态更新 HTML UI。在这个相对简单的场景下，使用第三方库会有什么显着的好处吗？
【问题讨论】：
@ColinE：您无法获得更多答案的原因是您有一些问题。我想你至少有两个问题：
1.) “为什么要购买第 3 方编程组件？” （广泛而模糊的问题）和
2.）“鉴于我的具体用例，我应该购买第 3 方实时消息传递组件吗？” （具体到您的情况，而不是一般知识）
不过，我会尝试一下，尝试平衡可能阅读本文的每个人的广泛知识，然后解决您的特定用例。我在发布 Comet/Bayeux 的 WebSync 实现的公司工作，所以我在这方面有很多经验。为了平等起见，我将尝试在我的术语中非常不可知论，但可以公平地假设我列出的实时消息传递的特性/功能/好处是基于我在 WebSync 方面的丰富经验。我对 Java 和 Apache 的实现了解不多。
对于几乎所有第三方编程组件，网络上的某个地方都有开源替代方案可用。虽然很难对 3rd 方组件与开源进行一刀切的评估，但我想说，我的经验是开源的东西（例如：CodeProject 文章）往往寿命很短，没有长期支持。这些开源风格的实现通常是由一个人构建的，试图避免支付组件的成本来解决一个特定的用例。出于这个原因，他们通常只为他们的应用程序实现最重要的功能。
当您购买第三方组件时，您很少只购买基本概念。您正在购买：
所以购买决定是这样的：实施我自己的彗星实施需要多少小时？以我的收费率计算，那段时间的价值是多少？该金额是否低于第 3 方组件的价格？
当然，您必须考虑风险和未来：我自己的实现在未来项目中的可重用性如何？如果项目范围扩大，我将承担哪些风险？如果范围发生变化，我的预算时间津贴可以增加一倍或三倍吗？我可以花多少时间来调整可扩展性或测试负载平衡系统的性能？我的老板/客户在未来为我们的项目做广告的另一个平台是什么？
如果您正在从事的项目是营利性专业项目，您自己节省的时间和第三方组件提供的支持通常会比为此付出的代价高出很多。如果您的项目是一个非营利、开源、社交的初创公司，您可能更愿意将您的钱包放得更紧一些，并争取一些社区支持来填补空白。
您的问题也无法将固定间隔 ajax 轮询作为彗星的替代方案。我想稍微澄清一下差异，以帮助做出最终决定。
定义
该行业的一个问题是人们混淆了 Comet、Bayeux 和 Streaming。 Comet 最初专门指长轮询，现在已成为通过普通 HTTP（与协议无关）进行实时消息传递的通用术语。 Bayeux 是关于数据应该如何“通过网络”（协议）看起来的规范。流媒体是通过互联网实时发送内容的想法。人们经常交替使用它们，暗示一个系统具有所有三个特征/功能。一些类似“彗星”的系统，不要使用行业标准“bayeux protocol”。它们并不相同，但您会发现“bayeux”得到了许多大型行业参与者的支持，并指定了我们与我们的服务器对话的方式来处理类似彗星的应用程序。 Bayeux 也是使行业标准实现很好地结合在一起的原因（一件好事）。我自己什至可能会混淆这些术语，但至少现在你知道我说“Bayeux”时在说什么了。
网络上的数据复制与初始状态 + 差异更新
使用固定间隔轮询机制，您可以获得听起来像是固定间隔的确切信息。 Bayeux 的想法是避免网络上的数据重复。如果数据没有改变，为什么要再次发送？这可以为您节省带宽成本和服务器上的处理开销。两者都是非常实际的财务成本，以影响您的决定。另一方面，如果数据确实每秒更改 3 次，comet 为您提供这些数据是没有问题的。
更进一步，Bayeux 允许“初始状态 + 差异更新”的概念。这意味着，当您的 javascript 客户端启动时，您订阅了一个返回 100 个实体（可能是大量数据对象）的初始状态的通道，然后 Comet 机制将继续提供增量差异更新。示例：实体 1 刚刚被删除，实体 7 刚刚被编辑，我们刚刚在列表中插入了另一个实体，等等……这些是对初始状态的差异更新。您永远不会发送完整的 100 个实体集合（除非所有 100 个实体在最后 1/3 秒内确实发生了变化）。
如果您失去连接（Wi-Fi 掉线），客户端将重新订阅并以新的初始状态重新开始，然后继续进行差异更新。这可确保您永远不会“错过”更新。如果您尝试使用简单的 Ajax 轮询来执行此操作，您可能会复制数据（占用带宽）或冒“丢失”差异更新的风险（不可靠）。
通过这种安排，您在性能、带宽使用和开销方面总是与 ajax 长轮询机制相同或更好。在大多数情况下，您的带宽使用情况要好得多。
Bayeux 批处理
Bayeux 提供了一个“渠道系统”来对交付给客户的数据进行分段。例如，如果您进行了 AJAX 轮询，您最终会得到一大块需要解析（并生成服务器端）的数据。使用频道系统，您可以发布到像“/entityA”、“/entityB”这样的频道，甚至是像“/entityA/fooMessages”和“/entityA/barMessages”这样的多级频道。 Comet 服务器会将所有已发布的消息批处理到客户端，客户端可以将消息分发到每个数据段（每个通道）的适当 javascript 处理程序。
服务器端支持
虽然并非在所有 Comet/Bayeux 实现中都可用，但我知道 WebSync 具有出色的服务器端事件机制，可让您“审核”进出服务器的所有消息。在这些服务器端事件中，您可以加载新数据、转换现有数据、记录诊断信息、评估身份验证状态、调用第 3 方跨域 API 等。这里有很多功能可以准备/处理您想要的数据分发给您的客户。
好的，现在我们有了一个广泛的框架来评估是开源还是购买商业实现的选择。因此，让我们逐步了解您在问题中给我的参数。
每个客户端需要 100 个实体，每秒更新 3 次。因此，每个客户端都有 300 个单独的 JSON 对象/消息飞来飞去。这是很多需要推动的数据。我想说的是，您可以采取任何措施来减少网络上的重复数据，这将使您受益匪浅，因此我建议您使用具有初始状态 + 差异更新的彗星实现。此外，由于跟踪的实体如此之多，使用渠道进行数据分割将真正帮助您完成编码并节省您的时间。
选项：使用 AJAX 每秒轮询服务器 3 次。
优点：
缺点：
选项：购买feature-rich comet implementation。
优点：
缺点：
【讨论】：
在你的情况下，我会说选择取决于你，我个人更喜欢使用我自己的库来做这个用途。但这里是第 3 方与家庭的利弊：
第 3 方库的优点：
第 3 方库的缺点：
以下是我对这个困境的看法，希望对你有用。
【讨论】：