作者：Tsahi Levent-Levi（原文链接）
翻译：刘通
原标题：How Many Users Can Fit in a WebRTC Call?
前文链接：一通WebRTC通话中能容下多少用户（一），一通WebRTC通话中能容下多少用户（二）
级联单个会话
级联是将一台媒体服务器连接到另一台媒体服务器的过程。我用下图展示了我的意思：
我们有一个4路群组视频通话，分布在3个不同的媒体服务器上。服务器根据需要在它们之间路由媒体，以及连接它。那么你为什么需要做这些呢？
#1—地理分布
当你运行的服务范围覆盖全球，并且将SFU作为其一部分时，有一个问题会突然出现，就是要进行新的会话你将为其分配哪个SFU？在哪个数据中心里？由于我们希望让媒体服务器尽可能靠近用户，因此我们要么知道会话的预先信息（pre-knowledge）并知道将其分配到哪里，要么通过合理的方式来决定，就比如地理位置—我们需要选择离创建会议的用户最近的数据中心。
加入我们现在有4个人正在进行通话。其中3个人来自纽约，而第四个人身处法国。那么如果这个法国人是第一个加入会话的人会发生什么？
如果服务器被设在法国。这4个人中有3个人都离媒体服务器很远。并不是最好的方法。
一种解决方案是通过将会议分散到最接近每个参与者的服务器上进行：
我们使用更多的服务器资源来进行此会话，但这样我们会对媒体路由有更多的控制权，所以我们可以更好地对它们进行优化。这会改善会话的媒体质量。
#2—碎片化分配
假设我们可以在单个媒体服务器上连接最多100个参与者。此外，每个单独的媒体会话最多可容纳10个人。理想情况下，我们不希望为每个媒体服务器分配超过10个会话。
但是我告诉你，平局会议规模是两个人。它可以让我们看到这种类型的分配：
这会导致服务器资源的大量浪费。我们又该如何解决这个问题呢？
1. 通过让人们提前达到最大会议人数限制。这个方法你一定不想用。
2. 冒个险，假设如果你已经分配了50%的服务器空间，那么剩下的容量你可以给以存在的会议预留下来以备它们增加人数。你仍然会浪费一些资源，但是程度较低。但是会出现一种边缘情况，就是你可能会因为服务器资源的问题而无法达到会议最大人数。
3. 跨媒体服务器迁移会话以对服务器进行“碎片整理”。它实际上跟听上去一样困难，而且有可能会影响用户。
4. 级联会话。允许它们进行跨机器增长人数。
那么级联的最后一个会话该怎么办？你可以通过预留部分媒体服务器的资源来将现有会话级联到其他媒体服务器来实现此目的。
#3—更大规模的会议
如果你想要创建一个比单个媒体服务器可以处理的更大规模的会议，那么你唯一的选择就是级联。
如果你的媒体服务器可以容纳100名参与者，但是你希望会议中有5000名参与者，那么你需要能够将它们级联起来。这并不是一件容易的事情，这就解释了为什么没有很多这样的解决方案可供使用，但这是完全由可能的。
请注意，在这样的大型会议上，媒体流不会是双向的。发送媒体的参与者较少，接收媒体的参与者更多。对于纯粹的广播场景，你可以参考我在Red5 Pro上写的客座文章。
温习一下
我在这篇文章中提到了很多的领域。在尝试确定有多少用户能够加入到你的WebRTC通话中时，你应该进行以下操作：
1. 无论你考虑多大规模的会议，都可以使用WebRTC进行支持
1）这将是一个成本问题，并将其与你的商业模式想匹配，从而决定是选择还是打破该模式
2）会议规模越大，正确完成它就会越复杂，并且你需要考虑更多的限制及假设
2. 分析你需要支持的复杂性
1）统计每个设备和媒体服务器的传入和传出流
2）决定每个流的视频质量（分辨率和比特率）
3. 决定你要使用的媒体服务器
1）选择一种机器类型以运行媒体服务器
2）在溢出之前找到你需要的尺寸大小
3）判断增长率是否与服务器资源成线性关系
4）决定是根据带宽，CPU还是流的数量来判断是否溢出
4. 如何进行级联
1）提供更好的地理位置支持
2）协助在云基础架构上的资源碎片化
3）或者在会议规模超出单个媒体服务器的承受范围内的情况下，用这种方法实现继续扩大会议人数
