背景

随着全民直播时代的到来，以及最近疫情的爆发，在线教育行业又变的炙手可热，成为了新的风口。这两者的背后都是依靠着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	Java	C++	Node.js
快速入门	☆☆☆☆☆	☆☆☆	☆	☆☆☆☆
标准库	☆☆☆☆	☆☆	☆☆☆	☆☆
运行性能 CPU密集	☆☆☆☆	☆☆☆	☆☆☆☆☆	☆☆
并发编程 IO密集	☆☆☆☆☆	☆☆☆☆	☆☆☆☆	☆☆☆☆☆
编译、部署速度	☆☆☆☆☆	☆☆	☆	☆☆☆☆☆
跨平台	☆☆☆☆☆	☆☆☆☆☆	☆☆☆	☆☆☆☆☆
代码可读性	☆☆☆☆☆	☆☆☆☆	☆☆	☆☆☆

这里就不一一进行解释了，总体来说就是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时代。

项目网址：

主页	https://monibuca.com
文档	http://docs.monibuca.com
插件市场	https://plugins.monibuca.com
Demo演示	http://demo.monibuca.com
Github 源码库	https://github.com/Monibuca
Github demo	https://github.com/langhuihui/monibuca

创作场景

重新定义流媒体服务器