融云媒体服务中心详解

对于Media Server，我们可以将其理解为在一台物理硬件的服务器上面部署了一套服务。但事实上，对于大规模的云厂商来讲，一般是在某一个地方建立一个数据中心，在里面会投入很多的机器来运转。一个媒体服务中心的架构设计往往非常简单，对于左边的HTTP请求要做Load Balance，然后把它分布在其他各种平台的Media Server上，并且在中间还加了一个反向代理。

在数据中心里虽然有很多的媒体服务，但如果我们不做任何策略的话，就可能会出现以下情况：当三个人在一个房间聊天时，可能会被分配到了两台Media Server上，即在数据中心内还需要Media Server之间的通信，这样是十分影响性能和质量的。那么，我们该如何解决这个问题呢？

如前所述，调用接口时要传Token、Room ID/Channel ID、SDP。因此，我们可以通过算法将Room ID相同的用户归并到同一台Media Server上，只要这个房间内的订阅人数没有超过该Media Server的物理上限，则可以保证该房间里用户全在一个Media Server上进行通信，此时的性能是非常好的。除了上述情况外，还有另外一个问题，例如当前进行会议的房间的人数特别多，而且用户数超过了Media Server所能承载的业务量。对于这种情况，我们就需要进行打散，也就是将用户分散在不同的Media Server上。

接下来，总结一下我们在媒体服务方面除了上述内容之外还做了哪些事情。在进行HTTP接口调用时，HTTP接口支持QUIC，可减少交互握手的次数来优化性能。另外，我们还做了媒体服务的端口收敛以及尽可能的去实现单中心间媒体服务的0调用。

接下来，针对前面提出的问题来总结一下结果：

1）我们按照新设计的架构模型实现了信令服务和媒体服务的解耦，当上线一个新的媒体服务时，无需在信令服务里添加任何注册配置，唯一要做的就是在Smart DNS里为这个媒体服务增加一条记录；

2）信令和媒体服务之间不存在任何调用关系，所以也就不存在任何数据和状态的同步；

3）媒体中心间也不需要状态同步；

4）我门已经把媒体服务管理和添加的成本降到非常低的水平；

5）直接复用融云的通讯通道，在融云RTC的SDK里面已经内涵了一个精简版的IM协议栈。