CN114327858A - 基于控域的云边端分布式算力协同方法及系统 - Google Patents

Abstract

本发明提出一种基于控域的云边端分布式算力协同方法，包括：当用户将作业提交至该用户所属控域，由作业分配设备将该作业分配给作业执行设备进行部署；由该作业执行设备生成该作业的任务和该任务的运行实例，将该运行实例发布至该控域；由实例分配设备将该运行实例分配给实例执行设备进行部署；实例执行设备接受该作业对该运行实例的调用请求后，执行该运行实例，将该运行实例的执行结果返回给该作业执行设备。还提出一种基于控域的云边端分布式算力协同系统，以及一种数据处理装置。

Description

基于控域的云边端分布式算力协同方法及系统

技术领域

本发明属于云计算技术领域，特别是涉及一种基于控域的云边端分布式算力协同方法和系统。

背景技术

随着雾计算、边缘计算、物端计算等新计算场景不断出现，智能应用日益增加，用户侧对算力的需求不断提升，而用户侧算力主要为物端，且物端算力通常受限。传统的解决方案是将计算任务完全卸载至云中心，但海量数据的远距离传输加重了物端与通信线路的传输压力，造成物端设备功耗上升与计算任务响应延迟增加等问题，严重影响用户的体验质量。同时，现有解决方案仅能利用云端提供的算力资源，但边端两侧也存在大量异构算力，如运营商区域数据中心剩余算力，个人PC闲置GPU，以及智能手机闲置的神经网络加速器等专用加速芯片，目前采用的云计算模式无法有效管理与利用边端侧算力资源。此外，云计算模式认为云侧资源在整个计算系统中处于更高地位来管理边端资源，但相较于云资源，边端资源距离用户更近，在边端资源能充分满足用户应用程序需求的情况下，云资源并非必需，造成资源浪费。并且，边端侧网络具有不稳定性，若边端资源与云中心链接中断，容易导致整个计算系统的瘫痪。

例如在网络在线抓逃场景中，该场景需对多地摄像头采集的视频数据进行实时分析，包括车牌识别、人脸识别、路线分析等分析任务。在传统云计算模式中，摄像头采集的数据需要全部上传至云数据中心进行分析处理，这不仅对云数据中心产生了较大的计算与存储压力，还对通信线路与摄像头设备产生较大能耗、带宽等资源的压力。并且，随着逃离人员的移动，重要数据产生的位置也会随之改变，数据产生地与云数据中心越远，网络环境愈复杂，传输速率与响应速度更难以保证，严重影响在线抓逃的效率与成功率。而云边端天然具有地理分布、算力异构的特性，因此急需一种有效的云边端分布式算力协同机制来提升计算效率。

基于深度学习的目标检测与识别、语音识别等人工智能类应用通常对算力具有较大的需求，随着这类应用的大量普及，用户侧对算力的需求不断提升，但现有物端设备通常无法满足，云边端算力形成的资源池却未被有效利用。因此，云边端算力资源需要一种有效的协同机制，来增强其协同计算能力，以此支撑用户侧各类应用不断攀升的算力需求，同时提升边端侧设备的资源利用率。

《面向控域的体系结构:一种智能万物互联的体系结构风格》(“计算机研究与发展”，2019；56(1):90-102.徐志伟，曾琛，朝鲁，彭晓晖)提出了控域概念，具体来说，控域是用来划分人机物三元世界并界定其子集范围的概念，规范三元世界各端的控制权与范围，用户可根据自身需求选择或构建合适的控域来完成自己的计算。

发明内容

本发明基于控域概念提出一种云边端算力协同方法，包括对多端资源统一管理、调度与监控等，为用户侧应用程序提供分布式算力支持，具体包括：当用户将作业提交至该用户所属控域，由作业分配设备将该作业分配给作业执行设备进行部署；由该作业执行设备生成该作业的任务和该任务的运行实例，将该运行实例发布至该控域；由实例分配设备将该运行实例分配给实例执行设备进行部署；实例执行设备接受该作业对该运行实例的调用请求后，执行该运行实例，将该运行实例的执行结果返回给该作业执行设备以执行该作业。

本发明所述的云边端分布式算力协同方法，还包括：由该控域计算集群内具有可用资源的云设备、边设备和端设备向该控域的去中心化分布式数据库发送注册数据以完成算力注册，以完成算力注册的云设备、云设备和端设备为算力设备；该作业分配设备和该实例分配设备，通过该分布式数据库获取其他算力设备的注册数据分别作为该作业和该运行实例的分配依据；该注册数据包括设备属性信息和设备状态信息，该设备属性信息包括设备IP、服务端口、所处位置、系统类型和架构类型，该设备状态信息包括CPU利用率、内存总量与剩余量、当前功耗、剩余电量、总资源量和可用资源量。

本发明所述的云边端分布式算力协同方法，完成算力注册后，由该分布式数据库向该算力设备返回租约；当该算力设备的设备状态变化量小于活性阈值时，该算力设备向该分布式数据库发送仅包含该租约的心跳数据进行续约以维持设备活性；当该设备状态变化量大于等于该活性阈值时，向该分布式数据库更新设备状态信息。

本发明所述的云边端分布式算力协同方法，其中将该作业随机提交给任一算力设备，若该算力设备已启动调度程序，则以该算力设备为作业分配设备；反之，则由该算力设备将该作业转发给另一算力设备，直到接收该作业的算力设备已启动调度程序，作为作业分配设备分配该作业。

本发明所述的云边端分布式算力协同方法，其中以首先检测到该运行实例且启动调度程序的算力设备为该实例分配设备。

本发明所述的云边端分布式算力协同方法，其中以接收到该运行实例的算力设备为实例执行设备；当该实例执行设备接收该运行实例时或执行该运行实例中，若该实例执行设备的可用资源量不满足执行该运行实例的要求，则由该实例执行设备基于该运行实例生成新运行实例并发布至该控域，由其他实例分配设备将该新运行实例分配至实例执行设备进行部署执行。

本发明所述的云边端分布式算力协同方法，其中当该实例执行设备执行该运行实例时，由该实例执行设备监测该运行实例的执行情况，当监测到该运行实例在预设时长内没有更新状态数据，则认为该运行实例已经失活，由该实例执行设备基于该运行实例生成新运行实例并发布至该控域，由其他实例分配设备将该新运行实例分配至实例执行设备进行部署执行。

本发明还提出一种基于控域的云边端分布式算力协同系统，包括：作业分配模块，用于将用户提交至该用户所属控域的作业分配给作业执行设备进行部署；实例发布模块，用于将接收到的作业生成任务和该任务的运行实例，并将该运行实例发布至该控域；实例分配模块，用于检测该控域上发布的运行实例，并将该运行实例分配给实例执行设备进行部署；实例执行模块，用于实例执行设备接受该作业对任务的调用请求时，执行相应运行实例，将该运行实例的执行结果返回给执行该作业的作业执行设备；算力注册模块，用于向该控域的分布式数据库发送注册数据以完成算力注册，并在完成算力注册后将当前设备加入该控域的资源池，以及通过该分布式数据库获取其他算力设备的注册数据分别作为该作业和该运行实例的分配依据；活性维持模块，用于接收该分布式数据库返回的租约，并在当前设备的设备状态变化量小于活性阈值时，向该分布式数据库发送包含该租约的心跳数据进行续约以维持设备活性，当该设备状态变化量大于等于该活性阈值时，向该分布式数据库更新设备状态信息；执行监测模块，用于监测当前设备对该运行实例的执行情况，并在认为该运行实例已经失活时，基于该运行实例生成新运行实例并发布至该控域。

本发明还提出一种计算机可读存储介质，存储有计算机可执行指令，该计算机可执行指令被执行时，用于实现如前所述的基于控域的云边端分布式算力协同方法。

本发明还提出一种数据处理装置，作为云设备、边设备或端设备接入控域系统，该数据处理装置包括：处理器；如前所述的计算机可读存储介质，在该数据处理装置执行用户作业时，该处理器调取并执行该计算机可读存储介质中的计算机可执行指令，以进行基于控域的云边端分布式算力协同。

附图说明

图1是本发明的基于控域的云边端算力协同机制部署概念图。

图2是本发明的去中心化算力注册与发现示意图。

图3是本发明的分散式全局资源调度示意图。

图4是本发明的应用程序三级分层示意图。

图5是本发明的设备独立的负载监控与复制示意图。

图6是本发明的基于控域的云边端算力协同流程图。

图7是本发明的控域计算集群架构图。

图8是本发明的用户作业依赖图。

图9是本发明的数据处理装置示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图，对本发明进一步详细说明。应当理解，此处所描述的具体实施方法仅仅用以解释本发明，并不用于限定本发明。

本发明中控域资源池是物理世界中所有算力的一个子集，包含可访问的云边端等多端资源，通过算力协同机制为控域上层应用程序提供计算支持。本发明针对云边端分布式环境，提出一种基于控域的算力协同机制，解决云边端资源注册与发现、资源调度、负载监控与任务复制等技术问题。

在算力注册与发现上，边端侧网络环境通常较差，且具有不稳定性，以及因电力或故障等原因宕机也可能发生，这导致计算设备会频繁退出与加入控域计算集群，无法通过选举主节点来有效管理集群，因此主从架构难以适应频繁变化的云边端环境，本发明采用设备以一定周期将自身状态写入分布式数据库的方式进行算力注册与发现，分布式数据库则采用Raft等高效共识算法来保证效率与数据一致性。在资源调度与分配上，若采用中心化架构即由单独主节点负责资源调度，集群仅存在单一调度器，则易受网络中断、设备宕机等问题导致调度服务不可用，同时集中式调度也会增大边端设备的负载压力，本发明采用分散式全局资源调度的方式提供控域计算集群的资源分配服务，分散调度压力，提高可用性。在负载监控与复制上，由于边端侧的不稳定性，无法保证卸载迁移的任务能够一直正常运行，负载的监控也显得格外重要，并且，负载运行时可能对单一任务存在并发请求，有效利用云边端分布式算力环境增强任务并发处理能力也是算力协同的重要挑战之一，本发明设计独立监控、任务复制机制增强计算系统对负载故障的处理能力与并发处理能力。

图1是本发明的基于控域的云边端算力协同机制部署概念图。如图1所示，云边端所有设备的算力资源构成控域资源池，各端算力资源通过分布式数据库统一组织管理，为算力协同提供基本的条件，控域资源池可供用户控域申请使用，用户(User)根据自身需求可申请全部或部分种类的集群，即控域可由云 (Cloud)、边(Edge)、端(Thing)等不同设备(Device)构成，所有控域共享整个资源池。用户构建可运行的用户应用程序，该程序可作为作业(Job) 提交至控域中，作业运行后，将可卸载任务提交控域，发出卸载迁移请求，调度器将其调度至合适的设备上部署执行。整个计算系统在运行时将对提交的作业与卸载的任务进行监控，根据运行情况进行重启与复制。

本发明的技术核心包括：

1)去中心化算力注册与发现

通过设备周期写入控域去中心化分布式数据库的方式进行算力注册与维活，以及通过读取分布式数据的方式获取所有算力信息，去中心化的分布式数据库采用Paxos、Raft等共识算法构建，整过程不存在单点问题，达到去中心化目标。

现有的分布式资源管理系统通常采用集中主从式架构，如Hadoop YARN、Kubernetes、Mesos等都由主节点进行资源注册、任务调度、资源分配等功能，从节点仅负责接收任务迁移、执行任务等功能。这种组织架构在云计算模式中起到了良好的效果，但边端环境与云数据中心环境显著不同，边端环境算力异构、网络不稳定等因素的存在容易导致主节点难以选举、单点故障频发等问题的出现，使得主从式架构难以适应云边端协同计算环境。因此，针对云边端环境，需要从去中心化的角度出发，设计一种分布式的资源管理系统，解决单点故障带来的严重问题。

本发明利用分布式数据库解决单点故障问题。计算设备以一定周期向分布式数据库写入自身信息及状态数据，即完成算力注册。读取数据库，即可获取设备集合，并根据写入时间，可确认节点存活状态与连通性。

图2是本发明的去中心化算力注册与发现示意图。如图2所示，计算系统部署有一个分布式数据库，该数据库可使用Paxos、Raft等共识算法保证数据的强一致性，进而保证各设备读取数据一致。新设备加入计算集群后，设备将自身信息(IP、服务端口、所处位置、系统类型、架构类型等)、自身状态数据(CPU利用率、内存总量与剩余量、当前功耗、剩余电量等)按照系统约定格式传输至分布式数据库进行存储，即完成了算力注册。可以发现，此过程除新注册设备和分布式数据库外，没有其他设备的参与，而分布式数据库采用 Paxos、Raft等共识算法构建，不存在单点故障问题，因此达到了去中心化算力注册的目标。设备完成注册后，以一定时间周期或状态发生较大变动时，向分布式数据库更新自身的状态数据，此过程与传统计算模式中的心跳类似，但不同的是，传统计算模式中心跳发送至主节点报告自己状态及活性，存在单点故障问题，本发明中的心跳发送至分布式数据库中，解决了上述问题。发送心跳主要达到两个目的：一、维持自身活性，避免其他设备以为本机不可访达而造成资源浪费；二、更新状态数据，使调度器能够依据最新状态数据进行资源分配。

此外，设备状态数据短时间内未发生明显变化，却仍需发送心跳时，若继续把所有状态数据进行完整传输则会造成网络带宽、能耗等资源的浪费。本发明采用续约机制优化心跳过程，每个设备进行首次注册时会得到一份租约，后续每次心跳时则需要携带这份租约进行续约，分布式数据库获取租约后即表示该设备存活状态良好。设备在状态没有发生明显变化时(例如设备状态变化量小于活性阈值)，仅需进行续约操作，即设备发送至分布式数据库的心跳数据仅包括租约，而无需传输具体状态数据；设备在状态发生明显变化后(例如设备状态变化量大于等活性阈值)，需要向分布式数据库发送更新后的自身状态数据。

由于采用去中心化式算力注册，调度器本身并不会直接存储控域资源池中所有的算力信息，当进行资源分配时，需通过算力发现机制获取整个控域资源池所有可用算力信息。本发明中通过读取分布式数据库中所有设备状态数据即可获取所有算力信息，完成算力发现。控域资源池中可能包含大量算力信息，若每次调度都完整读取一次数据库也会造成网络带宽、能耗等资源的浪费，同时会严重增加调度延迟。因此，本发明采用缓存与监测结合的方式优化该过程，调度器本身对控域资源池中所有数据保存一份副本，仅在调度器初始化时，进行一次算力发现，来初始化算力信息副本，后续直接利用副本信息进行资源分配。然后采用监测机制，监测数据库中的数据变化，当收到数据库变化通知时，获取新添加设备或发生变化设备的数据，并更新自身副本。

去中心化架构能够适应边端网络不稳定的环境，即使出现网络分区，各分区仍能自组成小规模控域资源池继续工作。

2)分散式全局资源调度

每一台设备都可以选择自身是否启动调度器，故集群中包含多个调度器，所有调度器都可通过算力发现获取全局算力信息并同时进行调度，最终由接收卸载的设备对调度决策进行确认。若确认失败则再次发起调度任务

云边端协同环境具有网络不稳定性，传统只有云中心节点运行调度器的方式可能会在网络中断的情况下导致边端任务无法提交与卸载，进而导致用户无法提交作业，或已有作业无法正常工作等情况的发生。

图3是本发明的分散式全局资源调度示意图。如图3所示，本发明所有设备都可以选择运行调度器(Scheduler)，地位等同，并能通过算力发现机制获取全局算力资源。资源调度包含作业资源调度(Job Manager)与任务资源调度(Instance Manager)。对于作业，用户可将作业提交至控域计算集群中任意一台设备，若该设备未部署调度器，则将其提交至部署调度器的设备，最终接受任务提交的设备将负责该作业的调度任务。设备将根据作业对时延的要求、资源占用量预测等方面决定其适合的设备，然后将其传输至目标设备部署。由于有多个调度器同时工作，可能传输至目标设备后，目标设备已接受其他作业或任务，导致其资源不足，此时即为调度失败，目标设备将重新发起调度任务，直至作业最终部署成功，或资源不足调度失败。

图4是本发明的应用程序三级分层示意图。如图4所示，本发明将应用程序从编程到运行设计为三级，分别为作业(Job)、任务(Task)和任务运行实例(Instance/Ins)。一个作业即为一个完整的应用程序，该程序中包含若干可卸载的模块，即为任务，任务卸载后被调度执行的实体称为运行实例，任务具体运行的实例可有多个，用于负载均衡、调优或容灾备份等。因此，三者中作业和实例都是可运行的实体，而Task则为虚拟设定，用于管理运行实例归属、记录任务基本信息等功能。对于任务，本发明采用调度器持续监测的方式进行调度。作业在运行后，会向所在设备提交需卸载的任务，该设备会依据任务需求构建待调度运行实例，并发布至控域计算集群中，所有调度器中最先监测到该待调度实例的将负责其调度任务，根据其运行需求将其卸载至合适的设备运行。与作业的情况相同，若设备在接收运行实例后无法完成卸载，则该次调度为失败。接收实例的设备立刻将该实例再发布至控域计算集群中等待再次调度，持续此过程直至该任务最终被部署执行。

由于所有设备都可以进行资源调度，因此降低了待卸载作业与任务堆积的可能，减少了等待资源分配的时间，分散了调度压力，同时避免了单一调度器导致的单点故障问题。

3)设备独立的负载监控与复制

各个设备负责监控运行在本机的作业与运行实例，当两者的运行情况不能满足性能要求时，设备有权通过发起新运行实例的方式完成运行实例的动态复制，提升运行性能。

现有的计算系统通常采用设备检测任务执行、上报状态数据、主节点分析处理的模式，这种方式主节点负载压力通常较大，且存在单点故障问题，不适用于云边端分布式环境。

图5是本发明的设备独立的负载监控与复制示意图。如图5所示，本发明采用“谁执行，谁监控”的方式对作业运行情况进行监控，即计算设备对其执行的作业与运行实例进行监控，监控的方面包括资源占用量、任务请求频率、任务响应时间等多项指标，并依据指标进行动态调整。计算设备在接受卸载的运行实例后，部署至本机执行，并对其进行持续监控，通过监控数据以及调整策略对其进行运行时动态调优，例如设备检测到请求速率高于响应速率时即表明该实例负载过重，该设备即可依据该实例配置信息，向控域算力协同系统发起新的待调度运行实例，调度器检测到带调度任务后，依据任务算力需求信息对其进行资源分配，将其迁移调度至合适的设备执行。新复制出的运行实例即可分担之前负载过重实例的压力。计算设备在检测实例状态数据的同时，会将该数据传输至分布式数据库中，运行作业的计算设备通过读取分布式数据库即可获知中各运行实例的运行情况。计算设备仅需监控在本机运行的作业，将检测到运行实例较长时间不更新状态数据后，即表明该运行实例已失活，则该设备将发起新的待调度运行实例，保证作业的正常运行。

独立监控分散了监控压力，同时能避免主节点失联导致作业无法执行、任务无法调用等情况的发生，通过赋予设备复制实例权限提升作业与系统的运行效率，保证用户使用体验。

图6是本发明的基于控域的云边端算力协同流程图。如图6所示，本发明的基于控域云边端分布式算力协同方法具体包括：

步骤S1，由控域的计算集群内具有可用资源的云设备、边设备和端设备向控域系统的分布式数据库发送注册数据以完成算力注册，将完成算力注册的云设备、边设备或端设备作为算力设备加入控域的资源池；注册数据包括设备属性信息和设备状态信息，其中，算力设备的设备属性信息包括设备IP、服务端口、所处位置、系统类型和架构类型，算力设备的设备状态信息包括CPU 利用率、内存总量与剩余量、当前功耗、剩余电量、总资源量和可用资源量；

通过算力注册，不但可以明确控域中具有剩余算力的设备，还能使参与作业分配和实例分配的设备通过分布式数据库获取其他算力设备设备属性信息和设备状态信息，作为分配操作的依据；

为减少网络带宽、能耗等资源的浪费，分布式数据库获取算力设备的注册数据后，向算力设备返回一份租约；当算力设备的设备状态变化量小于预设的活性阈值时，算力设备向分布式数据库发送仅包含租约的心跳数据进行续约以维持设备活性；仅当算力设备的设备状态变化量大于等于活性阈值时，才向分布式数据库更新设备状态信息

步骤S2，当用户将作业提交至控域后，将该作业随机提交给任一算力设备，若该算力设备具有调度程序(调度器)并已启动调度程序，则进行分配作业操作，将该作业分配给作业执行设备进行部署；若该算力设备不具有调度程序(调度器)或未启动调度程序，则由该算力设备将该作业转发给该资源池中的另一算力设备，重新进行分配作业操作，若另一算力设备也具有调度程序(调度器)或未启动调度程序，则由另一算力设备继续该作业转发给该资源池中的其他算力设备，直到有算力设备可以执行分配作业操作；

步骤S3，由可以执行分配作业操作的算力设备(作业分配设备)根据从分布式数据库获取其他算力设备设备属性信息和设备状态信息，将作业分配给可执行作业的算力设备(作业执行设备)进行部署；

步骤S4，由作业执行设备生成该作业的任务和该任务的运行实例，将任务的相关信息(源代码、算力需求等)保存至控域(分布式数据库)中，并将该运行实例发布至控域(分布式数据库)；

所有算力设备的调度器持续检测是否有新构建的运行实例，当发现有新构建的运行实例时，由首先发现有新构建的运行实例的算力设备(实例分配设备) 根据从分布式数据库获取其他算力设备设备属性信息和设备状态信息，将运行实例分配给可执行运行实例的算力设备(实例执行设备)进行部署；

步骤S5，当实例执行设备接收/下载该运行实例时或执行该运行实例中，若实例执行设备的可用资源量不满足执行运行实例的要求，则由实例执行设备基于运行实例生成新运行实例并发布至控域(分布式数据库)，由首先检测到新运行实例的算力设备将新运行实例分配至可执行运行实例的算力设备进行部署执行；这里的可执行运行实例的算力设备并不限于未执行与用户作业相关运行实例的设备，控域中所有满足新运行实例资源要求的算力设备都可以被分配新运行实例；

步骤S6，当算力设备执行运行实例时，由算力设备监测自身运行实例的执行情况，当监测到运行实例在预设时长内没有更新状态数据，则认为运行实例失活，由该算力设备基于运行实例生成新运行实例并发布至控域(分布式数据库)进行部署执行；

步骤S7，实例执行设备接受该作业对任务的调用请求后，执行相应的运行实例，并将运行实例的执行结果返回给执行作业的算力设备，以执行作业。

为了使本发明的目的、技术方案及优点更加清楚明白，以下展示的5台设备搭建一组控域计算集群，采用ETCD作为分布式数据库，以此对本发明提出的基于控域的云边端分布式算力协同机制进一步详细说明。应当理解，此处所描述的具体实施方法仅仅用以解释本发明，并不用于限定本发明。控域计算集群的设备配置如表1所示。

表1控域计算集群的设备配置

如图7所示，本发明所有设备通过以太网进行连接，设备可选择是否运行 ETCD数据库，引擎(Engine)启动时指定其读写的数据库、是否运行调度器等配置参数，读写同一个数据库的一组设备构成一个控域资源池。引擎启动后，即开始向ETCD发送心跳数据，包括自身IP、引擎端口、可用资源量、总资源量等信息，首次发送时即为算力注册，ETCD会返回一个租约，后续在状态数据未发生明显变化时，仅需向ETCD发送租约进行续约，即可维持自身活性。

假设某用户在该控域系统中已有一个控域，并计划向控域提交如图8所示的作业，其中包含两个任务，一个是计算参数a和b的平方和，记为Task1；另一个是计算a的平方，记为Task2。在作业主过程中，包含一个对两任务分别执行100次的循环过程，每次循环分别对两个任务调用一次。由于Task1计算时需调用一次Task2，因此，最终作业依赖如图8所示。

控域计算系统提供若干终端命令，包括算力查询、作业提交、作业启动、结果查询、控域创建、资源申请、任务调用等操作。控域中设备能够访问ETCD 数据库，故任一设备都能通过读取数据库进行算力发现。用户在自己设备终端中通过控域命令与控域计算集群进行交互，提交任务时，终端命令随机将作业提交至集群中任意一台设备。以提交至Thing1设备为例，由于Thing1设备并未启动调度程序，在接收作业后该设备将作业转发给集群中运行有调度程序的其他设备，假设转发至Thing2。Thing2的调度器依据作业提交时间、用户时延敏感度、资源占用量预估等方面在所有设备中选取合适的设备，假设最终决定将该作业在Thing2本机执行，然后，该设备将对作业进行解压部署，至此作业即已完成提交。

用户在获知作业已部署后，即可执行作业启动命令，该命令会直接发送至作业部署设备(Thing2)的引擎，引擎会将作业以进程的方式启动，并将其约束在用户所属控域中。作业启动初始化时，通过控域提供的运行时库将任务打包并提交本机引擎，该例中即将square和sos两个函数分别包装成两个任务提交至Thing2的引擎。引擎接收两个任务后，会将两者的相关信息(源代码、算力需求等)保存至ETCD数据库中，并构建新的运行实例并发布ETCD数据库中。在Thing2引擎接收任务后，并不会等待实例的发布、分配与部署等过程完成后再对作业进行响应，而是直接返回任务ID给作业，供其调用时使用。所有调度器持续检测新构建的实例，假设由Edge运行的调度器最先检测到两个待卸载实例，则该调度器依据算力需求对其进行资源分配，假设最终 Task1分配至Cloud1，Task2分配至Thing1，得出分配决策后，Edge会将决策分别发送至Thing1与Cloud1的引擎，两者在接收决策后，从ETCD数据库中获取源代码及相关数据，然后部署至本机中，并将运行实例限制在用户控域资源空间内。作业初始化完成后，将会运行主过程中的语句，即进行循环体内，当执行square函数时，并不会直接运行函数体代码，而是由运行时库提供的代理程序检查该函数是否已卸载，已被卸载后，该代理程序会将函数计算请求转发至本机引擎，本机引擎能够通过读取数据库获知Task2任务运行实例所在地即Thing1，然后引擎携带实例ID、计算参数向Thing1引擎发起请求。Thing1 接收请求后，调用部署的实例执行计算并将结果返回给Thing2引擎，进而返回给作业。执行sum_of_square与上述类似，仅是Task1内部也有对Task2的调用，调用过程与之相同。此时，该作业的执行使用到了Cloud1、Thing1和 Thing2的算力，达到了分布式算力协同的目的。

假设由于Thing1设备性能较弱，引擎监测到对Task2的计算请求速率大于设备处理能力，引擎则会构建新的运行实例发布至计算集群中，假设Cloud2 的调度器将新的实例调度至Edge运行，此时Task2有两个运行实例，完成负载的动态复制。Thing2引擎在进行计算请求时，采用合适的负载均衡算法将请求分发至两个运行实例，减轻Thing1的负载压力。

由于边端侧网络不稳定性，假设云端两设备与其他设备的以太网连接中断，此时ETCD数据库将产生两个网络分区，但其在边端侧的分区仍能独立工作。作业在调用Task1时将会调用失败，引擎通过读写数据库可获知较长时间未获取到Cloud1的心跳数据，则表明与Cloud1的连接已中断，引擎将对Task1 构建新的运行实例发布至集群中，由Edge或Thing2进行资源分配，并部署执行。此后作业又将继续正常调用Task1。这表明本发明提出的算力协同机制能够避免单点故障问题，在网络发生分区后，各分区仍能正常工作。

图9是本发明的数据处理装置结构示意图。如图9所示，本发明还提出一种数据处理终端，用于作为云设备、边设备或端设备接入云系统，并执行用户作业，数据处理装置包括处理器和计算机可读存储介质，其中处理器调取并执行该计算机可读存储介质中的计算机可执行指令，在数据处理装置执行用户作业时，进行基于控域的云边端分布式算力协同。本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件(例如处理器)完成，所述程序可以存储于可读存储介质中，如只读存储器、磁盘或光盘等。上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地，上述实施例中的各模块可以采用硬件的形式实现，例如通过集成电路来实现其相应功能，也可以采用软件功能模块的形式实现，例如通过处理器执行存储于存储器中的程序/指令来实现其相应功能。本发明实施例不限制于任何特定形式的硬件和软件的结合。

本发明的基于控域云边端分布式算力协同方法具有以下有益效果：现有针对云边端场景的计算系统多采用云计算模式，即由云中心节点作为主节点管理调度所有算力，但边端侧通常具有网络、电力、设备故障频发等问题，云计算模式在与主节点链接断开后容易造成系统不可用等问题的发生。本发明提出的基于控域的算力协同机制，整体上采用去中心化的资源管理策略，从根本上避免了单点故障的产生。设备算力的注册与发现仅与分布式数据库进行交互，与其他计算设备无关。所有设备均可执行调度任务，减少了待卸载作业和任务堆积的可能。对执行的作业与运行实例，进行设备独立的负载监控与动态复制。通过减少设备之间的耦合，去除中心节点的存在，降低了控域计算集群中单个设备的负载压力，进而提升了整个计算系统的运转效率。

以上实施方式仅用于说明本发明，而并非对本发明的限制，有关技术领域的普通技术人员，在不脱离本发明的精神和范围的情况下，还可以做出各种变化和变形，因此所有等同的技术方案也属于本发明的范畴，本发明的专利保护范围应由权利要求限定。

Claims (10)

1.一种基于控域的云边端分布式算力协同方法，其特征在于，包括：

当用户将作业提交至该用户所属控域，由作业分配设备将该作业分配给作业执行设备进行部署；

由该作业执行设备生成该作业的任务和该任务的运行实例，将该运行实例发布至该控域；由实例分配设备将该运行实例分配给实例执行设备进行部署；

实例执行设备接受该作业对该运行实例的调用请求后，执行该运行实例，将该运行实例的执行结果返回给该作业执行设备。

2.如权利要求1所述的云边端分布式算力协同方法，其特征在于，还包括：由该控域的计算集群内具有可用资源的云设备、边设备和端设备向该控域的去中心化分布式数据库发送注册数据进行算力注册，以完成算力注册的云设备、边设备和端设备为算力设备；该作业分配设备和该实例分配设备，通过该分布式数据库获取所有算力设备的注册数据分别作为该作业或该运行实例的分配依据；该注册数据包括设备属性信息和设备状态信息，该设备属性信息包括设备IP、服务端口、所处位置、系统类型和架构类型，该设备状态信息包括CPU利用率、内存总量与剩余量、当前功耗、剩余电量、总资源量和可用资源量。

3.如权利要求2所述的云边端分布式算力协同方法，其特征在于，完成算力注册后，由该分布式数据库向该算力设备返回租约；当该算力设备的设备状态变化量小于活性阈值时，该算力设备向该分布式数据库发送仅包含该租约的心跳数据进行续约以维持设备活性；当该设备状态变化量大于等于该活性阈值时，向该分布式数据库更新设备状态信息。

4.如权利要求2所述的云边端分布式算力协同方法，其特征在于，将该作业随机提交给任一算力设备，若该算力设备已启动调度程序分配该作业，则以该算力设备为作业分配设备；反之，则由该算力设备将该作业转发给另一算力设备，直到接收该作业的算力设备已启动调度程序，作为作业分配设备分配该作业。

5.如权利要求2所述的云边端分布式算力协同方法，其特征在于，以首先检测到该运行实例且启动调度程序的算力设备为该实例分配设备。

6.如权利要求2所述的云边端分布式算力协同方法，其特征在于，以接收到该运行实例的算力设备为实例执行设备；当该实例执行设备接收该运行实例时或执行该运行实例中，若该实例执行设备的可用资源量不满足执行该运行实例的要求，则由该实例执行设备基于该运行实例生成新运行实例并发布至该控域，由其他实例分配设备将该新运行实例分配至实例执行设备进行部署执行。

7.如权利要求2所述的云边端分布式算力协同方法，其特征在于，当该实例执行设备执行该运行实例时，由该实例执行设备监测该运行实例的执行情况，当监测到该运行实例在预设时长内没有更新状态数据，则认为该运行实例已经失活，由该实例执行设备基于该运行实例生成新运行实例并发布至该控域，由其他实例分配设备将该新运行实例分配至实例执行设备进行部署执行。

8.一种基于控域的云边端分布式算力协同系统，其特征在于，包括：

作业分配模块，用于将用户提交至该用户所属控域的作业分配给作业执行设备进行部署；

实例发布模块，用于将接收到的作业生成任务和该任务的运行实例，并将该运行实例发布至该控域；

实例分配模块，用于检测该控域上发布的运行实例，并将该运行实例分配给实例执行设备进行部署；

实例执行模块，用于接受该作业对该运行实例的调用请求后，执行该运行实例，将该运行实例的执行结果返回给执行该作业的作业执行设备；

算力注册模块，用于向该控域的去中心化分布式数据库发送注册数据进行算力注册，并在完成算力注册后将当前设备加入该控域的资源池，以及通过该分布式数据库获取其他算力设备的注册数据分别作为该作业和该运行实例的分配依据；

活性维持模块，用于接收该分布式数据库返回的租约，并在当前设备的设备状态变化量小于活性阈值时，向该分布式数据库发送包含该租约的心跳数据进行续约以维持设备活性，当该设备状态变化量大于等于该活性阈值时，向该分布式数据库更新设备状态信息；

执行监测模块，用于监测当前设备对该运行实例的执行情况，并在认为该运行实例已经失活时，基于该运行实例生成新运行实例并发布至该控域。

9.一种计算机可读存储介质，存储有计算机可执行指令，该计算机可执行指令被执行时，用于实现如权利要求1～7任一项所述的基于控域的云边端分布式算力协同方法。

10.一种数据处理装置，作为云设备、边设备或端设备接入控域系统，该数据处理装置包括：

处理器；

如权利要求9所述的计算机可读存储介质，在该数据处理装置执行用户作业时，该处理器调取并执行该计算机可读存储介质中的计算机可执行指令，以进行基于控域的云边端分布式算力协同。

Images