《腾讯云&中国信通院:2023边缘Serverless白皮书(42页).pdf》由会员分享,可在线阅读,更多相关《腾讯云&中国信通院:2023边缘Serverless白皮书(42页).pdf(42页珍藏版)》请在三个皮匠报告上搜索。
1、 目录 1.万物互联带来新机遇,边缘 Serverless 开辟新增长空间.1 1.1.产业数字化持续演进,催生众多边缘应用需求.1 1.2.边缘计算增长态势良好,发展进入高景气周期.2 1.3.契合边缘侧发展诉求,边缘 Serverless 大有可为.7 2.技术和市场相互促进,边缘 Serverless 生态日趋完善.8 2.1.阐明本质内涵,边缘 Serverless 概念清晰定义.8 2.2.用户需求旺盛,边缘 Serverless 产品日渐丰富.10 2.3.应用前景广阔,边缘 Serverless 生态持续繁荣.11 3.通用函数融合专用组件,边缘 Serverless 技术走向成
2、熟.12 3.1.边缘函数提供轻量化解决方案.13 3.1.1.边缘函数研发.16 3.1.2.边缘函数发布.18 3.1.3.边缘函数接入.20 3.1.4.边缘函数执行.27 3.2.边缘组件满足个性化业务需求.29 3.2.1.边缘存储.30 3.2.2.边缘 AI 推理.31 3.2.3.边缘图片处理.31 3.2.4.边缘中间件.32 4.边缘 Serverless 典型应用场景.32 4.1.边缘渲染.32 4.2.灰度发布.34 4.3.APK 动态签名.34 4.4.M3U8 改写.36 5.总结与展望.37 前言 数字经济蓬勃发展,重点行业积极创新,数字技术已成为各行业企业提
3、升竞争力的新战场。其中边缘 Serverless 充分融合边缘计算与服务器无感知的技术优势,缩短数据传输链路,简化运维复杂程度,盘活边缘算力资源,为万物互联互通背景下全行业的数字化转型开辟了新的道路。本白皮书梳理了边缘 Serverless 的发展背景,给出了边缘 Serverless 的清晰定义,分析了边缘 Serverless 的市场趋势,深度剖析了边缘 Serverless 的战略价值,详细解析了边缘Serverless 的技术要点。本白皮书从技术实践出发,对比了边缘 Serverless 解决方案较传统模式带来的显著变化与优势。充分展现了边缘 Serverless 的实际效用与现实价值
4、。最后,本白皮书对边缘 Serverless 的未来发展进行了展望。期望通过本白皮书能够加深业界对边缘 Serverless 的认知,为边缘 Serverless 建设提供参考思路,加速边缘 Serverless 技术的持续演进,推动边缘 Serverless 理念的广泛落地。1 1.万物互联带来新机遇,边缘 Serverless 开辟新增长空间 1.1.产业数字化持续演进,催生众多边缘应用需求 数字经济蓬勃发展,产业数字化进程持续加深。2022 年,我国数字经济规模达 50.2 万亿元,同比名义增长 10.3%,占 GDP 比重达 41.5%,连续 11 年显著高于同期 GDP 名义增速。其
5、中产业数字化规模占数字经济总规模的 81.7%,发展处于快车道1。2023 年中共中央、国务院印发的 数字中国建设整体布局规划 明确指出,要促进数字经济和实体经济深度融合,以数字化驱动生产生活和治理方式变革。当前,各重点行业正积极响应时代号召,拥抱数字化浪潮,深刻践行数字化转型方针,充分发挥数字技术效用,提升自身数字化能力,促进数字中国建设水平的跃升与中国式现代化伟大目标的达成。重点行业积极创新,全新数字模式构筑新常态。数字化已成为各行业企业提升竞争力的新战场,未来的生产生活都将与数字技术息息相关。一方面,传统行业正积极采纳数字技术为旧场景注入新活力。自动驾驶场景下,基于对周围环境及变化的感知
6、与决策可实现辅助驾驶甚至无人驾驶;智慧工厂场景下,通过对工业设备运行状况的实时采集、监测与统一控制,大幅提升执行效率、降低运维成本;智慧农业场景下,通过对土壤水分数据的采集与分析实时调整灌溉系统的出水量。另一方面,新兴的数字需求也演生出诸多新业态。以元宇宙为例,通过对虚拟现实、增强现实、边缘计算、区块链等先进数字技术的综合运用,以游戏、社交等场景为切入点,逐步实现物理世界与虚拟世界的深层次连接。算力需求爆发式增长,边缘侧计算能力成为刚需。截至 2022 年底,我国移动物联网 1 数据来源:中国数字经济发展报告(2023 年),中国信息通信研究院 2 连接数已达 18.45 亿户,较上一年度净增
7、 4.47 亿户,占全球总数的 70%2,万物互联基础不断夯实。随着终端侧处理需求的激增及数据量的暴涨,单纯采用中心云计算的建设方案暴露出网络带宽受限、决策实时性不足、隐私保护风险等问题,无法满足庞大的算力需求与流畅的交互体验,需要靠近端侧的边缘设备承担部分负载。边缘计算是一种将服务托管在靠近用户接入点的边缘设备上,通过减少端到端延迟和传输网络负载以实现高效服务交付的模式。边缘计算被视作实现 5G 通信与计算融合的一项关键使能技术,是中心云计算的有效补充,能够有效应对万物互联互通大背景下指数级增长的算力需求。图 1 中国移动物联网连接数量 1.2.边缘计算增长态势良好,发展进入高景气周期 国内
8、外政策积极引导,边缘计算被视作价值高地。从国际形势来看,各国充分重视边缘计算的发展。2019 年韩国科学技术信息通信部发布的5G+ICT 研发技术路线图(20192026)强调边缘计算是十大核心产业,并计划于 2026 年开发出融合公共、民间等不同领域使用的边缘计算技术。2020年欧盟发布的欧洲数据战略强调要抓住边缘计算、5G和 2 数据来源:中国互联网络发展状况统计报告,中国互联网络信息中心,2023 年 3 月 3 物联网带来的新机遇。同年美国白宫发布的引领未来先进计算生态系统:战略计划强调要从集中式先进计算资源向分布式边缘到云的联合计算和数据资源转变。2021 年澳大利亚航天局发布的空间
9、对地观测路线图 20212030强调要探索边缘计算在内的跨越式概念。从国内环境来看,政策红利驱使边缘计算与产业的融合。2020 年 4 月,工信部在关于工业大数据发展的指导意见中提出要推动人工智能、区块链和边缘计算等前沿技术的部署和融合。2020 年 12 月工业互联网专项工作组发布的 工业互联网创新发展行动计划(2021-2023年)指出要结合边缘计算等新技术应用和产业发展趋势,完善工业互联网标准体系。2022年 1 月国务院发布的“十四五”数字经济发展计划指出要加快实施“东数西算”工程,加强面向特定场景的边缘计算能力。2023 年中共中央、国务院发布的数字中国建设整体布局规划 指出要促进东
10、西部算力高效互补和协同联动,引导边缘数据中心的合理梯次布局。表 1 国外边缘计算的相关政策 发布时间 发布单位 政策名称 重点内容 2019.7 韩国科学技术信息通信部 5G+ICT 研发技术路线图(20192026)2023 年开发出制造、医疗、交通等产业现场使用的边缘计算技术;2026 年开发出融合公共、民间等不同领域使用的边缘计算技术。2019.11 美国白宫 国家战略性计算计划(更新版)有效利用包括边缘计算在内的国家计算生态系统。4 2020.2 欧盟 欧洲数据战略 抓住边缘计算、5G 和物联网带来的新机遇。2020.11 美国白宫 引领未来先进计算生态系统:战略计划 从集中式先进计算
11、资源(即“超级计算机”)向分布式边缘到云的联合计算和数据资源转变 2021.5 美国战略部 云战略 公布战术边缘云战略,推进边缘计算的军事化应用。2021.11 法国 国家云工业计划 支持法国创新产品开发,扩大法国企业在大数据或协作工作等关键技术方面的规模,加强边缘计算等颠覆性技术发展。2021.11 澳大利亚航天局 空间对地观测路线图20212030 探索边缘计算在内的跨越式概念 2022.3 日本总务省、学术机构 超越 5G 白皮书 重点关注边缘计算技术,通过非地面网络扩大网络覆盖范围。表 2 我国边缘计算相关政策 发布时间 发布单位 政策名称 重点内容 5 2020.4 工信部 关于工业
12、大数据发展的指导意见 加快数据汇聚、建模分析、应用开发、资源调度和监测管理等共性技术的研发和应用,推动人工智能、区块链和边缘计算等前沿技术的部署和融合。2020.9 工信部 关于深入推进移动物联网全面发展的通知 面向不同垂直行业应用环境和业务需求,重点加强包括边缘计算在内的多项新兴关键技术研究 2020.12 工业互联网专项工作组 工业互联网创新发展行动计划(2021-2023年)结合 5G、边缘计算、人工智能等新技术应用和产业发展趋势,完善工业互联网标准体系,明确标准化重点领域和方向,指导标准化工作分领域推进实施。2021.7 工信部 新型数据中心发展三年行动计划(2021-2023年)加速
13、改造升级“老旧小散”数据中心,提高“老旧小散”数据中心能源利用效率和算力供给能力,更好满足当地边缘计算应用需求。6 边缘计算优势显著,算力沉降突破触达边界。边缘计算与中心云计算相辅相成,深度贯通“云-边-端”,真正实现算力的全领域触达。边缘计算的主要优势如下:一是低延迟性能助力万物互联,在接近数据源的节点即可执行部分或全部的计算要求,缩短数据传输链路有效降低延时,满足高实时性场景要求。二是复杂网络环境下保障服务高可靠,边缘节点在网络正常时可不断从云端拉取最新元数据,在断网或弱网状态下能够从本地缓存获取元数据2021.11 工信部、国家标准化管理委员会 工业互联网综合标准化体系建设指南(2021
14、版)边缘计算能够有效推动工业数据纵向集成及实时处理,已成为工业互联网云边网端协同的关键枢纽环节。围绕边缘计算的需求、总体架构、关键节点模型及要求等方面形成一系列标准。2022.1 国务院“十四五”数字经济发展计划 加快实施“东数西算”工程,推进云网协同发展,提升数据中心跨网络、跨地域数据交互能力,加强面向特定场景的边缘计算能力,强化算力统筹和智能调度。2023.2 中共中央、国务院 数字中国建设整体布局规划 要促进东西部算力高效互补和协同联动,引导边缘数据中心的合理梯次布局。7 实现一定程度的自治,保障业务稳定运行。三是数据隔离特性为安全保驾护航,可通过就近边缘节点对用户源数据进行预处理,实现
15、敏感数据的隔离保护,同时支持数据在特定的安全边界内保持私有化,有效降低安全风险。边缘计算市场前景广阔,产业规模稳步攀升。随着边缘侧需求的增长,计算往边缘下沉的速度正在加快。边缘计算在 2020 年被 Gartner 评为十大战略技术趋势之一,根据MarketsandMarkets 统计数据,2022 年全球边缘计算市场规模超 447 亿美元,预计到 2027年底将达到 1013 亿美元以上。在人工智能浪潮的驱动下,2023 年全球边缘 AI 市场将从 2018年的 3.56 亿美元增长至 11.52 亿美元。国内市场来看,信通院调研数据显示 2021 年我国边缘计算市场规模已达到 436.4
16、亿元,预计 2024 年将达 1803.7 亿元,增长空间广阔。从落地角度看,IDC 预测,到 2023 年末将有 50%的企业 IT 基础架构软件选择在边缘部署,到 2024年末边缘应用将有 8 倍的增长。1.3.契合边缘侧发展诉求,边缘 Serverless 大有可为 落地面临挑战,边缘侧计算模式仍有待优化。区别于具备大规模海量数据处理能力的中心云计算,在边缘场景下,关注点更多聚焦于靠近用户侧的实时数据处理与分析。5G 技术的演进与落地进一步满足了严苛的实时性要求,然而边缘侧应用场景仍面临诸多挑战。一是边缘设备计算能力不足,为缓解中心云的负载压力,部分逻辑下沉到边缘侧执行,需要边缘节点提供
17、灵活简单的计算模式。二是边缘节点资源大小受限,单个边缘节点的计算、存储、网络等资源固定,需要更轻量化更低开销的方案,充分利用有限资源。三是边缘资源协同调度难度大,边缘节点数量众多且分散在全球各地,需要将分布式的边缘节点协调联动,面向用户提供统一的计算、分析、处理等服务。聚焦上层应用,Serverless(服务器无感知)是高频竞争时代的破局利器。Serverless 8 是一种将基础设施资源抽象成按需使用的服务,用户只需关注应用逻辑,而无需管理复杂的基础设施运维工作的设计模式。Serverless 定义了一种全新的开发范式,聚焦业务价值,屏蔽底层基础设施复杂性,具备按需伸缩、免运维、快速交付、按
18、量付费等特性,充分体现了以应用为中心的理念。FaaS(Function as a Service,函数即服务)作为 Serverless 最典型的计算形态,当有请求到来时,触发函数执行相关代码逻辑,当请求结束后,即可释放资源,突破了传统应用自行规划容量、提前申请并占用常驻资源的构建模式,在轻量、敏捷、弹性、成本等方面具有无可比拟的优势。切中边缘侧痛点,FaaS 与边缘融合释放倍乘效用。在边缘侧运用 Serverless 技术能够发挥两点典型优势:一方面体现为轻量化的代码托管能力。边缘计算的核心目的是把原先必须在云端执行的逻辑下沉到边缘设备,从而能够在更靠近用户的地方更快响应用户请求,因此边缘设
19、备需要具备灵活执行用户代码的能力。FaaS模式能够降低业务逻辑构建的复杂性,支持以更轻量化的方式编写、更新与托管代码逻辑。另一方面体现为算力资源的统筹利用。由于受到边缘物理基础设施的限制,边缘计算的资源扩展难度大。FaaS 模式下无需提前规划,能够充分调度边缘节点的资源实现按需弹性,同时运行完成后即可释放资源,充分提高资源利用率,盘活算力资源。2.技术和市场相互促进,边缘 Serverless 生态日趋完善 2.1.阐明本质内涵,边缘 Serverless 概念清晰定义 根据部署位置差异,函数即服务的形态可划分为两类:一是中心云函数即服务,二是边缘函数即服务。边缘函数是指运行在边缘节点上的代码
20、逻辑。边缘函数即服务是指基于事件驱动的边缘函数托管服务,可将不同地域的请求调度至就近边缘节点执行计算任务,且能 9 够根据请求量按需获取和释放计算资源,是服务器无感知架构的一种实现方式。边缘函数即服务与中心云函数即服务都是基于 Serverless 理念构建的,均具备Serverless 的敏捷、免运维、即需即用等特性,由于适用场景及其对应使用诉求不同,两类函数即服务在诸多特性上存在较大差异。表 3 函数即服务差异对比 边缘函数即服务 中心云函数即服务 部署位置 边缘节点,全球分布 中心集群,集中在主要大城市 冷启动延时 短 长 运行时 Chromium V8、WebAssembly 容器 最
21、大运行时长 秒级 分钟级 最大占用内存 MB 级 GB 级 代码包大小 KB 级 MB 级 支持语言 以 JavaScript 为主 多语言,如 Node.js、Python、PHP 等 可承受 QPS 高 低 适用场景 轻计算,延迟敏感 重计算,延迟不敏感 10 边缘组件是边缘 Serverless 生态的重要组成部分,边缘组件可以有效组织硬件资源,为边缘函数提供了丰富的功能补充。边缘组件也像边缘函数一样,具备低延迟、弹性、隔离、安全等特性,同时边缘组件 API 和边缘函数 Runtime 可以完美结合,开箱即用,使得非专业人员也可以使用专业度较高的组件能力。边缘函数和边缘组件共同组成了边缘
22、 Serverless,提供了强大的功能开发和运行能力。2.2.用户需求旺盛,边缘 Serverless 产品日渐丰富 图 2 边缘函数即服务发展历程 从国外情况来看,各厂商对边缘函数即服务的探索开始较早,并积极开展落地。亚马逊作为全球云计算领域的先行者,继 2014 年发布全球首款中心云函数即服务 Lambda 后,于 2017 年 7 月发布了以容器化形式将函数部署到边缘的解决方案 LambdaEdge,在 2021年又基于新的虚拟及隔离技术发布 Cloudfront Functions,进一步优化了冷启动时延与成本。2017 年 9 月 Cloudflare 发布基于 Chromium
23、V8 引擎的边缘函数即服务解决方案 Workers,冷启动时延可达到毫秒级别,并于 2019 年推出全球分布式键值数据库 KV store,能够与Workers配合使用。同年,Akamai 推出 Edge Worker,功能及性能与 Cloudflare Workers 类似。不同于Cloudflare 的技术路线,Fastly 全心投入 WebAssembly 的研究并自研 Lucet 编译器和运行时,2021 年正式发布 ComputeEdge,将冷启动时延缩小到微秒级别。11 从国内情况来看,各厂商的中心云函数产品已趋于完善,但边缘函数即服务仍处于建设阶段。2017 年,腾讯云、阿里云、
24、华为云、百度智能云先后发布中心云函数即服务产品。随着 Serverless 理念的发展以及边缘侧需求的增长,国内厂商逐步开展边缘函数即服务的实践。2021 年 7 月阿里云推出边缘应用 EdgeRoutine,同年 12 月白山云推出 FunctionEdge,2022 年 9 月腾讯云正式发布边缘函数 Edge Functions。同时,华为云、火山引擎、天翼云等厂商也正在持续打磨与孵化边缘函数即服务产品,国内边缘函数即服务的产业生态将持续繁荣。2.3.应用前景广阔,边缘 Serverless 生态持续繁荣 从入局企业来看,边缘 Serverless 服务提供商主要分为两大阵营。一类是云厂商
25、,云厂商通常配套丰富的云产品能力,且具备深厚的技术积累,能够将先进的云原生技术赋能到边缘侧,同时与中心云的相关产品结合,满足各类处理诉求。另一类是 CDN(Content Distribution Network,内容分发网络)厂商,传统 CDN 市场日渐式微,CDN 厂商正积极转型探索边缘场景,CDN 厂商通常具有数量众多的可覆盖全球的边缘节点,从而能够更靠近终端用户,一定程度上可减少触达时延。从市场规模来看,边缘 Serverless 实力强劲,增长潜力大。根据中国信通院测算,2021 年我国边缘计算市场规模为 436.4 亿元,其中边缘软件与服务市场规模为 146.2 亿元,预计 202
26、4 年边缘计算市场整体规模将达 1803.7 亿元。KBV 研究公司发布的 全球 Serverless架构市场报告显示,全球 Serverless 架构市场的规模预计到 2024 年将达 140 亿美元,且预测期内将以 23.4%的年复合增长率增长。Gartner 在 2022 云平台服务成熟度曲线中预测边缘函数即服务将在 2-5 年内进入稳定期。Akamai 的边缘应用业务(包括边缘函数即服务形态)在 2020 年收入为 1.51 亿美元,预计到 2025 年将增长至 90 亿美元,达到与传统 CDN 市 12 场相当的市值。Cloudflare 预测基于其 Serverless 架构之上(
27、包括 Workers、Workers KV 等产品)所提供服务的目标市场总值将在 2024 达到 7000 亿人民币。在边缘服务需求与 Serverless架构演进的双重驱动下,可以预见,边缘 Serverless 服务将进入高景气周期。图 3 Gartner 2022 云平台服务成熟度曲线 从应用情况来看,边缘函数即服务价值逐步被认可,采纳率可观。Datadog 于 2021 年发布的数据显示,四分之一的 Amazon CloudFront 企业客户已经在使用 LambdaEdge,如根据用户特征实现图像的动态转换,或者在 A/B 测试中提供 Web 应用程序的不同版本等,67%的 Lamb
28、daEdge 函数运行时长在 20 毫秒以内。根据中国信息通信研究院2022 中国Serverless 用户调查数据,近四成受访用户已将 FaaS 投入生产,其中用于核心业务生产环境的比例高达 17.83%,已采纳 FaaS 的用户中有 31.13%已将 FaaS 应用于边缘场景。3.通用函数融合专用组件,边缘 Serverless 技术走向成熟 边缘 Serverless 其实是将边缘 Serverless 节点当作一台超级计算机,边缘函数可以看作 13 这台设备的“计算模块”。单一的边缘函数计算服务能够满足大部分无状态的执行逻辑,但是对于有状态的逻辑开发,还需要为这台计算机添加边缘组件这样
29、的“存储模块”用于临时或者永久存储一些状态。因此,边缘组件同样是边缘 Serverless 生态中的重要一环,它和边缘函数一起构成了完整的边缘 Serverless 生态。随着技术发展逐步深入,在不同行业领域诞生了大量的专用硬件和软件,这些专用硬件和软件在对应领域的性能等方面往往大幅度领先通用组件,为满足在某些细分领域上有更高要求的开发人员,需要为边缘 Serverless 这台超级计算机添加对应的专有能力,例如“AI模块”、“图片处理模块”等。最后还需要类似“定时任务”、“消息队列”等辅助组件共同协作以完成复杂系统的开发。在实践过程中,边缘函数层负责将业务逻辑进行函数化包装,并在全球边缘 S
30、erverless 节点进行发布,根据用户请求执行对应的函数逻辑,最终返回结果;边缘组件层负责在函数从执行到返回的全生命周期中,依据不同的业务类型,提供各种能力支撑。图 4 边缘 Serverless 生态 3.1.边缘函数提供轻量化解决方案 尽管边缘函数具有诸多优势和价值,例如较低的延迟,更好的数据安全和隐私保护能 14 力,更高的灵活性和可扩展性等。但由于边缘计算与中心计算在部署架构和分布上存在明显区别,因此在边缘函数的研发、部署接入、全球数据状态一致性及完整性、以及边缘运行时的性能保障等方面存在诸多挑战。图 5 边缘函数架构 研发:由于函数执行本身对隔离性有一定的要求,因此函数往往被部署
31、在某个沙箱环境中,对外部组件、磁盘、网络等访问的过程由特殊的运行时 API 提供。因此用户无法完全在本地环境运行、调试函数,对研发过程造成了极大的不变,需要提供配套的工具链以改善研发体验。部署和接入:由于边缘网络具有全球分布性,经常跨越各个国家的一级运营商,同时不同地区的边缘设备可能位于不同的网络环境中,其网络状况和访问速度也会存在差异,导致函数的就近接入和全球部署变得困难重重。因此,要确保边缘函数在全球范围内的稳定性和性能,需要采取更加复杂和灵活的技术和策略。全球数据状态一致性及完整性:中心计算场景下,数据状态的强一致性通常比较容易保 15 证,因为中心计算通常运行在一个集中式的环境中,且中
32、心节点对于整个系统具有完全的控制权。因此,中心计算可以采用更为简单和直接的方法,例如在所有节点之间进行数据同步和复制,以保证数据状态的一致性。与此相反,在分布式环境中,数据同步的延迟和一致性非常难以保证。边缘设备的异构性和全球分布性,使得数据在不同的节点之间传输和同步存在各种不可预知的延迟和错误,例如网络延迟、节点故障、数据冲突等,这些问题都可能导致数据同步出现错误和不一致性。同时,边缘设备的异构性和全球各地机房管控标准的差异性也会导致全球数据状态的不完整。在全球同步数据的过程中,由于网络问题、劫持问题以及设备故障等原因,数据的状态很容易被篡改,进一步影响数据的完整性。因此,需要采取更加灵活和
33、可扩展的技术和策略,来解决边缘函数中全球同步数据的挑战,并保护数据的完整性。边缘运行时的性能保障:相比中心云,边缘设备异构且通常具有资源受限的特点,例如内存、存储和处理能力等方面的限制;同时,边缘函数所处理的任务并发量高(每秒千万量级次请求),负载相对较小(处理时长一般在 5 毫秒量级),用完即走,这对边缘函数来说是一个全新的挑战。从边缘函数本身的使用周期来讲,可以将这些技术挑战划分到四个阶段:研发阶段:由函数开发方完成函数的编写、调试和测试。发布阶段:函数研发完成后,由边缘 Serverless 平台部署到全球边缘 Serverless 节点中,等待请求接入。接入阶段:由边缘 Serverl
34、ess 平台提供域名等调度手段,将调用请求根据边缘 Serverless节点的负载、访问延迟等特征,调度至最优节点。运行阶段:请求被调度至当前边缘 Serverless 节点后,执行对应函数,计算产生结果。16 下面将围绕这四个阶段,从边缘函数的研发、发布、接入、及运行展开阐述具体的挑战和解决方案。3.1.1.边缘函数研发 问题和挑战:边缘函数一般运行在边缘计算节点特定的沙箱环境中,用户无法像在中心算力一样访问设备的任意资源,这导致边缘函数往往只能用于逻辑简单的无状态纯计算服务,应用场景明显受限。并且用户只能使用沙箱环境支持的语言和特定环境进行开发,无法本地测试,进一步增大了用户的研发难度。因
35、此边缘函数在研发阶段最大的挑战就是如何向用户提供一套和本地开发能力接近的研发平台,使得用户只需要像开发本地单机服务一样进行研发,就可以在全球部署。解决方案:边缘函数研发平台的目标是打造功能完备且易用的一站式解决方案。在开发阶段,希望为开发者屏蔽所有不相关的底层逻辑,例如申请对象存储、接入加速 CDN、部署队列服务等,他们只需要关注业务逻辑,基于熟悉的开发语言进行开发,实现各种业务应用。并且提供远程调试脚手架、实时流式日志等能力,提升调试体验。研发平台的基本思想就是把全球机房节点当作一个超级计算机,在之上去抽象网络、计算、存储接口。正如前面所提及,在边缘函数中,网络与计算类接口与中心函数计算差别
36、不大,而存储(计算状态)接口是边缘与中心的核心区别所在。因此,研发平台可按照边缘函数计算的无状态、弱状态、强状态去划分存储接口及演进体系。无状态:指的是在边缘提供一些常用的,与跨地域状态无关的计算能力,例如网络处理、17 流式计算等接口。这类接口可支持实现图片处理、页面渲染等无状态应用。弱状态:指的是在全球边缘提供最终一致性的状态同步能力,例如边缘缓存及 KV。有了这类接口就可以开发实现边缘 WAF、Public DNS 等需要弱状态同步的应用。强状态:指的是在边缘上实现全球强一致的同步,包括了支持事务性的数据库及强一致的对象存储能力等接口。这类接口将支持有强一致要求的应用,例如文档协同,多人
37、游戏等应用。模块扩展:同时,边缘函数研发平台还应支持更加通用的扩展性,包括了通过 WASM 通用字节码对多语言的支持,以及支持核心组件的服务化,包括视频编码、人工智能等能力的服务化。这样,不同专业领域的开发者都可以加入到同一个平台上,一起构建边缘函数研发生态。图 6 Serverless 接口分类及演进 同时提供脚手架命令行工具支持上述组件的绑定、发布、代码检查、实时调试、实时流式日志订阅等能力,使得用户可以像本地研发一样可以实时部署调试,所见既所得,全面提升边缘函数的开发体验。18 3.1.2.边缘函数发布 问题和挑战:服务在中心算力部署时一般部署在特定的某几个机房的某些设备上,而边缘函数出
38、于在全球各地提供低延迟服务的目的,需要在全球分布的大量边缘 Serverless 机房部署;并且由于边缘设备单机算力有限,又进一步导致了需要部署的边缘 Serverless 节点数量增多。由于部署的设备数量大幅度上升,以传统的推送部署模式在超大规模集群上发布边缘函数可能会遇到如下问题:因为无法知晓用户的请求会发送到哪些设备,因此新增函数在所有节点部署完成前无法提供给用户使用,函数必须再所有节点都完成发布后才能对外使用,整体发布耗时大幅度增长。部署消耗的带宽极大。假设需要在全球一万个边缘 Serverless 节点上部署 5MB 的函数,会产生 50GB 的流量。如果需要在 10 秒内部署完成,
39、单个函数部署的峰值带宽就会达到 40Gbps。即使使用压缩传输,带来的带宽开销也是难以承受的。部署产生的流量绝大多数都是无效流量,一是由于开发者可能仅出于体验测试的目的尝试部署,仅有个别节点会产生实际的访问。二是由于大部分的产品用户分布也较为集中,一般会集中访问某个地域的节点而不是全球所有的节点。因此如何在全球部署的场景下仍然保持极低的部署延迟和部署开销是边缘函数发布的主要挑战。解决方案:边缘函数的载体是代码文件,边缘函数的全球发布本质上是一次文件分发,而如何将 19 文件快速、低成本的分发至全球边缘节点恰好是 内容分发网络(CDN)本身需要解决的问题。CDN 从一开始就面临着如何将海量的用户
40、文件低成本快速分发至边缘节点以加速用户访问的问题。并且客户甚至不会通知 CDN 供应商哪些文件需要被分发。为了解决这一问题,CDN 厂商往往使用“回源”模式处理文件内容而非分发模式,即 CDN 厂商并不是主动将所有文件分发至边缘节点,而是当用户实际访问这些文件时再根据用户的访问路径和客户配置好的“源站”按需获取文件内容并流式传输给客户端同时缓存下来。如果当前节点某些文件并没有被访问过,那么 CDN 厂商并不会产生无效的文件拉取流量。虽然这会导致当前文件在节点上首次被访问的延迟上涨,但是这使得 CDN 厂商可以在不知晓源站文件列表也不需要主动分发文件的前提下,立刻为全球的用户提供边缘文件分发服务
41、。并且文件被访问过后会在边缘节点上生成缓存,后续的访问并不会有额外的延迟,同时源站也不需要提供额外的分发带宽。由于边缘函数发布本质上也是文件的全球分发过程,因此可以借鉴 CDN 的处理逻辑,采用类似“回源”的惰性拉取模式进行函数的分发:开发者提交函数后,不主动推送到所有边缘 Serverless 节点上,仅存储在中心管控。当客户端请求节点时,检查本地是否存在对应的边缘函数。如不存在,则实时向Serverless 中心管控系统拉取并缓存。当开发者重新发布边缘函数后,向节点下发清理旧函数缓存的信令,允许重新回源拉取。20 图 7 函数分发过程 使用惰性拉取方案具有如下优点:新接入的边缘 Serve
42、rless 节点在全球范围实时生效,用户无需等待即可访问。只有真正需要使用该边缘函数的节点会产生拉取动作,避免产生无意义的分发流量。信令大小远小于边缘函数本身的大小,可以在极短的时间内完成分发,无需担心分发带宽。同时,P2P 也是文件分发中经常被采用的一种技术,P2P 分发可以将分发从“中心到边缘”优化为“边缘到边缘”,降低中心服务的压力。边缘函数的分发也可以采用类似的思路,即当本地缓存没有对应函数时,可以尝试访问机房内或者临近机房的其他边缘 Serverless节点获取函数,可以进一步降低函数发布所需的成本。3.1.3.边缘函数接入 边缘函数部署在全球的边缘节点,边缘机房往往跨越各个国家一级
43、运营商,同时不同地区的边缘设备可能位于不同的网络环境中,其网络状况和访问速度也会存在差异,难以确 21 认当前用户的最优边缘函数接入点。因此,要确保边缘函数在全球范围内用户请求接入的稳定性和性能,需要采取更加复杂和灵活的调度技术和策略。网络质量实时探测 问题和挑战:对边缘网络来说,网络的复杂性要远高于中心网络。不同的地区、运营商甚至每个边缘 Serverless 节点的链路情况都不同。单纯基于运营商网络的特点和 IP 地址库等方式对网络质量进行评估是不够准确的,但是准确的网络质量评估是高质量调度策略中的关键信息之一。因此保证高质量接入的一大困难就是如何获取到用户具体的网络情况,比如:丢包率、带
44、宽、延迟等信息,从而综合评估出用户侧网络质量。由于用户设备本身存在频繁的上下线和 IP 切换等行为,直接探测用户设备会影响数据的稳定性,因此首先需要解决的就是如何选取到稳定可靠并且可以代表用户网络质量的探测点,并且得出综合的网络质量数据。解决方案:22 图 8 端到端网络访问 如图 8 所示,回归到网络本身,使用网络拓扑,寻找代表用户网络质量的汇聚点point。这类汇聚点一般是用户的网络出口,比较稳定且离用户较近,可以用来代表用户的网络质量。23 图 9 用户拓扑的聚集性 选取到可信的探测点后,就可以开始对这些探测点进行综合质量评估:端到端质量:如下图所示,通过机房对汇聚点发送 echo 请求
45、报文,得到延时、丢包、抖动数据,从而进行用户和机房端到端的网络质量评估。图 10 机房质量 质量函数:基于获取到的延时、丢包、抖动数据,通过质量函数计算,获得综合的质量 24 数据。质量地图:如下图所示,根据质量函数生成质量地图。根据质量地图调整机房排序,生成边缘网络的调度结果,并且可以实时调整用户访问调度。图 11 质量地图 DNS 就近接入 问题和挑战:在获取到准确的质量信息后,就可以综合容量等信息计算调度结果,尽可能使用 DNS将用户调度到就近的接入点,优化用户的访问延时。常用的方案为地理位置就近调度,即 DNS使用分地域解析机制,对不同区域的 LDNS 请求返回地理位置就近的服务节点
46、IP。但是,基于地理位置的就近调度方案存在一些问题:无法取得质量最优化:地理位置就近并非代表底层的网络距离也是就近的,就近的机房可能会出现质量不如距离用户更远的机房的情况。无法处理质量变化:机房的质量是动态变化的,基于地理位置的静态调度无法总是取得质量最优化的机房位置。调度粒度相对较粗:同地域可能存在多服务节点部署,对本地域不同的用户群体具有不同的服务质量。在这种情况下,按地域进行调度无法精细化优化质量。LDNS 牵引不符合预期:在海外很多国家的运营商,并非各个地域都有 LDNS 部署,无法 25 实现单独调度对应地域的流量。图 12 DNS 就近接入 解决方案:根据静态数据计算往往无法得到最
47、优调度策略,必须结合实时数据才能计算出对真实用户更加友好的调度结果,因此需要基于 LDNS 实时质量地图进行精细化调度:分析出全网的 LDNS IP,并根据 LDNS IP 所处的网络不同划分到不同分组 从各个服务节点实时探测各个 LDNS IP 分组,获得 LDNS 分组到各个服务节点的质量排序 每当收到 LDNS 的查询请求时,根据第 2 步的质量排序返回质量最优的边缘 Serverless节点 相比于基于地理位置就近调度方案,基于实时质量地图调度,全球平均可取得 10%以上的延时收益。HTTPDNS:权威 DNS 根据 LDNS IP 来判断请求来源。某些情况下,用户和所使用的 LDNS
48、出口距离较远(例如用户使用不支持 ECS 的 Public DNS),会导致用户访问到非最优的服务节点。对于有条件的情况,建议在客户端上使用 HTTPDNS,或者完整支持 ECS 的Public DNS 来解析服务域名。26 Anycast 就近接入 问题和挑战:Anycast 也是常用的将用户请求调度到就近节点的方案,和 Unicast 不同的是,Anycast 方案需要将路由前缀在多个服务机房进行发布。发布后,运营商路由器会获取到对应前缀的多条路径。一般情况下,路由器会根据最短路径的原则进行选路,进而将用户的请求路由到就近的服务节点。相比于 DNS 就近调度方案,使用 Anycast 方案
49、的优势是,不需要额外系统就能实现就近接入,而且服务节点对外中断后路由会自动撤销,实现自动化容灾。但是,在每个服务节点的各个出口直接发布 Anycast 路由,存在如下问题:负载风险:路由系统的复杂性造成路由发布的结果难以提前预测,在网络出口发布路由,可能会出现引流超过预期,出现服务节点过载。质量风险:新增发布并不一定会使质量优化,在路由系统出现多条可选路径的情况下,反而可能选择质量更差的路径。解决方案:为了解决上述问题,可以使用基于 Anycast 流域测量的 Anycast 路由发布方案:使用一个测试网段,尝试各种可能的发布组合 评估不同发布组合的质量和负载,根据业务需求选择质量和负载综合最
50、优的方案 将最终选择的发布组合,应用于实际服务网段 周期性执行上述过程,以针对流域的变化,不断调整发布组合 在一个全球 10 个服务节点的部署案例中,相比于全出口发布,基于流域测量的方案可 27 取得 30%以上的延时收益。3.1.4.边缘函数执行 性能优化 问题和挑战:边缘函数的执行性能和隔离性对于整个边缘函数系统的稳定性和可靠性至关重要。边缘函数的性能直接影响着边缘计算的延迟和响应速度,是保证边缘计算能够快速、准确地处理海量数据的关键。因此,边缘函数需要具有高效、可靠、低延迟的性能特点,同时具备强大的处理能力和数据处理能力,以满足不断变化的业务需求和应用场景。解决方案:对于性能优化,需要对
51、边缘函数开发的全流程逐一进行优化。边缘函数的执行流程一般包括启动隔离环境、预处理、编译和执行等几个步骤:首先,在执行边缘函数前,需要在边缘 Serverless 节点上启动隔离环境,隔离环境是为了避免边缘函数与其他程序之间的干扰,保证边缘函数的执行环境安全可靠。其次,在预处理阶段,边缘函数会加载函数代码,进行词法分析、语法分析等操作,生成抽象语法树。这一步是边缘函数执行的前置步骤,为接下来的编译打下基础。接下来,在编译阶段,边缘函数会将抽象语法树转化为字节码或直接进行 JIT(即时编译),最终生成机器码。最后,在执行阶段,边缘函数会根据业务需求执行相应的业务逻辑。在这个阶段,边缘函数可能需要依
52、赖一些网络框架或者其他系统资源,以实现具体的功能。同时,边缘函数在执行过程中也需要实时收集和处理数据,以保证计算结果的准确性和及时性。边缘函数的执行流程包含了启动隔离、预处理、编译和执行等多个步骤,每个步骤都影响着边缘函数的执行性能:28 隔离环境:在隔离环境上,可以根据实际的使用场景对隔离程度以及冷启动速度做权衡,实现不同级别的隔离方式,例如同一用户之间的边缘函数可以选择更轻量的隔离级别,以降低不必要的性能开销。同时,隔离环境和其他函数执行的资源分配本身是一个比较耗时的过程,如果在请求到来时再临时分配,对边缘函数的启动延迟会有明显的影响。因此推荐在服务启动时,Serverless 节点根据自
53、身的硬件资源和请求的大致分布预先初始化若干隔离环境。当请求到来可以从隔离环境池中直接获取一个已分配的空闲隔离环境,而不是临时分配资源,避免分配隔离环境对启动时间造成的影响。编译优化:对于单一边缘函数来讲,变更一般不会特别频繁,可以对函数编译后的字节码和其他产出物进行缓存,减少重复编译的次数,可以加快程序的编译和加载速度,提升整体性能。自动代码检查:边缘函数研发平台可以通过代码检查功能,优化冗余代码逻辑,移除未使用的变量、函数和无效代码,减少整体代码量,提升性能。多租户隔离 问题与挑战:在边缘计算中,多租户环境是相当常见的,即多个用户和应用共享同一个边缘计算资源池。因此边缘函数需要尽可能地保证多
54、租户间的隔离性,避免不同用户和应用之间的数据被非法获取或篡改。解决方案:为了避免多个用户间函数执行互相影响,边缘函数需要在应用程序内实现和操作系统类似的多任务调度能力。否则如果有用户的函数需要持续使用 CPU,会导致其他用户的函数无法执行。29 边缘函数在实际执行时可以切分为更小粒度的时间片分配 CPU 时间。当前边缘函数执行超过时间片限制后,可以挂起当前函数让出 CPU。根据某种任务调度策略挑选出一个等待的函数继续执行,尽量让所有函数都得到公平的 CPU 使用机会,避免单一用户的函数消耗过高影响其他租户。同时也可以根据边缘函数的类型(实时请求还是定时任务等特征),实现更加丰富的时间片调度策略
55、。,同时,隔离性还可以保证不同用户和应用之间的计算资源、存储资源等之间相互隔离,避免因为资源争用而造成系统的不稳定性和性能下降。数据完整性 问题与挑战:由于资源隔离的特性边缘函数往往允许直接访问本机的存储资源,对存储的访问通常会涉及到跨设备传输,如何保证跨设备传输数据的一致性也是必须要解决的问题。解决方案:边缘函数往往需要利用边缘存储(缓存、KV、文件存储)等服务完成更复杂的功能,对于此类存储服务,需要在网络传输和数据读写上保证数据完整性,避免数据错乱对逻辑造成未知的影响。可以根据自身的功能设计和可以接受的性能损耗定制传输和存储协议或者选择成熟的开源协议(如 TLS),利用额外的校验值验证数据
56、是否完整 3.2.边缘组件满足个性化业务需求 出于安全、隔离、弹性等考虑,边缘函数平台一般不会允许函数直接操作硬件资源,同时有部分硬件(例如 GPU)的直接使用难度较高,对开发人员有明显的专业性要求。对于这些资源的使用,边缘组件可以将硬件资源有效的组织起来,提供安全、隔离、弹性、开箱即用的抽象资源接口。30 边缘组件主要解决边缘 Serverless 开发中的三个问题:资源隔离,通过租户配额、屏蔽底层接口等方式,避免不同函数之间对硬件的使用互相影响。提升资源访问性能,通过同机房部署、就近部署、缓存、主动推送等方式,降低边缘节点对硬件资源访问的延迟。提供风格统一、简单易用的边缘函数 Runtim
57、e API,降低开发者的使用难度。降低开发者重复开发的工作量,尤其是在 AI 等专业难度较高的领域,可以由专业的研发人员负责开发边缘组件,普通开发者直接使用即可。3.2.1.边缘存储 边缘缓存 缓存是系统开发中常用的一种思想,通过将资源缓存在本地的内存、磁盘等方式,可以极大的提升系统的吞吐能力,降低对外部依赖的压力。在边缘 Serverless 节点中,可以将设备的内存、固态硬盘、机械硬盘等资源组织起来,形成访问速率、性能、成本各有优劣的缓存集群,通过边缘函数 Runtime API 对开发者暴露。开发者无需关心资源存储的形式,只需根据业务对延迟、缓存量级、成本等维度的要求,绑定合适的缓存介质
58、到 Runtime 中即可使用。边缘 KV 存储 KV 存储也是系统开发中常用的一种持久化的存储组件,用于存储类似于用户信息、任务状态等“键-值”形式的数据。由于边缘 Serverless 节点本身可能出现频繁的上下线等情况,因此并不适合在单一边 31 缘机房中存储有持久化需求的数据。对于边缘 KV 存储,可以采用在多地存储,全球同步的机制。即由多个机房的多台设备构成一个存储集群,以最终一致的形式存储持久化的 KV 数据,同时,当写入事件发生时,利用消息队列订阅等方式,自动推送至全球边缘 Serverless节点的 KV 缓存,使得用户可以在全球各地都以较低的访问延迟读取 KV 数据。边缘文件
59、存储 相似的,系统也可以用类似 KV 存储的形式提供边缘文件存储能力,使得用户可以方便的存储或者读取文件内容。3.2.2.边缘 AI 推理 近些年 AI 快速发展,在翻译、物体检测、内容生成等领域都诞生了非常成熟的应用模型,AI 开始逐渐与每一个应用相关。在边缘 Serverless 节点中,可以放置 GPU 等特殊计算硬件的设备组成 AI 专用的推理计算集群,通过边缘函数 Runtime API 暴露 AI 推理能力。在系统建设初期,通常可以将常用的经典模型内置在推理集群上,封装为开箱即用的工具化 Runtime API,满足绝大多数普通开发者对 AI 能力的使用。随着系统建设的愈加完善,用
60、户可以上传自己的自定义模型,在 Runtime API 中丰富 AI 预处理和后处理的能力,以便专业的 AI 开发者在函数内根据自己的需求将素材处理成自定义模型的原始入参,在边缘Serverless 节点内完成通用推理。3.2.3.边缘图片处理 图片是目前边缘流量中非常常见的一种资源类型,同时很多用户都有根据终端的类型、分辨率、网络质量等因素返回压缩格式或者大小不同的图片。32 在传统的中心计算模型下,一般都是由图片存储的中心组件完成对图片的二次加工,同时在边缘根据请求信息缓存多份内容,这一过程通常会产生不必要的中心算力和流量浪费。而在边缘 Serverless 节点内处理上述过程,可以天然规
61、避这些的问题。通过内置图片处理服务,支持开发者在边缘节点内完成对图片的二次加工。同时边缘节点距离用户更近,可以更加明确的感知到用户的网络质量等信息,做出更加丰富准确的图片处理决策。3.2.4.边缘中间件 定时任务 在一些应用场景中,边缘函数的执行并不是由实际的请求触发,而是自身周期性的执行,例如网络质量探测、信息收集、数据清洗等。对于这一类应用场景,边缘 Serverless 节点能够提供定时任务能力,可以按照用户需求,在全球定时驱动若干个节点执行。消息队列 消息队列是一种常见的组件,往往用于任务分派、结果通知、组件解耦等场景。通过在边缘 Serverless 节点内提供消息队列和边缘函数的订
62、阅者模式,可以帮助开发者构建更加复杂的多模块应用。比如,利用定时任务驱动作为任务中控的边缘函数发布网络探测任务,再由全球的消息队列消费者边缘函数消费这些任务,完成探测请求并通过日志推送能力收集数据,最后再通过定时任务驱动数据清洗边缘函数汇总数据。4.边缘 Serverless 典型应用场景 4.1.边缘渲染 场景需求:33 某业务需要在海外多个国家提供网页服务,而海外由于网络链路的原因导致用户访问性能较差。业务分别尝试了客户端渲染(CSR)和服务端渲染(SSR)。但是在实际操作中,由于客户端渲染依赖用户设备的性能且需要多次访问服务端获取动态内容导致效果不佳。而服务端渲染因中心服务距离客户端较远
63、,客户端访问服务端路径长会导致时延高。并且服务端需要处理众多客户端请求,处理压力也会变大。因此期望有一种新的解决方案,在距离客户端较近的边缘执行渲染操作。接入效果:边缘函数可以帮助用户实现边缘渲染(ESR),用户可以将 HTML 模板内置在边缘函数中,使用边缘存储组件放置其他静态资源,使用边缘函数在边缘 Serverless 节点上渲染支出页面,兼顾客户端渲染和服务端渲染的优势。图 13 边缘渲染 上线后其首屏渲染速度时延降低 42%,显著提升了用户体验;另外,客户端请求不再需要频繁回服务端,有效降低了回源成本。34 4.2.灰度发布 场景需求:某业务为了避免新功能发布到生产环境影响全网用户,
64、在 Web 前端希望采用灰度发布的方式让一部分用户试用新功能,根据观察用户使用情况再考虑全量放开或回退到上一个版本,这种方式可有效减少新版本发布时的风险和影响。如无灰度发布,新功能一旦发布有异常则会影响现网所有用户;如灰度发布在云中心实现,则控制链路长,时延高,会影响网站的访问速度和用户体验。接入效果:图 14 灰度发布 通过边缘函数可以在边缘侧根据用户特征实现某种灰度策略,对命中灰度策略的用户返回灰度内容或者重定向到灰度地址。相比云中心灰度发布,边缘节点更靠近用户处理灰度逻辑,可以尽可能降低灰度对网站的访问速度的影响。4.3.APK 动态签名 场景需求:35 安卓 APP 出于业务推广的目的
65、往往会向应用市场、搜索引擎、其他 APP 等投放渠道包,渠道包内通过 APK 签名的机制打入对应的渠道信息用于应用方区分不同的渠道。但是维护成千上百的渠道包引入了额外的运营复杂度,并且目前的安卓 APP 尤其是游戏 APP 往往非常大(几百 MB 到几十 GB),大量的渠道包又额外引入了不必要的源站存储和流量成本。某游戏业务遇到该问题后,希望可以将写入渠道签名信息的逻辑转移到边缘执行,不再依赖源站分渠道包准备不同的安装包。接入效果:图 15 APK 动态签名 接入边缘函数后,业务只需要打包一份原始 APK 放在源站,用户通过不同的渠道链接访问边缘 Serverless 节点时,由边缘函数根据访
66、问信息将签名数据打入 APK 内发送给用户。方案全量上线后业务源站回源流量下降接近九成,并且发布流程也明显简化。36 4.4.M3U8 改写 场景需求:HTTP Live Streaming(HLS)是一种基于 HTTP 的流媒体传输协议,广泛应用于直播和点播视频内容的传输。M3U8 文件是 HLS 技术中的一部分,包含对多个媒体文件的引用(通常是 TS 文件)。在实际使用中,视频的内容可能是付费内容/会员内容。出于对视频内容保护的目的,需要对 TS 文件的访问进行鉴权,避免未授权用户可以直接访问这些视频。由于鉴权串的计算一般都和 URL、时间戳等因素相关,导致每次用户访问 M3U8 文件时,
67、需要根据当前用户的访问信息,实时计算出 M3U8 中包含的 TS 列表的鉴权串,并将 M3U8 中的 TS 列表对应的 URL 修改为携带鉴权信息的 URL 后,再返回给用户。如果 M3U8 的修改由传统的中心计算负责,会增加用户的首屏延迟,同时增加额外的计算和运营成本,因此业务希望在距离用户更近的边缘 Serverless 节点完成 M3U8 改写。接入效果:37 图 16 M3U8 改写 在边缘 Serverless 节点直接进行 M3U8 改写,既可以满足业务希望对视频内容做鉴权保护的需求,又不会引入额外的访问延迟和计算成本。架构上边缘函数的改写逻辑和边缘缓存逻辑部署在一起,不引入额外的
68、外部依赖,也不会导致额外的稳定性问题。并且基于该架构还可以进一步扩展广告插入、自定义播放列表等个性化功能,具有充分的可扩展性。5.总结与展望 边缘 Serverless 是一种全新的算力模式,相对于传统的中心算力,天然具有低延迟、低成本的优势。然而边缘函数本身面临着网络条件复杂、硬件不稳定、节点分布零散等问题,针对这些问题,目前业界提出了如下解决方案:使用轻量级隔离环境和惰性加载等方案,降低部署和启动代价,使得边缘函数可以在全球任意节点随时执行,避免单机故障对用户造成影响。配合时间片调度等能力,提供和虚拟机、容器等环境类似的多租户隔离能力。提供边缘存储服务,避免单节点磁盘故障导致数据丢失,通过
69、校验和等方式保障数据完整性,使得用户可以在边缘使用存储能力构建有状态服务。通过精细化自动调度能力,保障用户始终被调度在距离调用方延迟和负载最佳的节点。近 20 年,得益于内容分发网络(CDN)的蓬勃发展,互联网完成了流量从中心到边缘的迁移。而当前人工智能算法和基础研究快速发展,生成式 AI(文生图、大语言)逐步开始大规模应用。OpenAI 推出 ChatGPT 将大语言模型带入了用户的日常生活,目前已经拥有超过 1.8 亿用户。国内互联网厂商腾讯、百度等也分别推出了“通义千问”、“混元”、“文心一言”等大语言模型,以文心一言为例,对外发布后,目前已经收获了超过 4500 万用户。大模型的大规模应用导致厂商对计算尤其是GPU计算的需求量大幅度增长,根据媒体报道,38 早在 2023 年 4 月,OpenAI 每天就需要为 ChatGPT 支付超过 70 万美元的成本。当行业出现一款真正的国民级 AI 应用后,计算的成本开销将成为该行业的主要成本之一。鉴于边缘函数天然的低成本优势,相信在可以预见的未来,算力也会像流量一样完成从中心到边缘的迁移。