作者丨刘钧石

编辑丨千山

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

日前，在51CTO主办的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产生新的火花的。