在架构尺度上的部分技术经验与积累分享

分布式无级联的RTC架构

首先，为大家介绍分布式无级联的RTC架构。对于RTC的架构，在WebRTC中的定义是一个Peer到Peer的通信。其中并没有直接给出一个明确的标准来告诉你如何去做信令服务、媒体服务等。那么，一个最简单的分布式媒体服务是什么样的呢？

一般的基本模式是，A用户和B用户首先通过一个信令服务，信令服务为A和B分别分配媒体服务，然后帮助它们之间建立一个联系。对于这种简单分布式但并不支持级联的RTC架构，它的优点是每一个媒体服务本身都不需要和其它的媒体服务建立连接，并且不会进行网络优化。但是，它最大的问题就是当我们给A客户端分配一个媒体服务后，B客户端也是需要连接同一媒体服务的。假如我们先给A客户端就近分配一个媒体服务，此时A客户端和媒体服务之间连接的质量是非常好的，但是如果A客户端和B客户端不在同一地区，B客户端也许距离这个媒体服务非常远，中间的网络就可能会非常不稳定，此时A客户端和B客户端通过这个媒体服务建立的通信就是存在问题的。因此，这种模式只适用小规模范围的通信，如城域或者是公司内部的私网。

下面将介绍有级联的RTC架构是如何实现的。

分布式有级联的RTC架构

有级联的RTC架构则要求A客户端和B客户端分别找到不同的媒体服务来进行通信，媒体服务之间也要做级联的通信，这样就能解决上述无级联RTC架构存在的问题。如上图所示，我们可以先为左边的Client找到一个对它来讲质量最好的媒体服务，然后再为右边的Client找到一个质量最好的媒体服务，两个媒体服务之间还要再通过一些网络优化的手段来保证它们的通信质量。上图系统中的蓝色部分叫做Signal Server，Client可以通过Signal Server和Media Server进行SDP交换。

分布式有级联的RTC架构可以实现链路的优化，但同时我们也不难发现，Signal Server和Media Server之间存在的耦合问题。这是因为所有的Media Server都需要在Signal Server中进行注册登记以进行管理，并且Signal Server还要和Media Server之间保持一个健康状态的检查，比如做一个TCP的长连接、做一个心跳包。此外，Signal Server不仅需要知道Media Server里有哪些用户正在使用流媒体通信，还需要知道它的用户状态。一方面，对于紧的耦合，当部署一个新的媒体服务时，就会需要很复杂的工程实施，因为在很多地方均要Update配置。另一方面，如果在通话过程中发现媒体服务或者信令服务之间存在一些异常状态，则会导致整个通话断掉，因为他们两个之间的耦合非常紧密。到目前为止，大家能够在市面上看到的开源解决方案基本上都是按这个模式去设计的。在电信运营商领域，Signal Server最典型的就是用SIP协议来实现的，包括我们之前做飞信也是用的一个SIP的简化协议SIPC。还有一种方案就是，可以搭一个XMPP的服务器，用它来实现Presence管理，所谓的Presence管理与SIP一样，就是用一条IM通道来做Signal Server。

在这一部分，我们分析了分布式有级联RTC架构的优点和缺点。接下来，我们一起来看看融云对分布式RTC网络的思考。

四、融云对分布式RTC网络的思考

如上所述，由于信令服务器和媒体服务是有耦合的，我们上线或下线任何一个媒体服务器均要在Signal Server里Update相关状态和配置。因此，我们的第一个诉求就是要设计一种将信令服务和媒体服务解耦开来的架构；第二个诉求就是要使得我们的信令服务和媒体服务之间能不管对方的状态如何，让它们不需要状态同步；第三个诉求就是让每一个媒体中心都是独立的；第四个诉求就是要降低新建与维护媒体中心的成本，因为通信云服务有数以千计或万计的机器和节点要管理；最后一个诉求就是要全面复用融云即时通讯通道。

上图是融云的分布式RTC网络架构，我们将Signal Server换成了融云的IM基础设施。简单来说，IM是用来发消息的，它实际上就是把一段数据通过一个长连接的、永远在线的通道从一端推送到另外一端，而且该服务要保证这条通道永远是可用的，同时发的每一个信令、指令都不能丢失，并且要以最快的速度到达。总的来说，这就是Signal Server的使命。