WebRTC常见的架构方式有哪些？如何兼容EasyRTC的应用场景？

　　我们这里常说的RTC可以理解为WebRTC技术，因为WebRTC技术是目前使用最广泛的即时通信技术，虽然在早期我们提到WebRTC、提到视频通话就会想到P2P的方式，但实际的视频通话方式背后的逻辑有很多种，p2p并不能解决所有的网络通信问题，视频通话会采用多种架构相结合的方式，保障用户视频通话的接通率。
　　WebRTC虽然是一项主要使用p2p的实时通讯技术，本应该是无中心化节点的，但是在一些大型多人通讯场景，如果都使用端对端直连，端上会遇到很多带宽和性能的问题，所以就有了下图的三种架构。
　　一、Mesh架构
　　即：每个端都与其它端互连。以上图最左侧为例，5个浏览器，二二建立p2p连接，每个浏览器与其它4个建立连接，总共需要10个连接。如果每条连接占用1M带宽，则每个端上行需要4M，下行带宽也要4M，总共带宽消耗20M。而且除了带宽问题，每个浏览器上还要有音视频＂编码/解码＂，CPU使用率也是问题，一般这种架构只能支持4-6人左右，不过优点也很明显，没有中心节点，实现很简单。二、MCU (MultiPoint Control Unit)
　　这是一种传统的中心化架构(上图中间部分)，每个浏览器仅与中心的MCU服务器连接，MCU服务器负责所有的视频编码、转码、解码、混合等复杂逻辑，每个浏览器只要1个连接，整个应用仅消耗5个连接，带宽占用(包括上行、下行）共10M，浏览器端的压力要小很多，可以支持更多的人同时音视频通讯，比较适合多人视频会议。但是MCU服务器的压力较大，需要较高的配置。
　　三、SFU(Selective Forwarding Unit)
　　上图右侧部分，虽然看起来和MCU区别不大，但其实在思路上大有不同，仍然有中心节点服务器，但是中心节点只负责转发，不做太重的处理，所以服务器的压力会低很多，配置也不像MCU要求那么高。但是每个端需要建立一个连接用于上传自己的视频，同时还要有N-1个连接用于下载其它参与方的视频信息。所以总连接数为5*5，消耗的带宽也是最大的，如果每个连接1M带宽，总共需要25M带宽，它的典型场景是1对N的视频互动。
　　目前，随着5G技术的推广，可以预见带宽越来越不是问题，所以SFU在未来，可能会更有优势。
　　建议：如果规模不大(5人以下) Mesh框架就够用了，毕竟实现简单；如果50人以下，且带宽有限，选择MCU比较适合；如果规模更大，且带宽良好，SFU相对更适合。
　　在TSINGSEE青犀视频产品体系里，我们也在不断对MCU、SFU的使用场景进行研究和拓展，在许多的应急指挥场景中，我们不仅需要即时的通信，而且需要事后的回溯，所以MCU的录像功能必不可少。
　　当我们在人数众多的集群调度和大班课教学时，我们又需要对感兴趣的视频源选择接听，而对大部分的非相关人员视频屏蔽，在多方连线场景中，我们需要选择性了解现场情况，放大单路视频，所以这些情况，MCU和SFU的选择不是绝对的，而将会是相互结合的。
　　在WebRTC方面，TSINGSEE青犀视频团队已经逐步拓展了EasyRTC视频会议与EasyRTS应急指挥系统，EasyRTC具有MCU和SFU两个版本，EasyRTS则采用SFU接入与后端视频处理的方式，完美地解决了视频即时通信的各种应用场景需求。