网易云信流媒体服务端架构设计与实现 _架构设计

实时音视频通话作为高效便捷的沟通手段在许多场景下得到应用。随着5G商用元年的真正到来，实时音视频通话将会得到更加蓬勃的发展。本次LiveVideoStackCon 2020线上峰会我们邀请到了网易云信资深音视频服务端开发工程师鲁林俊，他将结合网易云信流媒体服务搭建的实战经验，进行一些深入的分享。

文 / 鲁林俊
整理 / LiveVideoStack
?
大家好，我叫鲁林俊，很高兴参加LiveVideoStackCon 2020线上峰会，本次我分享的主题是网易云信流媒体服务端架构设计与实现。

文章插图

本次内容主要分为三个部分：一是实时音视频为基础的流媒体服务端设计；二是录制服务方案设计；三是视频会议传输质量控制。
实时音视频为基础的流媒体服务端设计1.1 分发架构
在设计以实时音视频为基础的流媒体服务器之前需要解决的一个问题是：转发方案的选取。讨论比较多的方案有三种：

文章插图

一是Mesh方案，即通话各端两两进行媒体通道的建立，并交换数据，实现媒体通话。从服务器角度看，这种方案比较简单，服务器只要实现一些信令和打洞相关的能力等就可以实现通话，但这种方案的缺陷是通话能否成功建立依赖于打洞的成功率。

文章插图

二是SFU弹性转发方案，下行转发的单位是每个用户的单个流。

文章插图

三是MCU方案，媒体服务器会进行媒体处理，将混合好的音频和视频进行重新编码并转发给下行用户。

文章插图

网易云信搭建音视频服务器时选取的是一个混合转发方案，它是基于SFU为主的媒体转发方案，辅助MCU进行特定场景转发。特定场景比如用户为观众端，可以以一条MCU的流转播给观众端。
这种方案的优势在于：一是基于SFU的设计，服务器逻辑轻、性能好。二是SFU弹性转发设计，可以配合发布订阅的逻辑，做到可选的下行转发。三是可以配合MCU，做到下行宽带的节省以及跨通话系统间的互通简化。
1.2 传输通道和协议

文章插图

协议通道的设计中有两个协议通道：非可靠的UDP通道和可靠的KCP通道。

文章插图

非可靠的UDP通道主要用于传输媒体，可靠的KCP通道主要用于登入、登出、网络状态同步、传输控制等。
1.3 小程序网关和WebRTC网关

文章插图

除此之外，传输层是基于我们自己的私有协议。

文章插图

做PaaS服务仅仅覆盖三端是不够的，要尽可能覆盖更多的平台，比如基于web的开发、基于小程序的开发。由于基于私有协议比较困难，我们搭建了WebRTC网关和小程序网关。
WebRTC网关基于WebRTC标准的实现，接收RTP/RTCP的流，进行协议的转封装，并推送到中转分发服务器的骨干节点上面，最终推送到私有用户上，这就实现了私有端和web端的互通，小程序的网关同理。这两个网关的搭建足够满足纯粹的实时音视频场景，但要做纯粹的实时音视频，PaaS服务是无法满足用户的需求的。
1.4 流媒体处理辅助系统

文章插图

当一个拥有几十万粉丝的用户进行一个简单的聊天时，想要获得聊天内容又想将聊天内容直播给粉丝看，此外，也想和粉丝聊天并将聊天内容给其他粉丝看。这就是在基于纯粹的实时音视频的基础上去获得录制、直播、互动直播的功能。

文章插图

为了满足用户的场景需求，在基于实时音视频为主要核心系统的基础上，搭建了两个辅助的媒体处理系统：直播系统和录制点播系统。
图中左边展示的是实时通话系统，实时通话内容把媒体数据推给互动直播服务器进行媒体数据协议封装，封装成私有协议或者RTMP协议，并推送到CDN和我们自建的直播源站，这样用户就可以基于标准协议从CDN或者直播源站上进行拉流，这也正是图中右侧所展示的直播系统。