融云分析 可扩展的公有云媒体服务设计解析

作为互联网通信云服务商，除了满足最基本的音视频数据实时传输需求外，还会需要提供很多个性化的云端服务。本文来自融云的联合创始人兼 CTO 杨攀在 LiveVideoStackCon2019 北京站上的精彩分享，结合融云去中心化的媒体服务架构，解析如何构建灵活的、可扩展的音视频通讯云服务。

大家好，我是融云的联合创始人兼 CTO 杨攀，本次我分享的主题是融云在公有云媒体服务设计的理念和思路。

我是从2002年参加工作，至今已经十七年，其中有十五年的时间都是在做关于 IM 的工作。2004年时我加入了 MSN，作为 MSN 进中国第一个落地的本地化服务，我在其中担任项目负责人的工作。2008年到2014年间我都在从事与飞信相关的工作，经历了飞信从一个非常小的业务成长为数亿级规模的水平。2014年后随着云服务的兴起，我与团队创立了融云，将即时通讯与云服务结合提供给开发者，让开发者可以通过调用 SDK 使用 IM 服务。

本次演讲将分为设计概述、媒体服务、能力服务、服务集群和服务网络五个部分展开。

1． 设计理念

融云是一家互联网通信云服务商，众所周知，要想做基本的音视频服务，首先你需要具备信令服务、能力服务和媒体服务这三种能力，这些能力都基于 WebRTC 技术，但 WebRTC 本身的定义是 Ｐ2Ｐ 的通讯，它本身并没有服务部分，在服务部分有很多开源的实现解决方案。其次 WebRTC 也没有定义信令服务的部分，很多厂家都是通过自己开发或采用第三方信令的方式来解决这个问题。信令其实就是一个长链接的通信通道，它与 IM 即时通讯其实是一样的，融云也有案例说明客户可以采用融云的公有云即时通讯解决方案来满足信令服务的需求。随着基础通信能力达到要求之后，又不断引入新的需求，比如对音视频内容的审核、更大规模的使用WebRTC技术替代直播平台的解决方案，这也就引入了类服务这样新的功能。融云即时通讯业务的设计理念是各司其职、避免依赖，核心服务专注通信，能力服务专注业务，只要做到这一点，系统就可以实现部署简单和运维方便，降低管理的成本。另外融云作为全球互联网通信云服务提供商，在设计之初就不可避免要考虑全球互联的问题，全球互联的架构与私有架构的不同需要充分照顾到。

2． 媒体服务

2．1 媒体服务基础能力

首先从三大能力中的媒体服务能力谈起，融云团队一般都称之为＂三无服务＂，＂三无＂是指一个媒体服务对其他的服务没有依赖，其他的服务对这个媒体服务自身也没有依赖，并且每个服务没有任何中心化的配置。根据工作中的经验，无论是在公有云、私有云还是混合云环境中，会面临要部署的环境和客户端的环境都非常复杂的情况，比如用户会在防火墙后或者服务器本身就在防火墙里面，遇到这些情况，融云采用端口收敛的方式进行通信的策略控制，这都是需要在设计之初就做到的事情。

另外融云还实现了两个实时通信场景，第一个场景是绝大多基础音视频厂商都能做到的二人 Ｐ2Ｐ 会话，第二个场景是多人视频会议，在这个场景中人数一般会在十人以上。随着业务的发展，大家都能感觉到一个技术趋势：用 WebRTC 的方式做直播，传统的直播是将客户端的流在服务端处理之后推给 CDN，最后由 CDN 进行分发，这样做的好处是利用 CDN 的基础架构可以实现大规模用户在一个房间收看直播，这是 CDN 技术特点所带来的优势，但同时 CDN 也存在着一些问题，比如首屏开屏的速度过慢，当然目前针对这个问题也有着各式各样的解决方案。有些客户在这基础上就会提出能否使用 WebRTC 来实现直播场景，业内也称这种方案为低延迟直播，由于延迟比较低，在直播中的互动也会更加友好。

2．2 信令服务与媒体服务

关于信令服务和媒体服务的关系，绝大多数的厂商信令服务和媒体服务都是在一起的，融云的设计理念强调要解耦，使得部署和维护都更简单，因此信令服务和媒体服务之间也需要解耦和无依赖，信令服务与媒体服务之间原本存在的状态同步也要解开，而且融云本身就有特别健壮的信令服务，因此可以复用融云的 IM 通道，融云本身在这方面的投入也相当大。

上图是信令服务与媒体服务的简单架构，每一个媒体服务都与信令服务相关，相关性的目的是让彼此清楚各自的状态，这个设计模式的特点是客户端与信令服务通信，通信结束之后可以与媒体服务通信，而媒体服务之间的对接不受影响。

2．3 实时通信发布／订阅过程解析

上图是为了实现解耦引入的实时通信发布／订阅的模型，当 Client A 要与 Client B 进行会话时，第一步是进行发布，首先用 Client 调用 IM Server，提交加入房间／通话申请，调用信令服务的目的是拿 Token 返回，Token 中包括之后整个订阅／发布功能所需要的关键数据，拿到这些 Token 之后去调用相关媒体服务的地址，传统的设计通常是找信令服务，在分析 IP 地址库之后指到媒体服务，由于我们需要做到解耦，因此在 Token 调用媒体服务后会给出一个返回值，返回值是 IP 地址和 Domain。返回 Client 之后就可以拿到 IP 的信息，连到媒体服务开始与 Client B 通信，通信的过程完全是依靠长链接的信令服务通道来进行的，Client A 将它得到的 Domain 信息发送给 Client B，此时发送阶段工作结束。发送阶段结束之后由 Client B 来执行订阅工作，Client B 会找到离它比较近的信令服务，调用媒体服务接口连到 Client A 连接的媒体服务，这就是完整的发布／订阅模式。

2．4 媒体服务对客户端接口设计

对于媒体服务对客户端接口的设计，只需要提供发布／取消发布流、SFU 订阅／取消订阅和 MCU 订阅／取消订阅的接口，就可以完成解耦过程，整个通信的过程也可以建立起来。

3． 能力服务

3．1 能力服务分类

本身正常的一对一、多对多通信完全可以通过媒体服务就可以实现，融云最初上线的版本也是基于媒体服务去实现通信需求。后续客户和业务产生了新的需求，比如在 AB 通讯时需要录像、对音视频的审核以及 WebRTC 实现低延迟直播等，融云将这些需求统称为能力服务。

3．2 能力服务设计原则

能力服务一样也有设计原则，首先，需要与媒体服务或信令服务解耦、无依赖；第二，无中央配置，无需通过配置来控制能力服务的功能和逻辑，而是通过接口和调用关系来控制；第三，结构简单，能够实现低成本运维；第四，能力服务可利用现有的网络能力。

3．3 媒体服务对接能力服务过程

通过上图来解释媒体服务对接能力服务过程中的逻辑，与发布／订阅模块相同，都是用 Client 调用 IM Server，调用信令服务拿 Token 返回，Token 可以直接生成一个 Hash 值，可以将 Token 理解为一个字符串，将想要的数据通过加密算法封到 Token字符串里，比如＂host＠clusterld＂，＂config＂，Token 返回 Client 之后还是寻找媒体服务，在连接另外一个媒体服务做通信时接入能力服务，由发起方提供能力服务的内容。