Mozilla分享：用Hubs和Hubs Cloud开展主持VR会议活动
将Hubs用于不同规模活动的注意事项
（映维网 2020年06月01日）虚拟活动都是独一无二，对用户容纳数量有着不同的需求。在这篇博文中，Mozilla讨论了将并发性视为虚拟活动一部分的不同方法，Mozilla Hubs和Hubs Cloud用于支持用户的当前功能，以及将Hubs用于不同规模活动的注意事项。如果你有考虑在会议中使用Hubs，或者只是单纯对平台的工作方式感兴趣，你可以继续阅读本文。
1. 虚拟活动的并发筹划
当我们进行传统的活动规划时，我们都需要考虑一个重要的限制：可用空间的物理量。当我们将线下活动搬到线上，并因而消除了这一考量后，我们很难理解给定平台可能存在的限制。
利用在线协作软件，一系列的因素将发挥作用。应用程序可能存在基于活动的限制，基于房间的限制或基于平台的限制，并可能会影响用户容量的规划执行。Hubs存在“基于房间”和“基于平台”的用户限制，而所述限制取决于你是不是在hubs.mozilla.com创建房间，或者是否使用Hubs Cloud。在规划参与活动的人数时，重要的是要考虑用户的分布和活动内容。这与实际的活动规划相关：尽管一个场馆可以容纳数千人，但你同时需要考虑不同的房间可以容纳多少人。
在思考如何使用Hubs或Hubs Cloud举行活动时，你可以考虑两种不同的选项：一种是从你要支持的人数开始，然后将用户分到多个房间；另一种是从活动规模开始，然后计算出需要多少个房间。下面我们将介绍有关Hubs和Hubs Cloud的空间与系统功能考量。
2. Hubs房间容量
对于Hubs，问题变得更为复杂，因为你可以通过集Hubs Cloud控制房间容量和“场馆”容量。Hubs支持单个房间中最多容纳50名用户。但需要注意的是，这是服务器对单个房间可容纳人数的限制，不能保证每个人都能获得适宜的体验。一般来说，通过智能手机或VR一体机接入的用户会先于使用游戏PC和有线网络的用户看到性能下降。尽管Hubs在共享来自web的各种内容方面提供了居大的灵活性，但要支持分享大型文件或流式传输内容，用户生成内容通常会带来大量的负载。所述性能问题通常表现为音频体验减损或帧率下降。
对于虚拟活动，与会者所采用的接入设备十分重要，家庭网络配置同样会产生影响。影响Hubs性能的因素包括：
- 在一个房间里的人数
- 房间中的内容量
- 房间中的内容类型
所以，Mozilla将默认房间容量设置为服务器总容量的一半左右，因为用户可能进入一个包含50名虚拟化身的房间。服务器容量存在上限，因为每位接入房间的用户都会打开一个服务器通道并发送网络数据（特别是语音数据），而且当用户数较高时，服务器运行的软件必须付出大量的努力才能处理相关数据，并将其实时发回其他客户端。尽管增加可用服务器的大小和数量有助于系统范围内的并发性，但考虑到接入客户端之间的底层会话描述协议（SDP）协商是一个单线程进程，所以单个房间容量不会增加超过50个以上。
Room Lobby（房间大厅）页面显示了会议室中人员和对象的列表，并允许用户在进入之前查看和听到正在发生的一切。
Hubs同时具有房间“大厅”的概念。在这里，访客可以看到房间里发生的一切，听到正在讨论的内容，并通过聊天发送信息，但他们并不以虚拟化身的形式出现。尽管Hubs中的大厅系统最初是设计成为在用户进入房间之前提供相关的情景信息，但现在大厅可以用作大型活动的轻量级预览体验，类似于你在Twitch等二维流式媒体平台中所经历的情况。Mozilla最近进行了一个实验性的改动，测试了多达90名客户在大厅查看共有10人的房间。对于适合被动式浏览体验的活动，这种方法可以容纳比房间更多的人数，因为大厅用户不向服务器发送数据，只接收数据，这对房间负荷的影响较小。
3. 扩展Hubs Cloud
尽管空间限制是虚拟活动的一个考虑因素，但系统范围的并发性成为了另一个问题。与实体场馆一样，虚拟平台同样对支持用户总数设置上限。这通常是应用程序后端运行的服务器功能和硬件的结果。对于Hubs Cloud，这主要取决于EC2服务器的大小，以及你是使用单个服务器还是多个服务器。一个小型的t3.micro服务器（能够运行Hubs Cloud的最小服务器）能够处理比c5.24xlarge更小的同时用户负载。在计算用于Hubs Cloud部署的服务器实例大小时，这是需要考虑的一个重要因素。
对于在Hubs Cloud运行的大型活动，确切的配置将取决于将要运行的会话类型，每个Hubs房间中有多少用户，以及用户是作为大厅的观众成员还是要具现在空间之中。Mozilla最近发布了一份指南，说明了部署在AWS的不同实例大小是如何转化为并发用户总数（CCU）。
4. 活动筹划策略
要将Hubs整合到虚拟活动中，不同的活动有着不同的需求。对于每一个活动，我们建议你要掌握相关的管理工具和最佳实践，但Mozilla根据实验和反馈提供了针对不同会议和组织的配置与策略示例。
对于最多25人的组别（如小型会议或大型活动的分组会议）：一般而言，一个hubs.mozilla.com中的房间已经足够。如果所有用户都是通过智能手机或VR一体机接入的虚拟化身，你可以尝试将群组分成两个或三个房间，并将它们链接在一起。
对于最多50人用户的组别（如网络活动和小组发言）：一个hubs.mozilla.com中的房间，其中演讲者以虚拟化身出现，而大约一半的与会人士是从大厅浏览体验，或两个hubs.mozilla.com中的房间，其中一个房间用于小组发言，另一个房间是供观众使用
对于需要向50人以上用户广播的活动（如大会主题演讲）：你可能需要设置一个允许你同时将视频广播到多个房间的流式传输服务，并为与会者提供一个中心位置以便他们发现彼此。这可以是一个单独的“大厅”房间，其中包含指向其他浏览区域的链接，或者是一个包含链接或嵌入不同房间的简单网页。尽管能够在hubs.mozilla.com以这种方式主持活动，但在托管的Mozilla Hubs架构管理属于同一活动的两个以上房间可能很难协调和创建统一的体验。对于需要两个或三个以上房间的活动，我们建议部署Hubs Cloud实例。
在Hubs中观看IEEE VR的主题演讲
对于Hubs Cloud，你可以更为精细地控制房间和活动容量，因为你不是简单地控制单个房间集的权限和设置，而是托管自己版本的hubs.mozilla.com。所以，你不仅可以设置平台范围的权限和配置，同时可以添加自己的URL、品牌、帐户、虚拟化身和场景等等。
5. 未来的扩展，以及通过Hubs和Hubs Cloud实现的并发机制
不同小组配置Hubs的不同方式给我们留下了深刻地印象。Hubs最初是为具有封闭私人会议室的紧密镜像平台设计，但随着越来越多的人寻求能够允许物理相隔的彼此能够联结交流的虚拟解决方案，Mozilla一直在寻找全新的方法来扩展平台，从而更好地支持更多的受众。这意味着需要考虑数个重要问题：
- 要允许一大群人虚拟地共聚一堂，什么才是正确的设计呢？在考虑如何最好地支持更大的社区时，你需要考量特定的技术和社会方面。我们可以尝试模拟物理环境的方法，只需专注于增加出现在同一个房间里的虚拟化身的数量，或者可以进行更多的实验，测试技术在重塑我们的社交和聚集方式时所呈现出的独特可供性。
- 对于虚拟会议平台所提供的功能，我们的假设存在什么折衷之处，我们又将如何在规模更大的、可能不太可信的组别中保持隐私和安全原则呢？在我们的日常生活中，我们发现我们的行为深受周围环境和社区的影响。当我们期待软件解决方案来支持其中一些用例时，我们必须考虑这些安全和隐私结构是如何继续成为平台的核心考量因素。
当然，关于web技术发展方式的潜在架构问题同样存在，并影响着我们如何在平台增长时探索和响应用户社区。你可以通过Mozilla的社区Discord服务器，GitHub或电子邮件就这一领域进行讨论、提出问题和作出贡献。
