去中心化的 RTC 通信平台架构设计

 

去中心化的RTC网络无需关心其它媒体服务状态，可快速增加地域媒体服务节点部署，与信令服务无耦合。本文来自融云联合创始人，CTO杨攀在LiveVideoStackCon 2019上海的演讲内容，由LiveVideoStack整理而成。在8月23-24日的LiveVideoStackCon2019北京大会上，杨攀还将分享《可扩展的公有云媒体服务设计解析》。

文 / 杨攀

整理 / LiveVideoStack

大家好，我叫杨攀，从开始工作至今有17年了，一直在从事电信、通信、社交以及开放平台领域相关的工作。大约在2004年左右，MSN刚开始进入中国并落地，当时我们的团队在上海将一些MSN的美国业务在本地做了电信运营商的落地。后续，我也参与到了整个飞信团队的建设之中，目前融云的研发团队就是之前中国移动飞信的核心研发团队，整个团队从研发到产品再到运营在一起工作了大约12年之久。

一、背景介绍

 

融云做的是通信云服务，可以说是基于IP的虚拟通信运营商，我们希望未来所有在Internet上的IP流量，包括消息、语音片段、视频片段、红包、表情、音频通话和视频通话等等，所有的这些通信都能承载在我们自己建设的全球通信网上，而这同样也是我们的使命。因此，目前我们在全球大规模地铺设了自己的网络，包括在北京、新加坡和北美建设的三个大数据中心，在全球有数百个接入节点和数千个加速节点。

本次要与大家分享的主要内容就是在架构尺度上的部分技术经验与积累。

二、分布式无级联的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交换。