streaming - 第三方流媒体库与本地流媒体库

Question

我知道许多第三方流媒体组件提供程序（Kaazing，Lightstreamer，W​​ebSync），但是我想知道使用第三方提供程序相对于本地提供程序的一般优势是什么。

我正在考虑的场景是用户在Web上显示大约100个实体，其中的属性以每秒最多3个更新的速度进行更新。我可以创建一个相对简单的JavaScript组件，该组件每秒轮询服务器3次，以根据接收到的结果动态更新HTML UI。在这种相对简单的情况下，使用第三方库是否有任何重大好处？

Answer 1

@ColinE：您无法获得更多答案的原因是您有一个问题很多。我认为您至少有两个问题：

1.）“为什么要购买第三方编程组件？” （广泛而模糊的问题）和
2.）“鉴于我的特定用例，我应该购买第三方的实时消息传递组件吗？” （具体取决于您的条件，较少了解常识）

不过，我会尽力而为，力求在平衡广泛知识的基础上，使每个可能读过它的人从中学习，然后解决您的特定用例。我为发布Comet / Bayeux的WebSync实现的公司工作，所以我在这方面有很多经验。为了平等起见，我将尽量避免使用我的术语，但是可以公平地假设，我列出的实时消息传递的功能/功能/优点是基于我对WebSync的广泛经验。我对Java和Apache的实现了解不多。

为什么要购买第三方零件？

对于几乎所有第三方编程组件，网络上都有某个地方可以使用开源替代方案。虽然很难对第三方组件与开放源代码进行千篇一律的评估，但我想说，我的经验是，开放源代码的东西（例如：CodeProject文章）寿命很短，没有长期支持。这些开源样式的实现通常是由一个人构建的，他们试图避免为解决一个特定的用例而付出付费组件的成本。因此，它们通常仅实现其应用程序中最重要的功能。

当您购买第三方组件时，您很少只购买基本概念。您正在购买：


经过数百个客户测试和审查的功能更广泛，功能更丰富的实现
既有可靠的历史又有未来的计划
都带有出色技术支持的承诺
如果您最终需要它，可以与经验丰富的开发人员签订合同


因此，购买决策是这样的：实施我自己的彗星实现需要花费我多少时间？以我的收费率计算，那段时间的价值是多少？该金额是否小于第三方成分的价格？

当然，那您就必须考虑风险和未来：我自己的实现在将来的项目中有多可重用性？如果项目范围扩大，我将承担什么风险？如果范围发生变化，我的预算时间津贴可以翻倍还是三倍？我可以花多少时间调整性能以进行可伸缩性或测试负载平衡系统？我的老板/客户广告是我们这个项目的另一个平台吗？

通常，如果您正在从事的项目是一个以营利为目的的专业项目，那么您自己节省的时间以及第三方组件提供的支持所带来的价值将远远超过为此付出的代价。如果您的项目是一个非营利性，开源，社会化的初创企业，则您可能更希望收紧钱包本，并争取一些社区支持来填补空白。

区分彗星与Ajax轮询

您的问题还不包括固定间隔的ajax轮询，它可以替代彗星。我想澄清一些差异，以帮助做出最终决定。

定义

该行业的一个问题是人们混淆了彗星，贝叶和流媒体。 Comet最初专门用于长轮询，现在已成为通过纯HTTP（协议不可知）实时传递消息的通用术语。贝叶斯（Bayeux）是有关数据应如何“在线”显示的规范（协议）。流式传输是通过Internet实时发送内容的想法。人们经常互换使用它们，意味着一个系统具有所有三个特征/功能。一些“彗星”之类的系统不使用行业标准“ bayeux protocol”。它们不是同一个人，但是您会发现“ bayeux”得到了许多大型行业参与者的支持，并指定了我们与彗星之类的应用程序与服务器进行通信的方式。 Bayeux也是使行业标准实现完美配合的一件好事（一件好事）。我甚至可能自己把这些术语混为一谈，但至少现在您知道我说“ Bayeux”时在说什么。

线上复制数据与初始状态+差异更新

使用固定间隔轮询机制，您可以确切地听到固定间隔的声音。使用Bayeux的想法是避免在线上重复数据。如果数据没有更改，为什么还要再次发送？这样可以节省带宽成本和服务器上的处理开销。这两种非常实际的财务成本都会影响您的决策。另一方面，如果数据确实每秒变化3次，那么彗星将毫无问题地为您提供。

更进一步，Bayeux允许使用“初始状态+差异更新”的概念。这意味着，当您的JavaScript客户端启动时，您预订的频道会返回100个实体（可能是重数据对象）的初始状态，然后Comet机制将继续提供增量差异更新。示例：刚删除了实体1，刚编辑了实体7，我们只是在列表中插入了另一个实体，以此类推...这些是对初始状态的差异更新。您永远不会发送完整的100个实体集合（除非所有100个实体在最后1/3秒内确实发生了更改）。

如果您断开连接（Wi-Fi掉线），客户端将重新订阅并以新的初始状态重新开始，然后继续进行差异更新。这样可以确保您永远不会“错过”更新。如果您尝试通过简单的Ajax轮询来做到这一点，那么您要么重复数据（占用带宽），要么冒“丢失”差异更新的风险（不可靠）。

通过这种安排，与ajax长轮询机制相比，您在性能，带宽使用和开销上总是相等或更好。在大多数情况下，带宽使用情况要好得多。

贝叶配料

Bayeux提供了一个“渠道系统”来分割要交付给客户的数据。例如，如果您进行了AJAX轮询，则最终将需要解析（并生成服务器端）一大块数据。使用通道系统，您可以发布到“ / entityA”，“ / entityB”之类的通道，甚至发布到“ / entityA / fooMessages”和“ / entityA / barMessages”之类的多级通道。彗星服务器会将所有已发布的消息分批分发给客户端，客户端可以将消息分发到每个数据段（每个通道）的相应javascript处理程序。

服务器端支持

尽管不是在所有Comet / Bayeux实现中都可用，但我知道WebSync具有出色的服务器端事件处理机制，该机制使您可以“审计”所有进出服务器的消息。在这些服务器端事件中，您可以加载新数据，转换现有数据，记录诊断信息，评估身份验证状态，调用第三方跨域API等。这里有很多功能可以准备/处理所需的数据分发给您的客户。

ColinE是否应该购买第三方彗星组件？

好的，现在我们有了一个广泛的框架来评估选择开源或购买商业实现的选择。因此，让我们逐步解决您在问题中给我的参数。

每个客户端需要100个实体，每秒更新3个。因此，为每个客户端飞来飞去的300个单独的JSON对象/消息。这是要推送的大量数据。我想说，您可以做的一切事情来减少网络上的重复数据，将使您受益匪浅，因此，我建议使用初始状态+差异更新的彗星实现。加上跟踪了如此多的实体，使用通道进行数据分段确实可以帮助您进行编码并节省时间。

选项：使用AJAX每秒轮询服务器3次。

优点：


便宜又容易
轻量级JavaScript


缺点：


每秒更新3次，而不管数据实际更改的频率如何（可能浪费带宽和处理开销）
您必须实现100％的服务器端JSON生成和大型（100个实体）JSON对象的客户端解析。 （没有通过通道的数据分段）
您必须构建所有错误处理逻辑。如果我的Wi-Fi断开3秒钟会怎样？您的请求会堆积吗？您会“错过”更新吗？您将如何赶上/重新启动页面？还是只保持每秒发送3次所有数据？


选项：购买feature-rich comet implementation。

优点：


与固定间隔轮询相比，可最大程度地减少带宽使用（省钱）
通道允许轻松进行数据分段（通过实现/解析节省时间）
批处理可保存HTTP请求（更好的性能/更低的带宽）
具有重新连接逻辑的出色错误处理能力，可配置的超时时间（提高了可靠性）
服务器端支持处理事件/消息/数据（强大而快速的服务器端代码）
经过验证的可靠性，可扩展性和客户端平台支持
专业的技术支持，文档，如有需要，可提供合同


缺点：


前期许可费用
与简单的AJAX轮询相比，功能丰富可转换为更大的JavaScript