在互联网云时代的今天，实时音视频的各种计算也在向云端发展,由于音视频的数据计算量巨大，加上移动、联通、电信等运营商之间的互通问题,使得中心云端的计算压力巨增，互通性的成本也随之增加。为了最优的解决这一矛盾，三体云在实践中不断的改进优化，实现了一套充分利用边缘云端分散计算的方式，很好的解决了这一矛盾。
大家好，我是来自三体云后端服务器的架构师时杰，从事有关编解码方面的工作。今天与大家分享的内容是三体云服务器在音视频合成的元边缘计算方面的发展历程。 之前我是从事广电行业的，也从事跟音视频网络相关的工作，但模式跟现在是完全不同的，以前3G、4G初的阶段面向的更多是广电系列的电视台、HTV之类的视频，与现在实时互动视频还是有一些差别的。
进入互联网时代后，在实时通讯方面，不光终端是端对端的，有很多计算都要通过服务器进行一些混合运算。比如多个主播进行连麦的时候，他们的音视频要进行合并后传递给观众，他们所看到的数据并不是直接从采集端发过来，而是要通过服务器进行各种加工、渲染，最后推到终端。问题是在所有的计算过程中服务器的结构过程会遇到各种的问题。今天跟大家分享的就是如何解决以及优化遇到的问题，并介绍一下三体云在其中是如何做的。
这次演讲的内容主要分为四部分:第一是音视频合成的相关的一些解释，为后面做云端分散计算进行铺垫;第二是音视频合成整链路的基本结构;第三是音视频合成计算的发展历程;最后是三体云在国内、国外一些案例的结构模型。
1. 音视频合成的相关解释
1.1 音频合成
音视频合成从文字上解释就是将发言者的声音通过混音器合成之后再输出的过程，也称之为混音。合成器可以是硬件也可以是软件，在服务器结构里不强调什么是硬件和软件的。这张图就很好的诠释了音频合成的一个过程，图中有四个音频输入，经过服务器进行合成后输出到混音，这是音频合成的一个简单的模型。
1.2 视频合成
视频合成是将所有连麦者的视频画面通过采集编码后 通过服务器解码进行混合，根据指定的布局或者样式进行布局，合成之后再推到观众端。这张图就是一个简单的模型，所有的主播或者终端客户，他们采集自己的视频到服务器进行一个合成，再推到观众端。这两个点服务器都有在进行大量的音频或者视频数据计算，我们需要做到将这些大量且复杂的运算进行边缘化。
1.3 节点类型
音视频合成链路基本结构里涉及到一些图形节点，一种是客户端，像手机、平板之类的电子产品通过采集或者声音的捕捉都是可以的。另一种节点类型模式是SFU，它只负责一种点对点的转发传输。最后一种节点类型是MCU，它是一个真正的核心运算终端，是一个多点控制单元，将所有终端上传的数据进行正常的分发以及合成。 其次，服务器所属机房分为单线和多线，就是某一个服务器在云端的部署时，它具有运营商的特性。比如举国内的一个例子来说，单线的指针可以是联通的或者是移动的，如果一个客户端本身是非联通、非移动，而是电信的，那这时就需要一个多线，它支持所有运营商的接入，这就区分了两种服务器的接入方式。
2. 音视频合成链路基本结构
2.1 SFU模型
下面介绍这种接入方式在服务器结构部署上的优势以及劣势，这张图是解释SFU的一种模型图，它是所有的终端进行SFU服务器的转发传输，并且是单进单出的一个模型。
2.2 MCU模型
下面介绍这种接入方式在服务器结构部署上的优势以及劣势，这张图是解释SFU的一种模型图，它是所有的终端进行SFU服务器的转发传输，并且是单进单出的一个模型。
2.3 单线模型
这个模型表示了一个简单的单线，这里以联通为例，如果左边用户是联通，只能接受一个单线服务器，那么右边的出口也只能和联通的另一个终端用户进行连接。
2.4 多线模型
如果两个用户不是同一个运营商，就需要一个多线服务器进行连接，多线服务器是不需要识别具体的运营商的，它的任何运营商都有接口接入的，而且它的出口也是多点的，这样所有的终端用户都会连到一起，并且畅通无阻。但问题是成本太高。对此的解决方案是用一个单线服务器，让它去承载三线所带来昂贵费用的功能点，然后分散到单线上，这也是我们这次内容的关键和中心。
2.5 节点之间的关系
节点之间的关系主要有两点：
- 一是所有节点之间都有网络链路连接传输;
- 二是节点之间以多媒体流处理和转发为主要功能。
3. 音视频合成计算的发展历程
3.1 音视频合成计算的第一阶段
这张图就是音视频合成的第一阶段模型，在2017年三体云成立之初，服务器结构全部都是以这种方式进行接入的。 这里列举一个简单的点对点、一对一的图，当然在现实的服务器中不是一对一的，而是非常多的。图中的椭圆形表示一个多线的服务器。图中的方形表示一个单线的服务器。服务器所具备的功能是图中所标识的SFU和MCU，通过前面概念的讲解，可知SFU是用来传输的，而不是用来运算的，而MCU不仅仅用来传输，里面还掺杂各种的混合运算。图中左边黄色的client1以及右边绿色的client2，它们在进行连麦时，各自有各自所对应的多线的服务器进行连接。这个时候就不去具体区分client1和client2是哪一个运营商，它们在接入服务器之后就可以畅通无阻的进行接通了。这种模型看似没问题，也解决了实际问题，使得client1和client2可以畅通地进行连麦通话，但问题是图中红色部分其实是在负载，计算client1和client2上所有数据的混合运算，所以图中红色标记都是运算的标记。图中所有的服务器都是一个多线服务器，所以在线上很多的服务器的结构是非常简单的。但问题还是过高的成本。
3.1.1 第一阶段的简介
中心计算节点都是多线IDC机房的(MCU)服务器，实现所有运营商之间的通讯，简单易实现这是它的一个特点。但问题是它的压力大，成本高，因为它是多线，就意味着所有的client都会去连接它，我们在做中心运算的时候是一个服务器在进行，不可能每一个服务器都在进行运算，因为要有一个数据的汇聚，这就是第一阶段的一个模式。还有一个问题就是计算和转发没有分离出来。图中所有多线服务器的SFU和MCU都在一起，没有分离出来，这就造成后面要提到一个问题。下面这个模型就是client1通过SFU和MCU多线，将刚才的图形模型以这种方式描述出来。
3.2 音视频合成计算的第二阶段
通过第一阶段后来看一下发展的第二个历程。在音视频合成的第二阶段，就只有一个三线服务器了，而且是红色的标识，它是参与中心计算的。左边方块的SFU和右边方块的SFU，仅仅是用来进行client1和client2的用户上行的接入转发的。如果client1是联通，client2是移动，那么它们所对应的图中黄色的单线服务器就是联通，绿色的SFU就是移动，所以它们汇聚时通过中心MCU是可以接入的，这就将一个多线的服务器变成两个不需要运算的、低成本的单线服务器接入了。
3.2.1音视频合成计算第二阶段的简介
这样一种进化，使它的计算压力并没有得到缓解，但是它的结构发生变化可以部署更多的SFU边缘计算机。所以它的特点就是以中心计算为主，以边缘为辅，因为边缘已经被慢慢地剥离出来，这样做就减少了多线服务器的压力，这种压力的减少更多的是在传输上进行了减压，但是在运算上还没有得减压，所以刚刚提出的问题还没有被解决。将上行分散到单线服务器，刚才第二阶段的上行全部都是单线服务器了，特点是这样的软件结构比第一阶段复杂，因为要实现SFU在传输过程中找到对应的三线服务器，而且需要更多的SFU服务器。还有一个特点就是计算和转发是分开的，但问题还是中心计算问题并没有得到实质性的解决，只是把转发的这一部分功能从多线服务器剥离了出来，但是计算还停留在第一阶段的结构上。
3.3 音视频合成计算的第三阶段
接下来是第三阶段的进化，这也是我们目前三体云线上所部署的正在使用的一种场景。这种阶段不是最终的目标，但就目前而言是比较优化的。 图中可以看到client1和client2，它们各自接入自己的单线服务器上行，比如client1是上海，client2是北京，它们会找最近的SFU服务器以及对应的运营商，同理client2也会在上海找对应的这个SFU服务器以及相对应的运营商，并把数据传输到对应的MCU服务器。问题是图中红色的MCU，方块MCU代表的是一个单线。在第三阶段，我们已经把计算的方式开始边缘化，已经分配到它所对应的单线的MCU服务器上了，还要保证client1和client2畅通无阻的连接，所以还需要图中右边椭圆形的多线服务器去进行汇聚连接，这就很好地把中心计算剥离出来并将其分散到单线MCU。但并不是右边的SFU跟MCU多线服务器不进行计算了，而是中心服务器的运算量在减少，这只是一个client1和client2简单的连麦模型。而线上是一个网状、树状的结构，它的连接关系是非常的复杂的，这里SFU和MCU多线服务器起到了多运营连接跳转的作用，所以SFU和MCU中心节点还是不能省的，但是它们在client1和client2连接过程的模型中只做了转发，没有做任何的运算，这就达到了音视频计算边缘化的目的。
3.3.1音视频合成计算的第三阶段的简介
第三阶段就是分散到边缘，减少多线服务器的压力，所有的单线服务器都是参与计算的。但特点是软件实现复杂，即通过我们的设计结构以及框架去改变之前的中心节点计算下压力大的问题，就是把它的复杂度通过软件的实现达到减少压力，减少成本，减少多节点服务器的目的，这样每一个服务器都参与了计算，并且SFU和MCU的软件部署是可分可合的，这也使得部署过程非常灵活。 模型中的SFU单线到MCU单线，在实际的生产过程中，为了节约带宽成本，图中左边红色单线中心计算服务器MCU和黄色的SFU(大概率)在同一台服务器，可以节省左边黄色的SFU到MCU之间带宽的费用，因为两者都是单线，能够连接说明它们具有相同的运营商属性，所以把它们部署到一块，可以节省两者之间的通信带宽的费用。 其次，边缘计算还带来另一个节约成本的作用，在第一阶段，每一个三线中心服务器在做运算的时候，它汇聚所有的客户端传来的数据时，势必会增加宽带的压力，就意味着服务器所承载的95峰值计算的峰值达到很高，不利于成本的节约。相反，单线服务器承载运算之后，每一个点都在运算，它所承担的数据汇聚就把之前的中心节点分散出来，使得95峰值的带宽降下来，进而节约了带宽的成本，这就是边缘计算带来的成本上的节约。 图中SFU和MCU左边红色标识，它们在一个服务器上，就使得它们的带宽得到节省，传输距离也缩短了，短距离的网络传输使得延迟变短，传输更加流畅，卡顿率降低，这方面就得到进一步的优化。以前的方式，中心量大，CPU的总线以及带宽的总线都达到了极致，就会造成卡顿，并非是距离上的，而是负载上的，负载太高就会造成卡顿，也更容易丢包，所以把这些问题分散就能解决了。
4. 三体云的国内、国外案例模型
4.1 三体云的国内案例模型
这部分是三体云在目前服务器部署上的一个简单拓扑。是前面所讲的client1和client2稍微复杂的一种拓扑图，所有的client对应的是单线的SFU，都有各自的运营商。 这张图是一个国内的例子，表示一个房间里的连麦，在这个连麦的过程中，所有用户在一个房间内进行连麦只使用一个多线服务器，并且大量使用单线边缘的服务器。图中红色标识承载了房间内所有用户的混流的合成运算。从业务上讲，图中C1、C2可能是主播，由它发起创建一个房间，所以离它们的计算服务器最近，其他与之连麦的主播通过它们各自的SFU和MCU进行转发，汇聚到主播所在的SFU多线服务器，最后再汇聚到SFU红色的方块内进行混合运算。混合运算以后就推给它所在的粉丝或者是观众。
4.2 三体云的国外案例模型
国外看似跟国内没什么区别，图中展示也只是图形发生变化，在国外没有单线服务器的概念，所有的服务器都是多线的，可以随意的联通，但计算的点还在主播端。 在实际的生产过程中，有一个案例，在印度有一部分人在房间内做交互，如中间这张图，他们视频连完之后，计算就在他们的计算范围内。如果会议需要一部分印尼人参加，需要把印尼的数据直接传输到印度所在房间的MCU中心计算服务器上。先将印尼的数据进行收集，通过离得最近的SFU服务器汇聚到他们所在的SFU、MCU多线服务器，汇聚完之后把他们的数据统一汇聚到印度MCU中心计算服务器上，最后再输出。同理，左边的迪拜，可能人数更少，也是按这样一个过程进行。 这种方式的好处是不需要把每一个人单独通过他们的单线去连接到印度，而是在印尼做一个小范围的汇聚，然后再全部汇集到一起。好处是比如图中绿色和红色的椭圆的中间的连线出现了问题，因为跨国的带宽费用高，保证性也比较差，万一出现了中断，至少印尼里C3、C40、C41三个用户所组成的结构是可以互通的，互通完后网络有可能变好或者恢复，所以这是一个树状的结构，保证小局域范围内的安全性。
4.3 三体云的国内、国外案例模型对比
将国内和国外的两个案例模型做一个比较，国内和国外的网络运营方式不同。国内多运营商，互通性是有问题的，我们的联通、移动是不通的。这种跨运营商之间的互通的中断，很容易造成三线节点增多，带来的不确定的因素就越多，就增加卡顿以及掉线率。所以如果用单线和用一个多线服务器技术进行中转的话，因为多线节点变少了，效果就会好很多。 而国外是没有单线这样的问题的，全部都是多线，所以边缘节点可以任意选取，如果用户发起一个房间的连麦，那么他所在的多线边缘节点就参与计算，以及区域内的保障和区域之间互通的特点。
4.4 三体云边缘计算
从2017年经过这样一个优化过程到现在，得到了如下一些成果，首先因为单线多了，部署节点就更多，这就意味着所有的客户端在连接各自的服务器时就更近、更容易，那丢包和卡顿就会很少，像前面讲的峰值、带宽的成本也会下降。所以服务器越多，节点边缘越多，它的覆盖用户越多，贷款成本、核心负载下降，这就达到了我们让所有线上的服务器都运转起来、都参与计算的预期效果。
5. 总结
总的来说，三体云在去中心充分利用边缘云端分散计算的方式使服务器资源得到最大限度的利用。相比之前的方式，大大降低了服务器成本，因为单线服务器成本几乎等于多线服务器成本的三分之一，甚至更低。虽然服务器的成本下降，但边缘计算还将持续优化下去。虽然这种部署是每一个边缘节点都参与了计算，但并不是每一个都参与计算才是最好的，往往要根据流量，包括成本控制去计算，比如两个人都在上海，各自上行对应各自的服务器，如果把他们两个上行的用户都通到一个服务器上，那另一个服务器目前就空出来了，但是这并不能给服务器的带宽带来质的飞跃，并不影响它的计费，这种情况下服务器就可以省出来并用来做其他事情，这也是一种优化。所以我们的优化方案需要不断地调整，也希望大家在这次的分享中得到一些启发。
