2
雷锋网按：本文作者冼牛，即构科技市场运营总监，香港大学MBA，十年研发经验，音视频云服务技术专家，专注连麦互动直播技术应用研究。 本文是连麦互动背后的混流方案系列的第二篇，接着上一篇：《聊一聊直播利器，连麦互动背后的混流方案》谈要不要混流，来谈谈如何混？在哪里混？
借《无间道》中曾志伟黑老大的名言作为开场白：出来混，迟早是要还的。
虽然话这么说，但是在哪混，跟对了老大，命运际遇就会大不相同。在连麦互动直播中，在哪混（流），同样很重要，做对了选择，用户体验就会大不相同。
在上一篇《混流 vs 不混流》发了之后，很多朋友找到我说：很喜欢这一类技术干货，鼓励继续写下去，但是：1）多配点图，没图的文章基本看不下去，就像没手机吃不下饭。2）不要太长，不求能在卫生间里看完，但求能在上下班路上看完。3）多说人话，少说码农语言，因为老板不编码好多年了。
虽然心里想着：臣妾做不到......，但是一说出口就变成：这个可以有！
闲话少说，容我开篇论道。
在决定在哪混之前，让我们先搞清楚可以在哪里混。
上一篇我们讨论要不要混流，这一篇我们将讨论在哪里混流。
图一 连麦互动直播方案系统拓扑图
图一是目前业界主流的连麦互动直播方案系统拓扑图。
拓扑图里包含以下实体：
1) 推流端（主播端）：主播的工作环境，包括手机硬件配置和网络环境。手机的计算能力和上行网络往往会成为连麦互动直播的瓶颈。
2) 服务端（服务器集群）：庞大而复杂的服务器集群，实现音视频云端的调度和计算能力。具体会包括信令服务器，媒体服务器集群，混流调度中心和混流服务器集群等。
3) CDN网络：第三方独立的公共服务网络，提供缓冲，存储和转发的能力。
4) 拉流端（观众端）：观众观看直播的环境，包括手机硬件配置和网络环境。拉流端一般来说是从CDN拉流，而不会参与连麦互动，手机的计算能力和下行网络不会成为直播的瓶颈。
拓扑图中的实体之间的活动包含：
1) 推流：推流端把原始音视频流推到媒体服务器集群。
2) 拉流：分为两种情形：推流端从服务器集群拉取其它主播的音视频流；拉流端从CDN网络边缘节点拉取音视频流播放，可以是单流或者多流。
3) 转推CDN：分两种情形：如果在服务端混流，服务器集群会把一路混好的音视频流推到CDN网络；如果在推流端混流，推流端会把一路混好的音视频流推到CDN网络。
搞清楚江湖上有哪些山头后，我们就可以明智地选择在哪里混了。
首先，排除CDN网络，因为它是第三方服务，在连麦互动直播云服务平台的掌控之外。
接着，在拉流端混流其实就是上一篇中提到的不混流方案。拉流端拉多流，在播放的时候根据业务侧的需求，对多路流进行灵活操控。拉流端混流方案的优势是高度灵活易于操控，劣势是网络带宽成本相对比较高。因为已经在上一篇深入讨论过，所以这里不再展开讨论。
最后剩下的选择，是推流端和服务端：推流端使用了音视频云服务的SDK，服务端是提供音视频云服务的服务器集群，两者都是可以做混流的地方。
决定在哪混？
我们现在要决定在哪混，摆在面前有两个选择：推流端 vs 服务端。
我们要搞清楚在推流端混流和在服务端混流的优势和劣势，才能作出明智的选择。
如果要搞清楚在推流端混流的优势和劣势，那么得先搞明白在推流端混流的技术逻辑。
图二 推流端混流技术逻辑图
图二是在图一的基础上，增加了推流端混流的技术逻辑（蓝色部分）:
1) 推流端向服务器集群推原始音视频流。
2) 推流端从服务端拉取其它推流端推上去的音视频流。混流将在第一主播的推流端进行。第一主播要等到其它所有主播的音视频流到达以后才能开始混流。
3) 推流端进行混流的工作内容包括解码，对齐画面（音画同步），抖动缓冲，和重新编码。
4) 推流端（第一主播）把混好的单流推到CDN网络，以便拉流端拉流播放。
接着，让我们看看在推流端混流会带来多少额外的工作量。
在推流端混流有以下步骤：
1) 推流端拉流，等待其它主播的音视频流到达、2) 解码、 3) 混流、4) 编码、5) 转推流。
其中第1步至第2步是推流端在不混流的情况下也必须要做的事情，第3步至第5步是在要混流的情况下额外增加的工作。两路流混成一路流的工作量大概是解码一路流的一半不到，解码一路流的工作量大概是编码一路流的一半。然而，要考虑随着混流数目的增加，混流的工作量也会相应增加。
然后，让我们看看混流的要求和推流端的特点。混流是一个比较烧资源的事情，推流端是一个比较缺资源的地方，这俩天生八字不合。现在突然说要让它们在一起，那我们就要先研究一下它们的要求和特点。
（推流端）混流的要求
1) 比较好的上行网络带宽，因为推流端（第一主播）要推原始流和混流两路流。另外，网络要保持相对稳定，因为混流过程中的抖动缓冲将会由于网络不稳定而加长，从而增加延迟。
2) 比较好的手机硬件配置，因为要对多路音视频流进行转码和混流，比较耗费计算资源。如果需要转码的音视频流的码率总和比较高的话，某些采用软编的安卓平台可能会出现手机太烫，从而导致摄像头采集的时候丢帧的现象。
推流端的特点
1) 主播的网络环境可能是家庭宽带或者4G。下行带宽大概100M bps, 上行带宽大概1M bps。家庭宽带的稳定性和网速会随着繁忙时段而变化。这个在我国生活的人们都懂的。
2) 主播的直播终端是主播个人的智能手机。目前主流的手机配置是四核，可以进行连麦互动直播。然而，手机硬件配置终究难以和PC相提并论，更不要说和服务器相比了。
3) 不可控。直播业务平台或者直播云服务平台都无法掌控推流端的手机配置和网络环境。传统的秀场直播平台或者和传统媒体结合的直播平台会给主播提供直播间，拥有比较好硬件配置和网络环境。其它娱乐直播平台的主播一般都是使用个人手机和家庭宽带进行直播的。
这么摆开来一对比，一眼就能看出这俩真是八字不合：一个处女座，一个不给力。
最后，让我们来总结一下推流端混流的优势和劣势。
1) 成本低
整体来说，推流端混流是一个低成本的方案。它在两个方面降低成本：计算资源和网络带宽。本质上，在推流端混流就是服务端把混流的成本转嫁给推流端。服务端的计算资源和网络带宽都相对比较昂贵，而推流端的计算资源和网络带宽都是沉着成本。如果在推流端做混流，就降低了服务端的成本，充分利用了推流端能共享的资源。
2) 服务端压力小
在服务端混流是相对来说是集中的模式，这样会增加服务端的压力。在推流端混流是完全分布式的模式，这样可以降低服务端的压力。
3) 本地输出混流后的数据
在推流端混流以后将会输出混流后的音视频流，这样方便本地进行录制，或者直接把音视频流推到CDN网络进行分发。
在推流端混流的劣势
1) 增加额外延迟
首先，在推流端进行混流会增加额外的延迟，主要是因为要等待所有其它推流端的音视频流到达，才能开始混流。从图二我们可以看到，在服务端混流，只要所有主播的音视频流到达服务端，就可以开始混流；在推流端混流，要在前者的基础上，其它所有推流端的音视频流再被拉流到推流端，才能开始混流。这是额外的时间开销。其次，推流端混流完毕以后推流到CDN网络的延迟也相对较大，因为推流端的硬件配置和上行带宽质量都无法和服务端相比。最后，考虑到推流端种种不稳定的情况，额外的延迟只会增多而不会减少。
2) 手机硬件配置瓶颈
在推流端进行混流要求比较好的手机硬件配置。一般来说，目前主流的四核手机能满足连麦互动直播的要求。然而，如果算上混流的工作量，手机的硬件配置将会成为瓶颈。比如说，如果安卓手机采用软编，并且需要混的音视频流的数目比较多的话，手机会因为计算量较大而发热，很可能会导致摄像头（离CPU比较近）采集视频的时候出现丢帧的现象。
3) 上行网络带宽瓶颈
在推流端进行混流要求比较好的上行网络带宽。如果下行网络带宽是100M bps，那么上行网络带宽相对应一般是1M bps，好一点的会到4M bps。根据即构科技的经验，音视频流平均的码率是800k bps。推流端将会推两路流：原始的音视频流和混流后的音视频流，因此总共推流的码率大概是1.6M bps。再考虑到网络带宽在上网人数较多的时间段会打折扣，和网络不稳定等情况，推流端的上行网络带宽往往是不能够满足推流端混流的要求的。
4) 推流端环境不可控
综合上面第二和第三点，推流端的环境是不可控的。直播业务平台或者直播云服务平台都没办法管控推流端的硬件配置，使用习惯，网络信号和网络带宽等因素。因此，在推流端做混流的效果也是不可控的。
5) 难以扩展
在音视频云服务方案设计阶段，我们预期方案是易于扩展的。随着直播业务平台的发展，对推流端的计算能力和网络带宽都将会有升级的要求。然而，推流端的环境是不可控的，而且也是难以扩展的。相对而言，在服务端做推流，如果要增加服务端的CPU或者增加网络带宽，都是在音视频云服务平台掌控范围以内的事情。
综上所述，推流端不是一个理想的做混流的地方，但是它提供了一个低成本的混流方案。推流端混流能够满足相当一部分直播业务平台的某个发展阶段的业务需求。这个市场需求是应该被充分发掘和满足的。
如果要搞清楚在服务端混流的优势和劣势，那么得先搞明白在服务端混流的技术逻辑。
图三 服务端混流技术逻辑图
图三是在图一的基础上，增加了服务端混流的技术逻辑（蓝色部分）:
1) 推流端分别向服务器集群推原始流。
2) 服务端等待所有推流端的音视频流到达以后，开始混流。混流的工作内容同样包括解码，对齐画面（音画同步），抖动缓冲，和重新编码。
3) 服务端把混好的单流推到CDN网络，以便拉流端拉流播放。
接着，让我们看看在服务端混流会带来多少额外的工作量。
在服务端混流有以下步骤：
1）推流端推流，服务端等待所有主播的音视频流到达 2）解码 3）混流 4）编码 5）转推流。
所有步骤和在推流端混流几乎一样，只不过工作环境不一样。所有的步骤都是服务端额外增加的工作量。服务端混流的工作内容和推流端混流不一样的地方在于：推流端解码是不管混流还是不混流都要做的事情，而服务端解码却是因为要混流才额外做的工作。
然后，让我们看看混流的要求和服务端的特点。混流是一个比较烧资源的事情，服务端是一个资源比较丰富的地方，这俩貌似比较般配。现在突然说要让他们在一起，那我们还是要先给他们对一下八字。
在推流端混流的要求在上面已经分析过，这里只讨论在服务端混流的要求。
（服务端）混流的要求
1）比较好的上行网络带宽。所有推流端推出的音视频流在服务端集中，混流以后再转推到CDN网络。每一个连麦直播间相对应一路混流，因此这种集中混流的方式对服务端上行网络会造成一定的压力。
2）比较好的服务端硬件配置。这种集中混流的方式对服务端的计算资源会造成一定的压力。
服务端的特点
1) 网络带宽资源相对比较充足，而且支持扩展。
2) 计算资源相对比较充足，而且支持扩容。
3) 完全可控。音视频云服务平台可以根据网络和计算的压力对服务端进行配置调整。
4) 可以扩容。服务端一般都会采取服务器集群的设计方式，具有弹性，和可以扩容。对于网络带宽和计算资源的增长需求，可以比较灵活地进行升级，甚至可以做到动态地分配。
这么摆开来一对比，一眼就能看出这俩真的比较般配：一个喜欢买买买，一个家底丰厚。
最后，让我们来总结一下服务端混流的优势和劣势。
在服务端混流的优势
1) 低延迟
在服务端混流，天然地具有低延迟的特点。在服务端混流只需要等待所有其它主播的音视频流到达服务端就可以开始混流；在这个基础上，在推流端混流还要从服务端再拉流到推流端，要等待所有其它主播的音视频流被拉下来后才可以开始混流。在服务端混流的系统设计天然地比在推流端混流减少了这一段的网络传输的时间。另外，服务端的计算能力和网络带宽都是要比推流端高几个量级的，混流的过程和推流到CDN网络所耗费的时间，在服务端都会比推流端要来得少。综合起来，服务端混流可以获得比推流端混流低的延迟。
2) 计算资源充足
服务端的计算资源相对充足，而且可以进行扩展和调度，不会成为瓶颈。
3) 网络带宽资源充足
服务端的网络带宽相对充足，而且可以进行扩展和调度，不会成为瓶颈。
4) 可控可扩展
其实这是服务端最大的优势。在服务端有着云服务平台充沛的资源，可以进行弹性的调整和扩展，有着专业团队专业的服务和强力的支持。这是云服务平台的优势；这是集团军作战的方式；这是靠组织打硬仗的理念。说得通俗一点，根据即构科技的经验，1个核可以支持5路流，8个核就可以支持40路流，随着流不断增加，我就不断增加CPU，无感知地增强计算能力。换成终端手机的话，是没办法增加CPU的，要么换手机，要么只能等着烧糊。
在服务端混流的劣势
1) 成本高
在服务端混流，会让服务端承担了额外的计算成本和网络带宽成本，从而推高运营成本。
2) 压力大
在服务端混流，也叫作集中式混流。音视频流的带宽压力，以及转码和混流的计算压力都会汇集到服务端，天然地增加服务端的压力。这个情况也对服务端的架构设计提出挑战，要求服务端能够有扩展性，能够通过分布式和集群的方式来应对压力。
综上所述，服务端是一个理想的做混流的地方，它拥有低延迟和高服务品质的优势，但是它的成本也相对比较高。它能够满足相当一部分发展成熟或者走精品路线的直播业务平台的业务需求。这个市场需求是主流，而且是未来的趋势。
经过上面的论道，我们回过头来对比在推流端混流和在服务端混流的优势和劣势，我们会发现这两种方案其实各有各的优点。都代表了可观的市场需求。在行业发展的各个阶段，这两种需求都应该得到尊重和满足，以促进行业的健康发展和成熟。
然而，从一个中长期的视角来看，云服务平台的优势已经被承认和充分发展。云服务平台的哲学就是：通过云服务平台的资源和能力，加上专业的团队，给业界提供高质量的专业服务。在服务广大客户群体的过程中，即构科技观察到这样的趋势：越来越多的直播业务平台，特别是第一梯队的平台，十分善于借助云服务平台的优势来确保高质量的用户体验，进而快速地扩大市场份额。
好了，搞清楚江湖上各个山头的好处和不足后，我们就可以机智地选择在哪里混了。总而言之，有三个地方可以混（流）：推流端，服务端和拉流端。即构科技侧重考虑用户体验和服务质量，优先提供了服务端混流和拉流端混流两种方案，并且会在适当的时机，根据市场需求提供推流端混流方案。
最后，回应一下读者的吐槽：为毛你的文章看起来那么像编程语言，那么对称和结构化？
我的回答：你说呢？这些文章都是我把即构团队的源代码，经过Google Translate翻译成中文以后，再加以人肉润色而成的。技术背景的同学请自行体会一下。
这一篇讨论完了推流端和服务端混流的故事，下面还会继续分享即构科技的技术经验，一篇一个技术点。请继续关注即构科技技术干货分享系列，欢迎交流，拍砖请轻。
雷峰网原创文章，未经授权禁止转载。详情见转载须知。
