不同的 WebRTC 服务器分配方案用于扩展群组通话

在群组通话中，有不同的方式来决定WebRTC 服务器分配。下面是其中一些，以及何时使用什么的建议。

在 WebRTC 群组通话中，媒体服务器扩展是最大的挑战之一。有多种扩展架构被使用，而最有可能的是，你将瞄准一个路由选择，即媒体服务器被用来在会话的各个参与者之间路由媒体流。

随着服务的增长，您将需要处理规模问题：

由于单次会话用户数增加
需要同时满足更多的会话
仅仅是因为需要支持不同地理位置的用户

在所有这些情况下，您将不得不应对以下挑战：您如何决定在哪个服务器上分配新用户？WebRTC群组通话有多种分配方案可供选择，每个都有自己的优势和挑战。下面，我将重点介绍一些此类方案，以帮助您实现最适合您的应用程序的 WebRTC 分配方案。

单一数据中心分配技术

第一件事，WebRTC中的媒体服务器并不能很好地扩展。对于大多数用例，单个服务器将能够支持 200-500 个用户。当支持的人数超过这些数量时，通常是因为它在设计上发送较低的比特率，只支持语音或仅用于处理一种方式的实时流媒体场景。

这可以被看作是一件坏事，但在某些方面，这并不全是坏事–对于云架构来说，最好是保持较小的故障爆炸半径，这样，一台错误的机器最终会影响较少的用户和会议。WebRTC媒体服务器迫使开发者在开发的早期处理扩展问题。

我们今天的首要任务是决定如何处理同一数据中心内不止一个媒体服务器的问题。我们可能会通过我们的信号服务器策略来平衡这些媒体服务器的负载，当用户加入一个会话时，有效地将一个媒体服务器与一个用户或一个媒体流联系起来。下面是做出这一决定的几个备选方案。

服务器封装

这个比较简单，我们先把一个媒体服务器的容量填满，然后再继续填下一个。

优点：

易于实施
维护简单

挑战：

通过设计增加爆炸半径
几乎不使用其他闲置的服务器资源

最少使用

在此技术中，我们寻找具有最多空闲容量的媒体服务器，并将新用户或会话放置在其上。

优点：

自动平衡跨服务器的资源

挑战：

要求分配策略始终了解所有服务器的容量

循环法

我们的“不要想太多”的方法。将下一个用户或会话分配给一个服务器，然后转到服务器列表中的下一个服务器以进行下一次分配。

优点：

易于实施

挑战：

感觉很随意

随机的

然后是随机选择服务器的方法。这听起来很鲁莽，但在许多情况下，它与最少使用或循环法一样有用。

优点：

易于实施

挑战：

感觉真的很随意

区域选择技术

第二部分是确定将一个会话或一个会话中的用户发送到哪个区域。

如果您计划围绕处理整个会话的单个媒体服务器设计您的服务，那么挑战将是在哪里打开一个全新的会如果你打算围绕一个处理整个会话的单一媒体服务器来设计你的服务，那么挑战将是在哪里打开一个全新的会话（无论如何要在同一台服务器上增加更多的用户）。今天，许多服务正在从单一的服务器方法转向更多的分布式架构。

让我们看看一般情况下我们的选择是什么。

首先进入房间

会话中的第一个用户决定在哪个区域和数据中心创建它。如果该数据中心中有多个媒体服务器，那么我们将使用我们的单一数据中心分配技术来确定使用哪一个。

这是最直接的方法，几乎成为许多人开始使用的默认解决方案。

优点：

易于实施

挑战：

小组规模受限于单台机器的大小和规模。
如果第一个加入的用户位于所有其他用户之外，那么所有其他参与者的媒体质量就会下降。
由于需要为潜在的额外用户保留容量，这使得决定服务器的容量和资源的可用性更具挑战性。

注意凡事都有解决办法。但是，这些解决方案使这更难实施，并且可能在其处理的边缘情况下的降低用户体验。

具体应用

您可以选择第一个加入房间的人来做出地理定位决定，或者您可以使用其他方式来做到这一点。在这里，目的是使用您在应用程序中提前知道的内容来做出决定。

例如，如果这是一门课程，老师从印度加入，所有学生都从英国加入，那么将每个人连接到英国的媒体服务器可能会有好处，反之亦然——这取决于您想放在哪里。

一种类似的方法是让会话由主持人确定位置（类似于房间里的第一个）或者是主持人的配置——在帐户创建或会话创建时。

优点：

通常易于实施

挑战：

组大小受单个机器大小和规模的限制
由于需要为潜在的额外用户保留容量，因此决定服务器上资源的容量和可用性更具挑战性
不完全是挑战，但主要是观察——对于某些应用程序，用户群使得创建此类优化毫无意义。示例可以是特定于国家/地区的服务

级联

级联也被视为分布式/网状媒体服务器架构——选择你想要的名称。

通过级联，我们让媒体服务器相互通信以共同处理单个会话。这种方法是现代服务扩展或提高媒体质量的方式——在许多方面，这里的许多其他方案都“融入”了这一方案。以下是一些适用于此的技术：

始终将新用户连接到最近的可用媒体服务器。如果此媒体服务器尚未成为会话的一部分，则通过将其与满足此会话需求的其他媒体服务器啮合，将其添加到会话中
当媒体服务器中的容量耗尽时，通过使用本文开头的单个数据服务器分配中描述的技术之一在同一数据中心水平扩展会话，将新用户添加到会话中
在真正的大规模会议中（考虑10,000个用户或更多），你可能想考虑创建一个媒体服务器的层次结构，其中一些甚至不与终端用户互动，而是作为媒体服务器之间的媒体中转站。

优点：

可以实现每个用户的最高媒体质量

挑战：

难以实施
通常需要更多的服务器资源

发件人决定

这个在我第一次看到时让我很吃惊。在这种方法中，我们将所有传入的流量与传出的流量 “断开”，并将它们中的每一个单独处理，就像一个独立的实时流。

这意味着什么呢？当一个用户加入时，他将总是连接到离他们最近的媒体服务器，以便发送他们的媒体。对于来自其他用户的传入媒体，他将直接在这些用户的媒体服务器上订阅他们的流。

优点：

实施起来相当简单

挑战：

服务器之间没有使用良好的数据中心间链接
“感觉”不对。事实上，没有一个媒体服务器知道用户设备的状态，这一点让我对在这种架构下如何优化带宽估算等问题感到困扰。

关于分配指标的说法

在这一切中，我忽略了一件事，那就是您如何知道一个服务器是 “满 “的。这个决定可以通过多种方式进行，我看到不同的供应商在这里采取不同的方法。这里有两个相互竞争的方面需要处理：

利用率——我们希望我们的服务器得到充分利用。我们付费而不使用的资源是浪费的资源
碎片——如果我们在服务器上塞满更多用户，当新用户加入会话但在托管该会话的媒体服务器上没有空间时，我们可能会遇到问题。所以有时，我们想为这些用户留一些余地，唯一的问题是有多少空间。

以下是一些示例，因此您可以做出明智的决定：

会话数。限制服务器上的会话数，无论每个会话有多少用户。适用于会话大小相当小且可预测的服务。在服务器碎片化的情况下更容易处理资源分配
用户数量。限制单个服务器可以处理的用户数
中央处理器。设置 CPU 阈值。一旦超过该阈值，将媒体服务器标记为已满。您可以在此处使用两个阈值 – 一个用于不允许服务器上的新会话，一个用于不允许服务器上的任何更多用户
网络。以类似于我们上面为 CPU 所做的方式设置网络阈值

有时，我们会使用多个指标来做出分配决策。