什么是 WebRTC 中的供应商锁定？

供应商锁定是指企业从一家供应商转向另一家供应商时面临高昂转换成本的现象，这些成本可能涉及时间、资源或风险。WebRTC 生态系统也存在其独特的供应商锁定机制。

作者：Tsahi Levent-Levi 博士，WebRTC专家
原文：https://bloggeek.me/vendor-lock-in-webrtc/
编译：webrtc学习和实践

本文将探讨 WebRTC 供应商锁定的具体表现形式。在日常服务客户过程中，我几乎每天都能看到他们面临供应商选择与技术栈调整的决策困境。

要点总结

• WebRTC 中的供应商锁定问题源于高昂的转换成本，而这些成本又受到时间、资源和风险的影响。
• WebRTC 应用包含多种服务器类型：应用服务器、信令服务器、STUN 和 TURN 服务器以及媒体服务器。
• 视频API供应商由于API不规范和行为差异，带来了严重的锁定问题，使得供应商转换变得复杂。
• 托管服务（例如 TURN 服务器）可能会导致厂商锁定，但如果配置得当，切换服务在技术上可能很简单。
• 在开源服务和托管服务之间进行选择，需要考虑供应商锁定、成本影响以及对组织核心竞争力的了解。

WebRTC应用程序的结构解析

我们首先将 WebRTC 应用程序分解成各个组成部分。这一切都源于 WebRTC 中存在的主要参与者，简而言之，我们在 WebRTC 应用中通常部署四种主要服务器类型：

• 应用服务器，承载应用逻辑。本文暂不讨论此类服务器——它们与WebRTC关联较少，更多涉及应用程序的具体实现。
• 信令服务器负责会话协调。WebRTC规范中虽未明确要求部署此类服务器，但相较应用服务器，它们具有高通信频率（且双向传输）的特性，其信令协议与扩展机制对 WebRTC 核心运行至关重要。
• STUN 和 TURN 服务器处理 NAT 穿透问题。大规模部署时需尽可能靠近用户端。
• 媒体服务器虽未在 WebRTC 规范中明确提及，但多数商用 WebRTC 应用均配备此类服务器。其主要用于处理群组通话、直播及录制等功能。

为何需关注这些细节？因为不同服务器类型可选择不同供应商，亦可将所有服务整合于单一供应商。接下来我们将探讨各类方案及其与供应商锁定的关联性。

CPaaS 和视频 API 供应商以及供应商锁定

让我们深入探讨一下，首先从 CPaaS 和视频 API 供应商入手。这些方案属于“全包式”方案，信令、STUN、TURN和媒体服务器都由供应商提供。这些供应商还提供媒体服务器范围之外的其他功能和特性，这使得切换变得更加复杂。

使用视频API供应商意味着被供应商锁定。从一个供应商切换到另一个供应商通常成本很高且风险很大。

造成这种情况的原因有很多：

• 由于没有标准 API，因此集成代码需要从头开始重写。
• 行为差异。虽然平台在理论上可能支持相同的功能集，但实际上它们的行为可能大相径庭——尤其是在群组通话和特殊情况下。这会带来切换风险，而这些风险只能通过严格的测试来降低。
• 学习曲线。需要学习新供应商的新 API、行为和机制。同时，还需要了解其与当前所用供应商之间的差异。

在切换供应商时，许多公司会选择搭建一个抽象层，以降低供应商锁定风险。此外，它还可以帮助公司使用多个供应商——目的是为了拥有多种选择、针对不同市场提供解决方案，或者仅仅是为了增强自身的议价能力。

托管消息传递和信令服务

在决定采用何种信令方案时，我们需要从以下两点进行选择：

• 采用哪种信令协议？
• 选择自主托管还是采用选择托管式方案？

第二种方案主要适用于专有信令协议。

在很多方面，选择第三方服务商来处理信令是一个明智的选择。虽然确实存在一定的厂商锁定效应，但通常没有令人信服的理由去更换服务商。价格通常比较合理，而且功能集远比单纯的信令功能要丰富得多——如今的即时通讯服务可能包含推送通知、聊天逻辑、图片和文件管理、内容审核等功能。

我对此并没有特别强烈的意见。在某些情况下，使用托管消息平台非常合理；而在另一些情况下，自行管理和维护信令则更为明智。我不太关注信令方面可能存在的厂商锁定问题。对我而言，两者之间更重要的是选择使用哪种信令协议。

托管式 TURN 服务的魔力

关注我的人应该都知道我对托管 TURN 服务的痴迷。

如果说 WebRTC 中有一项逻辑，你应该始终问问自己是应该自己运营还是外包，那就是你的 TURN 服务器。

原因很简单。他们在技术方面没有真正的供应商锁定：从一个供应商切换到另一个供应商非常容易，因为 API 非常容易上手，切换应该不到一天的时间。

然而，真正的挑战在于，如果你有很多企业客户，并且你已经指导他们基于某个 TURN 服务配置防火墙。现在切换到另一个 TURN 服务，就意味着你需要联系所有这些客户，让他们重新配置防火墙。

这里哪个供应商更好？很难说。你需要监控生产环境中的路线行程时间值，看看从一个供应商迁移到另一个供应商后，行程时间是否会出现倒退。

TURN托管服务唯一明显的厂商锁定问题似乎只出现在这种情况。至于其他情况？切换应该很简单。

开源的魅力（和挑战）

人人都想要免费的东西。WebRTC 也不例外，尤其是开源的 WebRTC 媒体服务器。至于 libWebRTC本身嘛…它也是开源的。

选择在 WebRTC 中使用开源方案时，请谨记：所有问题和烦恼依然由你承担。你并未将它们“外包”给开源软件包。若功能无法正常运作，你必须亲力亲为解决问题。你使用的软件不附带任何服务等级协议（SLA），因此你可能无法从开源包维护者那里获得你所依赖或期望的帮助。

使用开源软件可能导致对非供应商的深度锁定，最终结果可能更糟……

记住：

• 有些开源项目没有官方的维护公司，这意味着维护者可能会在某个时候失去兴趣，导致项目逐渐消亡。
• 其他开源项目背后可能有公司或官方团队，但他们的重心并不在此。这意味着他们可能不会提供付费支持和定制服务，甚至可能不愿意讨论项目路线图和您可能提出的需求。
• 从一个开源软件包切换到另一个开源软件包，与从一个托管服务切换到另一个托管服务一样困难。

我并不反对使用开源软件，实际上我很支持。但你需要了解其中的运作机制，比如WebRTC 的开源生态系统是什么样的，以及你选择使用的特定软件包是如何管理和维护的。

测试和监测

你可以使用托管服务来进行 WebRTC 测试和监控。我知道……我曾经是其中一家服务的 CEO 和联合创始人，直到我们被收购为止。

使用 SaaS 进行 WebRTC 测试非常简单。由于它不涉及实际的生产服务，因此风险很小，唯一的区别在于相关的成本。

对于监控而言，情况则有所不同。主要问题在于历史记录。如果你目前使用托管服务收集监控数据，那么切换到其他服务意味着一切从零开始，你将失去所有历史数据点和分析结果。

测试和监控的重点不在于集成、API 和风险，而在于学习曲线和适应不同的应用程序。

Hybrids

市面上存在两家颇具特色的视频API供应商，它们同时提供托管服务与开源方案：8×8 JaaS（Jitsi即服务）和LiveKit。

两者的运作模式都很简单：你可以使用我们的开源产品，随后切换至SaaS服务，反之亦然，且你编写的代码将保持完整无损。

表面看来，这里不存在供应商锁定问题。

然而魔鬼藏在细节里。

实际运维中存在大量专有封闭的环节：从扩展性、区域部署到负载均衡等。凡是涉及多台机器协同的场景，通常会被隐藏在开源代码中——可能附带一份说明文档，也可能直接缺失。这并非出于恶意，而是因为这类组件本就不常见于开源项目。坦白说，供应商需要盈利生存，不可能无偿提供所有服务。

总之，这种混合方案对寻求中间地带、犹豫不决或追求灵活性的用户而言颇具吸引力。

自建还是购买决策

每当我们审视 WebRTC 的供应商锁定和托管服务时，自建还是购买的问题就会凸显出来。

以下几个方面值得考虑。

明确的关键绩效指标

在选择供应商时，要清楚自己需要考虑哪些方面……确保公司内部的关键绩效指标 (KPI) 设定合理且达成共识。然后，要有相应的衡量方法。

如有需要，可考虑在相关供应商平台上进行简短的概念验证。

虽然过程可能有点冗长，但这很重要。

TCO、ROI 和其他术语

这些是人们经常挂在嘴边的金融术语，他们以为每个人都知道这些术语（但大多数时候并非如此，我自己也总是需要几秒钟或更长时间才能理解它们）。

对我来说，这里最重要的指标是总拥有成本（TCO）和投资回报率（ROI）。哦，还有上市时间（TTM）。

估算一下这些成本。分别针对你选择的两种方案。然后估算一下供应商锁定风险带来的成本。或者更准确地说——当你想要从一个供应商切换到另一个供应商时，成本会是多少。

数据主权与治理

运营数据的所有权归谁？如何管理？存储和处理地点在哪里？

如果你自己要遵守这些规则，那么你需要确保你所依赖的供应商也能遵守这些限制/要求。

我发现这种情况会导致犹豫不决，或者选择其他方案（例如更换供应商或改用开源软件）。

隐私和安全

与数据主权类似，你所使用的供应商如何维护隐私和安全也是一个重要问题。他们需要满足你的要求。许多公司在采用供应商之前还需要对其进行安全审计，因此最好尽早了解这些信息。

核心能力和重点领域

这种情况大多数时候都被忽略了。

贵公司的核心竞争力和重点领域是什么？作为市场上的企业，你最擅长的是什么？

如果你想凭借视频质量脱颖而出，那么你应该将视频质量作为核心竞争力，并自行构建（很可能使用开源软件），减少对第三方的依赖。

假设你将通信视为一种必需的商品，类似于电力或 IaaS 的公用事业。那么，当然可以选择一家供应商来提供托管服务，并依赖他们来完成这项工作。

你在此处选择的方法也应该指导你确定工程团队所需的人员配备和技能水平。通常情况下，使用托管服务并不意味着你可以忽略精通 WebRTC 的工程师，只是意味着他们无需能够背诵RTCP报头的结构或实现数据包速率控制以优化带宽估算机制。

别忘了你的支持团队。他们应该能够回答用户提出的问题……而不是只会鹦鹉学舌地说“我们的供应商说这是你们的错”——这种说法已经行不通了。

应该选择哪种方案？自建还是购买？开源还是托管服务？混合方案还是完全采用CPaaS？你是更喜欢外包复杂性但面临供应商锁定带来的种种麻烦？还是更喜欢充满挑战的自我提升之路？

总之不管怎么选，你都要清楚你的锁定条款！