CN111245906A - 一种业务请求分配方法 - Google Patents

Abstract

本发明公开的业务请求分配方法，涉及计算机技术领域，通过接收用户终端发送的业务请求，判断计算节点的剩余缓存空间是否大于业务请求业务量的大小，若是，则根据计算节点的计算能力、通信能力和队列的实时情况，为业务请求制定分配方案，利用分配方案，执行业务请求，降低了业务请求执行的总时延，在云节点及雾节点都处于任何状态时都适用，提高了适用性。

Description

一种业务请求分配方法

技术领域

本发明涉及计算机技术领域，具体涉及一种业务请求分配方法。

背景技术

随着工业信息化的快速发展，工业物联网(Industrial Internet of Things,IIoT)在工业4.0背景下受到学术界和工业界的高度关注。 IIoT使用了大量的智能设备，以提高生产力、工作效率和可靠性，具有规模庞大、精确性要求高、时延敏感等多方面特性,但随着产生业务量的急剧增加，本地处理业务的模式已渐渐不能满足需求。因此，IIoT需要一个强大的数据处理中心。

事实上，云计算已经被认为是满足IIoT应用程序需求的关键推动者。但云数据中心总是远程部署，将计算任务分配到云端中将会产生难以接受的传输时延和较大的能源损耗，使云计算不适用于时延敏感的应用。因此，雾计算的概念应运而生。通过在远程的云和设备之间引入中间雾层，以部署本地化的计算和存储资源。雾层不仅可以直接向用户提供服务，还可以利用云层更为强大的计算和存储能力协同进行服务。

但云雾计算在工业物联网中的应用并不成熟，因此如何高效地处理工业物联网中产生的大规模业务仍没有一个可行的实际方案。

随着云计算和雾计算的发展，将它们应用到工业物联网中已有了大量的研究。Mohammad等人介绍了IIoT和工业4.0的体系结构，讨论了雾计算如何在IIoT环境中提供计算支持，为雾计算在工业物联网中的应用提供了理论支持；Shi等人构建了云雾集成物联网架构，使用RCGA-CO算法来平衡负载以减少业务处理延迟，并提出了一种任务重新分配和重传机制，降低雾节点故障时的平均服务时延，但该文提出的机制只适用于云节点及雾节点都处于空闲状态的情况；Li 等人提出了一种基于服务流行度的智能资源分配方案，用于支持IIoT 中的雾计算，由于雾节点是由性能较弱、分散的各类功能计算机组成。因此，将业务分配到雾节点上处理时，若业务到达速率大于雾节点的处理速率，将会不可避免地在雾节点上产生业务排队等待执行的情况。一方面，这会导致额外的排队时延，对业务的处理时延将造成很大影响；另一方面，雾节点的缓存能力有限，因此缓存区可容纳的队列长度也有阈值限制，一旦超过这个值，业务将会丢失，不能保障任务处理的可靠性。更重要的是，当队列长度较长时，业务分配到雾节点上执行将会产生较高的等待时延，性能反而不如本地执行该业务。

发明内容

为解决现有技术的不足，本发明实施例提供了一种业务请求分配方法，该方法包括以下步骤：

接收用户终端发送的业务请求；

判断计算节点的剩余缓存空间是否大于所述业务请求业务量的大小，若是，则根据所述计算节点的计算能力、通信能力和队列的实时情况，为所述业务请求制定分配方案，其中，所述计算节点包括云节点及雾节点但不包括雾网络的接入节点；

利用所述分配方案，执行所述业务请求。

优选地，判断所述计算节点的剩余缓存空间是否大于所述业务请求业务量的大小包括：

若否，则将所述业务请求分配给用户终端。

优选地，则根据所述计算节点的计算能力、通信能力和队列的实时情况，为所述业务请求制定分配方案包括：

分别计算利用用户终端执行所述业务请求所需的时间t1及利用计算节点执行所述业务请求所需的时间t2并比较t1与t2的大小，若 t2小于t1，则根据所述计算节点的计算能力、通信链路的通信能力和当前队列的情况，将所述业务请求分割为多个子任务并将所述多个子任务分配给所述计算节点执行。

优选地，分别计算利用用户终端执行所述业务请求所需的时间t1 及利用计算节点执行所述业务请求所需的时间t2并比较t1与t2的大小包括：

若t2大于t1，则将所述业务请求分配给用户终端。

优选地，在确定所述业务请求的分配方案之后，实时更新所述计算节点当前的队列长度。

优选地，分别计算利用用户终端执行所述业务请求所需的时间t1 及利用计算节点执行所述业务请求所需的时间t2包括：

根据公式

计算用户终端执行所述业务请求所需的时间，其中，D_i为业务请求φ_i的任务量大小，

用户终端i的计算能力；

根据公式

计算利用所述分配方案执行所述业务请求所需的时间，其中，δ_ij是将第i个业务请求的业务量分配到第j个计算节点的比例，Q_j(t_{i_rea})为子任务到达节点时的队列长度，β表示传输开销导致的传输数据大小与原始任务数据大小的比值。f_j表示第j个计算节点的计算能力，R_j表示控制节点与第j个计算节点之间的数据传输速率。

优选地，根据所述计算节点的计算能力、通信能力和队列的实时情况，为所述业务请求制定分配方案包括：

根据公式

及

确定所述业务请求的分配方案。

优选地，实时更新所述云节点及所述雾节点当前的队列长度包括：

利用公式

实时更新更新计算节点当前的队列长度，

表示将第i个任务量分配至第j个计算节点上执行的总时延。

本发明实施例提供的业务请求分配方法，具有以下有益效果：

基于云节点及雾节点的计算能力、通信能力和队列的实时情况，为业务请求分配最优的分配方案，降低了业务请求执行的总时延，在云节点及雾节点都处于任何状态时都适用，提高了适用性。

附图说明

图1为本发明实施例提供的业务请求分配方法流程示意图；

图2为采用用户终端、一般云雾网络联合方案及本发明实施例提供的QCF-IIoT架构的延迟性能比较示意图；

图3为任务到达间隔对处理时延的影响示意图；

图4为雾节点缓存能力对任务处理时延的影响示意图。

具体实施方式

以下结合附图和具体实施例对本发明作具体的介绍。

为了满足工业物联网中大规模业务的需求，并提高整个处理系统的缓存能力，本发明实施例采用云雾计算联合的模式，考虑在云雾节点上可能存在排队现象，构建了基于动态队列的云雾工业物联网 (QCF-IIoT)架构。该结构分为三层:云计算层、雾计算层和终端用户层。

终端用户层主要由传感器节点、智能工业机器人、机械臂、智能终端等组成，它的功能是执行特定的生产活动，例如制造、物流和计算等。终端设备负责收集原始数据，并上传至上层进行计算和存储, 处理后的结果也将返回到这一层。

雾计算层一般由智能网关、路由器、交换机、接入点、基站等构成，提供一定程度的计算、存储和通信功能。由于雾节点距离用户较近，可以处理时延敏感型业务，从而满足用户的实时性要求。雾节点也可以对收集的数据进行预处理，再把预处理的数据上传至云端。

云计算层主要由多个高性能服务器和存储设备组成，它具有强大的计算和存储功能，可以执行复杂的计算任务。云模块通过控制策略可以有效地管理和调度边缘节点和云计算中心，为用户提供更好的服务。本发明实施例假设只有一个云服务器，为了提高QCF-IIoT的计算能力和缓存能力，可以把它也看作是一个计算节点。

终端用户随机产生大小不等的业务D，并将其发送到雾计算层的接入节点。P个用户由用户集U＝{U₁,U₂,...,U_P}代表，P个用户的本地计算能力由π＝{π₁,π₂,...,π_P}表示。V_m代表雾网络的接入节点，它作为控制节点，负责为业务制定最佳的分配方案。其余雾节点和云节点为计算节点，用节点集V＝{v₁,v₂,...,v_j,...,v_k,v_k+1}表示，代表有K个雾节点和一个云节点，负责处理分配到的子任务，它们的计算能力用 F＝{f₁,f₂,...,f_j,...,f_K,f_K+1}表示。

用φ＝{φ₁，φ₂，...,φ_i,...,φ_N}表示业务集，它们按照独立同分布的形式顺次到达控制节点，其中，

且φ_i＝{D_i,t_i,UE_i}。D_i为业务φ_i的任务量，t_i为业务到达控制节点的时间，那么任务到达的时间间隔为Δt_i＝t_i-t_i-1。UE_i代表产生此业务请求的用户，显然

为了简单性考虑，假设用户在执行业务的过程中不会产生业务，即业务在本地执行时不存在排队等待的现象。但由于本地计算资源有限，且用户的计算能力较差，用户将产生的业务请求分配到计算节点上执行依然是首要选择。

计算节点具有一定的缓存能力，即每个计算节点前都有一个任务缓冲区来存储到达的任务，任务在缓冲区排队等待执行。各个计算节点前的队列长度表示为Q＝{Q₁,Q₂,...,Q_j,...,Q_K}。由于计算节点的缓存能力有限，那么可被允许的缓存队列长度也必然存在着限制，用

来表示各个计算节点的队列阈值。

如图1所示，本发明实施例提供的业务请求分配方法，包括以下步骤：

S101，接收用户终端发送的业务请求。

S102，判断计算节点的剩余缓存空间是否大于业务请求业务量的大小，若是，则根据计算节点的计算能力、通信能力和队列的实时情况，为业务请求制定分配方案，其中，计算节点包括云节点及雾节点但不包括雾网络的接入节点。

S103，利用该分配方案，执行该业务请求。

可选地，判断计算节点的剩余缓存空间是否大于该业务请求业务量的大小包括：

若否，则将该业务请求分配给用户终端。

可选地，则根据计算节点的计算能力、通信能力和队列的实时情况，为该业务请求制定分配方案包括：

分别计算利用用户终端执行该业务请求所需的时间t1及利用计算节点执行该业务请求所需的时间t2并比较t1与t2的大小，若t2 小于t1，则根据计算节点的计算能力、通信链路的通信能力和当前队列的情况，将该业务请求分割为多个子任务并将所述多个子任务分配给所述计算节点执行。

可选地，分别计算利用用户终端执行所述业务请求所需的时间t1 及利用计算节点执行所述业务请求所需的时间t2并比较t1与t2的大小包括：

若t2大于t1，则将该业务请求分配给用户终端。

可选地，在确定所述业务请求的分配方案之后，实时更新所述计算节点当前的队列长度。

可选地，分别计算利用用户终端执行所述业务请求所需的时间t1 及利用计算节点执行所述业务请求所需的时间t2包括：

根据公式

计算用户终端执行所述业务请求所需的时间，其中，D_i为业务请求φ_i的任务量大小，

用户终端i的计算能力；

根据公式

计算利用所述分配方案执行所述业务请求所需的时间，其中，δ_ij是将第i个业务请求的业务量分配到第j个计算节点的比例，Q_j(t_{i_rea})为子任务到达节点时的队列长度，β表示传输开销导致的传输数据大小与原始任务数据大小的比值。f_j表示第j个计算节点的计算能力，R_j表示控制节点与第j个计算节点之间的数据传输速率。

其中，若业务请求φ_i分配至云雾节点上联合执行，则采用分布式计算的模式，由多个计算节点协同执行。

因为计算结果数据量较小，所以在此处不考虑结果返回的时延，那么，业务在节点上处理总过程中，时延包括任务的计算时延、排队的等待时延和信息传输的通信时延。

用φ_ij表示业务φ_i分配到节点v_j执行的子任务，子任务φ_ij在节点v_j上的计算时延如式所示：

当φ_ij到达节点v_j时，它必须等待队列中待执行的任务处理完毕，才能被执行，因此φ_ij的排队时延为

其中，Q_j(t_{i_rea})为子任务到达节点时的队列长度。

本发明实施例不考虑任务在传输过程中的阻塞情况。将φ_ij从节点 V_m分配到v_j的过程中，传输的数据量为βδ_ijD_i，其中β表示传输开销导致的传输数据大小与原始任务数据大小的比值，那么节点V_m和v_j之间的通信时延的表达式为：

因此，子任务φ_ij在节点v_j的处理时延为：

分布式计算总任务的处理时间等于所有子任务中最大的计算时延。因此业务在云雾节点上的处理时延为

综上可得，业务请求φ_i的总处理时延为

可选地，根据计算节点的计算能力、通信能力和队列的实时情况，为所述业务请求制定分配方案包括：

根据公式

及

确定所述业务请求的分配方案。

可选地，实时更新云节点及雾节点当前的队列长度包括：

利用公式

实时更新更新计算节点当前的队列长度，

表示将第i个任务量分配至第j个计算节点上执行的总时延。

其中，独立同分布的任务顺次到达控制节点，队列模型为FIFO 模式，即每个任务必须排队等待它之前的任务处理完毕才可以被执行。

在系统初始化后，第一个任务到达控制节点时，各个计算节点上没有待处理的任务，即Q_j(t₁)＝0。节点v_j前的队列长度(以bit为单位) 的更新公式为

Q_j(t_i)＝max{Q_j(t_i-1)+δ_(i-1)jD_i-1-f_j×Δt_i,0} (7)

其中，i＝2,3,....N，j＝1,2,...,K+1，δ_ij为业务请求φ_i分配到节点v_j执行的子任务比例，若业务φ_i没向节点v_j分配子任务，则δ_ij＝0。特别地，当业务φ_i本地执行时，

考虑将φ_ij从节点V_m分配到v_j需要传输时间，而各个计算节点在不间断的工作，所以当φ_ij到达节点v_j时，队列的实际长度为：

因为计算节点的缓存能力有限，队列Q在任何时候都要小于或等于阈值，即

通过分析可得，只要保障子任务到达节点队列时，满足队列长度小于或等于阈值，即可满足队列阈值约束。即

本发明的研究目标是针对多个随机到达的业务，根据QCF-IIoT 架构的实时状态，为到达控制节点的业务做出最佳的处理方案，判断本地处理该业务还是将该业务分配到云雾节点处理的时延最小。但在预先计算任务在云雾节点执行的处理时延时，为了在不超过各个计算节点缓存能力的前提下最小化业务的处理时延，必须根据云雾节点的计算能力、通信链路的通信能力和队列的实时情况，为业务φ_i找到一个最优的任务分配方案，即找到一组最优的{δ_i1,δ_i2,...,δ_iK,δ_i(K+1)}。综上所述，本发明实施例的优化目标为

为了找到式(10)的最优解，即根据QCF-IIoT架构的实时情况和业务的特点，最小化业务的处理时延，引入了一种用于约束优化问题的实数编码遗传算法(RCGA)。在实数编码遗传算法的过程中，每个个体的染色体为X_i＝{x_i1，x_i2，...，x_ik，x_i(k+1)}表示优化问题的一种可能解，以实数随机初始化个体，作为群体的可能解。然后，经n代的种群迭代演化，按照遗传算子的设定，群体的个体发生染色体交叉，而且还存在个体变异的概率，整个群体按照优胜劣汰的原则被诱导着进行种群进化，直至进化最大代数后，将最佳适应度的个体进行相应解码后，便是目标问题的最优解。

与传统的实数编码遗传算法不同，RCGA算法中的适应度函数的计算公式如式(12)所示:

其中，F代表搜索空间S的可行域，那么S-F为不可行域。h为惩罚因子，t_j(X)为第j个约束不可行个体的约束违逆值，ξ(X，g)为第g代不可行个体的一个附加启发式值。设置这些参数的意义是，确保在迭代过程中所有可行域的可能解优于所有非可行域的。

t_j(X)和ξ(X，g)的计算公式分别如式(14)和式(15)所示：

在式(13)和(14)中，t(x)表示第g代个体的适应度值,Worst(g) 通过g代进化记录最佳适应度的可行个体。

在RCGA算法中，将种群中的每一个个体X_i设计为含有K+1个基因的一维实数组，首先在搜索空间S中以实数随机初始化种群，然后根据式(13)计算每个个体的适应度值，并记录下当代的最优适应度的个体及其对应的适应度。接下来，执行遗传操作更新初始种群。具体的遗传算子如下：

选择：在当前种群中保留高适应度个体，并淘汰适应度较低的个体的过程，本发明实施例采用了一种比较选择策略。

交叉：在RCGA算法中使用算术交叉，其中两个新的子个体，即X′₁,X′₂，由双亲个体X₁，X₂的线性组合产生，即X′₁,X′₂。遗传算法中，父母和子女之间的关系表达式如式(16)和(17)所示。

X′₁＝λX₁+(1-λ)X₂ (16)

X′₂＝λX₂+(1-λ)X₁ (17)

其中λ是区间(0,1)上的随机数。

本发明的效果可通过以下仿真进一步说明。

由图2可知，由于用户的本地计算能力较差，本地处理方案的时延明显高于QCF-IIoT架构和一般云雾联合方案。随着到达的业务数目不断增多，云雾节点上将产生业务排队等待执行的现象，一般的云雾联合方案不能自动调节节点上不断积累的待执行任务，这将不可避免地导致业务处理时延增长，此时QCF-IIoT架构的优越性便体现出来。在QCF-IIoT架构中，当云雾节点的队列长度较长时，部分业务将在本地处理，这不仅可以减少业务的处理时延，还可以减少云雾节点的队列长度。因此，QCF-IIoT架构适用于IIoT场景中的大规模业务处理。当到达500个业务时，与本地处理模式和普通云雾混合模式相比，QCF-IIoT架构的时延性能分别提升了35％和4.8％。

由图3可知，业务到达速率越快，处理时延就越高。经分析可得，造成这一现象有两个主要原因。第一，因计算节点的计算能力有限，那么业务到达速率越快，排队等待执行的业务将会越多，业务的排队时延将增加；第二，业务到达速率越快，则业务到达的时间间隔越小，然而在业务到达的时间间隔里，系统依然不停止的处理着缓存中待处理的排队任务，因此业务到达的时间间隔可以间接的减少业务的排队时延。

由图4可知，雾节点的缓存能力对业务处理时延有很大影响。若雾节点无缓存能力，则在处理大规模业务时，到达控制节点的业务必须等待前一个业务执行完毕并且结果返回后，才能被发送至计算节点，这种模式并不适合处理大规模业务。在一定范围内，增强雾节点的缓存能力可以显著降低业务处理时延，但当雾节点的缓存能力足够时再增加缓存，带来的增益并不明显。这是因为雾节点的计算能力有限，当雾节点上待处理的业务较多时，架构分配给该节点的任务量将减少，雾节点上的队列长度会达到一个稳定状态。因此，雾节点的缓存能力不需太强，只需与节点的计算能力匹配。

本发明实施例提供的业务请求分配方法，通过接收用户终端发送的业务请求，判断计算节点的剩余缓存空间是否大于业务请求业务量的大小，若是，则根据计算节点的计算能力、通信能力和队列的实时情况，为业务请求制定分配方案，利用分配方案，执行业务请求，降低了业务请求执行的总时延，在云节点及雾节点都处于任何状态时都适用，提高了适用性。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

可以理解的是，上述方法及装置中的相关特征可以相互参考。另外，上述实施例中的“第一”、“第二”等是用于区分各实施例，而并不代表各实施例的优劣。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

此外，存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM) 或闪存(flash RAM)，存储器包括至少一个存储芯片。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本发明实施例中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质 (包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (8)

1.一种业务请求分配方法，其特征在于，包括：

接收用户终端发送的业务请求；

判断计算节点的剩余缓存空间是否大于所述业务请求业务量的大小，若是，则根据所述计算节点的计算能力、通信能力和队列的实时情况，为所述业务请求制定分配方案，其中，所述计算节点包括云节点及雾节点但不包括雾网络的接入节点；

利用所述分配方案，执行所述业务请求。

2.根据权利要求1所述的业务请求分配方法，其特征在于，判断所述计算节点的剩余缓存空间是否大于所述业务请求业务量的大小包括：

若否，则将所述业务请求分配给用户终端。

3.根据权利要求1所述的业务请求分配方法，其特征在于，则根据所述计算节点的计算能力、通信能力和队列的实时情况，为所述业务请求制定分配方案包括：

分别计算利用用户终端执行所述业务请求所需的时间t₁及利用计算节点执行所述业务请求所需的时间t₂并比较t₁与t₂的大小，若t₂小于t₁，则根据所述计算节点的计算能力、通信链路的通信能力和当前队列的情况，将所述业务请求分割为多个子任务并将所述多个子任务分配给所述计算节点执行。

4.根据权利要求3所述的业务请求分配方法，其特征在于，分别计算利用用户终端执行所述业务请求所需的时间t₁及利用计算节点执行所述业务请求所需的时间t₂并比较t₁与t₂的大小包括：

若t₂大于t₁，则将所述业务请求分配给用户终端。

5.根据权利要求1所述的业务请求分配方法，其特征在于，在确定所述业务请求的分配方案之后，实时更新所述计算节点当前的队列长度。

6.根据权利要求3所述的业务请求分配方法，其特征在于，分别计算利用用户终端执行所述业务请求所需的时间t₁及利用计算节点执行所述业务请求所需的时间t₂包括：

根据公式

计算用户终端执行所述业务请求所需的时间，其中，D_i为业务请求φ_i的任务量大小，

用户终端i的计算能力；

根据公式

计算利用所述分配方案执行所述业务请求所需的时间，其中，δ_ij是将第i个业务请求的业务量分配到第j个计算节点的比例，Q_j(t_{i_rea})为子任务到达节点时的队列长度，β表示传输开销导致的传输数据大小与原始任务数据大小的比值。f_j表示第j个计算节点的计算能力，R_j表示控制节点与第j个计算节点之间的数据传输速率。

7.根据权利要求1所述的业务请求分配方法，其特征在于，根据所述计算节点的计算能力、通信能力和队列的实时情况，为所述业务请求制定分配方案包括：

根据公式

及

确定所述业务请求的分配方案。

8.根据权利要求5所述的业务请求分配方法，其特征在于，实时更新所述云节点及所述雾节点当前的队列长度包括：

利用公式

实时更新更新计算节点当前的队列长度，

表示将第i个任务量分配至第j个计算节点上执行的总时延。

Images