去中心化的 RTC 网络无需关心其它媒体服务状态，可快速增加地域媒体服务节点部署，与信令服务无耦合。本文来自融云联合创始人，CTO 杨攀在 LiveVideoStackCon 2019 上海的演讲内容，由 LiveVideoStack 整理而成。在 8 月 23-24 日的 LiveVideoStackCon 2019 北京大会上，杨攀还将分享《可扩展的公有云媒体服务设计解析》。
文 / 杨攀
整理 / 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 交换。
分布式有级联的 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 的使命。
接下来，我将为大家详细讲解融云的 RTC 建连过程。
如上图所示包含有五个角色，分别是 Client A、Client A 对应的 Media Server、IM Server、Client B 对应的 Media Server、Client B。Client A 是通信的发起方，IM Server 就是我们的 Signal Server。在这个架构里面，我们引入 Pub/Sub 模型来实现解耦，下面将分两部分讲解。
Pub过程：Client A 会利用 Smart DNS 直接找到自己对应的 Media Server，然后调用该Media Server上开放的一个HTTP接口，调用该接口是为了传递传 Token、Room ID/Channel ID，以及交换 SDP，这个在后面会详细解释。调用完之后，Media Server会返回该 Media Server 的 IP 地址和 Client A 在 Media Server 上注册后所分配的 Resource ID，Resource ID 是 Client A 在 Media Server 上唯一的身份标识。Client A 接收到 Media Server 返回的信息后就可以直接与 Media Server 建立 RTC 连接，接着就可以开始利用信令通道了。之后 IM Server 要将 Client A 呼叫 Client B 的指令 Push 给 Client B，并且会将 Media Server 返回给 Client A 的信息直接 Send 给 Client B。此时，Pub 过程就完成了。
Sub过程：与前面相同，Client B 也要通过 Smart DNS 找到一个相对来说质量最好的 Media Server，然后调用其另外一个接口将刚才传过来的信息告诉这个 Media Server。当 Client B 对应的 Media Server 拿到了 Client A 对应的 Media Server 的信息后，由 Resource ID 就可以知道要将 Client A 和 Client B 之间建立连接，在内部建立关联后返回一个 ACK，说明已经调用成功。一旦 Client A 和 Client B 建立 RTC 连接成功后，Client A 对应的 Media Server 和 Client B 对应的 Media Server 就建立起了级联。
当 RTC 的通道连接建立成功后，去中心化完成，此时我们就完成了 Media Server和Signal Server 之间的解耦。
总结一下，融云的 RTC 建连过程采用了极简的接口设计。如上述的时序图，有几次 HTTP 调用实际上全都是通过一个 HTTP 接口来实现的，而这一个 HTTP 接口通过传递不同的参数就非常简单的实现了发布/取消发布流，SFU 和 MCU 的订阅/取消订阅。
下面将详细讲解一下在前面提到的 Media Server。
对于 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 协议栈。
下面将介绍一下融云的 RTC 全球网络。
五、融云 RTC 全球网络
融云是一家覆盖全球的云通信服务商，目前已经建立了全球的通信网络，遍布中国、东南亚、中东等地。只要客户需要，我们的工程团队就可以去当地建设数据中心，将整个的通信网络基础设施铺到那里。目前，我们已经将全新建设一个 Media Server 的成本降到非常低的程度，以至于只仅添加一条 DNS 记录就可以搞定，这也是我们整个后端的研发团队引以自豪的地方。
那么，我们在全球网络上做了哪些工作呢？首先，我们引入了一个新的概念 HTTPDNS，融云每天有几千万的活跃用户，因此连接访问的次数可能会是特别大数量级的。根据我们手里掌握数据的分析结果来看，DNS 是影响连通率指标的罪魁祸首，尤其在国内复杂的网络环境下。因此，需要引入 HTTPDNS 来进一步提高通信质量。其次，媒体中心间的物理链路优化。级联的一种简单方式就是物理连接，现在几乎所有的厂商都会花钱进行物理链路的优化。此外，对于跨厂商或者在网络比较复杂地区可能要建设一些物理服务器，那我们就要解决逻辑链路的优化，在这里面通常是采用一些转发的策略，其中的基础逻辑就是收集数据、实时分析数据然后做出决策去实现调度。
接下来，再补充介绍一些其它的技术点。
1）RTC 鉴权
在最初的实时通信模型架构中，根据 Room ID/Channel ID 直接加入即可订阅它的流，并且可以看到它里面的内容，这就导致了存在安全的隐患。那么如何解决这个问题呢？解决方法就是在前面所讲到的模型中调 HTTP 接口时要传一个 Token。具体来讲，当两个客户端建立连接时，在同步调用 Signal Server 的过程中会传一个 Token 回来，Token 是信令服务调用后台的密钥服务所分发的一个令牌。当拿着这个令牌去连 Client 对应的 Media Server 时，Media Server 会 Check 令牌隐含的信息是否与要建立连接 Client 的 Room ID/Channel ID 相匹配。如果不匹配，则没有权限查看里面的内容。验证是否匹配的基本逻辑是上图中的 Key Server 和 Media Server 共享一套密钥算法和密钥，它们都是部署在数据中心里的，里面的协议也都是我们内部来实现的。此外，在这里还有一个算法来验证 Token 是否有二次的 I/O 请求和调用，这是一个常见的大规模高并发系统架构设计的基础原理，即尽量在某些场合巧妙的通过一些算法和验证减少 I/O 的请求和调用。
2）融云 IM 加速网络
接下来，为大家介绍一下融云 IM 的加速网络。从上图中可以看出，我们的加速网络模型是一个混合云，包含国内私有部署、国外私有部署，目前已经实现了国内外的互通。需要跟大家介绍的是，国内和国外的网络之间访问的质量是受到影响的，因此对于国内外的互通还需要进行一些专门的优化。这些优化说白了就是砸钱来解决问题，因此我们在国内有自己的加速节点，在国外也有自己的加速节点，并且还可以在国内外实现私有部署，包括把信令服务私有部署在用户那里。举例说明，目前我们有一个客户是一家国内顶尖的IT企业，它的员工大概有十几万人，遍布在全球的各个城市和大区，他们希望通过我们帮助建立企业内部十几万人之间的 IM 与 RTC 沟通。由于全球各个地区网络情况复杂，他们自己的团队无法保证网络质量的问题，对于链路情况复杂和距离较远的情况也无法解决。最终，他们采用的是融云的解决方案，通过在北京的数据中心私有部署了一套 IM 的基础设施服务，然后租用了融云的全球加速网络，采用的就是经典的混合云模式。
3）融云 RTC SDK
融云 RTC SDK 就是我们将所有东西解耦之后所得到的另一个副产品。实际上，音视频通信云服务领域已经发展多年，在这个领域有一个很有意思的现象就是很多厂商把能力和功能耦合在一起。这就会导致如果我想做一个场景，那么就需要添加大量新的接口，而在大量新加的代码里隐含着一个业务的场景和逻辑。前面讲过，我们将 RTC 建连过程转变成了 Pub/Sub 模型，使得系统变得极其简单，如同几块乐高积木一样。因此，无论我们想要引入何种逻辑，比如两人通话、多人会议、千人的会议、小班课、直播连麦等等。这些场景都可以通过简单的几个模块直接搭建出来，而我们要做的就是在上层将这一段业务场景或逻辑封装成一个 SDK，目前已有的 SDK包括Call Kit、Call Lib 等等，其中 Kit 指的就是 UI Competent。举例说明，微信音视频电话的场景，我们的 SDK 包含了这个场景的 UI 组件和通信组件，用户想要实现这个场景直接引用 SDK 即可，不用再做任何二次开发的工作。类似地，会议会控、直播的 UI 组件和通信组件等等都会封装成 SDK。并且，我们会随着用户的需求通过这些积木实现不同的业务场景。
接下来总结一下融云 RTC SDK 的特点：1）我们真正做到了 SDK 组件自底向上地单向依赖，并且 SDK 组件没有任何交叉调用；2）架构中间的可替换的信令层 Signal Server 与 Media Server 没有任何关系，这意味着用户可以使用我们的 Media Server，使用自己的 Signal Server，这个架构完全实现了解耦；3）所有场景都全部实现组件化，因为它们的底层就是用积木搭建出来。
六、未来计划
最后，我们的架构设计未来计划是可以将 Media Server 做成 Dockerfile，放到网站上供大家下载。我们还可以支持混合云模式，实现 RTC Media Server 的众包。众包指的就是用户可以找寻合适的网络，通过自己的硬件部署一个 Dockerfile、架设一个自己写的 Media Server，还可以成为融云全球加速通信网的节点中的一员。第二种模式就是用户租用融云的全球通信网，但可以实现私有的信令部署。再有一种模式就是用户可以按照模型自建媒体服务，然后自建私有的信令部署。
点击阅读原文
立即注册获取更多干货
↓↓