10 月 19 日, 云 + 社区开发者大会 (北京站) 圆满落幕. 本次开发者大会的主题为 "5G 探索: 核心技术与挑战", 邀请了腾讯内部及业内行业大咖就 5G 场景下应该如何面对新业务与挑战? 大型网站的技术应该如何进化? 如何真正理解万物互联? 5G 有哪些值得探索与实践的方向? 5G 对应用发展的影响有哪些? 等问题进行了深度探讨. 同时, 在圆桌论坛环节, 各位技术专家也与到场的开发者们展开了开放式对话, 精彩不断. 下边是廖龙老师关于 5G 下的 CDN 技术与产业发展变化如何引领时代的分享.
讲师介绍: 廖龙, 腾讯云专家工程师. 2010 年加入腾讯, 曾参与 QQ 空间, QQ 农牧场等项目. 2014 年开始负责腾讯云 CDN 研发, 专注于后台技术架构设计研发, 对点播直播性能优化有丰富经验, 在海量突发服务有较多心得. 现任腾讯云 CDN 技术负责人, 主要关注边缘计算, 全球加速, 安全等领域.
本次分享大概讲几块. 首先我们来回顾一下 2G,3G,4G 发展究竟什么样的曲线? 可能大家觉得世界变得很快, 我们重新看一下. 这个是来自于中国互联网报告的数据, 2009 年那个时候是 3G 刚开始, 60% 网民使用手机入网, 到最近 2018 年 98% 人都有手机, 这应该符合大家的预期. 剩下 2% 人不知道在干啥? 竟然没有手机. 所以现在所有的网民基本都是移动网民. 我们原来很多设计是针对固定网络的, 全国各地这么多用户在移动网络上使用, 这些人当未来升级到 5G 时, 有没有考虑过会面临什么样的新挑战? 从这个数字可以看到中国数据发展很快, 这是未来需要思考的东西.
2G 成就了 QQ,3G 成就了社交, 微博和微信, 4G 成就了视频, 例如大家都用的快手, 抖音, 火山小视频等. 还有一些直播类的, 像是电商不做直播说不过去, 都在炒这个热度. 当然现在直播热度慢慢有所下降. 而在 5G 时代下, 流量会越来越大, 可能这些东西会进一步兴起, 甚至会有新的业务形态产生, 当然现在也没有办法预计究竟产生什么样的新业务形态.
2020 年这个时间点非常的关键, 我们认为它是 5G 的商用元年. 我们看到北上广深几个城市纷纷出台 5G 措施, 2019 年北京在五环以内有 5G 信号覆盖, 四个城市都争抢说在 2020 年成为 5G 领先城市, 全市内都有 5G 信号覆盖. 不知道大家有没有买过新的 5G 手机? 可以买回来之后试试下自己家里有没有 5G 信号.
我来自于深圳, 在深圳做很多的测试, 例如跟 5G 实验室同事去深圳比较偏远的地方测, 会很惊讶地发现, 之前在那个地方测一些 4G 的功能, 突然发现手机连上 5G 网络了. 因此看到运营商一旦决定要做 5G 了, 基站建设速度会非常的快, 因为工信部要求他做, 速度就会提升得很快. 现在牌照和政策都已经出来了, 我相信 2020 年会是一个不同寻常的年份.
具体到 5G 的 CDN 和边缘计算, 会给现在的业务带来什么样的变化? 大家知道 5G 时代都讲高带宽, 低延时, 万物互联, 所有人都可以随时随地联网, 我待会讲一下腾讯云在这块小小的实践, 也拓展一下大家的思路.
第一个可以看到的变化, 就是万物互联. 每个设备, 包括提到的智能设备, 会有一个架构上的变化. 为什么这样讲? 当前的智能设备, 一般会集成很多的芯片, 组装了很多功能, 才能够去做交付. 比如说最早在做图像识别的腾讯优图实验室, 在商店和超市里面去做监控, 视频人物识别之后, 会把一块安卓版配备 GPU 的 "优图盒子" 放在店里里面做计算, 对本地的视频进行识别. 因为 AI 的推理要求性能非常大, 对视频类的数据延时要求比较低, 所以只能搞一个性能比较高的板子放在店里去做本地的计算. 我们看到, 这种交付对于店长来说, 搞这样一套东西好复杂, 成本好高, 可能店长会抵制, 接入的意愿不大. 现在慢慢有一种趋势, 这些逻辑不在设备上做了, 设备本身很轻. 在 5G 时代, 设备插插卡就 OK 了, 它基于 5G 的低延时能力能够回传到云上, 所有业务都在云上做, 原来我们认为一定要在设备端上做的事情, 现在端上都不做了, 纯粹用网络传到云上做. 在云上有一个最大的问题是延时太大的, 把数据中心都放在北京这里, 那广东的用户和海南的用户怎么办? 海南的用户如果把视频传到北京真的很遥远, 怎么去解决?
大家提到的边缘计算概念怎么做到的呢? 设备端也可以是边缘, 远离云数据中心的 CDN 节点也是边缘. 因此, 我们在 CDN 节点上做了很多尝试, 因为 CDN 在全国各地都会有, 每个省份和运营商都有自己的 CDN 节点比较靠近用户, 例如在酒仙桥某个地方就有一个节点, 它可以做到比较靠近用户, 我们把逻辑从云中心迁移到 CDN 边缘节点上, 通过这种比较靠近用户端的方式实现边缘计算的能力.
我们在直播的场景里面做了这个尝试, 我们看到直播的数据不一定经过中心, 在这里拍个视频可能在北京就直接看了, 北京的节点能够就近处理, 北京的片区用户就能够直接覆盖. 大家知道很多直播不一定有很多人看, 尤其冷门的直播, 不像网红那样全国几万粉丝在看, 有的主播粉丝少, 可能就在片区周围有一些粉丝观看, 这种特别的适合把他降到边缘计算去, 因为边缘的能力比较靠近这些用户, 并且边缘的能力可以省掉跟云中心之间带宽的消耗, 能够在这一块降低很多的成本. 我们在这里做了很多实践, 比如说一些转码, 连麦, 像乔碧萝事件就是连麦功能, 并且还有 AI 打码打了一个头像上去, 我们逐渐尝试把这些计算逻辑放在边缘这里做, 因为不能在手机上打码, 手机上打码对主播端的性能要求太大, 手机发热厉害可能会导致它卡. 在云中心做因为比较远, 效果也不高, 我们在 CDN 边缘节点做尝试, 打码, 连麦这种典型的应用就可以在这里做, 两个主播之间的连麦合成一个, 最终让用户看到. 这个场景的优化, 我们效果很明显.
还有智慧零售行业, 最开始想做一个性能比较强的板子, 让每个商店的人买一台比家用路由器大一点的设备还要插电, 插网络, 还要搞个光纤去连, 整套部署, 实施是一件很麻烦的事情. 如果做成只要插上卡, 插 200 伏的普通电源, 把数据都传到 CDN 节点去, 通过几毫秒延时就能够处理这些数据. 然后再决定业务的逻辑, 这个是不是 VIP 会员, VIP 会员来了我要很快给他做一个响应, 告知这些商铺的店员去做服务.
智慧零售借助这个能力, 可以实现很多店铺的智能化转变. 比如说原来的店铺都是店长雇佣很多的员工在里面看铺, 员工可能自己上班不积极天天玩手机, 店长不在那儿看着也不知道. 还有个场景, 很多顾客到店里来, 顾客喜欢看哪款, 顾客流动线路图是什么样的, 顾客在哪些货架前停留? 这些东西都要进行分析, 我们叫人的热力图, 相当于之前做网页的时候鼠标移动的热力图一样. 这种热力图可以拓展到人身上, 这些都需要做算法的分析. 这些算法做一样就需要加 CPU, 做两种能力就需要两个 CPU, 因此在端上做这件事情不利于未来的拓展, 很可能加几个新功能就发热了. 当移到边缘节点去以后, 它能够很好的实现你算法的叠加, 可以不断的更新, 升级更多的算法, 达到更高的效果.
还有一个 Case 是把计算逻辑下沉到 CDN 节点上, 例如叮当语音助手, 腾讯的一个语音平台, 专门提供语音操作的能力. 可能大家玩过天猫精灵, 小爱音响, 我们腾讯之前也出了好几款, 去年司庆的时候每人发了一个, 叫 9420 音箱. 每次跟它对话的时候, 比如说小爱同学今天天气多少度? 它要转一个圈, 或者等 2s 反应一下才说今天若干度. 它把语音返回到数据中心, 数据中心转文字, 识别之后在自己的领域里面查对应的答案, 查到答案之后再把文字转成语音, 再把语音发过来播放. 基本逻辑听起来不复杂, 但是语音转文字, 文字再去做数据库查找非常的耗时, 尤其语音转文字转到最后一个字, 才知道这句话究竟是什么? 做网页的人知道 3s 是一个极限, 3s 打不开这个网页方访客就要流失了, 语音这个东西说句话都是 2s, 非常的挑战人的极限, 因此腾讯音箱的团队努力想办法优化时延. 他们发现, 很多用户讲的问题大多数都是类似, 经常喜欢问播放谁的歌, 或者时不时的问天气多少度? 或者最近流行周杰伦, 很多人去播放周杰伦的歌. 他们发现很多问题可以命中缓存, 对计算能力的要求不是很大, 这个时候可以把它下沉到 CDN 节点去做, 这样做有一个好的地方, 当你距离比较远, 云距离数据中心比较远的时候, 缩短一百毫秒的延时, 累计下来就非常的可观, 至少能降 30% 的总体时间, 达到 1 秒多响应的效果.
我把计算转移到 CDN 边缘节点, 还面临到另外一个问题. 这么多的视频, 这么高的视频板流, 未来可能还有游戏, 还有 VR 的视频, 怎么样保证高稳定? 前面提到 5G 下腾讯视频是 300 兆的带宽, 下载一个游戏 100 兆的带宽, 怎么保证这些用户稳定的传输呢? 传统的 CDN 节点在服务移动网络用户时, 是有很大的瓶颈的, 接下来详细讲一下.
我们先看下, 各个层级的基础设施它们的时延究竟怎么样? 这里要理清楚一个概念, 这里有两个网络, 一个是固网, 一个是移动网. 很多时候大家提边缘计算这种新的概念都会想到是一个固网的东西, 固网 OC 节点 5 毫秒, 再下沉到就近的一座大厦可能就是 1 毫秒以内. 这几个时延差异不大, 到了移动网差异就大了. 首先手机链接移动基站 20 毫秒过去了, 20 毫秒等于原来的设备差不多连到本地数据中心了. 基站因为是在移动网络里, 比如我是广东深圳的, 深圳的核心网在广州, 一般在每个地方的省会. 二线城市, 三线城市的流量先走到省会去, 省会再做一个交换才回到数据中心. 这里面又会有十几二十几秒的延时. 如果看视频怎么办? 四五十毫秒的延时, 很可能会有一个波动, 导致速度传输非常的不稳定. 虽然你是 100 兆的带宽, 经常几 K,100 兆不断地波动, 会导致你的观看体验很不好.
因此我们去想做 MEC 的方案, 进一步缩减这里的传输时延. MEC 是下沉到边缘节点, 在移动网络的基站那里. 在基站上面部署很多的互联网设备, 因为正常的基站都是自己的专有电信网络设施, 需要改造加入通用的 X86 服务器进去. 在这里加入服务器之后具备把内容和数据, 计算下沉到这里的先决条件, 并且它这里确实是离手机最近的一个地方.
MEC 这个东西也比较有意思, 在 5G 规范里, 是有要求 MEC 具备哪些功能的. 但是最早通信行业提出来, 那时候并没有考虑到互联网人怎么去使用. 反正就是说我有这个, 你爱用不用. 于是我们去用的时候才发现有个比较大的挑战.
大家可以把 MEC 理解为路由器, 在这个地方有个路由器, 所谓路由器是什么? 原来你访问一个 IP 经过路由走到互联网去, 你给它发一个指令就能说把路由器的数据流转到另一个地方. 假设再看一个视频, 你看着好好的, 突然发的指令说把这个视频路由发到本地去, 你会发现这个视频就断开了, 原因是这边的服务器就收不到请求了, 那边服务器就收到从中间开始的请求. 做过互联网的人, 尤其是参加面试被问过 TCP/UDP 的后台开发, 会发现在 TCP 层级上这个数据是断开的, 不管怎么搞就连不上. 因此, 在这个基本的场景里面, 当你作为一个本地下沉的切换, 这个用户就挂掉了. 这在通信行业人的视角看, 这个逻辑很合理; 但是在业务层面上看, 这个逻辑就很麻烦.
除了这个以外还有别的问题, 从手机那边看, 感知不到周边有 MEC; 从服务器这边看, 也看不到周边的 MEC. 它像是一个黑盒, 像你去政府办事, 永远不知道政府那边有多少的关卡, 怎么办呢? 在标准设计的时候, 就不打算告诉你这些事情, 他以为自己玩的很好, 结果你用的时候就很坑爹. 包括 5G 实验室的同事在去年很多实践时, 就提到很多的方法, 行业内基本提了二三十种方法, 想解决当时标准的坑, 归下来有三大方案:
第一, 在手机端上做, App 方面想办法探测. 用探测端口或探测 IP 方式探测. 第二, 是 DNS 中间网络交互过程中, 尤其 DNS 层级做一个延时探测. 第三是, 网络出口这里, 通过采用固定出口 IB 的方式做探测. 每种方案各有优缺点, 第 1 个方案对 App 改造特别大, 不是每个业务和用户都适合. 第二个方案在 DNS 这快, 对 DNS 要求很大, 尤其是 HTPS 场景很难使用. 腾讯视频的案例里面采用的是第三种 NATP 方案.
假设在下沉已经解决了, 怎么样保证它的数据传输稳定呢? 可能大家用手机用的比较多, 也会经常遇到这样的场景, 进电梯的时候手机信号没有了, 甚至到这个门背后上厕所, 一进厕所手机信号就没了. 在人群拥挤的地方, 发现 4G 信号也没有了. 很多的场景在原来固网状态下根本没有遇到, 因为当时 TCP 网络只考虑丢包, 丢包一定是网络非常拥塞, 很多这种场景在原来的网络协议上考虑不到, 也是我们需要去解决的. 腾讯内部有一套自己的网络协议和算法, 去考虑很多这种事情. 会把很多网络上的特色做分类, 分类之后自己做一个机器学习, 包括用常见的深度学习神经网络去调参数, 调发送, 是否要发送, 是否要发大包, 是否要发小包, 做策略上的选择, 同时还会做带宽上的优化. 比如说你的手机是 5G, 带宽非常的充足, 会尽量往大带宽上跑, 这样, 就能达到比较好的效果. 未来 5G 我们设想到会往好几个方向去做, 比如说通用的一个场景, 常见的网页传输, 还会有一种视频类的场景, 这个会作为很独特的, 大家都特别去看待的一个场景. 还会做高并发的情况, 包括未来 HTTP3 的协议, 也会逐步去落地. 这些协议原来已经不用 TCP 改用 UTP 了, 在 UDP 的情况下会有新的特点出现, 这是我们腾讯团队为了应对未来越来越大的带宽和不限流量的传输去做的思考.
第三个场景, 刚才讲到的 5G 大带宽. 5G 带宽非常大之后, 大家想得到会看更大的视频, 4K 这个东西大家讲提了很多年, 包括 4K 的电视也出了七八年. 最近有的家里装的电视 60,70 寸, 虽然提了很多年, 但是 4K 不怎么流行. 换一个思路去看, 会发现我们在电脑上看的视频的确在逐渐产生变化. 这里有一个最近的统计, 可以看到很多视频的帧率悄悄的提升, 原来看的是 20 帖, 25 帖, 现在看到的主流是 30 帖, 帖率越高说明视频的质量越高. 还有视频的分辨率, 以前看的 720P 是非常高清, 现在 1080P 从 3% 上升到 30%, 已经成为三分天下, 三分之一人看视频首选 1080P. 可能也不是他首选, 是因为他买了会员, 会员自动给他选高清.
随着各个视频网站自己推出的 4K 之后, 也是一样的, 电视会帮助你主动选 4K 视频, 在你不知不觉的时候, 你就看到更高清的视频. 包括这种电视带来的娱乐, 包括这种视频带来的娱乐, 以及包括抖音, 快手随时随地去看, 包括随时随地去玩游戏, 这种娱乐会带来一个很大的挑战就是带宽, 尤其是服务器这边带宽的挑战. 这是 2017 年 - 2019 年的一张图, 会看到经常有人搞 "6.18","双 11", 一年每个季度都有很多的活动, 每次活动都有带宽带来的大挑战. 背后橘色是这次活动带来的带宽峰值, 下面的绿色是这些服务器日常能支撑的带宽容量.
2017 年的时候采用的方法, 客户提前跟我说 "双 11" 有活动, 会涨多少倍, 我们会去给客户准备这么多的设备堆资源. 堆设备永远可以解决问题, 靠运维手段解决问题. 但是我们发现这样很累, 每次活动搞一天, 为了搞一天的活动, 我要加两个星期的班才能堆好这些设备上线. 在 4G 已经这么惨了, 到 5G 是不是更惨, 堆设备可能堆不完. 尤其这种独角兽, 比如说视频类的, 抖音, 头条已经非常大了, 随便出现一个新业务的话, 作为云厂商去承担会非常的辛苦. 因此, 我们开发了一个新系统, 可以看到 2017 年下半年之后, 我们的储备能力就不需要在经常扩容, 可以很好的支撑不断突发的带宽需求, 这个系统是什么? 我们自己内部叫 Volcano 突发资源系统, Volcano 就是火山的意思. 专门形容火山即将喷发, 这套系统能够应对火山喷发带来的冲击. 技术原理是怎样的呢? 每个服务器都有或多或少的资源空余, 例如这台服务器日常也就跑 60% 的容量, 属于高水位. 还有 30% 的空间可以榨取, 因此我们设定空间榨干所有的资源, 榨干之后还要做一个预估, 现在服务器是晚高峰, 下一个时刻带宽可能跑到多少? 不能榨到 100%,120%, 那个时候服务器崩了.
借助这个之后, 还有一个容器化的技术, 可以做到把全网 10 几 T 的冗余资源带宽利用起来, 通过高可靠技术快速的创建, 快速申请 IP, 快速加入调度, 能够在 60 秒内做好准备工作, 在 5 分钟左右可以协调 1 个 TB 的带宽加入到新网, 去服务这样的突发.
除了纯粹技术上的解决方案未来 5G 还会有产品上的能力包装解决方案. 整个链路从中心到终端上, 会有很多的公有云产品. 例如我们潜心研究视频编码器, 因为当前主流的编码器, 它不一定能适应未来 5G 的编码. 我们从编码器源头做起, 让更好的编码产出更好的视频内容.
在比较边缘的 CDN 节点上我们做两个事情, 一个是极速高清, 借助超分辨率技术把低分辨率提升为高分辨率, 比较适合于以前的港片, 港片分辨率都很低, 做出高分辨力出来. 第二个是 MEC 下沉, MEC 当前还有一些挑战, 解决完这些挑战之后, 我们把它上云给多的客户便捷实用, 而不需要太关注运营商的坑, 直接享受最新的技术, 去提升我们业务的体验. 最后, 终端上还会有有 X-P2P 的能力提供给大家.
讲了 5G 的实践, 也许不一定算是 5G 上的成功案例, 毕竟大家都在摸索 5G, 所以抛砖引玉, 供大家一起学习, 共同进步, 谢谢!
来源: https://www.qcloud.com/developer/article/1527370