公有云

公有云

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

科技创新融云那些事 发表了文章 • 0 个评论 • 64 次浏览 • 2020-06-16 18:26 • 来自相关话题

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

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


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


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


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

设计理念

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

媒体服务
2.1 媒体服务基础能力


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

另外融云还实现了两个实时通信场景,第一个场景是绝大多基础音视频厂商都能做到的二人 P2P 会话,第二个场景是多人视频会议,在这个场景中人数一般会在十人以上。随着业务的发展,大家都能感觉到一个技术趋势:用 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.1 能力服务分类


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

3.2 能力服务设计原则


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

3.3 媒体服务对接能力服务过程


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

3.4 媒体服务对能力服务接口设计


媒体服务对能力服务接口设计分为申请推流/接受推流申请和推出推流/接受推流推出两种。

服务集群
4.1 服务集群设计原则


关于服务集群的设计理念,首先还是贯穿始终的结构简单、易于维护,其次是可低成本构建集群以及可快速的扩缩容。

4.2 媒体服务集群框架


整个媒体服务集群的架构如上图所示,其中每台媒体服务器应该有自己独立向外暴露的 IP 地址,用于进行 RTC 相关的通讯。媒体服务现在有两个角色,一个是用于 RTC 相关的通讯,另外每个媒体服务器现在有自己 HTTP 的接口,用负载均衡和反向代理来控制这些 HTTP 接口的调用,通过反向代理实现规则调度。

4.3 服务集群实现


媒体服务集群还实现了实时通信单中心间媒体服务零调用,直播模式单中心理论上支持无限扩容以及通过代理层的控制实现无业务中断的更新。

4.4 MCU 能力服务集群


MCU 能力服务集群与媒体服务集群逻辑相同。

4.5 集群概况


在没有能力服务的情况下,上半部分就是融云标准的数据中心模型,引入能力服务后,需要复用媒体服务集群现有的基础设施,所有的能力服务就会与媒体服务部署在一起,但实际上由于架构实现解耦,比较灵活,并不需要物理上部署在一起。

服务网络
5.1 全球网络设计原则


融云在做 IM 的时候对于全球网络设计有非常丰富的经验,通过多年来在全球覆盖地区 IM 网络和基础数据的收集,基本可以了解全球各个地区的实时网络变化情况。在这过程中团队总结出任何物理的优化都不是特别稳定,因此全球网络的设计理念就包括客户端就近接入,多链路选择,数据中心间同源音视频只有一路级联,利用IaaS能力进行中心间级联链路的优化。

5.2 跨国级联示意图


跨国级联示意

5.3 全球网络的工作


另外,融云在全球网络中还做了一些工作,比如 DoH 刚在2018年9月变成RFC 的标准,主要解决 DNS 中间人劫持问题,根据融云这么多年业务开发经验来看,很多连接问题最终发现都是由 DNS 劫持导致的。另外在引入 SmartDNS 时会遇到 LocalDNS 缓存不准的问题,这些都会导致最终分配的就近地址不是真正的就近地址。融云目前的工作模式是将三者结合起来使用,在引入 SmartDNS 技术的同时引入 BGP Anycast 运营商技术来解决最近地址问题,通过这三层技术最大化来保证找到用户的最近地址。另外可以在某些特殊情况下采用公网链路来做数据中心之间的级联通信,绝大多数厂商碍于成本的考虑也采取了这样的方法,但公网存在某些特殊情况不稳定的问题,因此需要有一些备用链路,甚至在一些特殊的国家地区做物理链路优化,融云 IM 在全球的基础网络设施投入很大成本,也收获了很可观的成绩。

未来工作计划

关于融云目前正在开展的工作计划,随着业务的不断增加,按照现有的架构其实可以引入更多基于场景的能力服务,只要遵循架构模型就可以不断地引入新的模型。另外在融云的架构模式下天生支持混合云模式,由于各个服务间都是解耦的,任何私有环境下的服务都可以直接利用已经存在的公有媒体服务架构之上,对于公有媒体服务来说,只要遵循相同的发布/订阅模型就可以直接使用。

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

科技创新融云那些事 发表了文章 • 0 个评论 • 64 次浏览 • 2020-06-16 18:26 • 来自相关话题

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

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


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


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


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

设计理念

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

媒体服务
2.1 媒体服务基础能力


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

另外融云还实现了两个实时通信场景,第一个场景是绝大多基础音视频厂商都能做到的二人 P2P 会话,第二个场景是多人视频会议,在这个场景中人数一般会在十人以上。随着业务的发展,大家都能感觉到一个技术趋势:用 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.1 能力服务分类


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

3.2 能力服务设计原则


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

3.3 媒体服务对接能力服务过程


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

3.4 媒体服务对能力服务接口设计


媒体服务对能力服务接口设计分为申请推流/接受推流申请和推出推流/接受推流推出两种。

服务集群
4.1 服务集群设计原则


关于服务集群的设计理念,首先还是贯穿始终的结构简单、易于维护,其次是可低成本构建集群以及可快速的扩缩容。

4.2 媒体服务集群框架


整个媒体服务集群的架构如上图所示,其中每台媒体服务器应该有自己独立向外暴露的 IP 地址,用于进行 RTC 相关的通讯。媒体服务现在有两个角色,一个是用于 RTC 相关的通讯,另外每个媒体服务器现在有自己 HTTP 的接口,用负载均衡和反向代理来控制这些 HTTP 接口的调用,通过反向代理实现规则调度。

4.3 服务集群实现


媒体服务集群还实现了实时通信单中心间媒体服务零调用,直播模式单中心理论上支持无限扩容以及通过代理层的控制实现无业务中断的更新。

4.4 MCU 能力服务集群


MCU 能力服务集群与媒体服务集群逻辑相同。

4.5 集群概况


在没有能力服务的情况下,上半部分就是融云标准的数据中心模型,引入能力服务后,需要复用媒体服务集群现有的基础设施,所有的能力服务就会与媒体服务部署在一起,但实际上由于架构实现解耦,比较灵活,并不需要物理上部署在一起。

服务网络
5.1 全球网络设计原则


融云在做 IM 的时候对于全球网络设计有非常丰富的经验,通过多年来在全球覆盖地区 IM 网络和基础数据的收集,基本可以了解全球各个地区的实时网络变化情况。在这过程中团队总结出任何物理的优化都不是特别稳定,因此全球网络的设计理念就包括客户端就近接入,多链路选择,数据中心间同源音视频只有一路级联,利用IaaS能力进行中心间级联链路的优化。

5.2 跨国级联示意图


跨国级联示意

5.3 全球网络的工作


另外,融云在全球网络中还做了一些工作,比如 DoH 刚在2018年9月变成RFC 的标准,主要解决 DNS 中间人劫持问题,根据融云这么多年业务开发经验来看,很多连接问题最终发现都是由 DNS 劫持导致的。另外在引入 SmartDNS 时会遇到 LocalDNS 缓存不准的问题,这些都会导致最终分配的就近地址不是真正的就近地址。融云目前的工作模式是将三者结合起来使用,在引入 SmartDNS 技术的同时引入 BGP Anycast 运营商技术来解决最近地址问题,通过这三层技术最大化来保证找到用户的最近地址。另外可以在某些特殊情况下采用公网链路来做数据中心之间的级联通信,绝大多数厂商碍于成本的考虑也采取了这样的方法,但公网存在某些特殊情况不稳定的问题,因此需要有一些备用链路,甚至在一些特殊的国家地区做物理链路优化,融云 IM 在全球的基础网络设施投入很大成本,也收获了很可观的成绩。

未来工作计划

关于融云目前正在开展的工作计划,随着业务的不断增加,按照现有的架构其实可以引入更多基于场景的能力服务,只要遵循架构模型就可以不断地引入新的模型。另外在融云的架构模式下天生支持混合云模式,由于各个服务间都是解耦的,任何私有环境下的服务都可以直接利用已经存在的公有媒体服务架构之上,对于公有媒体服务来说,只要遵循相同的发布/订阅模型就可以直接使用。