本帖最后由 中国计算机学会 于 2024-4-18 14:00 编辑
摘要—本文提出了端边云计算连续统，从系统架构、评价指标和运行时管理等方面简述了其面临的挑战。然后，为TEC3提出了“物群-机群”分布式架构，以及任务吞吐量、系统尾时延和时延标准差三个宏观性能指标。最后，介绍为TEC3设计和实现的运行时管理系统原型。
彭晓晖（中国科学院计算技术研究所）
王一帆（中国科学院计算技术研究所）
关键词 ：端边云协同 计算连续统 信息高铁算力网
引言 网络计算已进入万物互联时代，感控、网络、计算融为一体，即学术界常常提到的人机物三元融合[1]。这些感知与控制设备、算力[2]设备通过接入网和骨干网络，连接成一个跨地域的人机物网络计算系统。文献[3]阐述了人机物三元融合的含义：人类社会、信息空间、物理世界成为计算系统的组成部分。但人和物的世界是模拟的，计算机的世界是数字的，系统需要将信息在模拟和数字两种形态之间频繁转换，形成一种被称为“人机物图灵税”[3]的巨大开销，降低这种开销需要系统底层逻辑的颠覆式创新。因此，中国科学院计算技术研究所提出了“信息高铁”（Information Superbahn）算力网[3~5]，通过在基础设施层提供低熵有序的支持提高用户的实际体验，通过原生支持“人机物”适应万物互联时代的亿万应用。 如何实现无缝衔接的端边云是信息高铁要解决的三大科学问题之一[3]。本文提出端边云计算连续统（Thing Edge Cloud Computing Continuum，TEC3）尝试解决该问题。TEC3借鉴了数学领域的连续统概念，描述当前网络计算中将人类社会、信息空间和物理世界连接起来的端边云计算资源链路，并在该链路上合理迁移和执行计算任务，使系统在满足任务服务质量（Quality of Service，QoS）需求的前提下，实现计算任务吞吐量的最大化。内容分发网络（Content Delivery Network，CDN）是一种端边云数据连续统，它的端主要是手机、平板电脑、个人电脑等人端设备。在TEC3中，除了人端以外，还包括摄像头、无人机、无人车、环境传感器等大量物端设备。它们通过感知物理世界产生大量数据，这些数据沿端边云传输、计算和存储。 德勤的报告显示，2030年中国的自动驾驶车辆将达到3000万台，每台每天产生的数据高达数十太字节（Terabyte，TB）[6]。这些汽车分布在全国各地，每台汽车与附近的边缘机房、城市的数据中心及链路上所有的通信设备组成了覆盖全国的自动驾驶TEC3。这些数据需要在该连续统上合适的位置完成处理，以达到车载终端上所有应用的QoS要求。TEC3广泛存在于万物互联网络的各个具体应用领域，例如，智慧家庭、智慧工厂、平方公里阵列射电望远镜、遥感卫星系统等。对这些场景产生的高并发、强实时、地理分布广的感知大数据进行实时处理是TEC3面临的核心科学问题。本文将介绍TEC3的架构设计和关键技术面临的挑战，以及信息高铁团队在端边云协同计算方面取得的进展。 TEC3的系统架构 文献[7]最早对“边缘”给出了定义： Here we define “edge” as any computing and network resources along the path between data sources and cloud data centers. 上述定义将数据中心以外的所有计算和网络资源都称为边缘。从网络的角度看，摄像头、雷达等物端设备感知到的大数据通过边缘接入网络传输至云端，并在端至云间的边缘算力上进行加工处理，这是一种端-边-云（Things-Edge-Cloud，T-E-C）三级架构，符合上述定义。但是，从计算系统的角度来看，三级架构与当前分布式计算系统广泛采用的客户机-服务器（Client-Server，C/S）和浏览器-服务器（Browser-Server，B/S）的二级架构是矛盾的，这给分布式系统的设计和实现带来巨大挑战。在传统的C/S和B/S架构中，软件的安装部署位置是明确的。C和B部分的软件模块安装在客户端上，S部分的软件模块安装在服务器上，中间通过互联网协议通信。在T-E-C三级架构中，边缘是指端至数据中心间的链路上所有网络和计算设备，这导致边缘部分的软件模块没有固定的安装部署位置，系统软件设计的复杂度和应用开发与部署的难度均大幅增加。
为了简化上述三级架构，我们为TEC3提出了“物群-机群”系统结构，如图1所示。物群（Cluster of Things，COT）是由一定地域范围内的感知与控制设备、计算设备和通信设备组成的边缘网络计算系统。物群是对各类边缘计算系统的一个学术抽象，其核心特征是感知资源、计算资源和控制资源可在一定地域范围内共享与进行功能协作。物群广泛存在于智能家居、智能园区、智慧工厂、无人战场等计算场景中。机群（Cluster of Workstations，COW）指数据中心服务器集群组成的分布式计算系统。我们将物群看作用户（Client），将机群看作服务器（Server），它与现有分布式计算系统广泛使用的C(B)/S架构模式一致，可大幅度降低系统软件和应用的开发与部署难度。 TEC3的性能评价指标 万物互联带来的重要变化之一是系统的应用负载大量并行化，一个应用或服务可能包含成千上万个协作部件，它们将大量采用并行或分布式程序[1]。如何评估这种网络计算系统的性能是一个十分复杂的问题。高性能计算机（超算）和大数据计算系统均是典型的并行计算系统，均具有典型的基准测试程序集和性能指标[8]，例如高性能计算机采用的每秒浮点运算次数（Floating-Point Operations Per Second，FLOPS）指标和大数据计算系统采用的每秒基本操作次数（Basic Operations Per Second，BOPS）指标。 TEC3不仅包含通用计算负载，还包含人脸识别、目标分类与追踪、激光与电磁信号处理、数据清洗与融合等多样化的计算负载。多样化的负载造成了应用QoS需求和系统性能要求的多样化，系统通常要在满足应用QoS需求的同时，将计算任务的吞吐量最大化。因此，FLOPS和BOPS等传统指标不再适合评估TEC3系统的性能，需要新的指标体系评估其系统性能和服务质量。信息高铁算力网提出了通量、良率、处理器熵等性能指标用于评估整个算力网的性能[4]。TEC3作为信息高铁算力网纵向算力系统，可使用任务吞吐量、尾时延、时延标准差三个宏观指标初步评估其系统性能。 1.任务吞吐量。任务吞吐量描述了单位时间内系统处理的计算任务数量。作为算力基础设施，算力网必然是亿万用户共享使用的分布式计算系统，不能只关注单个计算任务的执行性能，需要用任务吞吐量评价在相同资源量情况下TEC3的任务并发处理能力。 2.尾时延（Tail-Latency）。尾时延表示在一组计算任务时延值中，有多少百分比的值低于或等于该时延。例如，99%尾时延指标值表示在一组计算任务时延值中，有99%的值低于或等于该指标值。TEC3处理海量多样化的计算负载时，相比于所有计算任务的平均时延，具有高时延的计算任务对用户最终体验的影响更大。尾时延可以在一定程度上反映用户体验质量（Quality of Experience，QoE）。用户出现较差体验质量的概率与尾时延指标正相关。 3.时延标准差。时延标准差用于衡量一组时延测量值的离散程度或波动性，即实际测量值与其平均值之间的差异。其计算方式为计算测量值与平均值之差的平方的平均值。TEC3网络的异构性强、波动性大，计算环境复杂、不稳定，需要用时延标准差评估系统的波动性。时延标准差越大表示系统波动性越大，越小则表示系统波动性越小。 关键基础问题 时间一致性 TEC3的地域跨度可能非常大，因此确保整个分布式系统的时间一致性至关重要。分布式系统通常采用时间戳作为标记事件发生时间的关键元素，它的不一致可能导致运行结果不正确等严重的系统问题。下面简述TEC3中可能存在的时间不一致现象。 1.时间不一致导致计算任务出错。假设在某TEC3中，物群的端设备时间戳为12点00分00秒，机群的服务器时间戳为12点00分01秒。此时，某个端提交一个100毫秒内执行完毕的QoS要求的计算任务T1，即该TEC3需要在12点00分00秒100毫秒之前处理完T1。由于服务器端的时间戳是12点00分01秒，不满足T1的QoS要求，导致计算任务执行失败。因此，在TEC3这种跨地域的分布式计算系统中，计算节点时间戳不一致可能导致计算任务无法执行、结果不正确、系统行为混乱等严重错误。 2.时间不一致导致系统日志无法正确分析。记录行为日志是分布式系统用来分析系统性能和寻找故障的重要手段。如果TEC3中不同设备的时间戳不一致，可能无法按正确的时间顺序分析系统日志，进而导致故障溯源和系统行为分析不准确，影响故障排除、系统监控和审计跟踪。 3.时间不一致导致安全证书验证失败。时间戳常用于验证数据的合法性和时效性，在安全传输层协议（Transport Layer Security，TLS）、网络令牌等安全协议中起到非常关键的作用。不一致的时间戳会使证书合法性验证失效，允许对系统进行未授权访问或处理已过期数据。例如，在一个移动支付应用中，智能手机和云端服务器使用时间戳验证交易的时效性，不一致的时间戳可能会导致正常的合法交易失败。 空间一致性 空间一致性包含分布式计算系统资源的编址和命名两个基础问题。互联网是最常见的分布式系统，它使用互联网协议（Internet Protocol，IP）地址对联网的资源进行编址，使用统一资源定位符（Uniform Resource Locator，URL）对资源进行命名，并建立域名系统（Domain Name System，DNS）负责转换资源的名字和其对应的IP地址。物联网有一套类似的名字系统，通常由身份标识号（Identity Document，ID）、标签和解析系统组成。作为算力网的一部分，TEC3名字系统需要考虑以下3个问题。 1.统一的名字抽象。TEC3是万物互联的端边云协同计算系统，包含人机物三种元素，其编址和命名可能涉及互联网的IP和URL、物联网的ID和标签、人类社会的身份系统等。如何为人机物三种元素设计统一的名字抽象和命名机制是TEC3面临的基础问题之一。 2.地址空间的容量与地址的唯一性。与现有的网络计算系统一样，TEC3需要使用地址对资源进行定位和寻址，从而使系统能够准确找到并使用该资源。这要求地址空间可以容纳指数增长的联网设备和资源，且资源地址在整个TEC3系统中具有唯一性。早期的互联网设计忽视了该问题，造成IPv4的地址空间远不能满足万物互联时代的地址分配需求。物联网希望通过可扩展的ID系统解决该问题，但ID并不具备对资源的寻址和定位能力。 3.海量算力资源信息的存储和查询。TEC3的用户是海量的物端和人端，它们通过发送计算任务使用系统的算力。TEC3根据计算任务的QoS需求将其迁移至合适的算力资源上执行，实时、准确的算力资源信息是任务调度和迁移的基本依据。不准确的、过时的算力资源信息可能会导致错误的调度决策，算力资源信息的查询时延也影响计算任务的调度速度。因此，如何实现TEC3的海量分布式算力资源信息的快速存储和查询是TEC3名字系统设计需要考虑的关键问题。 运行时管理技术 因特网、万维网、超级计算机和云计算的数据中心等都是广义上的分布式计算系统。从操作系统的角度来看，它们都提供了新的抽象，以及围绕这个抽象的传输协议或运行时系统提高数据传输和应用执行效率和性能。因特网上的分布式应用（例如Telnet和FTP）采用C/S架构，应用的客户端和服务器端本质上是一组分布式进程，依托单机操作系统进行运行时管理，并通过远程过程调用、消息传递等机制进行通信。万维网应用的进程分别被浏览器和服务器统一管理，超级计算机围绕作业（Job）进行分布式应用运行时管理，而云计算的数据中心则围绕容器进行应用的运行时管理。这些应用本质上都是一组进程，但作业、容器等抽象使系统的应用运行时管理更加简单高效。 从网络的角度来看，因特网是数据传输的基础设施，它的所有设计和实现都是围绕IP数据包的高效传输进行的。万维网是因特网上用于结构化信息（网页）分享的基础设施，它的所有设计和实现都是围绕网页的传输和显示进行的。因特网和万维网上的分布式应用（服务）都是算网分离的执行模式，网络只负责客户端/浏览器和服务器端之间的数据传输。TEC3是因特网上用于计算任务传输与执行的分布式系统，需要一个新的抽象和围绕这个抽象的端边云统一的运行时系统，屏蔽端边云算力的多样性和网络的异构性，使物端产生的感知大数据在TEC3上传输的同时被高效处理。KubeEdge[9]是一个开源的、基于容器的TEC3运行时管理系统，但传统容器为云计算而设计，它的资源管理机制在资源受限的边和端上存在诸多问题。 潮汐：端边云协同的运行时管理系统 本文基于“物群-机群”架构，设计实现了一个端边云协同的分布式应用运行时管理系统原型：潮汐。它初步通过分布式隔离、动态资源供给和自动迁移等机制，使运行在端边云连续统上的分布式应用时延大幅降低，并使系统处理计算任务的吞吐量大幅提高。
在潮汐系统中，作为用户，物端设备通过向系统提交计算任务使用端边云算力。如图2所示，潮汐系统由TIDE-E和TIDE-C两部分组成，分别负责物群和机群上的资源与运行时管理以及任务调度，相当于C/S架构模式中的Server和Client两部分。TIDE-E根据物端发送的任务QoS需求决定该任务在物群内执行还是迁移至云上执行。作为算力基础设施的一部分，潮汐系统在设计上兼顾了高任务吞吐量、良好的应用隔离性与兼容性、较低的开发与部署门槛等功能特性。 1.高任务吞吐量。为了支持万物互联时代万亿级物端设备的高任务吞吐量需求，潮汐系统借鉴Go语言的GMP模型，设计了RESP调度模型。该模型包含计算任务（Routine）、执行器（Executor）、资源代理（Stub）和处理器（Processor）四部分。调度模块根据物端设备提交的计算任务的QoS需求（例如，必须在300毫秒内执行完毕），将任务调度至合适的节点，再由节点上的资源代理为其分配适量的执行器和处理器。 2.良好的应用隔离性。为了避免应用之间的干扰，潮汐系统设计了应用资源代理抽象。一个应用在TEC3上的所有资源代理形成其应用资源空间，并通过Linux的cpuset子系统限制该应用对资源的使用范围和量。该机制为运行在TEC3上的应用提供了分布式隔离机制。同时，为了应对应用请求的波动，潮汐系统提供了可根据应用需求变化进行动态伸缩的资源供给机制。当判定当前资源空间无法满足应用的QoS要求时，系统会增加该应用的资源供给，反之则收回部分空闲资源。 3.良好的应用兼容性。潮汐系统定义了一组标准的交互接口管理应用与执行器之间的通信，相应的编程语言仅需实现上述接口即可轻松接入潮汐系统。目前，潮汐使用了Containerd作为运行时环境，并基于Linux消息队列实现了对用Go和Python两种语言编写的应用的支持。 4.单点开发与分布式执行。潮汐系统降低了物端设备使用边缘和云算力的难度。在开发阶段，程序员仅需在物端设备上编写单体程序。在运行阶段，系统根据计算任务的QoS和预设的算力需求等信息，将其迁移至符合要求的资源上执行。
图3展示了一段使用Python编写的可运行在潮汐系统里的应用代码，其中init函数为注册初始化函数，main函数为正常业务逻辑代码，fn函数为可卸载函数。程序运行时首先创建执行器，然后立即调用init函数进行初始化，例如加载模型参数。注册fn函数时可以提供其资源需求、QoS要求等信息，调度策略会根据相关信息将其调度至合适的节点执行。如图3所示，tide.fn函数中预设了prefer属性为“GPU”，在运行时tide.fn函数就会被迁移至附近有GPU资源的节点执行。
本文选取了任务吞吐量和系统尾时延作为评价指标，采用YOLOX[9]作为应用负载，并以不同的频率向潮汐系统提交计算任务，测试结果如图4和图5所示。相较于配置不同的KubeEdge框架[9]、Ray框架[10]和裸机平台，潮汐系统的95分位尾时延降低了40%以上，计算任务吞吐量提升了2倍以上。 结束语 本文提出了一种新的分布式系统形态——TEC3，并从资源与运行时管理的角度，探讨了其架构方法、性能评价、资源和运行时管理等方面面临的挑战与问题，介绍了一个TEC3的运行时管理系统原型——潮汐系统。还有许多重要的技术挑战（例如端边云协同的编程方法）本文未涉及，希望有更多的研究人员通过本文粗浅的介绍和探讨，关注并参与TEC3系统的设计与关键技术研究。 ■
致谢：感谢郑守建同学协助潮汐系统原型的实现和实验。本研究得到北京市自然科学基金（No.4212027）资助。
脚注： 1 本图部分图片来自中科曙光服务器和互联网，在此一并致谢。 参考文献： [1] 中国科学院信息领域战略研究组. 中国至2050年信息科技发展路线图[M]. 北京:科学出版社, 2009. [2] 孙凝晖, 张云泉, 刘宇航. 算力[J]. 中国计算机学会通讯, 2022, 18(12):106-109. [3] 徐志伟, 李国杰, 孙凝晖. 一种新型信息基础设施：高通量低熵算力网（信息高铁）[J]. 中国科学院院刊, 2022, 37(1):46-52. [4] 俞子舒, 李奉治, 郑守建, 等. 信息高铁的低熵高通量性质验证[J]. 计算机学报, 2023, 46(11): 2302-2321. [5] 王晓虹, 王卅, 唐宏伟, 彭晓晖. 构建“新基建”国家战略的技术底座——“信息高铁”综合试验场建设的实践与思考[J]. 中国科学院院刊, 2021, 36(9): 1066-1073. [7] Shi W, Cao J, Zhang Q, et al. Edge computing: Vision and challenges[J]. IEEE Internet of Things Journal, 2016, 3(5):637-646. [8] Wang L, Zhan J, Luo C, et al. BigDataBench: A big data benchmark suite from Internet services[C]//Proceedings of the 20th International Symposium on High Performance Computer Architecture (HPCA). 2014: 488-499. [10] Ge Z, Liu S, Wang F, et al. YOLOX: Exceeding YOLO series in 2021[J]. arXiv preprint arXiv:2107.08430, 2021. [11] Moritz P, Nishihara R, Wang S, et al. Ray: A distributed framework for emerging AI applications[C]// Proceedings of the 13th USENIX symposium on operating systems design and implementation (OSDI). 2018: 561-577.
版权声明：中国计算机学会(CCF)拥有《中国计算机学会通讯》(CCCF)所刊登内容的所有版权，未经CCF允许，不得转载本刊文字及照片，否则被视为侵权。对于侵权行为，CCF将追究其法律责任。
| 
京公网安备 11010802032778号 )
发表于 2024-4-12 17:25:25