企业级直播云服务的应战与架构演进

作者丨刘钧石

编辑丨千山

本文整顿自取得场景视频技术总经理刘钧石在WOT2023大会上的主题分享，更多精彩内容及现场PPT，请关注技术栈群众号，发信息【WOT2023PPT】即可间接支付。

日前，在主办的WOT世界技术翻新大会上，取得场景视频技术总经理刘钧石带来了主题演讲《企业级直播云服务的应战与架构演进》，围绕企业级直播云服务面临的诸多应战，详细引见了取得场景视频在架构演进中的通常和阅历总结，为群众出现了全新的视角。

本文将摘选其中精彩内容，一致整顿，宿愿为诸君带来启示。

一、企业级直播云服务的应战

成立于2005年的“取得场景视频”努力于面向全行业用户提供一站式视频处置打算，关键业务包含企业培训、在线教育、数字人直播等。当天在此关键是和大家分享一下咱们公司的架构是如何演进的。

首先简述一下直播的运行场景。直播往往并不独自存在，咱们做的直播通常都跟各种业务环境相联合。比如教育直播就会联合到白板、问卷等教学工具；优惠直播就会联合到排行榜、红包雨等营销工具；再比如赛事直播、大会直播、电商直播，数字人直播，可以说各有各的方式和需求。

通常来说，直播的业务流程分为推流、业务处置和拉流这三部分。推流触及到多源输入，手机、电脑摄像头、VR采集设备都可以是输入源，待这些媒体流/数据流上行到云端后，经过源站，由于流的协定不一样，所以要转码后再散发，处置的同时将视频存上去以便回放和启动数据剖析，最后依据不同的输入端口启动不同的适配处置，达成多端输入的结果。

详细到业务场景时，它又要和更下层的业务系统去买通、对齐。

重点讲一下在提供企业级直播云服务的环节中面临的应战。

第一，场景不同，需求也不同。比如说优惠直播要求拙劣晰度；赛事直播动辄数十万人甚至百万人，因此要保障高并发；文娱直播注重的则是高互动性。

第二，客户研发才干不同。不同客户的技术才干千差万别。研发才干较高的企业往往只需求咱们提供底层才干，比如SDK；研发才干中等或许要求不高的客户，或许只需为他定制UI即可；另外一些研发才干还在起步阶段的企业或许会偏差于让咱们提供开箱即用的软件。对此，咱们当然无法能逐个为其量身定制，咱们的战略是分层，须要底层允许的放开PaaS，只想做定制UI的就提供UISDK或许APaaS，想要开箱即用一步到位的就放开咱们的SaaS产品。

第三，客户痛点。首先在视频这一环节，提早必需是最大痛点之一，看直播时假设出现提早、卡顿等现象会间接影响用户体验。而后不同场景下，更高的并发、突增的流量都或许构成应战。

二、如何提高流媒体品质

视频直播里的重中之重是视频品质。咱们在看直播时，经常会遇到的意内现象有黑流、提早、卡顿等。不论是什么起因惹起的，前提都是某段链路出现了疑问。

网络一共分为三段，从推流端到边缘节点，再到合流，再经过CDN散发。在每一段上最关键的是，如何选用最适合的那一段链路，这就关涉到调度疑问。关于任何一个直播系统来说，低劣的调度系统肯定是最关键的组成部分之一。

那何时做调度呢？其实不只仅是开播时，从推流开局就触及到调度了。咱们会在四个环节区分启动调度：开播调度、推流重试调度、播放调度、热切调度。

如何做调度呢？肯定有两个数据起源——服务端和客户端。通常咱们被动监控的就是服务端数据，流量如何、带宽如何、负载如何，将这些数据都采集起来。然而疑问在于，服务端的数据都是曾经出现的数据，由于流来了，恳求曾经到了，主机才会出现相应变动。那么还没开局推流的时刻呢？构想一下，更多的人关上客户端，进入直播间，推风靡将开局，恳求行将抵达。客户端是知道这些数据的。所以咱们把服务端数据和客户端数据整合到一同，经过咱们的决策模型来做调度，这样的调度不只仅是准确，更有肯定的预测性。

当然做调度的前提是数据。咱们每天最常处置的状况就是某个直播又卡了，某个节点负载又高了。详细状况究竟如何，咱们程序员通常会检查这些数据，从而了解是部分疑问还是全体疑问，以便更快地定位。

经过实践测算，咱们发现，没有这些数据之前，直播缺点出现后要定位或许解除某个疑问，都得超越30分钟。如今咱们可以做到3~4分钟确定一个客诉究竟是什么疑问、什么级别。咱们给这个系统起名叫“魔镜”，也正在把魔镜的数据对客户放开，从而便于客户自行排查。

关于缺点疑问的处置，假设经过服务商的程序员启动处置，照应再灵敏也要经过多级沟通。因此可以说，疑问越能前置处置，影响就越小。原本很小的疑问经过层层排查，或许也会由于照应不迭时演化为较大的疑问。所以疑问越提早泄露，越能处置得更好。

三、如何允许高并发

在做直播的时刻如何允许高并发？并发来了，会出现哪些疑问？这里罗列三个比拟有代表性的瓶颈点。

上方详细分享一下咱们针对这三点区分做了哪些针对性措施。

1.登录优化

最后咱们有个业务叫接口认证，用户想登录咱们的系统的时刻，用户信息都存在咱们客户的系统，咱们经过调用客户的服务端去失掉他的信息去认证。

全体流程大略是：用户从他要登录的一个客户的视频列表页，进入咱们的直播播放页，把用户名、明码给到咱们的服务，咱们再去恳求服务端。

现在设计的时刻咱们没无看法到这种操作有什么疑问。起初发现，咱们没有方法保障客户的服务端是怎样样的，咱们可以做一些过载包全，然而假设很多客户同时都在直播，这个中央就十分容易出疑问。于是咱们做了一个比拟便捷的变革，就是咱们不再去调客户的服务，而是由客户到咱们这边来创立，再经过列表页把这个Token带给咱们，这样就处置了这一典型疑问。

2.信令带宽

以聊天室业务为例，我发一个聊天，这个房间里的一切人都收到。假设这个平台上跑了一万个直播间，那届时怎样处置呢？

打个比如，最开局有20台主机专门树立SocketIO，一切人都连过去。作为用户，我要把一条信息发到其中一个Socket主机上，而后经过一个广播，经由Pub/sub，把这个信息同步发到另外20个主机上。

这里的疑问在于，自身就是优惠直播，比如有一万团体，你又有一万个直播间，光这一条信息就加大了20倍，假设这个聊天室里再有人刷屏，这里的信息量可谓恐惧。

架构是演进进去的，但有时也是紧急状况下催生的。2019年某个突发状况下，咱们花了三天三夜就启动了加快调整。收获极大但思绪很便捷，就是分组，按用户、按渠道把你的资源启动分组，找到正当的组。

3.高性能模板

用户看直播，除了失掉直播流以外，他或许还有一些业务数据要失掉，比如说他想看看能不能拉到历史的聊天数据。

通常一场直播必需都是先登录直播页，而后恳求业务系统把这些历史数据都分波拉上去。然而假设有一些直播量十分大，比如，你了解到某场直播在明日早晨7点有十万人同时进，假设这些人同时恳求你的业务系统，系统压力肯定会十分大。对此，咱们可以侧面处置，比如用弹性扩容、用容器化服务。然而咱们也有一种波折的思绪，就是预制这些数据。

面向这种直播，咱们必需是可以做一些升级战略的。比如拉历史聊天数据，聊天室里那么多信息，假设少了10条、20条，其实是不影响的，而且你可以把聊天室信息经过火类做区分，主播的信息不能丢，然而其他人的信息可以丢一点。最关键的是把这些数据提早都启动处置，预制到这个页面外面，把它静态化。其适用户关上这个页面的时刻，大部分的数据都曾经在这个页面里了，只要很少的一部分是须要去服务端恳求。经过这种预制数据的方法，一下就能把恳求数据量或许恳求接口量降到原来的10%以下。因此这对咱们来说也是很好的阅历。

四、如何成功高可用

关于如何成功高可用，首先分享一个很多年前的缺点案例。

过后，咱们的视频处置组做了一个十分弱小的配置更新——加快回放。原来视频直播完结后，视频录制或许须要一段期间才干生成，配置更新后，直播完结立刻就能生成回放。没想到这一配置上线后，出现了直播完结一大量观众立刻观看回放，惹起存储元数据的数据库压力过大。而且过后咱们还没做拆分，回放一侧出了疑问，新用户也无法参与直播间。后续咱们就做了一些解耦。

第一步，把回放和直播在服务层解耦。直播怎样样，不能影响回放。回放怎样样，不能影响直播，践行了一个基本的缺点隔离的思绪。

第二步，把回放元数据冷热分别。直播中，特意是部分业务数据，比如画笔，200毫秒一条，特意大的量，之前没过多地对这份数据做处置。起初咱们做了一些冷热的分别，保障这个库的压力不会太大。

第三步，回放元数据成功静态化。跟之前提到的高性能模版的思绪一样，咱们提早对数据启动处置，把这些数据变成静态化的，这样再去恳求页面的时刻，只恳求这些数据，很少的一部分去恳求数据库。经过这样的战略，也能大大优化咱们的可用性。

另外，详细就回放来说，回放的业务某种水平上比直播更复杂。关于回放的处置，尤其是回放的录制，咱们也做了很多上班。

原来直播跟回放在一同，咱们一台主机既担任直播流的转发，又担任视频文件存在本地的责任，所以经常会造成主机IO和带宽同时高，经常捉襟见肘，造成应用率很低，弹性也很成疑问。由于直播是有形态的，视频流不时推着，这个流不能切，一切就断了，但录制是可以的，由于你在这台机器录一半，在另外一台机器再录一半，而后把两者拼在一同就可以了。所以咱们花了不少精神打造有形态的弹性的录制系统。

此外，在直播安保方面，咱们也采取了很多措施来防止盗链、盗播。虽然触及到的系统逻辑不太一样，但外围理路依然是把这些数据的配置拆分开来，尽或许做到解耦，让每一个业务流彼此独立。

五、组件化分层架构

关于分层架构的内容，我以问卷配置为例启动详细说明。之前咱们的直播和互动也是在一同的，至少从业务逻辑上是不太区分的，便捷来说，直播推流和动员问卷都是由一个大模块来治理。这里就出现了几个疑问。

这三个疑问象征着，必需将直播和互动分开。咱们间接做了这样的变革：把一切的问卷服务从直播服务都拆进去，所有SDK化。如图所示，咱们把直播类与互动类的信令分开，把业务逻辑分开，在UI层面把UI都分开。这样一来，不只能处置以上痛点，还能大大优化开发效率。

直播与互动彼此独立，这样的话就可以树立一套放开的、互动的组件平台。而且作为云服务商来讲，咱们岂但可以自己去开发这个组件，也可以约请咱们的协作同伴或许咱们的客户自己去开发、奉献他的组件。

综合上去，分层架构的逻辑大抵如此：最上方是IaaS层，而后是咱们的撑持系统，撑持系统咱们可以称之为是PaaS层，这三层都可以对外提供。

把直播服务跟互动服务分开，其好处在于彼此可以独立运作。而且如今树立他乡研发中心渐成趋向，虽然视频会议很遍及，但相较面对面沟通，沟通老本依然很高。更好的打算还是让他们彼此不影响、彼此商定好接口、商定好规范，这是最高效的。所以把互动跟直播拆开，是咱们近几年来最关键的变动。

假设从客户视角来看，从最底层的IaaS提供的组件，而后到INFSDK，面向的是自身有研发才干的这些客户，他们可以间接自定义INFSDK。假构想只是自定义UI，不自定义业务流程，可以用UISDK。想开箱即用的这些客户，可以间接经常使用SaaS运行。

而后咱们是层层依赖的，最下层SaaS运行依赖UISDK，UISDK依赖INFSDK，全体再依赖Common-SDK。然而每一层又可以独立地对外提供。组件化平台，这也是咱们近两年的外围技术思绪。这样的方式就是可以对不同的类型客户提供允许，自己又可以不用重复地去造轮子。

便捷总结一下组件化的技术价值：

六、未来展望：数字人直播

面向未来，咱们关键的思绪就是拥抱AI。我感觉，如今无论你谈不谈AI，首先你必需得接受，它就是一个肯定的趋向。然而也不用那么恐慌，由于咱们最关键的就是如何经常使用它。总体来说，AI给咱们直播行业也带来了一个十分大的契机。

原来的数字人其实挺鸡肋的，由于它没有灵魂，它疑问你在说什么，一点不好玩。然而有AI的赋能之后，除了比拟经常出现的语义了解外，更关键的是它能生成，能被动发生内容。如何把数字人和AI联合，是咱们目前的一个重点方向。

咱们如今曾经上线的一个运行是人工默认客服。当然这个客服关键是针对教育场景的助理，教育场景通常有学员提问，而且教育场景又是很轻薄的，不能乱说。很多时刻GPT的回答不拘一格，甚至可以说齐全不着边沿。所以咱们要去控制，对数据启动定制训练，做更多的调优。前面咱们还会对其余场景做优化，比如直播带货，还有一些口播的短视频，这是咱们如今正在测试阶段的两个产品。

总体来说，我感觉咱们至少是直播行业，未来肯定是跟AI严密联合的，除了能看得见的运行，包含外部的流程，还有一些业务的逻辑，都是可以跟AI发生新的火花的。