首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Recommended Services
Amazon Web Services
LeanCloud
New Relic
ClearDB
V2EX  ›  云计算

金山视频云:直播平台的高并发架构设计

  •  1
     
  •   ksyun · 2016-06-29 15:57:18 +08:00 · 4318 次点击
    这是一个创建于 1208 天前的主题,其中的信息可能已经有所发展或是发生改变。

    Part 1 :兴起及现状


    日常生活用手机来看视频的次数越来越多,时间越来越长,看的内容也是种类越来越多。包括最近从 3 月份美国开始火起来之后,国内也在火的移动视频社交类。这个也是我们现在在重点切的一个垂类,这个垂类为什么现在会火?我们总结下来一部分原因是因为它的娱乐性很强,延迟很低,和主播有强互动的可能,所以越来越多的人在关注。国内现在起码有几家已经上线,有几十家正在联系准备上线,其中总归会有几个火起来的。 t 这就是对我们现在接触到的这些行业做了一些分类,有综合类的,就是用户产生内容,以娱乐为主,不对用户产生的内容做强的划分。会有一些建议,但是不会强制要求。还有一部分行业性比较强的,像财经、体育,教育这些类。

    还有就是最广泛的秀场类的,这个盈利模式也是最清晰的,它的量特别大,主播依赖特别强的这种业务。这部分厂商的核心需求很明确,大部分来自于他们的业务需求,他们擅长做的是装机量,保持高日活,保持主播和用户之间的黏性,然后怎么做商业化,商业化已经让很多人头疼了,这些事情够他们忙,而且是他们擅长的。

    但是在多媒体的这部分,门槛很高,以前做点播业务,像两年前我在做媒体云的时候,当时都是点播的业务。做到后面,我觉得点播业务其实并不像想象的那么难,你想你有一个稳定的存储,找一家靠谱的 CDN ,然后找一个大概能用的播放器就做出来了,这有什么难的呢?你可以找云服务公司,也可以找外包,或者你自己招一个人都能做。但是现在发现到了移动,尤其是 3 月份移动直播火起来之后,这个门槛突然变高了。因为内容产生方变成了移动端,后面会详细说。

    Part 2 :核心需求


    先说一下这个核心需求为什么会出现。大家在看移动直播的时候,如果有人关注的话,会发现那些主播经常问的一句话就是“卡不卡,是不是又卡了,我要疯了,又卡住了”。你们看点播的时候,看短视频的时候,不会有人这么问吧?不会说你们看短视频,它又卡了,这种问题是最近才出现的。真正的客户都已经返回这种问题了,说明流媒体的门槛又变高了,所以他们对流媒体的需求是在增长的。那我们就看一下这些需求都有哪些。

    1 、首先内容产生方就是推流端,现在主流的 IOS 、安卓, IOS 比较简单,就是那个几个机型,基本大家适配都很好。但是安卓的碎片化是非常严重的,大量的精力都需要做对安卓的适配,而且软编耗电量普遍非常高,手机用了一会就会发烫,都担心会不会爆炸。用户体验就是在不同的网络情况下,上传的视频有可能会卡,有可能不连贯,报各种各样的错误,这个是作为一个开发者他自己不可能去适配的。说白了从用户那边提的需求就是推流端不能卡,画质要好,不能太烫,这是我们接触到的客户真正提的问题,是我们从有点偏技术的角度抽取出来的,它背后对应的是哪些事情。

    2 、然后是分发网络。分发网络其实躲在一个很后面的地方,用户其实看不见的。真正对分发网络提需求用户也提不出来,所以基本这部分需求都会提给播放端,提的需求也是不能卡,不能花屏,首屏一定要快,一点就要看到,还不能把延时弄的太大。其实这些很多都是和源站分发网络有关系的,只是用户看不到这个需求会跟后面的播放器接在一起。

    对这个需求我们做一些抽象来说就是用户的可触达性要好,我们的 CDN 节点要在全区域、全运营商有覆盖,包括教育网。有很多人,像那些小运营商都会忽视教育网,我们也遇到过这样的例子,教育网确实不好接,因为节点不够多,这其实不是什么难点,只是一个坑,注意到了就能做到。低延时的操作大部分来自端的配合,服务端只要是做好缓存,保证这个数据是连贯的。如果要丢数据的话,把关键帧保留好,丢 GOP 中间那些 PB 帧,主要是在端上会收到。

    首屏时间,就是用户点开就要看,以前那些开源架构就是 rtmp server ,它是做不到一点开就能看的,现在一些开源的国内资源写得也比较好了,可以看到。我们是自己开发的,所以也花了一些工作,能保存之前的关键帧的信息,用户一点开就能看,这个就是很细节的东西了。如果这个做不好的话,会黑屏、绿屏,或者是半天看不着图像。

    3 、在播放器这边也是我们在接业务的时候,遇到用户投诉最多的,因为所有的问题都是在观看的时候体现的,所有的雷都得是播放器的同学去扛。这个需求也是不能卡,不能延迟太高。如果延迟高了,要追回来,追的时候声音不能变,最好是追的策略也能自己控制,这是用户真正提出来的需求。

    对于我们来说,要满足这些需求,我们需要做好多分辨率的适配,保证好流畅性,保证好我们追赶的策略不会出现任何异常。所以这三个端很多是相互耦合的,像推流和分发在一起,要保障好用户的流畅性和画质,分发和播放器在一起要保证好低延时和播放的流畅。所有的这些需求里共同的一点就是不能卡,后面我们在设计方案的时候,也是重点考虑怎么能做到不卡。

    Part 3 :解决方案


    t

    这个是我们这边的系统架构图。最下层是依托金山的云服务,因为我们已经有了很好的平台,提供了我们计算资源,提供了存储,提供了很多自建的节点,当然还不够多,我们还是个融合 CDN ,然后提供了数据分析的能力。我们依托它做了橙色的这一层,就是我们自己的核心,流媒体直播,然后围绕这个核心我们再做的回看点播、在线转码、鉴权、内容审核。

    为什么要做回看点播?因为这不是一个短视频录播的项目,而是一个直播,直播就决定它的并发不会很高,内容不会很多,热点比较少。如果你不回看的话,用户很难维持它的日活,很难维护用户黏度,所以用户一定会要求做回看的。

    为什么要做在线转码?推流端其实做了很多把更好的画质想尽办法传上来的工作,投了很多人力来做。传上来之后,观看也在移动端,它不一定看得了。如果他看不了怎么办?我们就需要在线转,在线转码其实承担的更多更重要的事情。

    鉴权,用户都不想被盗链,尤其是推流的时候,如果我不鉴权,谁都可以来推,推个法 lun 功怎么办?这是必须要有的。内容审核,现在我们没有办法帮他做到自动审核,技术还不够。现在做到的是截图,按用户指定的时间定期截图,这样的话,用户就可以请一些外包来看是不是有敏感内容,是不是要下线,这个对于现在这种三四秒延迟的直播来说非常重要。你做不到的话,没准政策因素你就做不下去了。

    数据分析一部分是依托金山已有的,一部分是我们自己做的,因为我们延迟性,时效性要求更高。客户会经常大半夜突然提出一个主播看起来特别卡,问你为什么,要是像以前那种方式,一个小时生成报表,然后出体验图,告诉他为什么卡了,客户可没有这个耐心。

    我们现在基本能做到 5 秒间隔就出之前的各种问题定位,这个定位包括从源站收集的数据画的曲线。还有从端上,如果端上用户允许的话,推流和拉流端我们都会有上报数据,几个曲线一拟合,我们就知道问题出在哪里。所以现在不止是 RD 可以来查这个问题,我们很多售前都在承担着帮用户出这个图的工作。

    t

    这个是介绍业务具体的流程图,这个流程图并没有什么特别,只是一般的流媒体的数据走向、各种请求。但是其中有一些坑我可以跟大家重点说一下,首先看一下直播发起流程,这肯定是由应用向自己的服务端去请求一个推流地址,这个推流地址他就用来向我们的流媒体服务器推,然后我们给它鉴权。

    鉴权之后,它可以在参数里选择是不是要录像。如果需要录像截图,或者需要 HLS 的分发,我们都可以帮他做,做完之后存到我们的存储里,这也是后面会提到的,我们各个业务之间在做隔离、分不同的优先级,这种后端的多媒体的处理尽量都会依赖别的服务,然后就是正常的结束流程。

    这个是实际中遇到的一个问题,现在做流媒体,用户推流,他想知道这个流结没结束,一般互联网公司做云服务都怎么做?都是给回调,如果这个推流结束了,我来回调业务方,让业务方知道我结束了,你可以做你的逻辑了。

    但实际操作中我们遇到了问题,就是业务方的服务器没那么可靠,我们可能过去时间特别久,有延时,有丢,或者他们的服务稳定性我们也确认不了,这其实就是一个双方的耦合了。而且它的服务器,由于是我们来调,它的鉴权功能没有办法做得很复杂,他自己的服务器也存在安全漏洞。如果有人来攻击他的话,他的整个业务流程的状态全是乱的。

    在试了几家客户之后,我们就改成另外一种方式,也是大家普遍都接受的,就是由 APP 和自己的 Server 发心跳,如果 APP 的网络不异常的话,它自己结束它的 Server 肯定是知道的。如果异常的话心跳断了,他也会判断出是结束了的。而且我们这边源站服务也会保证,你 5 秒钟没有数据就一定是结束的了,我们会把你的流给踢掉,这样就能达到用户的业务状态也是稳定的,我们的流媒体服务也是稳定的,而且耦合也会比较少。

    这是我们实际遇到的一个坑,这个其实不难,只是看现在普遍云服务提供商还都是在用回掉的方式,所以我特别提一下另外还有一种可选的方式,效果更好。

    播放的流程,播放器会先向他自己的服务请求播放地址,然后来我们这拉流,可以是鉴权也可以不鉴权,取决于它的业务形态。如果拉流失败,我们有一些定制化的操作,他用 RTMP 来拉流的话,我们会告诉他具体是什么错,包括鉴权失效,鉴权参数错误,还是这个流有问题,我们都会在状态告诉他的。这是之前用户提到的需求,说是播放需要知道哪里出了问题,所以我们尽量把状态码都特别详细的返回给用户。包括我们源站也有查询接口,如果他需要那种统一查询也可以来查。

    文章作者:郝明非,金山云视频技术总监
    6 回复  |  直到 2016-12-18 23:18:51 +08:00
        1
    McContax   2016-06-29 18:11:01 +08:00 via Android
    我能否问下你家的 github 库是否 abuse
        2
    leonayy   2016-06-29 20:44:28 +08:00
    Mark
        3
    techme   2016-06-30 00:36:39 +08:00
    学习一下,对于云服务还是没有深入的使用体会
        4
    great2soul   2016-07-01 17:17:05 +08:00
    一些最近都在讲的点,难得看到一篇说的这么细致 清晰的
        5
    great2soul   2016-10-03 21:13:19 +08:00
    @McContax 不太了解。我个人的应该不会。
        6
    chenjin3   2016-12-18 23:18:51 +08:00 via iPhone
    清晰易懂
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1276 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 35ms · UTC 23:48 · PVG 07:48 · LAX 16:48 · JFK 19:48
    ♥ Do have faith in what you're doing.