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

本篇文章向大家介绍《三体云–高可用实时音视频服务演进之路》，主要包括MySQL、Windows、github、javascript、html5，具有一定的参考价值，需要的朋友可以参考一下。

三体云的前身是一家视频会议提供商，如今致力于为多领域提供实时音视频技术整体解决方案,为开发者提供简单易用、极度稳定、低延时、高保障的直播云服务，这其中的转变在架构升级、系统调度和质量监控三个方面都有不同的体现。本文来自于张光在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 质量监控示例

好了，本文到此结束，带大家了解了《三体云–高可用实时音视频服务演进之路》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多数据库知识！