重新定义流媒体服务器

背景

随着全民直播时代的到来，以及最近疫情的爆发，在线教育行业又变的炙手可热，成为了新的风口。这两者的背后都是依靠着 CDN 以及视频云等基础服务，而这些基础服务的底层又依靠着流媒体服务器这种有着“悠久历史”的特殊服务器软件。为什么说特殊呢，因为这种服务器软件的架构和传统的 Web 服务器有很大的差别。

在直播系统或者视频会议系统中，有 三大件 构成：

• 推流器——采集、编码、协议封包

• 流媒体服务器——协议解包封包、转发

• 播放器——协议解包、解码、渲染

这三大件有着不同的技术领域，而今天的主角就是其中的流媒体服务器，他的主要职责就是转发。现在让我们看看这位在幕后默默付出的角色的发展历程以及最新的架构设计思想。

流媒体服务器 1.0

本人的第一份工作就是和它打交道，当时它叫 FCS，全称 Flash Communication Server。那时候 Flash 还属于 macromedia 公司。我在一家小公司上班，产品就是用 Flash 开发的视频会议系统以及后来的培训系统，今天看来还是比较超前的。从 FCS，到后来的 FMS（全称 Flash Media Server）现在叫 AMS（Adobe Media Server）基本的架构没有变化。（FCS、AMS 后面统称 FMS）

在这个架构一下面，推流和播放都由 FlashPlayer 承担，FlashPlayer 可以嵌入到网页中，也可以做成独立的 exe。后来官方专门制作了一款用于推流的软件 FMLE（全称：Flash Media Live Encoder）。这 FlashPlayer 和 FMS 之间通过 RTMP 协议进行通讯，这个协议一直到现在还在广泛使用（虽然 Flash 已经被淘汰）。在 FMS 端还可以通过编写服务器脚本进行业务逻辑开发，可以非常方便的实现房间里面的状态同步，这个得益于 RTMP 协议可以传输一些 AS（action script）的指令，包括 RPC、共享对象等。当然如今 RTMP 人们只是用来传输音视频，其他功能都已经被忽略了。

（这里补充一点：微软也有一套流媒体服务器，但使用不是很广泛，就不做赘述了）

流媒体服务器 1.5

由于 FMS 的授权费用相当昂贵，当时一个核心 4000 美金，很多企业都承担不起，尤其是创业型公司。随后就催生出了开源的流媒体服务器，其中最著名的是 Red5，由 Java 开发。以及性能更为强悍的 crtmpserver（又名 rtmpd）由 C++开发。当然这些服务器的功能是不如 FMS 的。我当时潜心研究 crtmpserver，并用 C#进行了移植，这个移植版本在 github 上开源，有兴趣的朋友可以去观摩：https://github.com/langhuihui/csharprtmp基本的结构是一模一样的，就是 socket 部分采用了 C#的非阻塞异步 Socket，然后对象做了池化。

流媒体服务器 2.0

随着 Flash 被封杀，原有的依靠 Flash Player 作为直播的工具被迫下岗。新的技术被不断开发出来，最终形成了百花齐放的局面（其实也是被逼出来的）。

其中安防领域基本都是 RTSP 协议为主，现在逐步形成了 GB28181 标准。网页端由于苹果的影响力，HLS 被广泛采用，不过这个协议最大的缺点是延迟很高，适合观看一些视频节目。DASH 协议是最新的替代 HLS 的方案，增加了更多的功能，不过暂时还没有 HLS 那么流行。谷歌的 WebRTC 发展了多年，由于兼容问题导致流行度没有 HLS 高，但技术更为先进，未来会是非常好的方向。为了追求低延迟我在 2016 年开始研发基于 websocket 的 H5 播放器，现在命名为 Jessibuca（未开源），不久之后 Flv.js 开始支持 ws-flv 协议。（与 flv.js 不同的是 Jessibuca 的渲染方式是 wasm 解码后通过 webgl 渲染到 canvas 上，flv 采用的是 MSE——Media Source Extension），还有一些开源项目也是类似 Flv.js,只不过是其他协议 over websocket 随着移动互联网的兴起，大量手机端 app 开始进入直播领域，由于 APP 可以完全采用私有协议传播所以可以很好的防止视频的泄漏。

那么流媒体服务器又变成了怎样的呢？由于众多的协议需要得到支持，原来的只支持 rtmp 协议的流媒体服务器自然无法胜任，于是很多流媒体服务器开始接入更多的传输协议。我当时为了能很好的接入 WebSocket 协议，就选择了 MonaServer 作为基础进行改写。这个服务器前身是 CumulusServer?，而 CumulusServer?的前身叫 OpenRTMFP。

说起 OpenRTMFP，就不得不说 Flash 的一个 RTMFP 协议，这个协议可以使用 P2P 的传输模式，极大的减少服务器的带宽损耗，所以当时我研究了一番，不过由于 FlashPlayer 并没有开源，即便破解了 RTMFP 协议，也无法替代 FlashPlayer 作为播放器。而且由于众所周知的原因，P2P 逐步的离开了人们的视线。

MonaServer 相比 crtmpserver，采用了更先进的 C++11 标准，代码看上去更加现代，然而 C++的内存需要开发者自己管理，所以好死不死的我改写的服务器出现了内存泄漏问题。排查了一段时间后，发现了更好用的服务器 SRS，并且提供了一个用 go 写的小程序，可以将 SRS 提供 http-flv 协议转换成 ws-flv 协议。用了一段时间后，就希望少一层转换。于是尝试修改 SRS 源码，不过由于 C++功力太浅，就放弃了。但是看到这个 go 的程序写的十分的简洁，几行代码就能实现协议转换，不由被震惊了。当时 Go 语言刚刚兴起，在很短的时间内，就出现了用 Go 开发的流媒体服务器，比如 livego，gortmp 等，（后来还了解到了 joy4）于是尝试采用修改 gortmp 的方式来使用 websocket 协议，修改十分顺利。

当时由于本人从事 Node.js 开发，了解到一款 Node Media Server 的流媒体服务器（还处于早期）和作者进行了友好交流，不过由于测试发现性能并不好，就打消了使用 Node.js 开发流媒体服务器的念头

流媒体服务器 3.0

经过一段时间迭代，为了能够很好的进行二次开发，以及解耦业务逻辑和流媒体核心功能，方便独立迭代，又因为受到 vue 框架设计思想的影响，遂发展出了渐进式开发框架 Monibuca。这套框架建立在以 Golang 语言为基础之上，之所以是 Golang，是由于 Golang 的一些特性所决定。下面和其他语言做一些对比，这里要强调一点：对比含有主观因素，并且只针对开发流媒体服务器这个特殊场景，并非普遍适用。

这里就不一一进行解释了，总体来说就是 Golang 适合 CPU 密集+IO 密集这种情况。

另外 Golang 有一些特别先进的特性，需要说道说道。

✔ 用户态线程/绿色线程/协程（goroutine）

✔ 语言级多路复用（select）

✔ 信道（channel）

✔ 通信顺序进程(CSP)

✔ 读写锁（RWMutex）

✔ context、defer

✔ 组合继承

✔ 函数多返回值

前三个特新其实是服务于第四个特性就是 CSP，简单的来说 CSP 就是方便程序在多线程下进行按顺序执行逻辑，这对于一个复杂的并发为主的服务器程序中可以起到化繁为简的效果。而 context、defer 这种，则可以非常优雅的实现一些“退出”操作，比如发布者意外退出，订阅者意外退出等。总而言之 Golang 所实现的流媒体服务器的代码量远远低于 C++和 java 的。不仅可读性提高，而且减少了很多无法排查的错误的隐患。

下面我们再对比一下传统的转发机制，和 Golang 实现的转发机制

大部分的流媒体服务器的核心都是将数据包进行复制然后通过一个 For 循环分别向订阅者的 TCP 连接逐个进行写入操作。在多线程的情况下就很难进行内存的共享。如果一定要共享内存又会遇到写入阻塞造成延迟等一系列问题。最终需要比较复杂的缓存来解决问题。

Golang 里面 channel 可以很好的实现缓冲队列，同时解决并发的各种复杂问题。内存方面可以通过建立对象池的方式减少 GC。

通过 len 函数可以很简单判断 channel 是否已满，然后采取丢包措施

这种方式已经运行良好，但是一次偶然的机会，一个网友提出了一种新的思路，是否可以采用订阅者自取的方式呢？我当晚就想出了一个绝妙的方式并连夜编写了出来。这种方式用到了 RingBuffer 这种结构结合读写锁，可以优雅的实现首屏秒开，丢包策略等许多操作。起初我采用的是双向链表方式实现 RingBuffer，最终采用了数组来模拟链表，可以方便随机访问，以及计算距离等。数组要实现头尾相连，最佳方式就是将数组的长度设置成 2 的 N 次方。

假如我们的数组长度设置成 2 的 10 次方，共 1024，那么当我们访问到 1023 下标时就到了数组的末尾，下一个就要返回到数组头部，使用二进制按位与操作，就可以快速得到下标 0 了。所以指针+1 后每次都和 1023 进行与操作就可以不用管现在指针到了哪里，也不会出现越界的情况。

那么现在我们如何写入数据后通知所有的订阅者来读取最新的数据呢？这里我们采取一种巧妙的办法，就是通过读写锁（RWMutex）让订阅者通过加 R 锁阻塞在最新的数据那里，等待 W 锁释放。当发布者写完最新数据后，释放 W 锁，所有的订阅者都将在第一时间主动读取到最新的数据，并通过网络发送出去。对于那些网络不畅的订阅者，就会逐渐落后于发布者的位置，此时需要判断落后的距离，如果距离过长就需要启动丢包机制，可以在 RingBuffer 的当前位置跳跃前进，跳跃到下一个关键帧位置开始读取，这样可以保证播放视频的时候不会花屏。另外新加入的订阅者可以直接从最近的关键帧开始读取并追赶，实现首屏秒开。RingBuffer 中的每一个数据块都被重复使用，相当节省内存，也减少了对象的回收。

传统流媒体服务器有一个最大的缺陷，那就是缺乏可扩展性。因为早期传输协议基本都是以 rtmp 协议为主，所以名称也大多和 rtmp 有关系，例如 crtmpserver、simple rtmp server（srs）、gortmp 等等。所以基本上是在实现了 rtmp server 的基础上再进行一些功能的叠加。Monibuca 在设计之初就从根源上改变了这一个基础。在吸收了 vue 的渐进式框架思维的基础上形成了将流媒体核心和协议分离的架构，并采用插件的方式来组合所有的功能。

渐进式设计的价值：

✔ 快速启动项目

✔ 快速理解核心原理

✔ 快速地确立 MVP(最小可行性产品)

✔ 按需加载节省服务器资源

✔ 业务逻辑解耦，保证核心稳定性

✔ 插件之间分开迭代，互不干扰

✔ 逻辑复用粒度适中，插件开源避免重复造轮

✔ 高级插件可用于商业授权，产生收益

✔ 形成生态环境，降低社会总成本

插件运行的机制是通过编译阶段将插件引入到项目中，在运行阶段初始化的过程中将插件注册到引擎中，引擎负责读取配置文件并初始化每一个插件。这个过程有点类似于 vue 中的插件运行机制。Vue 是通过 vue.use 来引入插件，并且通过打包机制生成最终的 js 文件。Vue 插件定义一个 install 函数来执行插件的配置和初始化。同理 Monibuca 的插件定义一个回调函数，并通过调用引擎的 InstallPlugin 函数将自身注册到引擎中。由于 Golang 属于强类型语言，所以插件的配置类型都是在插件内部定义的，引擎并不知道，那么如何让引擎统一的给每个插件传递配置呢？答案是引擎先将总的配置文件序列化成 Json，再逐个反序列化到插件的配置对象中。

后记

在这个直播兴起的时代，云厂商的流媒体服务占据了重要的市场地位，但还有许多中小企业也想在这个红利时期分得一杯羹。传统的流媒体服务器由于缺乏扩展性，使得二次开发非常困难，流媒体服务器的专业性又很强，普通程序员无法胜任，这就使得中小企业无法快速的试错，错过许多机会。Monibuca 为了扭转这个局面而诞生， 使得开发流媒体系统不再困难，这就是流媒体服务器 3.0 时代。

项目网址：