【从0-1 千万级直播项目实战】实时音视频 | 业内各种常见直播场景架构方案

直播发展历程

1.0时代

在那个时候，大众接触得最多的平台是YY的语音直播，大概是在08年的时候上线的，那个年代是PC直播平台开始了，而后的几年各大公司也纷纷入局，一时间PC直播大战彻底打响，前期的商业模式主要是走在线音乐/喊麦、秀场方向，靠用户打赏实现营收。

2.0时代

时间来到2016年，这是不平凡的一年，4G网络开始普及，移动互联网时代正式宣布到来，越来越多人在手机上观看直播，同时这一年所谓的 "千播大战" 正式打响 wangyi yingke、huajiao、momo等众多直播平台入局，掀起了惨烈的移动直播大战，与此同时，某牙、某鱼、long珠等平台在游戏直播赛道展开激烈角逐。

最后千播大战胜利的选手们大多成为了现在咱们互联网耳熟能详的上市公司，某陌在这一波竞争中业绩腾飞市值一度超过百亿美元,这一时代可谓是互联网直播红利最好的一个时代，我的许多前同事们也是在这一阶段开始入场直播赛道的，有的人已经吃了前期红利实现财务自由，有的人还经常和我炫耀自己亲自去纳斯达克敲钟的场景。

3.0时代

全民直播时代，在这个时代其实互联网发生了很多大事，因为疫情的到来，大、小长倒闭得不少，裁员潮也正式开始，众多大厂电商平台也纷纷强化直播业务，某手、某音、某信也从短视频赛道迅速切换到直播赛道，新一轮直播大战衍生出了很多新的商业模式，例如社交电商直播、带货直播、知识变现直播、全行业直播变现，我们大家熟悉的罗胖子也搭上了这一波末班车，给我们上演了一出 "真还传"

直播的技术点介绍

推流

推流指的是把采集阶段封包好的内容推送到服务器的过程。

拉流

拉流是服务器中已有的直播内容(各种类型的流)，通过指定的地址进行拉取的过程。

转码

直播转码（视频、音频转码），是指将直播现场推送出来的原始流，在云端转换为不同编码格式、分辨率、码率的转码流推送给观众，以满足不同网络环境、终端设备等在各种场景下的播放需求。

流媒体服务器

指以流方式在网络中传送音视频等媒体形式。相对于下载后观看的网络播放形式而言，流媒体的典型特征是把连续的音频和视频信息经过压缩后放到服务器上，用户可以边下载边观看，而不必等待整个文件下载完毕。

实时音视频(RTC)

RTC 实时音视频（Real-Time Communication），可以实现用户的就近接入，提供网络低延迟、低丢包率的音视频通信。

低延迟直播协议(RTS)

基于RTC实时音视频引擎和传统RTMP直播系统的基础上，分别对直播推流端、播放端、边缘节点嵌入RTC模块，集成最新的RTP推拉流协议和实时媒体传输策略，提供易接入、毫秒级延迟、高并发、高清晰度、流畅的音视频直播和连麦服务。随着网络带宽和CPU计算成本的逐步下降，国内外各大云厂商大规模化部署、研发和技术成熟度的提升，低延时直播系统一定是未来的技术发展趋势。

长连接协议

长连接多用于操作频繁，点对点的通讯,这里我们一般指客户端-服务端之间的点对点通讯。传统的tcp连接都需要三次握手，如果每个操作都是短连接，么速度会降低很多，长连接可以每个操作完成后都不断开连接，下次处理时直接发送数据包就OK了，不用重新建立TCP连接，并且短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。

不同直播场景解决方案

1.秀场/视频直播场景

场景介绍

主播之间连麦互动、跨房间PK、才艺展示、粉丝打赏等玩法。

方案架构

方案说明

秀场直播采用这个方案延迟的容错是允许的，麦下用户可以选择实时拉流/低延迟/CDN方式，大家根据成本和业务包容性去选择方案即可，比如人多的直播间选择低成本的CDN或低延迟方案，当然这一类型业务选择哪一种整体没有太大问题。

2.语聊直播场景

场景介绍

语音直播，多人连麦互动、粉丝打赏等玩法，麦位比传统秀场直播多，上下麦的延迟问题是影响麦上麦下用户体验的关键因素。

方案架构

方案说明

这里把CDN方案给去掉了，几秒的延迟在语聊场景是不允许的，非常影响用户体验，建议成本没啥控制的话采用麦下用户采用实时拉流方案，当然对延迟没有太大要求且需要控制成本的话选用低延迟协议拉流方案成本会降低点。

3.KTV直播场景

场景介绍

多人合唱，排麦唱，跨房间PK唱等玩法，和语聊类似，延迟问题依然是重中之重。

方案架构

方案说明

在线KTV场景推拉流方案比较简单，难点是歌词与流的同步问题，比如第x秒对应哪一句歌词，歌词在主播段、合唱端、观众端也需要一致同步，同步性要求较高，其他倒还好。

4.培训、教育直播场景

场景介绍

K12在线教育直播、上网课，技能资格培训等，基本都是主播端在一直输出知识和推流，观众端可以观看直播、点播、视频回放，有个黑板支持主播和观众互动协作，比如在上面举手、写字、画画等。

方案架构

方案说明

多人实时协作黑板，支持互动涂鸦、实时轨迹同步等，屏幕共享、录制回放等。

5.元宇宙直播

场景介绍

虚拟形象、3D形象、虚拟小窝、虚拟世界、虚拟会议等3D场景，此类场景可能需配合一些物品操作功能用于个性化空间搭建，结合丰富的任务互动动作，打造一些特有风格化虚拟空间和形象

方案架构

方案说明

元宇宙的直播方案融合了RTC推拉流，长连接通讯，美术资源编排，角色、动作帧数据同步，Unity层渲染的方式协同打造元宇宙直播方式。当然这里画的只是个简单的元宇宙架构，还有一些虚拟世界玩法比较高级，涉及到多人物控制、自定义运镜、并结合一些硬件来增强交互感。

总结与注意事项

1. 在进行方案选型时得深度分析自己的业务场景，不同场景适用不同方案，当然同一方案可适用于多场景，比如语聊直播，这里面有很多玩法场景，狼人杀、剧本杀、相亲连麦等其实都是同一套方案，可能在处理细节和业务实现上有不同的方式，大体上这一类目业务都算相同场景。

2. 图上列的流媒体服务器相当于RTC服务器，RTC这一块其实这里没做太多详细讲解，因为如果真的自建RTC的话非常复杂和高成本，小、中型公司一般都是采用云服务商的RTC SDK，在选型时要避免一些功能烂/服务不好的服务商，当然最好的办法就是接入多种服务商，这样既不会被单边卡脖子，也能根据需要切换自如。

3. 重视用户体验，比如直播间内一些实时互动的体验，这里没有细讲长连接，大多时候我们都是利用长连接使客户端与服务端进行一个通信，长连接的选型也要根据用户所处网络环境来分析，比如xxx非洲地区，大多都还是用3G网络，这个时候你的长连接选型要求肯定要是数据包小，省流量，弱网抗性强等特点的框架才能满足需要。

4. CDN，能用CDN方案的地方(允许几秒延迟的情况)尽量采用CDN，在云服务商中CDN拉流的整体成本会比实时拉流成本低很多，当然如果公司财大气粗的话可以不用在意，选择实时音视频服务体验更好

作者：消灭知识盲区
链接：https://jueji.cn/post/7218204815121842233。