三体云–高可用实时音视频服务演进之路

 

三体云的前身是一家视频会议提供商，现在致力于为多领域提供实时音视频技术总体解决方案,为开发者提供简单易用、极度稳定、低延时、高保障的直播云服务，这其中的转变在架构升级、系统调度和质量监控三个方面都有不一样的体现。本文来自于张光在LiveVideoStackCon2019北京站上的精彩分享。

文/ 张光

整理 / LiveVideoStack

你们好，我是三体云CTO张光，今天我演讲的主题是三体云如何提供高可用的实时音视频服务。我从2005年开始从事音视频技术研究，有十年的移动端音视频研发经验，曾任著名视频会议厂商研发经理,负责过多行业100+音视频项目，2008奥运会有幸担任TD3G供应商项目主要负责人，目前更加关注与实时音视频技术的发展。

1. 高可用

1.1 高可用的定义

 

众所周知，云服务厂商与客户签定协议之时通常都会附带SLA协议，而SLA协议中基本就已经定义了厂商给用户提供的服务须要达到什么样的等级。SLA协议中更多提到的是服务在何时能够提供给客户使用，而具体的使用效果并无明确说明，所以三体云对自身提出了更高的要求，但愿提供的服务可以在可用的同时带给用户更好的使用体验。

1.2 如何作到高可用

 

三体云的前身是一家视频会议提供商，总体软件的架构都是由视频会议过渡而来，要提供实时音视频服务并处理海量并发需求，当务之急是须要对系统架构进行升级，另外，好的调度系统也能使音视频服务变得更好用。在提供优质服务以后，三体云还但愿可以建设一套全面的质量监控系统，更好更快的找出系统的不足，不断地改进以提供更好的服务给客户。

2. 系统架构升级

2.1 早期适用于视频会议的系统架构

 

既然三体云以前是视频会议的系统架构，那么就先从早期架构谈起。如图所示，早期的业务和媒体节点都部署在一个地点，若是没有高并发、跨地域等的需求状况下，仅仅一个master就能提供服务。随着用户有更多分支机构的变动以及更多用户接入的状况出现，就须要在MASTER节点上用SLAVE节点链接作拓展，随着层级愈来愈多，延迟也会愈来愈大，MASTER节点可能会成为瓶颈。在这种结构下，全部的状态都存储在业务服务器上，业务同步会很是复杂，某一节点宕机以后通常都采起双机热备的方式处理。所以三体云在转型音视频服务以后须要对旧的系统架构进行全面的升级。

2.2 更适合公有网络部署的方案

2.2.1 媒体接入及转发

 

系统架构升级的第一步是对媒体接入及转发作一些改变，在媒体接入部分，三体云将全国各地的每台服务器作平级化处理，相互之间没有分层，全部的媒体服务器都会向loadbalance节点上报状态，帮助其作一些调度方面的决策。而在媒体之间转发部分，在视频会议架构中节点转发须要上报根节点以后才能下发到相应节点，而改变也如图中所示，例如北京移动转发到广东电信须要通过BGP中心节点来帮助作路由转发，广东到上海也会有一个三线IDC来帮助其转发。

2.2.2 信令及状态维护

 

信令和状态维护方面的改变与以前媒体部分的改变比较相似，loadbalance节点一样作接入和分发的工做，而业务之间也不存在层级关系，都会向loadbalance上报本身的状态，同时全部跟业务相关的房间、用户的状态信息等都会写入redis，业务之间的数据同步就会变得更简单。

2.2.3 结合

 

上图表示的是一个客户端想要接入系统首先须要链接loadbalance，当前更多采用域名的方式来链接，接入以后调度到指定的业务服务器上，全部的业务都须要把状态写到redis，业务服务器分发以后首先会有校验和建立状态的环节，完成以后就会给他分配媒体服务器。改变以后的业务和媒体的拓展比以前的树状结构要简单许多，不须要把新加的媒体或业务挂在某一个MASTER或SLAVE节点下，只须要部署在平台上并注册在loadbalance上就能够，业务和媒体的个数不用一一绑定，拓展要相对灵活一些。尽管三体云作到了这些架构升级，但在现实中仍然出现Loadbalance和redis集群瘫痪所引起的问题，所以须要进一步改进框架，优化产品服务。

2.2.4 优化

 

经过对系统架构的升级优化，客户端在接入时，会有如图两套loadbalance链接，并且redis分开写入，两个loadbalance之间保持高速同步，这样能够作到两我的经过不一样的loadbalance进行连麦操做。但这样作仍是会出现部分用户链接不到服务器的问题，通过排查发现缘由是这部分用户的域名被劫持，所以三体云又多建了一套固定IP，与前两个loadbalance一块儿写入SDK，用户使用服务进行连通时若是访问不到域名就会尝试链接静态IP来访问，更进一步保证了服务的连通性。

3. 智能调度

3.1 节点的选择

 

系统架构的升级在必定程度上提升了三体云服务的用户体验，但仅仅靠架构优化远远达不到咱们的预期，还须要智能调度来进一步提高产品质量。中国幅员辽阔，大的国土面积带来的问题是会出现各类各样的网络问题，若是要为不一样地方的用户提供服务就须要部署更多的服务器，目前在国内就已经有两百多个数据节点，而对于不一样位置须要对节点部署进行选择。首先须要找到一些可以部署服务器的机房，找到节点以后进行拨测，保证服务器真实可用且知足基本条件就能够部署服务，部署成功再通过内部测试才能够上线，而上线以后才是对于节点的真正考验。节点上线以后咱们会对其进行数据监控，以观测该节点是否符合服务标准，最终会对不符合条件的节点进行淘汰，并从新在该区域选择节点部署。这样对于节点的选择流程会使三体云部署的所有节点都是符合服务标准的选择。

3.2 第一千米&最后一千米

 

想要作到智能调度的第一点是要让节点部署离用户更近，最初三体云是经过IP库返回所在地域以及运营商进行选择，但实际上国内的网络环境很是复杂，IP库也存在必定的准确性问题，甚至服务器获取的IP与媒体服务器获取到的IP可能不一致，这些问题都急需解决。

 

经过IP库返回所在地域以及运营商这件事自己并无错，问题出在运营商并无将这件事解决完全，所以在进行用户调度时须要更严格要求就近原则、运营商匹配度以及负载均衡，除此以外还须要作一些兜底保障和数据统计的工做来完善调用规则。

3.3 路径选择

 

互联网作实时音视频交互大部分都是跨区域连通，而三体云在解决这部分问题时也遵循着四个原则，首先经过探测机制探测各节点间的网络情况（分区域），毕竟在国内目前就存在两百多个服务器节点，对这些节点进行探测是基本不可能的，所以是按区域划分进行探测，各区域会把本身的探测结果上报到决策中心去作统一的调度。第二点是关于实时负载情况的统计，国内两百多个服务器节点的配置是不同的，因此必须把实时运行的状态上报到决策中心，方便作后续分配。最后在路径选择方面还须要基于成本考量，而且遵循最短路径原则。

3.4 路径切换

 

路径选择完成以后在真实网络环境下还会出现，国内的网络包括主干网和单线机房都会随时发生抖动，或者发生机房宕机等状况，为了尽可能避免这些特殊状况对用户体验的影响，还须要在智能调度中加入路径切换，可以在使用过程当中对路径作实时选择。

3.5 服务下线、升级

 

服务器部署以后并非一成不变的，算法的改进和服务节点的替换都是服务下线和升级的过程，而在这个过程当中咱们也但愿能有更好的用户体验。假如A服务须要下线、升级，以前的作法是直接杀死A服务，依赖client的断线重连使服务维持下去，但这期间会发生黑屏、卡顿等很是影响用户体验的情况发生。然后的改进措施是先从loadbalance上注销A服务，保证调度时再也不有新的用户访问A服务，等待A服务用户逐渐归零以后再升级服务，但现实状况下根本没办法等到全部用户都从A服务上下线，因此最终三体云的改进方法是主动发送信令通知用户从A服务迁移到B服务，在此期间作到用户对于服务下线、升级彻底无感知，体验不到中间有任何的断开。

4. 质量监控

 

在作完服务器部署以及智能调度以后，已经能够保证用户可以无时无刻的访问三体云的业务，但最终的使用效果若是没有质量监控是没办法观测到的，而且须要作到先于用户发现问题，或者帮助客户一块儿来改进服务质量。如下是三体云质量监控系统对某客户使用效果的一些指标统计数据

4.1 质量监控示例