写点什么

5G 和云原生时代,技术的下半场从哪里开始

  • 2020-12-14
  • 本文字数:7336 字

    阅读完需:约 24 分钟

5G和云原生时代,技术的下半场从哪里开始

随着 5G/芯片/区块链等等新技术的不断成熟、云计算的普及和云原生时代带来的诸多便捷,开发者和架构师们眼前的挑战也不再只是 0-1 的建设问题,技术如何更多地带来业务价值成为了一个值得讨论的话题。


由极客邦科技举办的 QCon 全球软件开发大会 2020(深圳站)上,阿里巴巴集团研究员,阿里云智能视频云业务负责人林昊(花名毕玄)发表了主题演讲《5G 和云原生时代的技术下半场》,以 5G 典型场景音视频为例,探讨相关技术和技术人的下半场,以下内容为演讲整理。


很多人可能听过,比如阿里巴巴集团董事局主席逍遥子在很多场合都会讲到,现在世界最大的确定性的变化是数字化,意思是未来大的变化多数是“数字化的加速进行”。而在数字化的趋势中,我们看到“视频化”有着更大的确定性。

5G+云原生,给业务带来什么变化


5G 跟业务系统关联性最大的两部分是延时更低、带宽更宽。


现在的主流网络比如 4G,延时大概在 10ms~100ms,它的延时范围还是比较大。而 5G 通常来讲延时会降到 1~10ms,它的目标是 10ms。那么,当延时变得越来越低、带宽变得更宽的时候,业务上我们会看到什么样的变化?



上图主要显示的是当带宽变得更大、延时变得更低的时候,会有哪些典型的案例。比如现在特别火的话题——云游戏。游戏对延时要求是特别高的,像赛车类、竞技类等,4G 网络本身已经不可能让延时再低,但在 5G 场景如果延时压到 50ms 以下,很多业务就有可能变成现实。


所以从 5G 的业务层面,我们关注的是,什么业务需要更大的带宽,什么业务需要更低的延时。


说到云原生,它确实是现在特别火的一个话题。在去年的双 11,我们说最大的变化是所有的核心系统都上云,而今年双 11 我们对外讲的是所有核心系统开始云原生化。


但我们也说,每个人心目中的云原生可能都不一样,谁都不知道什么叫云原生。


对阿里来讲,我们为什么非常激进地推进云原生?我以前是负责阿里整个核心系统上云的架构师,我觉得整个业务的演进过程,最重要的是所有的业务开始从基于一个封闭自主的技术体系走向一个开放的技术体系,这便是云原生带来最重要的变化。


云原生以后,整个社会建造业务系统的自有体系会越来越开放、越来越公共化。这对很多业务创新来讲,是有很大帮助的。因为以前很多东西得自己做,但现在很多东西可能可以基于一个相对比较成熟的技术去做。就像阿里看到有一些业务在云原生化以后,对我们整个业务创新的速度、业务迭代的速度产生非常大的帮助。

最典型场景:视频


像前面说到,5G 带来低延时和大带宽,云原生带来的是走向一个开放公共的自由体系。那 5G+云原生以后,最典型的场景到底是什么?什么样的场景对 5G 和云原生有特别大的诉求?


从目前来看,我们非常确定的是视频。因为疫情原因,今年视频好像突然就成为了整个行业特别火的业务创新以及技术创新领域。但其实视频技术已经发展很多年了,只是今年看起来再度爆发。


我想很多人有这样一些感受:以前多数业务系统里面其实是没有视频的,但现在大多数业务系统,都开始或多或少地引入视频。短视频、直播以及音视频通信是当前最火的几个场景。


我们认为从场景层面来讲,视频是非常典型的 5G+云原生的场景,原因是:所有做视频业务的,不管是直播业务、短视频业务、还是音视频通话业务,关注的第一要点就是体验。


做视频最重要的是体验,比如看直播是不是足够流畅、画面的清晰度怎么样,短视频亦然,音视频通话就更加是了——比如大家开视频会议最关注的是能不能听清楚对方在说什么,另外是画面够不够流畅。


所以一旦做这个业务以后,第一要关心的话题是体验,而视频业务的体验要做得好,面临的第一个问题就是视频能不能很好地分发到离各个用户比较近的一个点。


说实话,多数中小型创业公司甚至很大规模的公司都很难解决这个问题。通常来讲,为了把整个体验做得非常好,多数业务上来就需要依赖背后一张巨大的网络,而这个网络通常只有云厂商公司会提供,因为其他公司要构建这张网络是需要非常大的投入。


所以,从体验上来讲,视频是非常典型的、会更多地考虑到应该去使用云原生的服务,而不是自己从头构建。


除了体验,视频业务开始做之后面临的第二个比较大的问题是成本。视频跟很多业务不一样,这些业务规模如果没有上来,付出的代价也许不是太大,可能只是做几台计算资源的机器、一点存储、一点数据库。当然,如果是做大数据和 AI,相对投入就更大一些。


但是,一做视频就会在带宽上面临非常大的挑战,因为带宽“上来就是钱”。除了带宽以外,视频稍微做大一点,还会面临存储成本,因为要存下来,而视频的文件显然比以前所有的东西都大。


有了存储以后,视频还会面临计算消耗的问题,因为可能要对视频做一些处理,比如做一些编解码或其他东西,导致计算资源整体会有比较大的消耗。所以整体来看,视频除了解决体验问题以外,还会面临巨大的成本消耗的问题。而为了解决成本问题,可能会产生各种问题。因此对于很多团队来讲,基于视频的云原生服务是一个相对来讲比较好的选择。


讲下我自己的另外一个感受,我觉得视频业务是需要在基础技术领域投入非常大的技术领域。比如要让视频在分发的过程中、播放的过程中将带宽控制得更好,我们可能要去解决的问题是怎么让多数用户看到的视频画面质量不怎么改变的情况下,怎么把带宽成本降下去,控制码率。对很多公司来讲这是非常重要的,因为在大多数公司的业务中,少数视频占了最多的带宽费用,但又不能把少量视频的质量降下去。因为质量如果降下去,会影响用户体验。



为了解决这个问题,我们可能需要投入大量的人员去做编解码优化。当然开源也是有的,开源的质量也不差,但如果想在开源基础上做得更好,这个投入就非常大了。


另外大家可能也听过,在看一段视频的时候,视频内容其实是直接决定了哪些地方是需要非常清晰、哪些地方相对来讲是不那么重要的,这可能就要结合 AI 做视频内容的理解,然后做动态的编码优化,基于你感兴趣的点去做优化,背后可能涉及各种各样的团队,编解码的团队、AI 的团队、算法的团队,所以为了一点点的提升,背后可能有非常大的投入。


让延时再低些


延时变得更低到底能来什么好处,简单给大家举几个例子。


第一个是在线教育。最早的时候在线教育是录播的,老师提前录完视频然后再放出来,其他人再点开看。但对很多客户来讲,比如对家长来说这是不太能接受的,因为跟老师不能有很好的互动。后来在线教育就更希望能让老师跟学生之间有更强的实时互动,而不是录播的毫无互动。


为了做到互动,最关键的是延时。传统直播技术通常大概延时在 5 秒左右。当然,像电视直播等延时会相对长一点,但那是因为其他的要求,技术层面大概都在 5 秒范围,这是受协议约束的结果。而在线教育是希望把延时降到几百毫秒,这样音视频互动才能更好地进行。


第二个是电商,这方面阿里有非常强的感受。阿里最早做开始手淘直播的时候,也是采用比较传统的技术,场景上面临的最大问题是:主播上来告诉大家,“我要开始卖一个东西了”,然后他要上链接,还要做消息互动。但这时候有可能会出现的是:主播说话与用户观众发消息的两个过程是有延时的,但消息的延时跟视频的延时又可能不一样,消息可能在 1 秒,视频可能在 5、6 秒。


这时候就会出现消息跟视频不在同一个画面的问题——主播可能都已经切到下一场,而买家还在跟他交流上一场的问题。


所以在手淘场景里,我们不断跟手淘团队一起尽可能把延时往下推进。比如在今年双 11 里,手淘大量采用了低延时直播,大概把直播的延时降到 1 秒左右,控制在 1 秒范围内之后,我们可以看到它对整个 GMV 的转化有很大的帮助,因为主播跟观众之间有了更强的互动关系。


在所有直播体系里我们都看到了对于延时的诉求,现在直播都希望走向强互动直播,而不希望是原来那种比较单向的行为,因为观众也希望有更强的互动。


最后一个是大家疫情期间感受最为强烈的场景,视频会议。现在视频会议的延时在技术上能够做到几百毫秒,所以现在大家普遍能开视频会议。虽然以前是电话会议多一些,但现在很显然视频会议的比率在上升。毕竟任何人的交流都更加希望能看到人,而不纯粹只是电话传递的声音。


举另外一个例子,很多公司的面试到决定性或者很关键的一轮时,都会把候选人邀请到本地,然后面对面地完成这轮面试。这是因为觉得在仅通过电话面试、看不到人的情况下,很多东西是难以判断的,需要见到本人。但是有了视频会议以后,一些面试就可以无需把人邀请到现场进行。


所以延时技术在视频领域的作用是非常明显的,从几秒到几百毫秒催进了非常多视频场景的创新。


但对视频来讲,这依然不够。比如视频会议,之前一个学术机构的研究报告显示,其实像视频会议这样存在几百毫秒延时的场景,对比人跟人的当面交流,还是存在很大区别。


大家开视频会议应该都有这样的感受:在视频会议的场景下,仍然会出现抢话情况,你说了一句话,可能还没有说完对面就已经抢话,这是一定会出现的,因为人跟人当面交流的延时并没有几百毫秒。


在视频场景里,我们是有非常强的动力去思考怎么把延时往下推得更低,让大家有更真实的体验,包括现在很多公司做很多东西都是为了让大家在远程会议上,可以有跟当面交流比较接近的体验。对我们来讲,延时如果能够越来越低,是一个非常好的事情,可以在这基础上做更多业务层面的创新。

音视频传输延迟引入分析


音视频整体技术可能跟系统层面技术有一些差别,我们来看一下延时。比如直播,音视频中比较典型的场景,你拿一个手机开始拍,这是采集的过程,把一个视频影像留下来,去采集,然后编码,多数可能是在端上去做。这个延时,现在大概在 60ms 左右的范围。


采集完之后会把这个流(比如直播、摄像流)直接推到远端,多数是云端或者自己服务器端。在云端之后,通常还会做一些处理,比如直播通常要做内容审核,内容需要过一遍审核处理,有些稍微复杂点的直播可能还要做其他事情,比如加 logo,做一些镜头的剪辑和镜头的切换。


如果有多个摄像头机位,还会涉及到直播的时候选用哪个机位的问题。另外是分发,怎么把服务器端推到很多的点。然后是把客户端流拉到本地,拉完以后开始解码和播放。



从整个时间耗时看,以前是 3-5 秒的延迟,主体时间多数耗在拉流那一端,这是协议决定的。RTMP 是比较标准的协议。现在业界比较流行的低延迟直播,是把直播延迟从 3 秒推到 1 秒,推到 1 秒以后,我们给它的名词都叫低延迟直播,相比以前更低延时一点。


大家看上图中的整体优化,更多是把协议层开始做替换,现在多数公司的低延时直播都会基于 RTC 协议,就是 Google 开源的 webRTC 协议去做。可以看到,当基于 RTC 推流、RTP 分发,前面协议层都在替换,差不多可以把拉流这端开始压到 1 秒以内。现在阿里手淘的直播,整体延时在 1~1.2 秒范围,1~1.2 秒在消息类互动场景已经足够了。主播跟观众如果是用消息互动,发一条消息或者打赏什么的,大家都不会有太长的延时感觉。可以看到,这种场景下,我们可以通过协议替换把整个延时往下拉低。


但也可以看到,其实还有很多延时是整个网络造成的。如果是网络造成的,现在其实是没有太多很好的解决方案,就非常地难。而标准的 RTC 可以做到 200-300ms 的时间,就是这样一个状况。


这三种延时,除了技术层面的差别以外,另外的层面是当采用这些技术以后,整体的成本是有很大变化的。当你延时要做得越来越低的时候,其实成本是会上升非常多的。像 RTC 相比传统直播延时,有可能成本大概是在 7 倍以上。像低延时直播,现在各家公司在不断努力尽可能让这两者成本开始接近。



为了很好地控制延时,推流最重要的是协议的替换。因为协议替换以后,从 TCP 到 UDP 以后,很多东西需要自己来做了。


各视频厂商关注的最重要的指标是抗丢包,多数公司追求当丢包在 50%、60%、70%的时候,在不同场景去满足诉求。比如视频会议如果只是为了开会,最大的诉求其实是在音频端——音频清晰度和流畅度,而画面如果有一点卡顿,我们勉强还能接受。当然,如果那个视频会议是讲 PPT,那就不能接受了,那优先级可能变成视频的清晰度。所以,不同场景需要有各种各样不同的策略。


比如大家如果去看直播场景和视频会议类型的场景,它面临最大的不同是什么呢?直播场景的话,比如我是主播,其实只要摄像头跟我、以及我跟服务器的链路整体没有太大问题,基本上观众之间互相是没什么影响,这个观众看的时候会卡,另外一个观众有可能是不卡的,因为观众之间没有什么影响。但如果是视频会议类型的场景就完全不一样了,比如现在有十个人在开会,这十个人里任何一个人,出现卡了或者视频、音频不大正常,就会影响整场会的效率。


在这样的场景里,为了要保证延时,同时又要保证流畅度的时候,抗丢包层面需要做非常多的事情,包括综合的策略。


我们去看很多音视频公司,它们很大的竞争力在于对端的适配能力。因为每个端的状况不大一样,比如有人用苹果,有人用安卓,尤其是安卓,安卓手机有无数种,每种手机的音频能力、视频能力有很大差别,还有大家所处的网络环境,比如现在连了 Wi-Fi,走动的时候可能 Wi-Fi 点会切换,还有可能从 Wi-Fi 切到 4G,这里面网络点怎么去处理也是非常关键的。


所以当整体延时越来越往下探的时候,它的技术门槛在不断地升高,我们怎么样做好卡顿的控制,是各家公司去做这类型业务上面临的最大的一个问题。


这里主要讲的关键技术,一是推流,二是分发,三是整个拉流层面为了控制延时做的一些事情。推流主要是协议层面和抗丢包,分发层面主要是背后整张网络的分发。


很多公司做视频业务,通常有几种方法,一是直接基于云厂商的 CDN 构建整张音视频网络,还有一种是基于边缘计算节点构建一张自己的音视频网络,但这都是有一个问题要解决的。不管用什么方案,都有这样一个问题解决:这么多的节点要怎么更好地调度?这涉及到非常复杂的调度问题,因为每个节点的带宽能力、计算资源能力可能不一样,怎么根据用户的情况去做整张网络的调度。


超高清是未来,但还有很多技术侧问题要解决


带宽层面,从目前来看,大家都在想 5G 带宽变大了以后,到底找谁把带宽用起来,总得有人把带宽用起来。就像 4G,其实是视频用起来的,短视频把 4G 视频带宽撑起来。现在互联网一大部分流量,主体都是视频构成的。5G 时代也是一样,我们为什么需要更大的带宽消耗,肯定要从业务侧看到很大的变化。



图中可能是大家经常看到的一些清晰度,我们现在多数场景里能看到的 720p 视频、1080 4K 和 8K。8K 其实很少看到,因为 8K 对屏幕要求非常高,基本要很大的屏才能展现 8K 的效果。


阿里曾经在几年前冬奥会的时候做过一个 demo,叫 5G+8K 看冬奥会的滑雪现场,它的运动感非常强,所以是非常明显的。而现在特别火爆的 VR/AR 是需要更高的清晰度,现在很多 VR 还是 4K,所以导致我们会觉得颗粒感很强,但当 VR 结合 8K 的时候,就会觉得颗粒感的问题好了很多,画面比较接近真实。


只有更大的带宽,我们才可能把清晰度更往前推进。关于清晰度,以前有人说,你去问很多人,他都会觉得现在的东西已经够清晰了,不需要更清晰。但当你给了他一个更清晰的东西的时候,他会发现他需要更清晰的。最典型的是,苹果推视网膜屏,当视网膜屏推出以后,大家就有了更好的体验。


现在短视频厂商也在不断推进 4K。很多人以前都觉得短视频没必要那么清楚,因为手机屏幕太小了,还不至于能看出 4K 的差别。


但从业界发展看,我们觉得这个趋势还是比较明显的,整体朝更清晰化发展,它肯定是有诉求的。而为什么现在进展比较慢?有很多原因,第一个是当清晰度要往前推进的时候,不光是后面播放侧的问题,还有很大的问题是制作侧。当然,现在很多摄像机可能是 4K,但是拍了以后怎么把 4K 视频做剪辑、处理,其实是非常复杂的,更不要说带宽消耗。带宽除了能不能放出来以外,还有一个问题是每放一次背后全部是带宽消耗,这个带宽消耗全是成本。


我们觉得超清是一个很好的发展方向,但怎么解决在超清的发展过程中面临的很多问题,是技术侧都需要关注的。



超高清技术里面涉及到很多东西,简单讲就是从视频输入开始,就是拍一段视频,然后到一段视频最后被用户看到的时候,到底我们要做些什么。


大家可能听到过一些词,比如上图里的“超分”。简单来说,就是手机拍出一段 2K 视频,怎么把它超分成 4K 的视频,让你看到一个类似 4K 的效果,这样做是为了制作端的成本问题,因为很多制作端都不具备制作超高清的能力。


另外,大家可能听过窄带高清等技术,其实是为了解决给你一段高清视频,但怎么来控制整个带宽成本的问题。如果做高清业务,成本是非常重要的。长视频就非常典型,多数长视频会提供非常多种清晰度的选择,多数公司会提供越来越清晰化和越来越好的体验,就像优酷自己,我们会提供帧享的东西去让大家能看到更好的不同的体验。


还有很多场景的问题,比如拍不同场景,航拍和运动类的视频对清晰度的要求是比较高的,尤其是运动类的视频就非常明显。阿里优酷做世界杯播放的时候,能明显地感受到,如果清晰度不够,很多时候可能连球在哪儿都不一定能看到,远景的时候是比较难的。在那段时间,大家在不断研究怎么能让这个画面变得更加清晰。


所以我觉得,对于很多公司来讲超高清技术是需要往前演进,需要解决从制作到分发、处理到播放整个链条的问题。带宽是基础,只有带宽越来越大的时候,这个东西才有可能变成现实。


因为我现在跟视频接触得比较多,从这 5G 和云原生这两个命题讲,我目前看到视频是结合最紧密的技术。


5G 带来的更多是低延时和大带宽。我们需要思考的是,当延时越来越低的时候,有可能带来什么新的业务创新,创新模式到底有什么改变。延时越来越低,在视频场景我们看到会带来越来越多业务上的变化,很多业务跟以前完全不一样了。


因为视频的成熟,在疫情期间很多事情开始转向,以前必须线下的可以转向线上业务。当整个社会技术在进步的时候,所有业务系统侧都要去思考,视频只是相对来讲可能更明显一点。另外是带宽,有什么业务对带宽的消耗越来越大。


举另外一个例子,计算资源的消耗。最早多数计算资源是用来做在线业务系统,比如交易系统等,消耗了大量的机器。但是后来我们看到很典型的变化是大数据,大数据变成了更主力的计算资源的消耗,再后来是 AI。


场景都在不断变化,我们应该去思考在所有业务场景里延时越来越低会带来什么,然后带宽的变化会带来什么,最后是基于云更快速做业务创新的机会到底在哪里,因为云原生更重要的是,我怎么更好地、更快速地完成整个业务的迭代和创新以及尝试,可能对所有做系统结构、做系统架构技术的人来说,这是需要慢慢结合自己的业务去思考的一个话题。

2020-12-14 11:112950
用户头像
罗燕珊 AI practitioner | Tech media

发布了 492 篇内容, 共 329.0 次阅读, 收获喜欢 796 次。

关注

评论 2 条评论

发布
用户头像
2021-02-22 16:48
回复
用户头像
mark
2020-12-15 10:07
回复
没有更多了
发现更多内容

Python With 关键字和语句

HoneyMoose

ECMAScript 2016(ES7)新特性简介

程序那些事

JavaScript ecmascript ES6 程序那些事 es7

区块链应用解决方案赋能到农产品溯源上究竟能解决什么问题?

源中瑞-龙先生

2月大事件:度目CM-Mini智能面板机全新发布,飞桨PaddleGAN“复活”李焕英

百度大脑

百度 百度大脑

翻译:《实用的Python编程》05_00_Overview

codists

(28DW-S8-Day20) 以太坊账户

mtfelix

28天写作

《精通比特币》学习笔记(第八章)

棉花糖

区块链 学习 3月日更

如何成为一名架构师?

xcbeyond

程序人生 方法论 架构师 成长与思考 3月日更

【LeetCode】验证二叉树的前序序列化Java题解

Albert

算法 LeetCode 28天写作 3月日更

这是看脸的时代吗——晕轮效应

Justin

心理学 28天写作 游戏设计

植树节,种个二叉树吧?

悟空聊架构

数据结构 算法 二叉树

3月12日学习笔记

Nydia

翻译:《实用的Python编程》05_01_Dicts_revisited

codists

Python

带你了解VXLAN网络中报文的转发机制

华为云开发者联盟

网络 网关 VXLAN 报文 分布式网关

华云大咖说 | 华云数据与瀚高软件携手共建国产云生态 助力政企用户安全可靠发展

华云数据

你以为在做的是微服务?不!你只是做了个比单体还糟糕的分布式单体!

程序猿DD

微服务

算法攻关 - 验证二叉搜索树 (O(n))_098

小诚信驿站

刘晓成 小诚信驿站 28天写作 算法攻关 验证二叉搜索树

算法喜刷刷之验证二叉树的前序序列化

Kylin

算法 3月日更 刷题笔记

关于广东欢太科技可不可信?那是你还不了解

Geek_4a453c

企业 欢太 欢太科技

真·“拜师学艺”?2021中科院开源之夏,开源大牛1V1&万元奖金只等你来!

京东科技开发者

开源 开源社区

硬核!一文学完Flink流计算常用算子(Flink算子大全)

五分钟学大数据

大数据 flink 28天写作 3月日更

聊聊什么是CommonJs和Es Module及它们的区别

蛙人

大前端 js ES6

“新作者 新入驻 新征程”第一季获奖名单

InfoQ写作社区官方

热门活动

微服务简介

insight

微服务 3月日更

滚雪球学 Python 之闭包操作,本系列第 8 篇文章

梦想橡皮擦

28天写作 3月日更

《未来世界的幸存者》读书笔记

SilentMacUser

极客时间 互联网 技术学习 阅读 阮一峰

力扣(LeetCode)刷题,简单题(第27期)

不脱发的程序猿

面试 LeetCode 28天写作 算法面经 3月日更

“种”下黑科技,守护每株绿,“植”了!

华为云开发者联盟

华为 AI IoT modelarts 森林

一步一步教你如何在Centos7中配置Kafka运行时环境

happlyfox

28天写作 3月日更

一起来学习LiteOS中断模块的源代码

华为云开发者联盟

代码 华为云 LiteOS 中断 中断控制器

物联网常用协议:MQTT、CoAP、LwM2M、HTTP、LoRaWAN和NB-IoT

不脱发的程序猿

物联网 通信协议 28天写作 3月日更 物联网常用协议

5G和云原生时代,技术的下半场从哪里开始_文化 & 方法_毕玄_InfoQ精选文章