在融合通讯中，我们经常听到如下一些术语：MCU服务，SFU架构，MESH架构，星形网络等等。很多客户听到这些数据都是一脸雾水，经常说我们就是要一个可以把多种设备拉到同一个会议中，怎么搞这么复杂。今天我们就来聊聊这些术语都从哪来的，分别都应用在什么地方，我们anyRTC又是如何做的。
一.Mesh 架构
由于WebRTC的普及，人们对于音视频通讯已不再像以前那么陌生，WebRTC本身是一个P2P的通讯模型，P2P就是点对点通讯，借助STUN/TURN服务可以实现任意网络下的通讯。对于P2P的通讯模型最常用的架构就是MESH：即多个终端之间两两相互连接，形成一个类网状结构。
如图所示B1、B2、B3、B4 四个终端进行多对多通信，当 B1 想要共享媒体（比如音频、视频）时，它需要分别向 B2、B3 和 B4 发送数据。同样的道理，B2 想要共享媒体，就需要分别向 B1、B3 和 B4发送数据，依次类推。这种方案对于终端少的情况比较友好，但是随着终端的数量增加，对各终端的带宽要求就会很高。
二.SFU架构
可以看出MESH架构并不太适合大规模的组会的场景，而SFU架构就应运而生。
SFU（Selective Forwarding Unit）架构：是由一个服务器和多个终端组成，但与 MESH相比，SFU在服务端对一路流进行广播，收到某个终端共享的音视频流后，就直接将该音视频流转发给房间内的其他终端，比如B1发布一路流到SFU，SFU就会把这路流分发给B2、B3 和 B4。同时SFU也不做音视频转码，对服务器的配置要求不高，实时性也很好，灵活度非常高，非常适合大规模的分发网络，这也就让SFU架构轻松成为目前市面上应用最普遍的架构。
三.MCU架构
这时候就有人会问，SFU架构已经看似完美了，其他架构就不需要了吧。答案非也，下面我们就介绍视频会议的鼻祖架构：MCU架构。
MCU（Multipoint Conferencing Unit）架构：由一个服务器和多个终端组成一个星形结构，与SFU不同，MCU是会做编解码和视频合成的。B1、B2、B3和B4将自己要共享的音视频流发送给服务器，服务器端会将在同一个房间中的所有终端的音视频流进行解码混屏，最终生成一个混合后的音视频流再发给各个终端，这样不同的终端就可以看到 / 听到其他终端的音视频了。由于增加了编解码，这会对服务器的配置要求非常高，所以MCU架构不太适合大规模分发，但这并不是说这个架构不重要。
MCU架构由于起步早，技术非常成熟，在硬件视频会议中应用非常广泛。同时MCU通过解码、再编码可以规避不同编解码设备的差异化，满足更多客户的集成和接入需求，提升用户体验和产品竞争力。还有就是接入MCU的终端都是一路上传一路接收，对于网络要求就不会那么高，用户体验相对较好。
四.总结
通过上面的介绍，我们了解了关于流媒体服务的这么多架构，anyRTC融合通讯系统，可以根据用户的实际需求交付不同的解决方案，这样才能更好的贴合实际的需求。
