基于边缘计算 Client-Edge-Server 业务模型实践
【基于边缘计算 Client-Edge-Server 业务模型实践】近期,以 《极致体验,揭秘抖音背后的音视频技术》 为主题字节跳动第五期技术沙龙圆满落幕。在沙龙中,火山引擎边缘计算产品解决方案架构师王琦从架构的角度,跟大家探讨了 Client-Edge-Server 云边端架构(以下简称CES架构),主要的业务场景及这种新型架构所带来的优势。内容如下:
- Client-Edge-Server 应用架构
- CES 适用的应用场景
- 基于 Client-Edge-Server 架构的实时音视频应用
- 火山引擎边缘计算节点服务
现代IT应用演进
文章图片
从现代 IT 应用演进来,应用前端与后端架构均发生了明显的变化。
- 首先,应用前端载体的移动化。从最早单机模式,逐渐区分出客户端、服务端,以及客户端类型去兼容浏览器的BS结构;再到现在,移动互联网高速发展,客户端的载体更加丰富。可预期的未来,手机、pad、电视,甚至更新颖的 AV/VR/MR 终端,智能机器人等等,都可能成为接入互联网服务的终端类型。也因此,前端需要去适配多样化的终端硬件。
- 其次,后端载体分布式化。后端即服务端,在其架构演进中,系统容量、可用性等一直是衡量其架构设计的关键因素。随着分布式架构理念的落地,通过集群部署代替单点部署,提升系统容量和可用性;再后来将服务端做上云部署,通过云服务的弹性、敏捷特性,可以随时扩缩容来满足突发业务的资源需求。近几年,随着以音视频为载体的新内容呈现方式涌现,数据传输和数据处理的效率,保障用户的实时交互体验等成为业务关键指标。所以在原来的基础上,服务端引入了数据源的物理位置概念,即不再以资源为中心,将数据传输到云中心,然后做处理提供服务,而是以数据为中心,将算力资源前置,在更靠近数据源的地方为用户提供低时延服务,也就是云+ 边缘计算 的云边混合部署模式,Client-Edge-Server 架构也随之诞生。
文章图片
Client-Edge-Server 架构即云边端混合部署架构,其最大的优势在于终端、边缘与中心各司其职,最终降低业务成本,为业务创造新的价值。
- 首先,从中心角度来说,CES架构会将一些关键任务下沉到边缘部署。如对时延比较敏感的实时交互、实时分析、实时决策的数据业务,或者能分布式部署的控制面业务。通过将这部分需要占用大量实时算力的任务下沉边缘后,可以降低中心的业务负荷,从而提升系统容量。中心本身也可以更加关注离线数据聚合,挖掘更多价值,以及关注软件开发迭代的流程和工具本身。
- 其次,从终端角度来说,随着终端类型的多样化,需要投入大量的人力、物力去做终端兼容性测试以及定向的优化。边缘计算在其中主要是辅助终端做一些高性能的计算任务,如图形渲染、高清视频编解码等,通过这种方式实现“瘦终端”的概念,帮助业务摆脱终端硬件的异构问题。
- 最后,从边缘计算角度来说,边缘和中心最大的区别是边缘计算节点可以覆盖除北上广深外,全国各省市、运营商的边缘节点,提供通用的算力资源和IT服务。通过这些资源,可以保障业务更靠近用户的低时延接入和更加广域的业务覆盖。同时,在边缘计算技术方案中,还提供更加精准的网络感知能力,以便业务动态准备资源或调整资源,实现 QOS 和 QOE 的提升与优化。
文章图片
另外,通过对中心部署和云边混合部署两种模式的对比,可以看到相比于中心部署模式,云边混合部署的优势更加显著。
- 第一,保障业务全局体验一致,云边混合部署支持终端用户优先接入本地节点,解决中心部署模式下的网络时延与不稳定问题,保证服务体验的一致性。
- 第二,提升系统整体容量与并发能力,云边混合部署模式采用分布式业务架构,将业务进行拆分,通过边缘计算实现业务全国范围内的分布式部署,帮助中心分担一部分计算、以及大部分网络资源压力,进而提升系统整体的容量和并发能力。
- 第三,降低带宽成本,在短视频、点播、直播这类流量型的产品中,带宽成本是业务成本的占比最大的部分,相比中心模式成本昂贵的 BGP 带宽,边缘计算极具性价比的带宽资源将成为更优选择。
边缘本地业务
文章图片
第一,边缘本地业务,主要指将原来全都部署在云端或某个数据中心的应用服务端,改为部署在边缘,使数据在终端和边缘所在的本地区域即可完成传输和处理的业务。目前主要应用于如智慧工厂、智慧园区等,对超低时延有比较高的要求,同时也需要考虑业务方的数据主权和私密性的场景。
边缘流量加速
文章图片
第二,边缘流量加速型。从终端用户访问后端服务的网络路径可以看到,中间链路会经过运营商的接入网、汇聚网、骨干网,然后再通过公网或专线到后端服务。对普通用户而言,中间链路的网络服务质量是不可控的,尤其是跨运营商、跨广域网传输,碰到丢包、网络延时等都有可能。边缘流量加速的模型就是在接入网络或汇聚网络的区域去部署边缘资源,然后通过专线或隧道和后端服务联通,通过这种方式为用户提供一个比较稳定的传输通道。另外还可以配合一些多路径传输、动态选路等方法,实现流量整体加速能力。这个模型在泛互联网领域的应用已比较成熟,比如 CDN、动态加速、直播等场景都会采用这种模式加速流量,来提升用户的体验。
中心算力卸载
文章图片
第三,中心算力卸载,指将一部分偏实时业务性质的服务从中心卸载至边缘部署。这样边缘不仅仅有数据接入和加速的能力,同时还具备一定对数据进行分析、识别、封装等能力,满足实时分析、实时决策的场景诉求,同时还能优化边缘到中心的带宽使用,目前主要应用于如智慧城市、日志的边缘分析和聚合、视频流的边缘 AI 推理等。
辅助终端计算
文章图片
最后,辅助终端计算,即将本来在终端上运行的一些图形渲染、高清音视频编解码服务放到边缘运行。通过边缘资源的标准服务器 CPU 和 GPU 去执行计算任务,从而优化终端的硬件形态以及业务的普适性。这个模型比较适用于云游戏、云桌面、云机顶盒,以及直播场景里面的一些高性能特效渲染。
基于 Client-Edge-Server 架构的实时音视频应用 此处以实时音视频场景为例,详细阐述 Client-Edge-Server 架构的应用及其创造的业务收益。
业务架构
文章图片
实时音视频(以下简称 RTC)服务目前被广泛应用于视频会议、互动直播、互动娱乐等业务场景,其关键指标比如用户接入时延、响应时延、同一个房间接入用户数等。如上图,RTC 服务本身来说有客户端的SDK、信令服务、媒体服务、配置管理、调度中心、服务监控等几个主要模块。主要业务流程如下:
- 首先,在终端和中心之间引入边缘计算后,将 RTC 服务中的信令服务拆分为边缘信令服务和中心信令服务,边缘信令服务只要实现终端信令请求的处理和转发,中心信令服务则实现信令鉴权以及不同边缘信令服务的异步同步能力。
- 其次,媒体服务则是完全部署在边缘,也就是所有的音视频流数据只会在边缘做接入和转发。
- 最后,在边缘还会有一个统一接入网关实现边缘和终端 SDK、边缘 RTC 服务和其他边缘 RTC 服务、以及边缘 RTC 信令服务和中心 RTC 信令服务的交互。
- 当然,在中心侧还是继续保留原来的配置中心、调度中心等服务,实现统一的配置管理和用户智能接入调度服务。
网络时延
文章图片
首先,CES 架构最大的优势主要在于网络时延,它跟终端用户体验是强相关性。我们把终端用户至云中心中间的区域都归类为边缘计算区域,然后再根据区域的特性,分为了三类:
- 第一类,现场边缘,即在用户数据产生的现场部署算力资源,可以直接提供边缘计算的资源服务。因为算力资源是和用户数据完全在一起,所以时延最低,一般能控制在1-5ms,通常应用于在垂直行业对时延和数据主权比较敏感的业务。
- 第二类,近场边缘,实时音视频服务及其他类似 CDN、直播等场景应用较多,主要在二、三、四线城市做边缘计算的节点建设,接入运营商优质带宽资源,网络时延可以保持在5-20ms。
- 第三类,云边缘,区别于近场边缘,云边缘节点建设主要位于区域中心城市,也支持多个运营商优质的优质带宽资源接入,在区域业务覆盖、数据汇聚和转发时,具备更高的灵活度,并有利于提升数据传输的效率和安全性。
数据面带宽成本
文章图片
其次,数据面带宽成本。举个例子,A 和 B 两个主播连麦,需要互相进行推流和拉流,平台方也需要对这两路流进行合流、转录转直播、审核等操作,因此平台的媒体处理服务也会再去拉 A 和 B 这两路流。
中心架构中,如图1,假设A用户在辽宁,B用户在河北,可能两位用户都会接入位于北京的某个 RTC 媒体服务,总共产生两进四出的 BGP 带宽消耗;而如果B用户在浙江,如图2,B用户可能就会接入上海中心的 RTC 媒体服务,此时涉及北京到上海两个媒体服务之间的推流和拉流,所以总共会有四进六出的 BGP 带宽消耗。
而转到 CES 架构后,业务模型导致的推拉流数目没有减少,但可以通过替换掉 BGP 带宽来降低成本。
- 第一,如图3,假设A用户和B用户都是河北石家庄联通的用户,其连麦的数据可直接在石家庄联通的边缘节点完成互相推拉流,媒体处理服务也直接在石家庄联通节点进行转发或加工。此时的带宽主要是两进四出的运营商单线带宽消耗。
- 第二,如图4,假设A用户是石家庄联通,B用户是洛阳联通,此时A和B用户都会优先接入本地媒体服务,保证最低接入时延。然后,通过边缘节点做媒体服务的级联推拉流。这样视频流的路数是和中心第二种图数目一致的,总计会有四进六出的单线带宽消耗。
- 第二,如图5,边缘的带宽因为区分了不同的运营商,可能会存在同个运营商不同位置,或者跨运营商间传输有网络丢包、时延的影响。此时选择边缘的多线节点,可以将不同运营商的流量进行聚合并转发,像图4直接节点级联做推拉流。但在网络连通性差的时候,就需要选某个三线节点将A和B的视频流先汇聚,进行交换后做运营商间的流量加速。这样最终呈现出来的实际带宽消耗是六进八出的边缘带宽消耗。
控制面系统容量收益
文章图片
最后,对比一下基于 CES 的应用架构与中心模式在系统容量的收益。依然举例说明,假设某个视频会议,其中有10个参与者需要视频发言,除此之外还有1000个观众。情况如下:
- 中心模式:所有用户的信令请求都发送至中心信令服务,包括加入房间、发布流、订阅流等相关操作信令,那么一个信令操作就需要中心信令服务分发1000次。而当其中一个参与者开始发布流了,那么1000个订阅观众都会收到信令提示,10个主播发布流就是10*1000=10000个信令开销。更甚至,如果会议设置是每个新用户加入房间都会给其他人发送提示信息的,那么按照从1-1000个用户依次进入房间,1000个用户的可能产生50万次信令开销。此时,如果开播瞬间用户密集,如此庞大的信令开销很有可能超出服务的处理能力,造成服务拥塞甚至不可用。
- 边缘 信令 模式:对比中心模式,用户所有的信令请求都和本地的边缘信令服务做交互,然后由边缘信令服务做请应答或转发。比如用户加入某个房间的信令请求,会先到边缘信令服务,此时如果本地有房间信息,可以直接应答并返回相关配置信息和流信息;如果本地没有房间信息,才需要边缘信令发起请求向中心的信令服务获取相关信息并缓存;再比如拉流请求,如果边缘本地已缓存这个流的ID、地址等信息,也是直接做应答,没有缓存才会向中心信令服务请求目标流信息。所以对中心的信令服务而言,其服务对象不再是数以万计、甚至更多的终端用户,而是边缘信令服务,一般来说,可控制在“百”级别。因此,基于 CES 的边缘信令模式,能极大降低中心信令服务的负荷和并发度,提升整体系统容量,最终实现支撑几十万、百万人规模的房间容量。
文章图片
目前,火山引擎也以 CES 架构为基础,构建了面向异构算力的新一代边缘计算云平台。边缘计算云平台整体采用一横 N 纵的结构,一横是指基于边缘计算基础设施打造的云原生边缘平台,N 纵指具象化的服务能力,如边缘虚机、边缘容器、边缘网络、边缘函数和边缘渲染等。
- 首先,在基础设施层,根据边缘算力的分布层级优选全国各省市丰富的边缘资源和运营商网络,并按地理位置部署优质的单线、多线和 BGP 的节点,结合多种架构的硬件设备,如:X86、ARM 服务器、智能网卡、GPU 等算力和网络资源,打造面向异构算力的边缘基础设施底座。
- 其次,在平台层,基于边缘基础设施底座,火山引擎边缘计算自研了云原生边缘平台,以面向边缘云原生的操作系统为核心,提供边缘自治管理、核心系统组件管理以及大规模部署的镜像服务能力。
- 第三,在资源服务层,边缘计算团队将云原生边缘平台模块化,通过自研网络组件提供多种功能,由此形成边缘计算资源服务层,可以按需提供不同的边缘能力,如:虚机、容器、网络、函数、渲染等一系列服务。
- 最后,边缘计算云平台配合云边管理和数据管理模式,实现业务的全域智能调度、实时数据大屏,满足内容分发、视频直播、实时音视频、云游戏等多个场景应用。
文章图片
- 节点丰富:基于覆盖全国各省市和运营商的边缘节点,提供更低时延、更高性能、稳定可靠的计算资源,实现业务应用更靠近用户侧的部署和服务;同时,边缘计算节点还具备超大规模分布式算力单元,能够提供单线、多线、等多种网络形态,满足不同场景的业务诉求。
- 功能完备:支持 VPC 私有网络、弹性公网IP、高性能负载均衡、防火墙、IPv4/IPv6 双栈等多种特性,提供开关自定义限速、VF 直通功能等满足业务的按需、弹性使用体验。另外,边缘计算节点的一键开通、镜像预热、自定义云报警、一键分发等特性功能,有助于帮助业务减少部署和运维成本。
- 极致性能:在硬件上,边缘计算节点优选新一代至强系列铂金处理器,100G/25G智能网卡,提供高效计算和网络转化能力;同时采用 SPDK 技术优化磁盘IO,并提供NVMe SSD 高效云盘和本地盘;边缘计算团队自研的高性能网络套件,目前也已实现边缘单实例 PPS 超 700W 的优异性能。
- 优质服务:在服务上,火山引擎边缘计算支撑了2021央视春晚抖音红包/818抖音新潮好物节等流量洪峰场景,沉淀了大型流量业务保障体系。经过这类大规模、海量业务的流量考验,形成了完善的监控、运维和服务体系,为业务保驾护航。
文章图片
最后这里,也和大家分享下火山引擎边缘计算的实践案例。
- 今日头条:通过火山引擎边缘计算提供的节点资源,帮助建设全域覆盖的CDN网络,加速头条业务的内容分发,保证用户使用体验。
- 抖音直播:边缘计算支撑了抖音的直播业务,通过全国覆盖的边缘节点以及VF直通、100Ge的高性能网卡满足业务高并发、高吞吐需求,提供高清、实时、流畅的观看体验。
- 住小帮:边缘计算的GPU资源在住小帮VR看房业务中,提供充足的边缘本地GPU实例,实现高效的 VR 全景素材的合成和渲染,加速传输效率和渲染效率。
文章图片
推荐阅读
- 基于SqlSugar的数据库访问处理的封装,在.net6框架的Web|基于SqlSugar的数据库访问处理的封装,在.net6框架的Web API上开发应用
- CK2031-基于okhttp 3 的 Android 网络层架构设计实战
- 基于Android官方Paging Library的RecyclerView分页加载框架
- 基于Android官方AsyncListUtil优化改进RecyclerView分页加载机制
- TensorRT+深度学习|ONNX+TensorRT:基于ONNX+TensorRT+AlexNet+Qt+WIN10的图像分类
- R语言初见|R语言使用strsplit函数基于指定字符或者字符串分割字符串、使用sub函数进行字符串替换、使用tolower函数将字符串转化为小写字符
- 苹果的计算器看得到记录吗
- Linux 内核 内存管理分区伙伴分配器 ⑦ ( z->watermark[WMARK_MIN] 最低水位计算 | min_free_kbytes 初始化 )
- 基于SqlSugar的数据库访问处理的封装,支持.net|基于SqlSugar的数据库访问处理的封装,支持.net FrameWork和.net core的项目调用
- linux