WebRTC 除了一对一通信外，最常见的使用场景便是多人视频会议。不要只考虑传统的会议室场景，有很多场景都超出了会议室的范畴，比如网上学习、客服支持、或者实时广播。在每个场景中，最重要的能力便是如何分发多路音视频流。
其实根据不同的需求，存在几种架构；这些架构基本都围绕两个维度展开，即中心化 vs 点对点连接（P2P）；混流 vs 路由中继。我会在这里介绍几种最流行的架构。
Mesh
Mesh 是最简单的架构。它在新的 WebRTC 服务供应商中很受欢迎，因为它（基本）不需要任何基础设施。该架构对于每个发送者和它所有可能的接收者而言，都会创建连接。尽管这种架构看起来很低效，但实践证明它非常有效；并且由于每个接收者都具备开箱即用的带宽自适应功能，可以将延迟降至最低。
唯一的问题在于，这种架构需要大量的上行链路带宽才能同时推流给所有接收者，并且目前的浏览器实现需要消耗大量的 CPU 资源才能对视频并行编码。
混流
传统的多人会议架构采用的是混流模式，并且这种架构已经使用了很多年了。这是因为它需要的客户端能力最少。这种架构使用中心节点与每个参与者保持一对一连接；中心节点接收每个发送方的视频流并将它们混合成单个视频流，然后发送给每个参与者。在视频会议领域，这些中心节点被称为 MCU（Multipoint Control Unit，多端控制器）。
混流架构的兼容性最好，可以兼容很多老旧设备；它也支持带宽自适应模式，因为混流单元可以为每个接收者分别生成不同质量的视频流。混流架构的另一个优点是它能利用硬件解码，许多 WebRTC 客户端的芯片都具有解码单个视频流的能力。
混流架构的主要问题是 MCU 的架构成本。此外，混流既需要解码还需重新编码，因此会增加延迟以及降低画质。同时混流也降低了客户端 UI 的灵活性（尽管存在一些解决方案）。
路由中继
路由中继架构是 H.264 SVC 普及后流行起来的，并且已经被广泛应用于新的没有历史包袱的 WebRTC 平台。该架构使用中心节点接收每个发送方的视频流，并将其转发给其他参与者。中心节点对数据包仅仅进行检查和转发，而不进行解码和再编码。
路由中继提供了一种廉价的且可扩展的多人会议架构；与混流架构相比，它具有较低的延迟，并且没有画质损失。但另一方面，大部分从业者往往缺乏搭建这种架构的经验，并且对于不同的接收方适配起来较为棘手。这需要发送方支持生成一个流的多个版本（比如 Simulcast 或者 VP8），路由器会根据接收方的客户端能力选择性地转发对应的流。
该使用哪种架构？
不幸的是，这并不是一个简单的问题。一些服务供应商为了满足不同客户的需求，提供了上述所有架构的支持。不过这里还是有一些通用的选择方式以供参考。
如果你提供的是纯音频服务，或者需要兼容老旧设备，那么混流架构是不错的选择。此外，假如你的成本开销并不是问题；并且参与者们各自的连接性非常不同，也可以使用混流。
如果你的服务的使用者们有着非常好的网络，他们的设备配置也很给力（比如公司内部服务），并且参与者数量有限，那么 Mesh 架构是不错的选择。
如果你要部署大规模服务，那么就选择路由中继架构。总的来说，路由中继架构既能较好地利用客户端算力，同时还能保持良好的扩展性和灵活性。
