编者按:作为互联网通信云服务提供商,除了满足音视频数据最基本的实时传输需求,还将需要提供很多个性化的云服务。本文来源于融云联合创始人兼CTO潘阳在LiveVideoStackCon2019北京站的精彩分享,结合融云的去中心化媒体服务架构,分析如何构建灵活、可扩展的音视频传播云服务。
大家好,我是融云联合创始人兼CTO潘阳。这一次,我分享的主题是融云对公有云媒体服务设计的理念和思考。
我从2002年开始工作,到现在已经十七年了,其中十五年一直在做IM。我于2004年加入MSN,作为MSN在中国的第一个本地化服务,我在那里担任项目负责人。2008年至2014年,我从事飞信相关工作,经历了飞信从一个很小的企业成长到几亿的规模。2014年以后,随着云服务的兴起,我和我的团队创办了融云,为开发者提供即时通讯和云服务,让开发者可以通过调用SDK来使用IM服务。
本次讲座将分为五个部分:设计概述、媒体服务、能力服务、服务集群和服务网络。
1.设计构思
融云是一家互联网通信云服务提供商。众所周知,为了提供基本的音视频服务,你需要具备三种能力:信令服务、能力服务和媒体服务。这些能力都是基于WebRTC技术,但是WebRTC本身定义为P2P通信,它没有服务部分。服务部分有很多开源的解决方案。其次,WebRTC没有定义信令服务的部分,很多厂商通过开发或采用第三方信令来解决这个问题。其实信令是一个长链接的通信通道,其实和IM即时通讯一样。在融云也有案例,客户可以使用融云的公有云即时通讯解决方案来满足信令服务的需求。在基础通信能力满足要求的情况下,不断引入新的需求,比如音视频内容的审核,更大规模的使用WebRTC技术替代直播平台的解决方案,也引入了类服务等新功能。融云即时通讯服务的设计理念是:各司其职,避免依赖,专注通信为核心服务,专注业务为能力服务。只要做到这一点,系统就可以实现简单部署,方便运维,降低管理成本。此外,作为全球互联网通信云服务提供商,融云在设计之初就不可避免地要考虑全球互联,全球互联架构与私有架构的区别需要充分考虑。
2.媒体服务
2.1媒体服务的基本能力
首先,从三大能力中的媒体服务能力来说,融云团队一般称之为“三无”。“三无”是指一个媒体服务对其他服务没有依赖,其他服务对媒体服务本身没有依赖,每个服务没有集中配置。根据工作经验,无论是在公有云、私有云还是混合云环境下,要部署的环境和客户端的环境都会非常复杂。例如,用户将位于防火墙后面,或者服务器本身将位于防火墙内部。在这些情况下,融云采用端口聚合进行通信策略控制,这需要在设计之初就完成。
此外,融云还实现了两个实时通信场景。第一种场景是大多数基础影音厂商都能做的两人P2P对话,第二种场景是多人视频会议,人数通常在十人以上。随着业务的发展,大家可以感受到一个技术趋势:WebRTC直播。传统的直播是客户端流经过服务器处理后推送到CDN,最后由CDN分发。这样做的好处是大规模用户可以利用CDN的基础设施在一个房间看直播,这是CDN的技术特性带来的优势。但同时,CDN也存在一些问题,比如首屏打开慢。当然,目前这个问题有各种各样的解决方案。在此基础上,有些客户会问,能否用WebRTC实现直播场景,业内也称之为低延迟直播。由于延迟相对较低,直播中的交互会更加友好。
2.2信令服务和媒体服务
至于信令业务和媒体业务的关系,大部分厂商的信令业务和媒体业务是在一起的。融云的设计理念强调解耦,这使得部署和维护更容易。因此,信令业务和媒体业务之间需要解耦和独立,信令业务和媒体业务之间的原始状态同步要解锁。此外,融云本身有一个特别强大的信令服务,所以它可以重用融云的IM频道。融云本身在这方面也投入了很多。
上图显示了信令服务和媒体服务的简单架构。每个媒体服务都与信令服务相关,相关的目的是让彼此知道各自的状态。这种设计模式的特点是客户端与信令服务通信,通信后可以与媒体服务通信,但媒体服务之间的对接不受影响。
2.3实时通信发布/订阅流程分析
上图是为了实现解耦而引入的实时通信发布/订阅的模型。当客户端A想要与客户端B进行对话时,第一步是发布。首先用客户端呼叫IM服务器,提交加入房间/呼叫的申请。调用信令服务的目的是返回令牌,令牌中包含了后续整个订阅/发布功能所需的关键数据。获得这些令牌后,调用相关媒体服务的地址。传统的设计通常是找到信令服务,然后分析IP地址库后指向媒体服务。由于我们需要解耦,令牌调用媒体服务后会给出一个返回值,返回值是IP地址和域。客户端返回后,可以获取IP信息,连接媒体服务,开始与客户端B通信,通信过程完全由长链接信令服务通道进行,客户端A将获取的域信息发送给客户端B,此时发送阶段结束。发送阶段结束后,客户端B将执行订阅。客户端B会找到离它比较近的信令服务,调用媒体服务接口连接客户端a连接的媒体服务,这就是完整的发布/订阅模式。
2.4客户端接口媒体服务的设计
对于媒体服务客户端接口的设计,只需提供发布/退订流、SFU订阅/退订、MCU订阅/退订接口即可完成解耦过程,也可以建立整个通信过程。
3.能力服务
3.1能力服务的分类
正常的一对一和多对多的交流都可以通过媒体服务来实现,融云的原版也是基于媒体服务来实现交流需求的。后续的客户和业务产生了新的需求,如AB通信中的视频录制、音视频审计、WebRTC上的低延迟直播等。融云将这些需求统称为能力服务。
3.2能力服务的设计原则
服务也有设计原则。首先,它们需要与媒体服务或信令服务分离和独立。第二,没有中心配置,不需要通过配置来控制能力服务的功能和逻辑,而是通过接口和调用关系。三是结构简单,可实现低成本运行维护;第四,能力服务可以利用现有的网络能力。
3.3媒体服务对接能力服务流程
通过上图说明媒体服务对接能力服务过程中的逻辑。与发布/订阅模块相同,IM服务器由客户端调用,并调用信令服务来取回令牌。令牌可以直接生成一个哈希值,这个哈希值可以理解为一个字符串,需要的数据通过加密算法封装到令牌字符串中。比如“host@clusterld”,“config”,令牌返回客户端后,仍然会寻找媒体服务。当连接另一个媒体服务进行通信时,它访问能力服务,发起者提供能力服务的内容。
3.4媒体服务到能力服务接口的设计
媒体到能力的服务接口设计可以分为两种:用于推送/接受推送的应用和推送/接受推送的应用。
4.服务集群
4.1服务集群设计原则
至于服务集群的设计理念,首先是结构简单,易于维护,其次是可以低成本搭建,快速伸缩。
4.2媒体服务集群框架
整个媒体服务集群的架构如上图所示,其中每个媒体服务器都应该有自己独立的exposedIP地址,用于RTC相关的通信。媒体服务现在有两个角色,一个用于与RTC相关的通信,每个媒体服务器现在都有自己的HTTP接口。负载均衡和反向代理用于控制这些HTTP接口的调用,反向代理用于实现规则调度。
4.3服务集群实施
媒体集群还实现了实时通信的单中心之间媒体服务的零调用,直播模式的单中心通过代理层的控制,理论上支持无业务中断的无限扩展和更新。
4.4MCU能力服务集群
MCU能力服务群集与媒体服务群集具有相同的逻辑。
4.5集群概述
在没有功能服务的情况下,前半部分是融云的标准数据中心模型。引入能力服务后,需要重用媒体服务集群的现有基础设施,所有能力服务将与媒体服务一起部署。然而,事实上,因为架构是解耦的和灵活的,所以它不需要在物理上部署在一起。
5.服务网络
5.1全球网络设计原则
融云在做IM的时候有丰富的全球网络设计经验。通过多年收集全球覆盖区域的IM网络和基础数据,他基本可以了解全球各个地区的实时网络变化。在这个过程中,团队得出结论,任何物理优化都不是特别稳定。所以全球通网络的设计理念包括客户端就近接入,多链路选择,数据中心之间同一音视频只级联一路。IaaS功能用于优化中心之间的级联链路。
5.2跨国级联示意图
跨境信号
5.3全球网络的工作
此外,融云在全球网络方面也做了一些工作。比如DoH在2018年9月刚刚成为RFC标准,主要解决DNS中间人劫持问题。根据融云这么多年的业务发展经验,很多连接问题最终被发现是由DNS劫持引起的。另外,在引入SmartDNS时,会遇到LocalDNS缓存不准确的问题,导致最终分配的最近地址并不是真正的最近地址。目前,融云的工作模式是将三种技术结合起来,引入SmartDNS技术和BGPAnycastoperator技术来解决最近地址问题,最大限度地发挥这三层技术的作用,保证能够找到用户的最近地址。此外,在一些特殊情况下,公共网络链路可以用来做数据中心之间的级联通信。出于成本考虑,大部分厂商也采用这种方式。而公网在一些特殊情况下是不稳定的,需要有一些备份链路,甚至在一些特殊的国家和地区需要优化物理链路。融云IM公司在全球基础网络设施方面投入了大量资金,并取得了可观的成果。
6.未来工作计划
至于目前在融云进行的工作计划,随着业务的不断增加,可以根据现有架构引入更多基于场景的能力服务,只要遵循架构模式,就可以不断引入新的模式。此外,融云的架构模型固有地支持混合云模型。因为所有服务都是解耦的,私有环境中的任何服务都可以直接使用现有的公共媒体服务架构。对于公共媒体服务,只要遵循相同的发布/订阅模型,就可以直接使用。
关于融云
融云是一家安全可靠的全球互联网通信云服务提供商,为开发者和企业提供即时通讯和实时音视频通信云服务。根据艾瑞咨询的权威数据报告,融云即时通讯云的市场份额已经连续多年排名第一。
11月30日,融云将在沪举办2019全球互联网通信云大会(WICC2019),这是全球首个讨论互联网通信云技术的行业技术会议。目前大会免费报名通道限时开放。开发者可在官网(wicc.rongcloud.cn)通过大会申请限时免费门票,并参与WICC2019期间所有场次的内容分享,包括主会场和技术分论坛。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)