大家好，我是金山云视频技术总监郝明非，在15年年底的时候做过一次移动直播最佳实践的分享，经过一整年的直播元年，看到直播市场有了很大改变，我们自己的服务也在不断演进，想在这里跟大家分享一下，我们做过的事情和趟过的坑。

视频需求推动云服务布局

我们这一年所有的改变，包括我们在云服务上的布局，都是围绕客户的需求来做的，直播这个业务和以前的业务还不太一样，客户特别敏感，我们出现几秒钟抖动，很快报障电话就都来了。客户对高可用的要求始终是最高的，这也很好理解，你做不好高可用，客户那边就是每天不停的赔钱，所以做高可用始终是我们被需求驱动的一个点。但是没有一家能够敢保证自己的高可用能做到百分之百，在服务出异常，或者有流量在某个地区突增的时候，你要把这个调度权交给客户，所以我们始终在布局的时候没有把带宽绑定在自己手里，把开放作为我们始终坚持的一个点，就是让客户能够了解到我们CDN各个节点以及整体的业务情况，把调度的权利交给客户。从去年年底开始开始接触到一些应用，希望在成本或者画质上深耕，同样在移动直播，有的人在用500K做推流，也有人用800K，也见到了一些客户开始用1M，随着码率的增长画质在变好，但卡顿也在上涨。如何在保证服务质量这个前提下，给客户提供持续的高画质的体验也是我们考虑的点。

金山视频云整体架构及历程

这是我们现在整体的视频云架构，因为我们从最开始就是想要做视频云，而不是纯粹在做CDN服务商，所以做了很多配套，开发顺序都是先做好配套，然后才做的CDN，也就是这个最开始的出发点决定了我们架构演进的每个环节，也带来了我们后头遇到的各种问题。我们认为有了全链路配套，很多东西都可控了，像教育垂类用到的翻页和视频内容的强同步这种需求，对于我们来说推流端在自己手里，CDN在自己手里，播放端也在自己手里，这种强同步的消息通道还算挺容易的一件事情，我们也把这个能力也开放出来，不管是在传输链路上开放的接口，还是在端上开放的接口，都可以把这个传输道用起来，这就是我们做全链路可以在更多垂类上去发力的一个思路。

服务端架构演进

1.直播CDN架构1.0

我们架构的演进，分享下我们趟过的坑。我们最开始也只是定位成一个源站，并没有想做CDN，所以就去基于其他家的CDN做分发，专注把源站做好。在一个region的两个机房，做了一套视频处理和分发的源站，这么做最大的好处就是好维护，我们只有一个大点，所有的流在这一个中心里面，信息都在一起，这个服务有任何波动，稍微掉一点量，我们马上就能发现得了，这个运维的成本就很小了。

这个思路不光是我们去年在用，现在有一定流量规模的客户，希望自己的掌控力更强的时候，也开始用这种架构来做自己的源站，收到流之后可以选择这些流给哪家CDN来分发，可以做视频的后处理，可以用自己的私有协议，很多好处。另外对于运维来讲易于维护，而且用BGP接收推流质量也还不错，通过我们的客户端数据做过横线比较，BGP收流和全国100个节点收流的质量相当，不好的地方也有，就是我用一个单点收流，链路不好时没有运维调整的手段，而且成本较高。

有了自己的源站之后，发现第三方融合很难把控质量，有些全链路的思路会在CDN分发的环节被卡住，于是我们就开始做自建分发，传统的树状结构，只是用来解决下行分发问题。

这套架构能满足多数需求，在我们专注做移动直播垂类阶段起了很大作用，但推流的单点问题始终是个隐患，因为源站背负这流媒体分发源头的责任，网络的波动会导致所有观众观看卡顿，影响我们一大片的服务质量，这种单点问题会影响我们业务继续发展，所以我们就就开始考虑，如何把这个问题解决，进入2.0的阶段。

2.直播CDN架构2.0——明确源站定位

在2.0阶段，我们做了最主要的一件事情就是明确了源站的定位，之前的源站既做了收流的中心，又做了视频处理的中心，还做了分发的中心，这对源站的质量要求太高，所以重新定位了源站，去掉一些功能属性，不让他再做分发的中心，目标是做好视频处理和垂类开放，这样即使在分发环节，把源站摘除了，像这种以直播为命脉的客户也完全不会感知到。把分发的高可用交给CDN完成，源站专心做好自己的角色，比如延时播放和内容审核。

直播的延迟不是越低越好，而是越可控越好，我们做了延时直播的功能，现在看到很多在直播上面的监管和审核的需求，我们在源站这个环节做了一些延迟设计，这个延迟有两个好处：一个是可以用来做审核，直播我们会提供两路流，一路用于审核、一路用于观看，这里我们还做了一系列API接口，就是如果你在运营的过程中发现有违规内容，你可以选择在什么时候封禁、什么时候恢复；第二这个延迟也可以用来抵抗卡顿，比如跨国推回来的时候，我可以把这个延迟用来抵抗推流过程中的不连续，像这种的定位就交给了源站，做好视频的后处理和增值的内容。

这张图其实和现在很多的CDN架构长得一样了，就我们用所有的边缘都去接推流，用上层来做分发的源头，上层这边我们也尽量减少对状态服务的依赖，也不希望由于状态服务的一个事故就导致这个流不可分发了，所以在上层会做一定哈希的事情，这样下来之后即使源站没有了，这个分发还是不受影响的。这个架构每一层接流之后都是可以分发的，刚才也有人提到了附近的人，不同的位置的人听到附近的人会感受不一样，有的人可能会觉得是一个社交关系，但是在我看来它就是个冷流，把我的成本又拉上去了，所以我们用收流的边缘节点就近分发，主播如果和观众在附近，就不用再一路回源回去，带来很多上层的回源带宽，直接用边缘去分发。这个架构做出来之后，其实就有一个可选择的地方了，像刚才源站可以把流推给友商或者推给第三方用户，边缘也有这个能力可以推出去。

那到底应该用哪个模块来转推会更合理？我认为这个就是一个场景的问题，比如客户如果希望这个转推流的质量，信息更实时、更准确，它可以选择我们用核心节点去推出去，这样的话我们在本地、在机房内部就可以把所有的转推信息实时汇总到数据库，通过接口就可以很快的查询到，如果是在边缘的话这个汇集可能会有一些延迟，尤其是如果这个转推出去的目标地址是客户的源站，我用全国几百个节点去推客户的源站的话，客户就要做好对这几百个节点的覆盖，对客户那边也是一个技术要求，但是我们如果用核心节点来做的话，其实核心节点质量相对还比较好，客户只需要关注一下他的源站和我们的核心节点之间的质量怎么样，所以从核心节点推也是有很多客户有这种需求的。从边缘转推适合多家CDN厂商互备，像现在很多游戏类的客户都会希望我们用边缘来转推，倒是对我们边缘转推的实时质量不是很关注。

全链路配套演进

第二个演进就是我们全链路配套的演进，这个主要是端的工作了，这也是我们和别人不太一样的地方，我们开始就做了很多端的工作，刚才花椒唐总分享的时候，也让我想起了好多去年我们在端上趟过的坑。这是我们最开始基本的框架，像刚才讲到的一些秒开、同步这种问题的解决也都是必备的了，此外当时在场景变换这部分，客户拿着手机这么快速的来回转，一转就看到编码的码率突增，推不出去了，会卡一片，算法的同学帮我们调整参数，在这种快速晃动的时候码率不会出现突然的一个尖峰，只要这个尖峰没有了后面的卡顿也就没有了，就很多这种细节的坑都是在这个阶段趟的。

1.金山云直播SDK组件化

趟过了这个阶段之后，我们就进入第二个阶段，输入能够支持的设备越丰富，我们能产生的内容也就越丰富，我们现在可以去接高清的镜头，去接在手机上直播，可以接第三方的那个无人机，可以录屏，可以用连麦，就这种输入的东西越来越丰富，内容也就越来越丰富，也越来越好玩儿。在图像处理这里加了美颜，滤镜，肢体识别和人脸识别，这些有的是我们做的，有的是第三方做的，让客户可选。这里有一些客户就是喜欢第三方的，但他自己集成的时候遇到很多问题，因为涉及到了音视频的基础的流码，涉及到一些处理和对接，我们就帮他做，越做越多之后就发现我们越来越像一个插件化的东西了，后面就会想往插件化转的这个思路。

在这一步的时候，我们还做了硬编硬解的适配，就像手机端基本264的硬编硬解做得都不错，但是客户基本都不敢用，因为他不知道那么多机型到底适配的好不好，不知道什么时候就花屏什么时候就crash，在硬编硬解上遇到的坑还是很多的，如果我们不做一些白名单，或者是这种指导性的下发，很多客户是不敢直接用的。此外会有一些音频、混音、变调相关的，在很多APP上也在用，只不过我们的角色不一样，我们是一个能力提供方，就不做什么决策了，就把各种能力都集成进来，集成的也是越多越好，不会对哪家第三方或者自研的有偏向。

2.金山直播云SDK CI实践

在不断的接入第三方之后，我们就慢慢的演变成一个组件化的架构了，最下面是编解码库，然后上面是容器层，再往上是我们抽象的推流播放和滤镜相关的，然后封装成SDK或者是Demo，然后每一层都有自己的发布平台，我们接第三方的插件会在相应的层插进去，然后把这种对应的版本也都会发布在下面的那些地方，让别人来使用，这么做的一个好处，模块化首先是能够接第三方更顺畅，我们自己也变成多主线的版本，就是我们可以很多人并行，解放生产力的一个事情。我们现在还基本保持着一周一发版，也是靠这种不停的自动化CI加一些简单的自动化测试和人工回归的方式来保证这个节奏。

3.大数据开启精细化服务

说起配套就会还有一些数据类的配套，在数据这边我们是作为一个使用方，我们的播放端和推流端用户数据，源站、CDN这些节点的日志，然后经过我们的数据拉取，客户端日志收集，简单的存储，流式的处理，最后产出的是一个实时类平台和一个离线的平台，两者目的是不太一样的，实时平台是为了我们更多的是没有固定模板，研发去定位问题用的，离线的平台就是出报表，出产品要看的统计数据的，这部分内容大家都会介绍到，因为每个CDN都会做这些事情。

最近比较火的CDN的边缘计算，我觉得我们现阶段的体量还做不了这件事情，但是边缘可以做一些日志分析类的还蛮是有效的，像我们在边缘日志量还是蛮大的，然后做一次简单的会聚，一分钟的时延传回来，之后的操作，不管是定位问题，还是出报表的时效性都会很好。像陌陌有拨测系统，我们也差不多，就是有重保包的时候，哪路流是重保，我们可以把命令下发下去，把关于这路流的全量日志抽取出来，这个量如果是所有的流都抽取会很大，我们处理也会有时延，但如果对一路流是没问题的，我们可以在服务端这边再出很详细的实时的链路信息去做重保的保障，这部分还都是对我们自己的。

此外我们还可以一些信息开放给客户，像很多客户在出帐单的时候——对主播的结算，也希望有个双保险，让我们去提供主播的各种流的推流时长，有各种复杂要求，我们也通过这种系统来出，包括我们节点的质量，推流和转推的质量，也是可以通过我们系统来提供给客户，还有刚才提到我们对SDK的支撑，通过每天那些千万DAU跑出来的数据我们可以分析出哪些机型是适合做硬编硬解的，从而产出一个白名单下发给SDK，这样线上的客户在对软硬支持这块就可以做得很轻松了，我们用每天跑出来的结果去指导这个下发，目前已经把解码上线了，编码应该会在5月份上线。

4.大数据指导冷流调度调优

我们也希望这些大数据能指导我们一个最迫切的问题——到底怎么解决冷流，这个我们也在摸索的阶段，我们觉得冷流如果解决不好会影响以后的业务。所以刚才提到的附近的人会带来很多冷流，我们就在用就近分发的方式来解决。还有一些比附近的人热一些的流，我们现在通过之前的离线分析，然后把它调度到不同的调度组，尽量把节点会聚，可能以前我们一百个节点来覆盖，分的很散根本就没有什么命中率，现在会聚到一两个节点来覆盖，就朝着这个思路来做，但这个还不算最终能解决，也和很多客户的形态有关，还在摸索的阶段，如果有好的想法我们也可以来交流。

算法演进

最后就是算法演进了，我们一直是觉得CDN做到后面同质化会越来越严重，一旦完全同质化的时候，怎么还能继续保持你的竞争力，所以我们最开始布局的时候就有算法团队，希望如果后面我们靠基础设施、靠架构解决不了的时候，可以靠算法再给我们一部分支撑，来提供一些弹药。

1.视频需求推动云服务布局

这个指标应该大客户、CDN厂商看着会很熟悉了，这就是每天悬在我们头上的刀，一旦这个指标超了，要么就被客户投诉，要么就量被切走，像百秒卡顿时长在直播这边，它会告诉你不能大于1.2秒，大于1.2秒可能你就垫底，然后就把你的量切给别人去整改吧，卡播比这些都是游戏类的客户要求很多的，卡顿次数、首屏、推流的丢帧率、首播时长这些指标都在我们头上悬着，我们可以通过调架构，然后去调覆盖把这个指标达到，但如果达到这个指标之后，还想再进一步有一个质变的话，就是我们在一直思考的问题。这个优化能力可以用来保持流畅性的同时提升画质，也可以用来降低卡顿比同时降低成本。

2.H.265应用场景&商用化

开场的时候提到的H265其实是一个很好的解决方法，它可以去提升画质或者省带宽，如果是用来省带宽的话，大家都知道像普通的视频网站都会有原画、高清、流畅可选，码率越低卡顿就越低，这个也是降卡顿提升观看流畅度的一个手段。

我们在15年完成了H265的工程优化，但是16年为什么一直没有推出去呢？客户普遍还都是在观望状态，甚至有的时候把H265妖魔化，他们会普遍的在想265比264复杂度高那么多，服务端转码速度还够吗？移动端，我还能够保持实时编码吗？会不会发热量很大，要一直插着电？移动端的解码还能够普遍的适配吗？各种顾虑都悬在客户那边，就在等着一个人先吃螃蟹，就没有一个人先往前走。

简单的说就是我们的H265要优化到让用户在用的时候，获得和用H264的软编软解一模一样的感受，不管是在客户端，还是在服务端，也就是你如果没有用到H264的硬件加速，，你会感受不到H265的软编或者软解和H264软编软解的差异，这就是我们的目标。这个也是为什么最近开始可以在大客户的点播和直播上落地的一个原因，我们的测试数据会详尽一些，让客户能接受我们，这个确实是可以商用的。这里我只举了一个安卓的例子，这些曲线可以看到H264和H265基本上已经看不出什么区别了。

3.完备的落地配套，全线支持265

我们这边做的事情就是希望H265能够更好的落地，所以做了各种配套，不管是在源站、CDN、转码、还是录像，在我们整个链条里面都做了H265的支持，这个对以内容或者是以活动为主要业务的客户没什么问题，但是对大客户肯定要考虑其他的供应商、CDN厂商是不是也都做了相应的跟进，在分发环节可能还会简单一点，主要是卡在录像上，像这种HLS的录像，还有端的支持，对于端的支持我们是可以提供能力的，而且能力提供是多层次的，可以提供SDK或者是直接提供编解码库，针对不同级别的客户我们会有不同的策略。像其他的CDN录像上的跟进，大客户是有能力去推动的，像现在已经有几个大客户接入之后，我觉得很多很多友商都会很快的跟进对H265的支持，因为这个确实不难，我们也可以在以后分享一些我们在服务端做录像对H265支持的经验。

高画质、低成本：移动直播解决方案

像刚才也提到H265在有些点上很有吸引力，但确实在Flash Player和H5上很难支持，我们也在试着去攻关，其实很早的时候我们就在Flash Player上做了H265的播放，但是后来去测兼容性的时候，发现在有一些主流的浏览器上Flash Player还是支持不了，会出现遮挡和1080P不支持的问题，这个我们也始终没有解决，在H5上就更难解决了，但是在移动端上会解决的比较好。所以H265的推广还是需要有一些产品场景配套的，不是随便就可以用的，就比如说你是一个直播，主要的量还在移动端，你可以做这个；如果你是一个短视频，是主营业务的客户，你可以在离线的时候，把热门视频转成H265，分发的时候也没有问题，如果需要分享就用H264，这也是一个很好的场景；在直播的时候，你也可以选择大主播同时转一份H264出来，H265和H264同时存在，在不同的端用不同的调度，这个都是需要客户的产品做一些来配套的。

其实我们自己也在考虑是不是要往SAAS那边走一层，把这个业务逻辑拿回来，让客户那边接入更容易，这个还在探索。在 H265使用中，我们会用全链路的配套来做支撑，像我们会做转码服务来支持H265，如果你有一些需求支持不了的话，我们可以同时转成H264，剩下就是端到端的支持，也是用插件化的方式来做。

高画质、低成本：短视频解决方案

这是在短视频上，就是在离线转码上来做的H265，相对来说这套方案走的会更顺畅一些，并不涉及到像直播的场景下，晚高峰并发流量的考虑，可以用闲时慢慢来转。

上面是我们这一年探索和演进的过程，很多新的尝试才刚刚开始，争取能够带来市场进一步的繁荣，谢谢大家