WebRTC 架构格局正在发生变化

来源：WebRTC.Ventures
主讲人：Arin Sime(CEO of WebRTC.Ventures), Alberto Gonzalez(CTO of WebRTC.Ventures)
内容整理：彭峰
链接：https://mp.weixin.qq.com/s/3EIsb9UTclnBBTwPJHyFtg

介绍
选项一：符合标准的 WebRTC
选项二：开源媒体服务器
选项三：CPaaS
提高 WebRTC 应用规模
- MCU(Multipoint Control Unit)
- SFU(Selective Forwarding Unit)
- MCU 和 SFU 的结合
新一代架构选择——选项四: WebRTC Unbundling
不同选择的比较
总结

介绍

对于使用 WebRTC 的实时视频应用来说，没有适用于任何场景的通用应用架构，实际中基于用例以及在后端服务的商业，可以选择的架构有许多，并且差异较大。

当第一次了解 WebRTC 时，经常会看到一个如下的图表，在这里有两个对等点在浏览器中彼此连接，他们必须通过某种连接信令服务器必须在他们之间进行某种消息交换，以帮助建立它们之间的连接。但是一旦建立了该连接，所有繁重的流量例如视频、音频、数据通道这些都是在对等架构中在这两个浏览器之间直接交换的，你的信令服务器并没有真正承载大量流量。因为不处理传输数据本身，这种点对点 WebRTC 的想法有一些很大的优势，这是一种最简单的模型，也是我们在 WebRTC 中讨论最多的模型，即不会在服务器上增加太多的负载，视频音频流量和数据流量不会通过这些服务器，因此这也意味着可以更加安全地确保没有第三方获取到通信数据。所有数据在传输过程中都可以被加密，在现代浏览器中只需要使用 JavaScript 调用底层加密 API 即可实现。

但在实际部署中，问题并不简单，首先需要 STUN 和 TURN 服务器，以便帮助建立点对点连接；然后还需要信令服务器使得在没有成功建立连接之前进行一些必要信息的交换；此外在浏览器中需要处理不同的视频编解码器；又或者在群聊场景下，参与者不止有两个，将几个参与者的系统扩展到大型群里的复杂性是极高的；最后不同设备、软件之间存在不兼容性以及除了聊天之外的功能例如录制视频等会使得系统与最初的点对点连接系统之间产生天壤之别。在如此复杂的场景下，可以通过三种不同的方式来构建 WebRTC 应用程序，第一种是符合标准的前提下自己构建整个系统，第二种是借助开源代码的基础上实现，第三种是使用 CPaaS – CommunicationsPlatform as a Service，由服务提供商来提供技术支持。

首先，让我们分别回顾一下之前的三种架构选择。在首席技术官 Alberto Gonzalez 在 2021 年 TADSummit 上做的“如何架构你的 WebRTC 应用”会议演讲中也谈到了这一点。

选项一：符合标准的 WebRTC

这是构建 WebRTC 应用程序的原始方式，从一开始，WebRTC 就被描述为一种使用普通 JavaScript 访问摄像头和麦克风并建立对等视频、音频和数据通道的简单方法。它旨在将电信通信带给开发人员大众，这样他们就可以在浏览器中构建东西，而无需了解 VOIP 或电话，然而，它总是比宣传的要复杂一些，需要一定的技术支撑。

当然如果直接在 WebRTC 的标准构建自己的技术栈，则可以拥有最强大灵活性，例如随意添加自定义功能和根据业务进行系统优化。伴随着这种强大的力量而来的是巨大的责任，业务开展者必须管理诸如 STUN/TURN 服务器、应用程序信令和浏览器/移动支持之类的事项，最重要的是，随着业务发展扩展应用程序也并非易事。

对于当今的绝大多数应用程序，没有理由选择从零开始构建整个系统，最好在开源媒体服务器实现或 CPaaS 之上构建（见下文）。许多人开始以这种方式构建应用程序作为一种学习练习，然后将现有框架用于他们的生产应用程序。

特别的情况是，如果因为市场上没有任何东西适合你的精确要求，以往你只能构建自己的媒体服务系统或者修改和重新编译 libwebrtc 以获得独特的用例，但现在 WebRTC Unbundling 将更好地涵盖大多数这些用例。

选项二：开源媒体服务器

MediaSoup、Janus、Jitsi 和 Pion 库中的开源媒体服务器都是不错的选择，因为它们降低处理 WebRTC 的许多复杂性。它们通常具有内置的 STUN/TURN、信令和浏览器/移动支持的详细信息。基于选择性转发单元等媒体服务器设计，它们还极大地提高了标准 WebRTC 的扩展能力。

当然业务开展过程中仍然需要处理服务器基础架构的所有方面的问题，以及对该基础架构的扩展。相比选项一来说，技术负担有所减轻。

选项三：CPaaS

对于许多客户而言，通信平台即服务 (CPaaS) 是一种引人注目的架构选择，因为它是速度最快的解决方案。通常商业平台内置了应用程序视频部分所需的所有全局扩展，并与新的浏览器和移动版本保持同步。常见的 CPaaS 解决方案提供商包括 Agora、LiveSwitch、Twilio 和 Vonage。

唯一需要权衡是成本，解决方案提供商提供的服务的收费会提高你的运营成本，这些费用是基于使用量来计算的。尽管 CPaaS 仍然是入门的绝佳选择，但是，如果需要对业务进行更低级别的控制，CPaaS 并不能提供较低级别的控制；或者业务规模增长到一定程度后，服务费用的增长会成为巨大的问题。

提高 WebRTC 应用规模

正如前文提到的，构建自己的 WebRTC 库可能很复杂，如下图所示，尤其是当想要扩展到多个参与者时，除了复杂性，系统的性能也会大打折扣。

开源实现的媒体服务器或者 CPaaS 可以帮助简化这些可扩展性问题，但如果想要在 WebRTC 的标准下自建系统，可以有一些替代方案。

MCU(Multipoint Control Unit)

第一种是 MCU（Multipoint Control Unit）多点控制单元。如下图所示，多点控制单元中，中央服务器负责混合所有音频和视频，每个参与者只需要下载一个音频和视频流，MCU 会为每个用户控制视频流的组合。但其会带来额外的延迟，因为 MCU 需要大量的处理以及可靠的网络条件。

SFU(Selective Forwarding Unit)

第二种是 SFU（Selective Forwarding Unit)选择性转发单元，如下图所示，选择性转发单元对于每个参与者仍然是唯一的流(允许在用户端更改布局)，其拥有更多的选项，当然其实现也是更复杂的；其不需要进行大量的处理，但需要应对不同的网络环境。

MCU 和 SFU 的结合

在一些特别的场景下，例如，在一个典型的视频会议应用程序，部分参与者可以以 SFU 的方式参与会议，但为了提供更多的功能，参与者可以通过 MCU，使用网络 SIP 语音呼叫通过移动设备加入会议。在类似的情形下，同时使用这两种选择是一个非常有效的。

新一代架构选择——选项四: WebRTC Unbundling

如下图所示，在 WebRTC Unbundling 架构中，可以组合各种 JavaScript API 来替换 WebRTC 应用程序中的媒体管道的一部分。其中包括WebAssembly、WebTransport 和 WebCodecs。

使用这种架构模型，可以将 WebRTC 应用程序中完成的标准编码/解码替换为 WebCodecs 库，从而允许根据独特的应用程序需求对视频进行个性化的优化，以及操作单个视频帧。

如果想使用比 WebRTC 更轻的传输协议，还可以使用 WebTransport 更改媒体管道的发送/接收部分。如果在用例不需要 NAT Traversal，那么实现自定义的基于 WebTransport 的应用程序是非常有意义的，因此 WebRTC 的 STUN/TURN 开销是不必要的。WebAssembly 可以更快地将所有这些部分连接在一起，并与围绕视频本身的机器学习组件或者其他东西集成。但目前这些 API 还不是在所有浏览器中都可用。

不同选择的比较

通常而言，应用开发者主要关心以下四个问题：

前期费用：构建这个应用程序需要多少钱？一般而言，CPaaS 或开源媒体服务器降低了构建 WebRTC 视频应用程序的复杂性，因此构建应用程序所需的时间比在 WebRTC 标准下自建系统要少。由于软件开发人员的成本很高，因此降低构建应用程序前期成本并减少开发时间。
持续成本：在生产环境中运行这个应用程序需要多少钱？这指系统上每个单独的视频通话的交易成本。由于 CPaaS 按分钟收费或根据所需的带宽量收费，因此它比使用开源媒体服务器构建自己的基础架构或按标准编码更昂贵。当用户数量较少时，这可能没什么大不了的。但是，如果业务规模扩展到数百万用户和视频通话，那么 CPaaS 的成本可能会变得过高。
技术难度：这与前期成本密切相关，专业的开发人员会需要较高的成本；随着业务的不断开展，维护应用程序也会逐渐成为一个问题，规模增长的技术难度巨大。
包括的功能：选择不同的架构，最后获得的功能上限是不同的，CPaaS 拥有大部分可以直接使用功能，例如 CPaaS 可能已经提供了用于背景替换或为视频添加字幕的选项，而对于自建系统，则必须自己构建该功能，当然，自建系统可以实现更多个性化功能。

对 Unbundled WebRTC 而言，构建应用程序的前期成本仍然高于其他选项，类似于直接针对 WebRTC 标准构建。如果想在媒体管道中操作单个视频帧，您需要对视频编码有很好的理解，额外的专业知识和时间/成本是为什么这不是更多应用程序的最佳选择。

与开源媒体服务器类似，选择 Unbundled WebRTC 将在此场景中控制自己的服务器基础架构，无需向 CPaaS 支付任何交易费用，因此 Unbundled WebRTC 应用程序可以提供相对较低的大规模持续成本。

Unbundled WebRTC 的技术难度要低一些，因为与尝试修改 libwebrtc 本身的内部结构相比，WebCodecs API 让您更容易访问视频帧。当然开发人员仍然需要对媒体处理管道和视频编解码器等内容有深入的了解。

Unbundled WebRTC 的最大区别在于它为您提供的强大功能。一方面，如前文提到，CPaaS 为您提供了包含的最高功能，因为其商业 API 中内置了更多功能。例如 CPaaS 可以提供录制功能。但是，如果不喜欢 CPaaS 实现记录的方式，会发生什么？开发者对此无能为力，而 Unbundled WebRTC 的优势在于用户可以根据需要修改媒体处理管道的各个方面，从而获得巨大的潜力来构建想要的功能，但这仍然是一项艰苦的工作。

总结

在基于 WebRTC 的应用开发中，架构选择需要权衡多种因素如需要的功能、拥有的预算、开发人员技术水平等，大多数情况下， CPaaS 或开源媒体服务器选项仍然是最好的选项，因为它们提供了较低的前期成本以及内置功能和可扩展性方面的优势。但是，如果开发者以及有了一个明确目标，清楚知道它的应用的使用者的需求，并且确定通过现有的媒体服务器（开源或 CPaaS）无法实现这些需求，那么选择自建系统或者使用 Unbundled WebRTC 是值得的，因为可以为用户提供更多的自定义功能，从而从激烈的市场竞争中获胜。