CN115840634B - 业务执行方法、装置、设备及存储介质 - Google Patents

Abstract

本公开实施例公开了一种业务执行方法、装置、设备及存储介质，其中，所述方法包括：从预设服务网络中的数据生产端获取待处理业务；服务网络包括数据中心集群和至少两个数据生产端，待处理业务携带业务参数；基于业务参数，确定待处理业务的业务类型；确定与业务类型匹配的初始执行模式；在初始执行模式表征为整体执行的情况下，基于业务参数，对待处理业务进行优化处理，得到优化结果；基于优化结果，确定待处理业务的目标执行模式。本公开实施例可以降低数据生产端业务执行时延，提升业务成功率。

Description

业务执行方法、装置、设备及存储介质

技术领域

本公开涉及但不限于计算机技术领域，尤其涉及一种业务执行方法、装置、设备及存储介质。

背景技术

随着大数据和人工智能的蓬勃发展，对用户设备产生的大量数据资源进行合理的处理、挖掘和应用是发挥数据价值、赋能各行各业的关键。近年来，为了提升用户业务的响应速度，实现数据的贴源采集、实时处理，计算模式从云中心处理转变为分布式协同处理。大数据分布式协同计算背景下，数据生产端负责数据源的数据处理（Extract-Transform-Load，ETL）、校验、标准化等计算任务，并将计算结果上传至数据中心（边缘）进行汇总，多个数据中心分散多个地理位置跨域部署，由云管控中心统一管控。针对数据生产端的超负荷采集、分析任务，多个数据中心可通过分布式跨域协同计算的方式为下发至数据生产端的ETL、校验、标准化等计算任务提供支撑。

现有的业务调度方式通常仅考虑时延和能耗问题，且业务执行机制仅考虑单一数据中心整体执行，忽略了对差异化终端业务的个性化调度方案设计。因此，面向海量终端差异化的业务应用需求，如何为数据生产端超负荷的采集与分析任务选择最佳的多数据中心协作执行方式是分布式跨域协同计算的关键问题。

发明内容

有鉴于此，本公开实施例至少提供一种业务执行方法、装置、设备及存储介质。

本公开实施例的技术方案是这样实现的：

一方面，本公开实施例提供一种业务执行方法，包括：从预设服务网络中的数据生产端获取待处理业务；其中，所述服务网络包括数据中心集群和至少两个所述数据生产端，所述待处理业务携带业务参数；基于所述业务参数，确定所述待处理业务的业务类型；确定与所述业务类型匹配的初始执行模式；其中，所述待处理业务的执行模式包括整体执行和分割执行，所述整体执行表征所述待处理业务由所述数据中心集群中的一个数据中心或一个所述数据生产端执行，所述分割执行表征所述待处理业务由至少两个所述数据中心和\或所述数据生产端执行；在所述初始执行模式表征为所述整体执行的情况下，基于所述业务参数，对所述待处理业务进行优化处理，得到优化结果；基于所述优化结果，确定所述待处理业务的目标执行模式。

另一方面，本公开实施例提供一种业务执行装置，包括：第一获取模块，用于从预设服务网络中的数据生产端获取待处理业务；其中，所述服务网络包括数据中心集群和至少两个所述数据生产端，所述待处理业务携带业务参数；第一确定模块，用于基于所述业务参数，确定所述待处理业务的业务类型；第二确定模块，用于确定与所述业务类型匹配的初始执行模式；其中，所述待处理业务的执行模式包括整体执行和分割执行，所述整体执行表征所述待处理业务由所述数据中心集群中的一个数据中心或一个所述数据生产端执行，所述分割执行表征所述待处理业务由至少两个所述数据中心和\或所述数据生产端执行；第一处理模块，用于在所述初始执行模式表征为所述整体执行的情况下，基于所述业务参数，对所述待处理业务进行优化处理，得到优化结果；第三确定模块，用于基于所述优化结果，确定所述待处理业务的目标执行模式。

再一方面，本公开实施例提供一种计算机设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法中的部分或全部步骤。

又一方面，本公开实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述方法中的部分或全部步骤。

又一方面，本公开实施例提供一种计算机程序，包括计算机可读代码，当所述计算机可读代码在计算机设备中运行时，所述计算机设备中的处理器执行用于实现上述方法中的部分或全部步骤。

又一方面，本公开实施例提供一种计算机程序产品，所述计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，所述计算机程序被计算机读取并执行时，实现上述方法中的部分或全部步骤。

本公开实施例中，首先，从预设服务网络中的数据生产端获取待处理业务；其中，服务网络包括数据中心集群和至少两个数据生产端，待处理业务携带业务参数。然后，基于业务参数，确定待处理业务的业务类型，以及确定与业务类型匹配的初始执行模式；其中，待处理业务的执行模式包括整体执行和分割执行，整体执行表征待处理业务由数据中心集群中的一个数据中心或一个数据生产端执行，分割执行表征待处理业务由至少两个数据中心和\或数据生产端执行。这样，通过业务类型可以快速准确地确定待处理业务的初始执行模式。其次，在初始执行模式表征为整体执行的情况下，基于业务参数，对待处理业务进行优化处理，得到优化结果。最后，基于优化结果，进一步地确定待处理业务的目标执行模式。这样，有助于为海量生产数据计算任务提供多数据中心分布式跨域协同执行方案，可以有效地降低数据生产端业务执行时延，提升业务成功率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，而非限制本公开的技术方案。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，这些附图示出了符合本公开的实施例，并与说明书一起用于说明本公开的技术方案。

图1为本公开实施例提供的第一种业务执行方法的实现流程示意图；

图2为本公开实施例提供的第二种业务执行方法的实现流程示意图；

图3为本公开实施例提供的第三种业务执行方法的实现流程示意图；

图4为本公开实施例提供的第四种业务执行方法的实现流程示意图；

图5为本公开实施例提供的第一种服务网络的网络模型示意图；

图6为本公开实施例提供的第二种服务网络的网络模型示意图；

图7为本公开实施例提供的第五种业务执行方法的实现流程示意图；

图8为本公开实施例提供一种有向无环图的示意图；

图9为本公开实施例提供的一种业务执行装置的组成结构示意图；

图10为本公开实施例提供的一种计算机设备的硬件实体示意图。

具体实施方式

为了使本公开的目的、技术方案和优点更加清楚，下面结合附图和实施例对本公开的技术方案进一步详细阐述，所描述的实施例不应视为对本公开的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本公开保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。所涉及的术语“第一/第二/第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一/第二/第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本公开实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本公开的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本公开的目的，不是旨在限制本公开。

本公开实施例提供一种业务执行方法，该方法可以由云控制中心的处理器执行。其中，云控制中心指的可以是服务器、云端平台、笔记本电脑、平板电脑、台式计算机、移动设备（例如移动电话、便携式视频播放器、个人数字助理、专用消息设备）等具备业务执行能力的设备。图1为本公开实施例提供的一种业务执行方法的实现流程示意图，如图1所示，该方法包括如下步骤S101至步骤S105：

步骤S101，从预设服务网络中的数据生产端获取待处理业务。

这里，服务网络包括数据中心集群和至少两个数据生产端，数据中间集群包括至少两个数据中心。云控制中心可以作为服务网络的指挥中心，云控制中心可以用于确定待处理业务由数据中心还是数据生产端进行处理。数据生产端可以是指能够与用户进行交互，生成待处理业务的设备，数据生产端也可在本地对待处理业务进行处理等，如，数据生产端为车辆、用户终端等设备。数据中心可以是指在后台能够为数据生产端提供资源（如计算资源、存储资源等）的设备，如，云服务器等。待处理业务可以是由数据生产端生成的业务，也可以简称为业务，如，人脸识别业务、路径规划业务等，这里并不限定。

针对数据生产端的超负荷采集、分析等待处理业务，多个数据中心可通过分布式跨域协同计算的方式为下发至数据生产端的ETL、校验、标准化等计算任务提供支撑。从数据生产端角度来说，不同类型的待处理业务往往对数据量、存储及计算能力有不同要求，相应地，其各自的最佳执行机制也会存在差异。例如：对于计算量较小且时延敏感型的待处理业务，在数据生产端进行本地执行最佳；对于计算密集型数据业务，由于数据生产端的计算资源等能力有限，为满足任务时延约束，应将待处理业务向上传输至计算能力更强的数据中心执行或云管控中心执行；同时，对于复杂的待处理业务，往往更宜将其分解为多个子业务，通过子业务间并行调度至多个数据中心或多个数据生产端协作执行来提升服务质量等。

待处理业务携带业务参数，业务参数可以是指待处理业务的属性，如，业务参数包括业务的生成时刻、业务所需的机器周期数量、业务所需的计算资源量、业务所需的输入数据量、业务的最迟完成时刻等，这里并不限定。例如：数据生产端响应于用户的控制操作，生成与控制操作匹配的待处理业务，并将待处理业务发送至云控制中心，以使得云控制中心获取待处理业务；云控制中心对待处理业务进行解析，得到待处理业务的业务参数。

步骤S102，基于所述业务参数，确定所述待处理业务的业务类型。

这里，待处理业务的业务类型可以是指待处理业务所对应的业务量类型，如，轻载型业务和重载型业务等，轻载型业务所需的资源量大于重载型业务所需的资源量，轻载型业务可以由资源量较少的数据生产端自身执行，重载型业务可以由资源量较多的数据中心执行等。可以利用时间约束来确定业务类型，如，基于业务参数，确定待处理业务的松弛时间，在松弛时间大于或等于零的情况下，确定待处理业务为轻载型业务；在松弛时间小于零的情况下，确定待处理业务为重载型业务；其中，可以基于待处理业务所需的机器周期数量、业务所需的输入数据量以及数据生产端与数据中心之间的链路数据率等预设参数，确定待处理业务的执行时延；基于最迟完成时刻与执行时延和当前时刻之间的差值，确定松弛时间。

步骤S103，确定与所述业务类型匹配的初始执行模式。

这里，待处理业务的执行模式包括整体执行和分割执行，整体执行表征待处理业务由数据中心集群中的一个数据中心或一个数据生产端执行，分割执行表征待处理业务由至少两个数据中心和\或数据生产端执行。初始执行模式可以是指基于业务类型而确定的执行模式，可以预先设置业务类型与初始执行模式之间的对应关系，在确定当前的业务类型的情况下，基于该对应关系，确定与当前的业务类型相匹配的初始执行模式。例如：轻载型业务对应整体执行，继而确定待处理业务可以由数据生产端或数据中心执行；重载型业务对应分割执行，继而对待处理业务进行分割，得到第一子业务和第二子业务，第一子业务可以由数据生产端执行，第二子业务可以由数据中心执行，或者第一子业务和第二子业务可以分别由第一数据生产端和第二数据生产端执行，或第一子业务和第二子业务可以分别由第一数据中心和第二数据中心执行等。

步骤S104，在所述初始执行模式表征为所述整体执行的情况下，基于所述业务参数，对所述待处理业务进行优化处理，得到优化结果。

这里，待处理业务的初始执行模式可以是为了初步确定待处理业务为整体执行或分割执行，其确定的用于执行待处理业务的调度对象（也即待处理业务的调度结果）是在各类业务参数的基础上获得的，并不能保证完全符合待处理业务的实际执行需求；因此，可以基于进一步对待处理业务的初始执行模式进行优化，确定优化结果。例如：可以建立基于时延及能耗联合最小化的优化问题，通过对该优化问题进行优化（如对该优化问题进行求解），以进一步筛选初始执行模式。例如：可以基于待处理业务所需的机器周期数量、业务所需的输入数据量以及数据生产端与数据中心之间的链路数据率等预设参数，确定待处理业务的执行时延；可以基于执行时延和数据生产端单位时间内发送单位数据的能耗成本等预设参数，确定待处理业务的能耗；基于待处理业务的执行时延和能耗，构建优化函数，在优化函数的函数值最小的情况下，确定对应的调度对象的数量（或者优化函数的解的形式等）；将调度对象的数量（或者优化函数的解的形式等）确定为优化结果。

在一些实施例中，在初始执行模式表征为分割执行的情况下，按照预设的分割方式对待处理业务进行分割，得到至少两个子业务；每一子业务的执行模式可以确定为整体执行，分别确定每一子业务所对应的调度对象；其中，调度对象可以是指数据生产端或者数据中心。

步骤S105，基于所述优化结果，确定所述待处理业务的目标执行模式。

这里，以优化结果为调度对象的数量（或者优化函数的解的形式等）为例进行说明，若确定调度对象的数量为2（大于1），那么可以确定待处理业务的优化结果与初始执行模式（整体执行）不一致，那么将优化结果确定为目标执行模式，也即确定待处理业务为的目标执行模式为分割执行；若确定调度对象的数量为1，那么可以确定待处理业务的优化结果与初始执行模式（整体执行）一致，那么将初始执行模式确定为目标执行模式，也即确定待处理业务为的执行模式为整体执行等。

在确定待处理业务的目标执行模式为整体执行的情况下，可以基于待处理业务的业务参数，确定待处理业务的执行时延和能耗等需求，继而从所有数据生产端和所有数据中心确定满足该需求的一个调度对象。在确定待处理业务的目标执行模式为分割执行的情况下，可以对待处理业务进行分割，得到多个子业务，继而分别确定每一子业务的一个调度对象等。

本公开实施例中，首先，从预设服务网络中的数据生产端获取待处理业务；其中，服务网络包括数据中心集群和至少两个数据生产端，待处理业务携带业务参数。然后，基于业务参数，确定待处理业务的业务类型，以及确定与业务类型匹配的初始执行模式；其中，待处理业务的执行模式包括整体执行和分割执行，整体执行表征待处理业务由数据中心集群中的一个数据中心或一个数据生产端执行，分割执行表征待处理业务由至少两个数据中心和\或数据生产端执行。这样，通过业务类型可以快速准确地确定待处理业务的初始执行模式。其次，在初始执行模式表征为整体执行的情况下，基于业务参数，对待处理业务进行优化处理，得到优化结果。最后，基于优化结果，进一步地确定待处理业务的目标执行模式。这样，有助于为海量生产数据计算任务提供多数据中心分布式跨域协同执行方案，可以有效地降低数据生产端业务执行时延，提升业务成功率。

在一些实施例中，上述步骤S103可以包括如下步骤S1031至步骤S1032：

步骤S1031，在所述业务类型为第一轻载型业务或第二轻载型业务的情况下，确定所述待处理业务的初始执行模式为所述整体执行。

这里，第一轻载型业务可以是指针对数据中心的轻载型业务，第二轻载型业务可以是指针对数据生产端的轻载型业务。例如：可以基于待处理业务的业务参数，分别确定待处理业务针对数据中心的松弛时间和针对数据生产端的松弛时间；在针对数据中心的松弛时间大于或等于零的情况下，确定待处理业务为第一轻载型业务，继而确定待处理业务的初始执行模式为整体执行；或者，在针对数据生产端的松弛时间大于或等于零的情况下，确定待处理业务为第二轻载型业务，继而确定待处理业务的初始执行模式为整体执行；其中，业务类型可以为第一轻载型业务或第二轻载型业务，也可以既为第一轻载型业务又为第二轻载型业务等，这里并不限定。

步骤S1032，在所述业务类型为第一重载型业务和第二重载型业务的情况下，确定所述待处理业务的初始执行模式为所述分割执行。

这里，第一重载型业务可以是指针对数据中心的重载型业务，第二重载型业务可以是指针对数据生产端的重载型业务。例如：可以基于待处理业务的业务参数，分别确定待处理业务针对数据中心的松弛时间和针对数据生产端的松弛时间；在针对数据中心的松弛时间小于零的情况下，确定待处理业务为第一重载型业务；在针对数据生产端的松弛时间小于的情况下，确定待处理业务为第二重载型业务；若确定待处理业务同时为第一重载型业务和第二重载型业务，那么确定待处理业务的初始执行模式为分割执行；其中，业务类型可以为第一重载型业务或第二重载型业务，也可以既为第一重载型业务又为第二重载型业务等，这里并不限定。

本公开实施例中，通过确定待处理业务的第一轻载型业务、第二轻载型业务、第一重载型业务和第二重载型业务等业务类型，可以快速准确地确定待处理业务的初始执行模式。

本公开实施例提供一种业务执行方法，所述待处理业务的业务类型包括：第一轻载型业务、第一重载型业务、第二轻载型业务和第二重载型业务；如图2所示，该方法包括如下步骤S201至步骤S209：

步骤S201，从预设服务网络中的数据生产端获取待处理业务。

步骤S207，确定与所述业务类型匹配的初始执行模式。

步骤S208，在所述初始执行模式表征为所述整体执行的情况下，基于所述业务参数，对所述待处理业务进行优化处理，得到优化结果。

步骤S209，基于所述优化结果，确定所述待处理业务的目标执行模式。

其中，步骤S201对应于前述步骤S101，在实施时可以参照前述步骤S101的具体实施方式；步骤S207至步骤S209分别对应于前述步骤S103至步骤S105，在实施时可以参照前述步骤S103至步骤S105的具体实施方式。

步骤S202，基于所述业务参数，分别确定所述数据中心的针对所述待处理业务的第一松弛时间和所述数据生产端针对所述待处理业务的第二松弛时间。

这里，第一松弛时间可以是指待处理业务针对数据中心的松弛时间，第二松弛时间可以是指待处理业务针对数据生产端的松弛时间，由于数据中心和数据生产端各自的资源量等属性的不同，导致第一松弛时间和第二松弛时间可能存在差异。例如：可以基于待处理业务所需的机器周期数量、业务所需的输入数据量以及数据生产端与数据中心之间的链路数据率等预设参数，确定待处理业务的执行时延；基于最迟完成时刻与执行时延和当前时刻之间的差值，确定松弛时间；其中，第一松弛时间所对应的执行时延可以包括业务数据上传时延、排队时延、计算时延及结果返回时延等四部分，第二松弛时间所对应的执行时延可以包括排队时延、计算时延等两部分，导致第一松弛时间和第二松弛时间存在差异。

步骤S203，在所述第一松弛时间大于或等于零的情况下，确定所述待处理业务为所述第一轻载型业务。

这里，可以确定针对数据中心的执行时延和当前时刻之间的时间和值，将最迟完成时刻与时间和值之间的时间差值确定为第一松弛时间，如，第一松弛时间为3秒，则确定待处理业务为第一轻载型业务。

步骤S204，在所述第一松弛时间小于零的情况下，确定所述待处理业务为所述第一重载型业务。

这里，可以确定针对数据中心的执行时延和当前时刻之间的时间和值，将最迟完成时刻与时间和值之间的时间差值确定为第一松弛时间，如，第一松弛时间为-2秒，则确定待处理业务为第一重载型业务。

步骤S205，在所述第二松弛时间大于或等于零的情况下，确定所述待处理业务为所述第二轻载型业务。

这里，可以确定针对数据生产端的执行时延和当前时刻之间的时间和值，将最迟完成时刻与时间和值之间的时间差值确定为第二松弛时间，如，第一松弛时间为2秒，则确定待处理业务为第二轻载型业务。

步骤S206，在所述第二松弛时间小于零的情况下，确定所述待处理业务为所述第二重载型业务。

这里，可以确定针对数据生产端的执行时延和当前时刻之间的时间和值，将最迟完成时刻与时间和值之间的时间差值确定为第二松弛时间，如，第一松弛时间为-1秒，则确定待处理业务为第二重载型业务。

本公开实施例中，通过确定数据中心的针对待处理业务的第一松弛时间和数据生产端针对待处理业务的第二松弛时间，可以快速准确地确定待处理业务的业务类型。

在一些实施例中，所述业务参数包括：生成时刻、机器周期、输入数据量和完成时刻；上述步骤S202可以包括如下步骤S2021至步骤S2024：

步骤S2021，基于所述机器周期、所述输入数据量和预设的第一设备参数，确定所述待处理业务的第一执行时延。

这里，生成时刻（

）（Generate Time）可以表示生成待处理业务（/>

）的时刻；机器周期（/>

）可以表示完成待处理业务所需的中央处理器（Central Processing Unit，CPU）周期数；输入数据量（/>

）可以表示待处理业务所需的输入数据大小；完成时刻（/>

）可以表示待处理业务的最迟完成时刻，也可以称为最迟完成时刻。第一设备参数可以是指数据中心以及数据中心与数据生产端之间进行数据传输的属性，如，链路数据率等属性参数，这里并不限定。可以基于生成时刻、机器周期、输入数据量和完成时刻等业务参数，确定待处理业务的时延、能耗以及松弛时间等执行参数，执行参数可以用于确定待处理对象的执行模式和调度对象等。

边执行（也即由数据中心执行待处理业务，数据中心可以简称为边）过程中的时延可以包括：业务数据上传时延、排队时延、计算时延及结果返回时延四部分。其中，端执行可以是指由数据生产端执行待处理业务，数据生产端可以简称为端。类似地，每个数据中心会维持一个边缘业务队列，记数据中心（

）处的业务队列为/>

，其最大能够容纳的任务数为/>

，且各个业务按照/>

值（最晚完成时刻）序列排队。

在一些实施例中，可以采用如下公式确定数据上传时延：

（1）；

公式（1）中，

表示数据上传时延，e代表Edge指边执行，u代表Uplink指带出流业务对应的数据通过上行链路上传给数据中心的过程，/>

表示数据输入量，表示数据生产端到数据中心之间的链路数据率，可以根据香农定理计算得到。

在一些实施例中，可以采用如下公式确定排队时延：

（2）；

公式（2）中，

表示排队时延，/>

表示中排在/>

前面的业务集合，每个数据中心上通常会有若干个虚拟机（Virtual Machine，VM）共同分担执行业务队列中的任务，且每个VM可能会被分配不同的执行能力，/>

表示完成待处理业务所需的CPU周期数，/>

为数据中心为待处理业务分配的VM对应的CPU频率，/>

为数据中心处的VM个数。

在一些实施例中，可以采用如下公式确定计算时延：

（3）；

公式（3）中，

表示计算时延，/>

代表为/>

分配的VM CPU处理频率，/>

表示完成待处理业务所需的CPU周期数。

在一些实施例中，可以采用如下公式确定结果返回时延：

（4）；

公式（4）中，

表示结果返回时延，其中d代表Downlink，指待处理业务通过下行链路返回给数据生产端，/>

为待处理业务返回结果数据的大小，/>

表示到之间的链路数据率，可以根据香农定理计算得到。

最终，待处理业务在数据中心的边执行时延（

）（也即第一执行时延）可以采用如下公式确定：

（5）；

公式（5）中，

表示边执行时延，/>

表示数据上传时延，/>

表示排队时延，/>

表示计算时延，/>

表示结果返回时延。

在一些实施例中，边执行过程中，数据生产端的能耗主要来源于其向数据中心上传及下载数据，由于结果数据一般较小，可以忽略下载结果数据的能耗。对于固定量的上传数据，其要求的发送时延越短，单位时间能传输的数据量越大，数据生产端发送数据消耗的能量越多。数据生产端单位时间内发送单位数据的能耗成本为

，可以采用如下公式确定边执行过程中的能耗：

（6）；

公式（6）中，

表示边执行过程中的能耗，/>

表示边执行时延，/>

表示预设的数据生产端单位时间内发送单位数据的能耗成本，/>

表示到之间的链路数据率，可以根据香农定理计算得到。边执行过程中的能耗/>

可以用于后续对待处理业务的初始执行模式进行优化，得到优化结果。

步骤S2022，基于所述机器周期和预设的第二设备参数，确定所述待处理业务的第二执行时延。

这里，第二设备参数可以表示数据生产端自身的属性，如，CPU频率等。任务端执行的时延包含排队时延及计算时延。每个数据生产端会维持一个本地任务缓冲队列，记数据生产端（

）处的任务队列为/>

（Task Buffer），其最大能够容纳的任务数为/>

，/>

中各个任务根据各自的/>

值排序，值越小的任务越靠近队列前端，代表其执行需求越急切。

在一些实施例中，可以采用如下公式确定排队时延：

（7）；

公式（7）中，

表示排队时延，/>

代表Local指本地执行，/>

代表Queue指排队，/>

表示/>

中排在/>

前面的任务集合，/>

表示完成待处理业务所需的CPU周期数，/>

表示数据生产端/>

为/>

分配的CPU频率。

在一些实施例中，可以采用如下公式确定计算时延：

（8）；

公式（8）中，

为/>

在/>

处的计算时延，/>

代表Computing，/>

为/>

为

分配的CPU频率，/>

表示完成待处理业务所需的CPU周期数。

最终，

在/>

处的端执行时延（也即第二执行时延）可以采用入纤公式确定：

（9）；

公式（9）中，

表示端执行时延（也即第二执行时延），/>

表示排队时延，/>

表示计算时延。

在一些实施例中，端执行过程中，其能耗由数据生产端CPU的负载量决定，CPU的负载量可以通过进行

衡量，设/>

为的端执行能耗，可以采用如下公式确定端执行过程中的能耗：

（10）；

公式（10）中，

表示端执行过程中的能耗，/>

为数据生产端/>

上每个CPU周期所消耗的能耗成本。端执行过程中的能耗/>

可以用于后续对待处理业务的初始执行模式进行优化，得到优化结果。

步骤S2023，基于所述完成时刻、所述第一执行时延和所述生成时刻，确定所述第一松弛时间。

这里，第一松弛时间可以表征为边时间约束（Edge Laxity Time，ELT），可以采用如下公式确定第一松弛时间：

（11）；

公式（11）中，

表示第一松弛时间，/>

表示完成时刻，/>

表示第一执行时延，

代表（Current Time），为计算时刻的时间值，如当前时刻至生成时刻的时间值。

步骤S2024，基于所述完成时刻、所述第二执行时延和所述生成时刻，确定所述第二松弛时间。

这里，第二松弛时间可以表征为端时间约束（Local Laxity Time，LLT），可以采用如下公式确定第二松弛时间：

（12）；

公式（12）中，

表示第二松弛时间，/>

表示完成时刻，/>

表示第二执行时延，

代表（Current Time），为计算时刻的时间值，如当前时刻至生成时刻的时间值。

本公开实施例中，通过不同类型的业务参数，可以准确地确定第一执行时延和第二执行时延，继而基于第一执行时延和第二执行时延分别快速准确地确定第一松弛时间和第二松弛时间。

本公开实施例提供一种业务执行方法，如图3所示，该方法包括如下步骤S301至步骤S307：

步骤S301，从预设服务网络中的数据生产端获取待处理业务。

步骤S302，基于所述业务参数，确定所述待处理业务的业务类型。

步骤S303，确定与所述业务类型匹配的初始执行模式。

其中，步骤S301至步骤S303分别对应于前述步骤S101至步骤S103，在实施时可以参照前述步骤S101至步骤S103的具体实施方式。

步骤S304，基于所述业务参数，构造所述待处理业务的整体优化函数。

这里，待处理业务的初始执行模式是为了初步确定待处理业务为整体执行或分割执行，其初始执行模式的确定结果是在各类执行时延等执行参数预测值的基础上获得的，并不能保证完全符合待处理业务的实际执行需求。因此，可以建立基于时延及能耗联合最小化的业务整体执行优化问题，以进一步严格筛选初始执行模式的确定结果等。如，针对业务整体执行优化问题构造整体优化函数，其中，整体优化函数用于表征待处理业务执行时延的耗时程度以及能耗的消费程度，可以采用如下公式确定整体优化函数：

（13）；

公式（13）中，

表示整体优化函数。/>

表示初始执行模式表征为整体执行的业务集合，/>

为一个具体的待处理业务/>

的标识，/>

表示/>

的整体时延，/>

表示执行/>

所需的整体能耗，/>

和/>

分别表示整体优化函数中预设的执行时延与能耗的权值，/>

、/>

分别表示/>

在边、端执行对应的执行时延，/>

、/>

分别表示在边、端执行对应的数据生产端能耗。

步骤S305，基于预设的第一约束条件，对所述整体优化函数进行处理，得到所述整体优化函数的求解结果。

这里，若

为整体优化函数的解空间（也即求解结果），/>

，其数值指示了业务整体执行的具体执行机制，/>

表示待处理业务边执行，否则业务不在边执行，

表示业务端执行，否则不在端执行，且二者最多有一个为1，故整体优化函数的解空间包含：（0, 0）、（1, 0）、（0, 1）三种解，当解为（0, 0）时，说明对应待处理业务无法在预设的第一约束条件下进行整体执行，则选择分割执行。基于此，可以建立如下优化问题，用于对整体优化函数进行求解：/>

（14）；

在对公式（14）进行求解的过程中，可以基于预设的第一约束条件进行求解。第一约束条件可以包括：

、/>

，用于约束优化问题中时延及能耗各自对应的权值，/>

、/>

可以根据不同业务属性（如侧重时延或者侧重能耗）进行调整，如对于时延敏感型业务，/>

可以适当增大值，降低/>

；/>

，用于约束在业务执行机制解空间中，/>

、/>

的取值非0即1；/>

，用于约束业务的具体执行机制，当/>

时，表明业务可以在边（数据中心）\云控制中心进行整体执行，当/>

时，表明业务无法整体执行；

，用于约束业务的实际执行时延不大于最大执行时间限制，其中：

；/>

，用于约束业务的实际执行能耗不大于数据生产端所能支持的最大能耗，/>

为数据生产端所能支持的最大能耗。

在一些实施例中，考虑到解空间

至多包含三种解，故单个业务的优化求解过程复杂度很低，采用简单的遍历解空间找到使每个业务对应的整体优化函数值最小的解，最终达到整体优化函数值最小。另外，/>

中任一业务出现/>

时，该业务也转为分割执行。

步骤S306，将所述整体优化函数的求解结果确定为所述优化结果。

这里，优化结果可以包括有解（1, 0）、（0, 1），和无解（0, 0）等。

步骤S307，在所述优化结果表征所述整体优化函数无解的情况下，确定所述待处理业务的目标执行模式为所述分割执行。

这里，当

时，表明业务无法整体执行，则确定待处理业务的目标执行模式为分割执行。

本公开实施例中，首先基于业务参数构造整体优化函数，继而通过对整体优化函数进行求解的方式，来实现对待处理业务的初始执行模式进行优化，得到待处理业务的目标执行模式。

本公开实施例提供一种业务执行方法，如图4所示，该方法包括如下步骤S401至步骤S407：

步骤S401，从预设服务网络中的数据生产端获取待处理业务。

步骤S402，基于所述业务参数，确定所述待处理业务的业务类型。

步骤S403，确定与所述业务类型匹配的初始执行模式。

步骤S404，在所述初始执行模式表征为所述整体执行的情况下，基于所述业务参数，对所述待处理业务进行优化处理，得到优化结果。

步骤S405，基于所述优化结果，确定所述待处理业务的目标执行模式。

其中，步骤S401至步骤S405分别对应于前述步骤S101至步骤S105，在实施时可以参照前述步骤S101至步骤S105的具体实施方式。

步骤S406，在所述目标执行模式为所述整体执行的情况下，从所述服务网络中确定一个目标调度对象。

这里，目标调度对象用于执行待处理业务，目标调度对象为数据生产端或数据中心；业务整体执行模式简单、易操作，主要是针对复杂度较低、实时性要求较弱的小型业务，在满足业务时延约束下，可以将业务看作不可分割的整体进行处理，整体执行模式具体分为整体边执行及整体端执行两种执行机制。例如：在确定待处理业务为第一轻载型业务的情况下，将对应的数据中心确定为目标调度对象；在确定待处理业务为第二轻载型业务的情况下，将对应的数据生产端确定为目标调度对象。

步骤S407，在所述目标执行模式或所述初始执行模式为所述分割执行的情况下，从所述服务网络中确定至少两个所述目标调度对象。

这里，分割执行模式则是针对复杂度较高的大型实时业务，这种业务若进行整体执行，不仅会因数据中心或数据生产端中服务器资源持续被占用造成其他任务堆积，而且难以满足业务的时延约束，为此，将业务分割为若干个子业务，通过多个子业务在不同执行位置的并行处理，降低服务器负荷及任务执行时延。

分割执行的业务会包含多个具有直接或间接依赖关系的子业务，本发明采用有向无环业务图（Directed Acyclic Task Graph，DATG）来描述一个被分割后的业务。具体来说，设某一业务被分割后对应的有向无环图为

，其中，/>

为图的顶点集合，即子业务集合，/>

为子业务总数，1为只有后继子业务的开始子业务（不一定唯一），/>

为只有前驱子业务的结束子业务（不一定唯一），/>

表示子业务间的依赖关系，即子业务/>

必须在子业务/>

完成后且获得的计算结果后才可执行，/>

，设

表示子业务/>

传送给子业务/>

的数据大小。

分割执行模式中的子业务执行机制又具体分为边执行及端执行两种，分别对应有不同的执行参数且满足：端执行能力

边执行能力。定义一个来自数据生产端/>

的业务

。其中，/>

表示数据生产端的生在成时刻，/>

表示完成所需的/>

周期数，/>

表示所需的输入数据大小，/>

表示的最迟完成时刻（/>

）。可以通过确定待处理业务在不同执行模式下的时延、能耗及松弛时间等执行参数的计算过程，确定满足该执行参数所表征的需求的目标调度对象。

本公开实施例中，通过确定待处理业务的目标执行模式，可以快速准确地确定与目标执行模式相匹配的一个或多个目标调度对象。

在一些实施例中，上述步骤S407可以包括如下步骤S4071至步骤S4073：

步骤S4071，在所述目标执行模式或所述初始执行模式为所述分割执行的情况下，对所述待处理业务进行分割，得到至少两个子业务。

这里，可以采用预设的分割方式对待处理业务进行分割，如，对待处理业务进行一次分割，得到第一子业务和第二子业务；对待处理业务进行二次分割，得到第一子业务、第二子业务和第三子业务。对于待处理业务的分割执行，可以采用不同分割方式进行多次分割，继而利用后续的优化处理确定最终分割得到子业务的数量等。

步骤S4072，基于每一所述子业务的业务参数，构造所述子业务的分割优化函数。

这里，若进行分割执行业务的集合为

。以来自数据生产端/>

的业务

为例，建立其被分割后的有向无环图/>

，设

为/>

的一个子业务/>

，其中/>

、/>

分别为子业务/>

的需求数据从数据生产端传输到执行位置的开始时间和结束时间；/>

、/>

分别表示子业务/>

在其执行位置的执行开始时间和执行结束时间；/>

表示子业务/>

执行所需的数据量

占/>

总数据量的比例，有/>

；/>

表示子业务/>

执行所需的计算量/>

占/>

总计算量的比例，有/>

。

对于

的任一子业务来说，其执行机制包含边、端执行两种，/>

表示/>

子业务执行机制集合，满足：/>

，且/>

执行过程中/>

不变（即/>

的边缘动态服务组不会改变）。设/>

表示/>

中子业务/>

的执行机制指示量，/>

表示子业务/>

端执行，/>

表示子业务/>

边执行，其中/>

的具体数值代表其对应的边缘动态服务组中的数据中心标识。/>

的所有子业务拥有相同的执行机制集合/>

。

在一些实施例中，可以采用如下公式确定分割执行时的数据上传时延：

（15）；

公式（15）中，

表示分割执行时的数据上传时延，/>

表示子业务/>

执行所需的数据量，当/>

时，/>

为数据生产端到数据中心的平均数据率；当/>

时，数据生产端执行无需上传数据。

在一些实施例中，可以采用如下公式确定分割执行时的排队时延：

（16）；

公式（16）中，

表示分割执行时的排队时延，/>

为/>

处的业务执行频率，/>

为的业务队列/>

中排在子业务/>

前面的任务集合，/>

为处的VM处理器个数，当/>

时，/>

。

在一些实施例中，可以采用如下公式确定分割执行时的计算时延：

（17）；

公式（17）中，

表示分割执行时的计算时延，/>

为/>

处的业务执行频率，/>

表示子业务/>

执行所需的计算量。

在一些实施例中，可以采用如下公式确定分割执行时的子任务间数据传递时延：

（18）；

公式（18）中，对于

，/>

表示分割执行时的子任务间数据传递时延，

表示子业务/>

执行所需的数据量。/>

表示子业务/>

执行位置与子业务/>

执行位置之间的数据率。

在一些实施例中，当业务整体执行模式无法满足时延约束时，其才会被调度为分割执行，因此，可以在设计业务分割执行优化过程中考虑以牺牲数据生产端能耗为代价来最小化整个业务的完成时间，从而尽可能满足业务的时延约束，保证业务顺利执行。针对业务分割执行优化问题构造分割优化函数，其中，分割优化函数用于表征子业务执行时延的耗时程度，对于

，可以建立如下优化问题，用于对分割优化函数进行求解：

（19）；

公式（19）中，

表示在分割执行使得执行时延。

步骤S4073，基于预设的第二约束条件，对所述分割优化函数进行处理，得到每一所述子业务所对应的目标调度对象。

这里，第二约束条件可以包括：

，用于约束任一子业务数据量与计算量不超过总业务的数据量与计算量；/>

用于约束所有子业务数据量与计算量之和等总业务的数据量与计算量；/>

、/>

用于约束任一子业务开始传输数据及开始执行时间均非负；/>

用于约束子业务数据传输完成才可进行执行；/>

用于约束子业务的执行不能被打断，即执行过程保持原子性；

用于约束子业务数据的传输过程不可被打断；

用于约束具有依赖关系的子业务之间的执行过程；/>

用于约束执行位置相同的两个子业务不可同时进行数据传输，但需要注意的是若两个业务完全互相独立（没有直接或间接依赖关系），可以并行在不同的VM上执行；/>

用于约束所有子业务的最大完成时间不超过业务的最大执行时间约束；/>

用于约束数据生产端总能耗不能高于其最大能耗供应，其中/>

为执行子业务/>

的数据生产端能耗等。

通过预设的第二约束，在使得分割优化函数的函数值最小的情况下，区域确定每一子业务对应的目标调度对象，如，第一子业务由第一数据生产端执行，第二子业务由第一数据中心执行，第三子业务由第二数据中心执行等。

本公开实施例中，通过构建分割优化函数，继而基于第二约束条件可以快速准确地确定每一子业务对应的目标调度对象。

在一些实施例中，上述步骤S4073可以包括如下步骤S411至步骤S414：

步骤S411，基于所述第二约束条件，确定所述子业务对应的有向无环图。

这里，可以将分割优化函数的优化问题转换为多子业务到多执行机制（边/端）的调度问题，以期望为每个子业务求得最佳执行机制，并达到业务执行时延最短。列表调度是基于DATG的经典调度算法之一，其过程一般分为：业务优先级计算和处理器选择两个步骤。传统的列表调度算法如（Modified Critical Path，MCP）、（Earliest Task First，ETF）、（Heterogenous Earliest Finish Time，HEFT）等在进行业务优先级计算时，往往更看重业务之间的依赖关系及业务图的关键路径等参数，并在调度过程中采用静态调度，其忽略了相互独立子业务之间的可并行性且缺乏灵活性，易造成***资源浪费。

步骤S411可以包括：按照预设的第二约束条件，对待处理业务进行分割，得到多个子业务，且子业务之间存在依赖关系等，如，首先，需要处理第一子业务和第二子业务；然后，需要处理第三子业务、第四子业务和第五子业务；其次，需要处理第六子业务和第七子业务等；基于该依赖关系确定所有子业务所对应的有向无环图。

步骤S412，基于所述有向无环图，确定每一所述子业务的优先级。

这里，记

中子业务/>

的前驱子业务集合为/>

，后继子业务集合为/>

，优先级为/>

，开始子业务的优先级为0（最高），从开始子业务出发，可以采用如下公式确定每个子业务优先级：

（20）；

例如：

；/>

；

；/>

；

；/>

；

；

等。在一些实施例中，可以发现具有相同优先级的子业务之间相互独立，因此可以基于优先级数值对整个DATG中子业务进行分层，同层子业务可进行并行调度。

步骤S413，基于所述优先级，确定所述子业务所对应的动态调度列表。

这里，为提高子业务执行调度过程的灵活性并实现最大并行调度，可以利用动态调度列表（Dynamic Scheduler Listing，DSL）实现调度过程的动态化。DSL中仅包含无前驱业务或所有前驱业务已完成的子业务，初始时DSL中包含DATG中的所有开始子业务，每完成一个子业务，查看位于其下一层是否有满足条件（无前驱业务或所有前驱业务已完成）的后继子业务可以加入到DSL中，进行DSL的动态更新，DSL中子业务并行调度过程主要是在优化问题指导下，为每个子业务选择执行机制集合中能够为其提供最短执行时间的执行机制。例如：确定所有子业务的优先级，将优先级最高的子业务导入动态调度列表，继而确定动态调度列表中的子业务的目标调度对象。

步骤S414，基于所述动态调度列表，确定每一所述子业务所对应的目标调度对象。

这里，可以先确定当前的动态调度列表中的子业务的目标调度对象，在动态调度列表中的所有子业务的目标调度对象确定完成后，删除当前的动态调度列表中的子业务，并将优先级次高的子业务导入动态调度列表，完成动态调度列表的更新，继而确定更新后的动态调度列表中的子业务的目标调度对象。

在一些实施例中，子业务DSL生成及执行机制调度过程包括：计算DATG中每个子业务的优先级，DSL为空，获得子业务执行机制集合

；优先级为0的子业务s₁和s₂加入DSL，进行并行调度；当优先级为0的任意一个子业务（s₁或s₂）完成后，从DSL中删除该业务并查看是否有对应的优先级为1的后继子业务满足加入DSL的条件，若有，更新DSL，继续并行调度DSL中子业务；当优先级为1的某一子业务（s₃或s₄或s₅）完成后，从DSL中删除该业务并查看是否有对应的优先级为2的后继子业务满足加入DSL的条件，若有，更新DSL，继续并行调度DSL中子业务；当优先级为2的某一子业务（s₆或s₇）完成后，从DSL中删除该业务并查看是否有对应的优先级为3的后继子业务满足加入DSL的条件，若有，更新DSL，继续并行调度DSL中子业务；当优先级为3的子业务s₈完成后，从DSL中删除该任务并查看优先级为4的后继子业务s₉是否满足加入DSL的条件，若是，更新DSL，继续并行调度DSL中子业务，否则继续等待直至s₉可调度；最后，结束调度。

需要说明的是上述过程按照优先级降序（优先级数值越小，优先级越高）进行了明确的执行顺序定义，但在实际过程中，各个执行步骤将不一定按照严格顺序依次执行，基于实际参数各个步骤之间是可以跳转执行的。例如：考虑如下情况，在s₂及s₅完成时，s₁才刚完成，此时具有不同优先级的s₃、s₄及s₇将分别利用第二步骤及第三步骤操作同时进入DSL。

本公开实施例中，通过确定动态调度列表，可以快速准确地确定每一子业务的目标调度对象。

在一些实施例中，上述步骤S413可以包括如下步骤S421至步骤S422：

步骤S421，获取所述优先级最高的子业务。

例如：第一子业务的优先级为0.9，第二子业务的优先级为0.6，第三子业务的优先级为0.5，那么确定第一子业务的优先级最高。

步骤S422，基于所述优先级最高的子业务，生成所述动态调度列表。

例如：在第一子业务的优先级最高的情况下，将第一子业务导入动态调度列表。

在一些实施例中，上述步骤S414可以包括如下步骤S423至步骤S424：

步骤S423，确定所述动态调度列表中的子业务的执行模式为所述整体执行。

这里，对于分割后得到的多个子业务，动态调度列表中的每一个子业务的执行模式为整体执行。

步骤S424，在所述动态调度列表中的子业务的执行模式为所述整体执行的情况下，确定所述动态调度列表中的子业务所对应的目标调度对象。

这里，利用整体优化函数，确定每一子业务所对应的目标调度对象。

本公开实施例中，通过优先级最高的子业务，可以快速准确地确定动态调度列表，并实现动态调度列表的更新，继而确定每一子业务的目标调度对象。

在一些实施例中，上述步骤S412之后还可以包括如下步骤S431至步骤S432：

步骤S431，在存在所述优先级相等的至少两个同级子业务的情况下，分别确定每一所述同级子业务所对应的目标调度对象。

例如：第一子业务的优先级等于第二子业务的优先级，则第一子业务和第二子业务为同级子业务，那么可以同时确定第一子业务对应的第一目标调度对象，以及第二子业务对应的第二目标调度对象。

步骤S432，采用并行执行的方式，基于每一所述同级子业务所对应的目标调度对象对所有所述同级子业务进行处理。

例如：可以利用第一目标调度对象和第二目标调度对象，分别同时处理第一子业务和第二子业务。

本公开实施例中，通过对同级子业务进行并行调度处理，可以提高待处理业务的执行效率。

在一些实施例中，上述步骤S424之后还可以包括如下步骤S441至步骤S442：

步骤S441，在所述动态调度列表中的子业务处理完成的情况下，获取下一优先级的子业务。

例如：动态调度列表中的第一子业务和第二子业务执行完成后，获取优先级次于第一子业务和第二子业务的第三子业务和第四子业务等。

步骤S442，基于所述下一优先级的子业务，对所述动态调度列表进行更新，得到更新后的动态调度列表。

这里，更新后的动态调度列表用于确定所述下一优先级的子业务所对应的目标调度对象。例如：确定优先级次于第一子业务和第二子业务的子业务为第三子业务和第四子业务，删除动态调度列表中的第一子业务和第二子业务，将第三子业务和第四子业务导入动态调度列表，实现动态调度列表的更新。

本公开实施例中，通过对动态调度列表的更新，可以遍历所有子业务，快速准确地确定每一子业务的目标调度对象。

下面说明本公开实施例提供的业务执行方法在实际场景中的应用，以为海量生产数据计算任务提供多数据中心分布式跨域协同执行的场景为例进行说明。相关技术中的业务调度方式通常仅考虑时延和能耗问题，且业务执行机制仅考虑单一数据中心整体执行，忽略了对差异化终端业务的个性化调度方案设计。因此，面向海量终端差异化的业务应用需求，如何为数据生产端超负荷的采集与分析任务选择最佳的多数据中心协作执行方式是分布式跨域协同计算的关键问题。

例如：相关技术中，在满足任务时延需求前提下，以李雅普诺夫漂移函数与惩罚函数之和最小化为目标建立边云协同下的任务调度技术，并考虑均衡***能耗及稳定性；或者，以保障边云负载比均衡度为目标进行多任务调度，利用各节点的资源剩余可用量计算得分后，建立调度策略分界线获取决策；或者，根据服务器及任务参数的双边匹配构造满意度函数，从而结合价格博弈方法进行任务定价以指导卸载决策。上述相关技术中的技术方案均在边云协同场景下对任务执行过程提出了不同的优化方法，但未实现跨数据中心背景下，数据中心-数据生产端对多异构任务的分割设计和并行调度的方案。

本公开实施例中，基于如下多个方面：1）任务属性及需求差异。不同属性任务对数据中心协作的资源需求及通信能力具有不同要求，任务执行过程要充分考虑上述差异化需求来提高服务质量。2）数据中心间的负载均衡。应尽可能规避业务执行调度的局部性弊端，从全局视角出发，实现业务数据在多个数据中心中的均衡分布，平衡全网负载。3）子业务间并行调度。面向多个具有依赖关系的子业务执行过程，应设计合理的任务优先级计算及并行调度机制，降低业务总体执行时延。提出了一种基于多种业务属性的分布式跨域协同执行策略，该策略面向网络中海量异构业务属性与需求，提出整体执行与分割执行两种业务执行模式及边执行与端执行两种任务执行机制，并基于松弛时间对用户业务进行建模，对于整体执行的业务建立时延及能耗联合优化的目标，对于分割执行的业务，设计基于动态列表调度的子业务并行执行优化，同时考虑边缘负载均衡问题，提高网络中业务执行效率与服务质量；有助于实现根据业务属性与资源供应为不同业务确定其较优的执行模式与执行机制，以及实现计算子业务优先级并实现并行调度过程。

如图5所示，本公开实施例中的服务网络的网络架构中可以包括：云控制中心501、数据中心集群502以及多个数据生产端503、数据中心集群502可以包括第一数据中心5021和第二数据中心5022等。远端云控制中心利用多跳有线或无线链路与数据中心进行通信；数据中心之间通过不同数据通信执行全局业务协同处理过程，同时为局部的数据生产端分担超负荷计算任务；数据生产端负责数据源的ETL、校验、标准化等计算任务，数据中心与多个数据生产端连接，但受硬件、软件及能量供应等因素影响，相较于数据中心，数据生产端的业务处理及数据存储能力有限，无法保障任务的及时性。

本公开实施例中，针对边执行机制考虑数据中心之间的负载均衡问题，引入边缘动态服务组（Edge Dynamic Server Group，EDSG）的概念，如图6所示，数据中心集群包括多个EDSG，如，第一边缘动态服务组601、第二边缘动态服务组602和第三边缘动态服务组603等。从数据中心角度来说，每个数据中心会与其相邻的数据中心组成一个EDSG，服务组成员相互协作执行业务，并定期交换各自信息（可用服务能力、负载比例、链路状态、任务队列状态等）。另外，每个EDSG会随着网络条件及需求动态变化（但在一个数据生产端任务执行期间其对应的EDSG暂时不会改变），不同EDSG可能会发生成员重叠。

从数据生产端角度来说，将EDSG中与其直接相连的数据中心确定为主边缘（Master Edge，ME），EDSG中其他的数据中心称为辅助边缘（Assistant Edge，AE）。例如：对于第三数据生产端（UE3）来说，边缘数据中心2（Edge Data Center，EDC）为ME，EDC2所在的EDSG1和EDSG2里面的其它数据中心均为AE。业务边执行时首先会向ME发送卸载消息；其中，卸载消息包括待处理业务的初始位置信等息；ME则结合自身掌握的EDSG成员的信息参数来决定业务的实际边执行位置，以尽量降低业务的执行时延并保持EDSG内负载均衡，具体执行规则如下：

a）对于数据需求较大的业务，ME优先选择EDSG成员中与任务之间具有最优链路状态的数据中心执行任务；

b）对于算力需求较大的业务，ME优先选择EDSG成员中可用服务能力最强的数据中心执行任务；

c）当同一EDSG中同时有多个业务需要进行边执行时，实时性较强的任务优先；

d）非上述三种类型的普通业务，ME优先选择EDSG成员中负载比例最低的数据中心执行任务；

其中，业务的数据、算力需求大小及实时性强弱，可分别根据当前EDSG中平均链路状态、平均处理能力及任务类型、约束等参数进行预判断。例如：若一个业务以EDSG中平均链路速率进行数据上传出现超时现象，则其为数据需求较大型业务。

本公开实施例提供一种业务执行方法，如图7所示，该方法包括如下步骤S701至步骤S713：

步骤S701，获取待处理业务的业务参数。

这里，云控制中心可以对待处理业务进行解析，得到待处理业务的业务参数。

步骤S702，基于业务参数，确定待处理业务的松弛时间，并确定与松弛时间相匹配的业务类型。

这里，松弛时间可以包括针对数据中心的第一松弛时间和针对数据生产端的第二松弛时间；在第一松弛时间大于或等于零的情况下，确定待处理业务为第一轻载型业务，否则为第一重载型业务；在第二松弛时间大于或等于零的情况下，确定待处理业务为第二轻载型业务，否则为第二重载型业务等。

步骤S703，确定待处理业务是否为第一轻载型业务或第二轻载型业务。

这里，若待处理业务为第一轻载型业务，或第二轻载型业务，那么进入步骤S704，进行初始执行模式的优化处理；否则，进入步骤S709，进行待处理业务的分割执行处理等。

步骤S704，确定待处理业务的初始执行模式为整体执行。

这里，若待处理业务为第一轻载型业务，或第二轻载型业务，确定待处理业务的初始执行模式为整体执行。

步骤S705，基于业务参数，对待处理业务的初始执行模式进行优化处理，得到优化结果。

这里，可以基于业务参数，构造待处理业务的整体优化函数；其中，整体优化函数用于表征待处理业务执行时延的耗时程度以及能耗的消费程度；基于预设的第一约束条件，对整体优化函数进行处理，得到整体优化函数的求解结果；将整体优化函数的求解结果确定为优化结果。

步骤S706，确定优化结果所表征的求解结果是否有解。

这里，整体优化函数的求解结果可以包括（1, 0）、（0, 1）、（0, 0）将（1, 0）和（0,1）确定为有解，将（0, 0）确定为无解；如有解，则进入步骤S707或步骤S708；否则，进入步骤S709。

步骤S707，在优化结果所表征的求解结果为（1, 0）的情况下，确定待处理业务的目标调度对象为数据中心。

这里，求解结果为（1, 0）表征待处理业务由数据中心进行整体执行（也即整体边执行）。

步骤S708，在优化结果所表征的求解结果为（0, 1）的情况下，确定待处理业务的目标调度对象为数据生产端。

这里，求解结果为（0, 1）表征待处理业务由数据生产端进行整体执行（也即整体端执行）。

步骤S709，确定待处理业务的初始执行模式为分割执行。

这里，若确定待处理业务为第一重载型业务和第二重载型业务。

步骤S710，确定待处理业务的所有子业务对应的有向无环图。

这里，如图8所示，第一子业务801和第二子业务802的优先级相等，且最高，属于第一优先层级；第三子业务803、第四子业务804、第五子业务805的优先级次之，属于第二优先层级；第六子业务806和第七子业务807的优先级属于第三优先层级；第八子业务808的优先级属于第四层级；第九子业务809的优先级属于第五层级等。

步骤S711，基于有向无环图，确定每一子业务的优先级。

这里，可以采用公式（20）所述的方式，确定每一子业务的优先级。

步骤S712，基于每一子业务的优先级，生成待处理业务的动态调度列表。

这里，可以先将优先级属于第一层级的第一子业务和第二子业务导入动态调度列表。

步骤S713，基于待处理业务的动态调度列表，确定每一子业务的目标调度对象。

这里，可以先确定动态调度列表中的第一子业务和第二子业务所对应的第一目标调度对象和第二目标调度对象；继而惯性动态调度列表，依次确定每一子业务的目标调度对象。

本公开实施例中，可以为不同业务属性的计算任务设计多种执行模式和执行方式，可主动判别业务需求灵活选择整体执行或分割执行，并提供边端协同执行机制；这样，有助于快速为数据生产端的超负荷的采集、分析任务灵活分配多数据中心资源，能够有效保证数据生产端任务成功率，提升数据生产端任务执行效率，降低计算任务平均执行时延等。

例如：数据生产端面临属性与需求各异的海量计算业务，不同数据业务往往对数据量、存储及计算能力有不同要求，本本公开实施例建立基于松弛时间的业务模型，提出业务初级执行模式调度方法，为不同业务属性的计算任务设计多种执行模式和执行方式，可主动判别业务需求灵活选择整体执行或分割执行，并分别为不同执行模式建立优化目标及求解过程，提升数据生产端异构计算任务执行效率，降低计算任务时延和能耗；以及针对数据生产端的部分复杂业务，任务整体执行模式难以满足业务质量需求，本本公开实施例除业务整体执行模式外，还支持业务分割执行模式，提出基于DATG图的子业务分割方法，将数据生产端业务分割执行模式下存在依赖关系的多个子业务进行并行调度，并基于改进传统的静态列表调度DSL方法，设计子业务优先级计算方式，将子业务调度至多个边缘数据中心或数据生产端，并实现子业务间的并行执行，从而最大程度地降低业务的整体执行时延，满足业务质量需求。

基于前述的实施例，本公开实施例提供一种业务执行装置，该装置包括所包括的各单元、以及各单元所包括的各模块，可以通过计算机设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器（CPU）、微处理器（Microprocessor Unit，MPU）、数字信号处理器（Digital Signal Processor，DSP）或现场可编程门阵列（Field Programmable Gate Array，FPGA）等。

图9为本公开实施例提供的一种业务执行装置的组成结构示意图，如图9所示，业务执行装置900包括：第一获取模块910、第一确定模块920、第二确定模块930、第一处理模块940和第三确定模块950，其中：

第一获取模块910，用于从预设服务网络中的数据生产端获取待处理业务；其中，所述服务网络包括数据中心集群和至少两个所述数据生产端，所述待处理业务携带业务参数；第一确定模块920，用于基于所述业务参数，确定所述待处理业务的业务类型；第二确定模块930，用于确定与所述业务类型匹配的初始执行模式；其中，所述待处理业务的执行模式包括整体执行和分割执行，所述整体执行表征所述待处理业务由所述数据中心集群中的一个数据中心或一个所述数据生产端执行，所述分割执行表征所述待处理业务由至少两个所述数据中心和\或所述数据生产端执行；第一处理模块940，用于在所述初始执行模式表征为所述整体执行的情况下，基于所述业务参数，对所述待处理业务进行优化处理，得到优化结果；第三确定模块950，用于基于所述优化结果，确定所述待处理业务的目标执行模式。

在一些实施例中，所述待处理业务的业务类型包括：第一轻载型业务、第一重载型业务、第二轻载型业务和第二重载型业务；所述第一确定模块，还用于：基于所述业务参数，分别确定所述数据中心的针对所述待处理业务的第一松弛时间和所述数据生产端针对所述待处理业务的第二松弛时间；在所述第一松弛时间大于或等于零的情况下，确定所述待处理业务为所述第一轻载型业务；在所述第一松弛时间小于零的情况下，确定所述待处理业务为所述第一重载型业务；在所述第二松弛时间大于或等于零的情况下，确定所述待处理业务为所述第二轻载型业务；在所述第二松弛时间小于零的情况下，确定所述待处理业务为所述第二重载型业务。

在一些实施例中，所述业务参数包括：生成时刻、机器周期、输入数据量和完成时刻；所述第一确定模块，还用于：基于所述机器周期、所述输入数据量和预设的第一设备参数，确定所述待处理业务的第一执行时延；基于所述机器周期和预设的第二设备参数，确定所述待处理业务的第二执行时延；基于所述完成时刻、所述第一执行时延和所述生成时刻，确定所述第一松弛时间；基于所述完成时刻、所述第二执行时延和所述生成时刻，确定所述第二松弛时间。

在一些实施例中，所述第二确定模块，还用于：在所述业务类型为第一轻载型业务或第二轻载型业务的情况下，确定所述待处理业务的初始执行模式为所述整体执行；在所述业务类型为第一重载型业务和第二重载型业务的情况下，确定所述待处理业务的初始执行模式为所述分割执行。

在一些实施例中，所述第一处理模块，还用于：基于所述业务参数，构造所述待处理业务的整体优化函数；其中，所述整体优化函数用于表征所述待处理业务执行时延的耗时程度以及能耗的消费程度；基于预设的第一约束条件，对所述整体优化函数进行处理，得到所述整体优化函数的求解结果；将所述整体优化函数的求解结果确定为所述优化结果；所述第三确定模块，还用于：在所述优化结果表征所述整体优化函数无解的情况下，确定所述待处理业务的目标执行模式为所述分割执行。

在一些实施例中，所述装置还包括：第四确定模块，用于在所述目标执行模式为所述整体执行的情况下，从所述服务网络中确定一个目标调度对象；其中，所述目标调度对象用于执行所述待处理业务，所述目标调度对象为所述数据生产端或所述数据中心；第五确定模块，用于在所述目标执行模式或所述初始执行模式为所述分割执行的情况下，从所述服务网络中确定至少两个所述目标调度对象。

在一些实施例中，所述第五确定模块，还用于：在所述目标执行模式或所述初始执行模式为所述分割执行的情况下，对所述待处理业务进行分割，得到至少两个子业务；基于每一所述子业务的业务参数，构造所述子业务的分割优化函数；其中，所述分割优化函数用于表征所述子业务执行时延的耗时程度；基于预设的第二约束条件，对所述分割优化函数进行处理，得到每一所述子业务所对应的目标调度对象。

在一些实施例中，所述第五确定模块，还用于：基于所述第二约束条件，确定所述子业务对应的有向无环图；基于所述有向无环图，确定每一所述子业务的优先级；基于所述优先级，确定所述子业务所对应的动态调度列表；基于所述动态调度列表，确定每一所述子业务所对应的目标调度对象。

在一些实施例中，所述第五确定模块，还用于：获取所述优先级最高的子业务；基于所述优先级最高的子业务，生成所述动态调度列表；所述第五确定模块，还用于：确定所述动态调度列表中的子业务的执行模式为所述整体执行；在所述动态调度列表中的子业务的执行模式为所述整体执行的情况下，确定所述动态调度列表中的子业务所对应的目标调度对象。

在一些实施例中，所述装置还包括：第六确定模块，用于在存在所述优先级相等的至少两个同级子业务的情况下，分别确定每一所述同级子业务所对应的目标调度对象；第二处理模块，用于采用并行执行的方式，基于每一所述同级子业务所对应的目标调度对象对所有所述同级子业务进行处理。

在一些实施例中，所述装置还包括：第二获取模块，用于在所述动态调度列表中的子业务处理完成的情况下，获取下一优先级的子业务；更新模块，用于基于所述下一优先级的子业务，对所述动态调度列表进行更新，得到更新后的动态调度列表；其中，所述更新后的动态调度列表用于确定所述下一优先级的子业务所对应的目标调度对象。

以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。在一些实施例中，本公开实施例提供的装置具有的功能或包含的模块可以用于执行上述方法实施例描述的方法，对于本公开装置实施例中未披露的技术细节，请参照本公开方法实施例的描述而理解。

需要说明的是，本公开实施例中，如果以软件功能模块的形式实现上述的业务执行方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本公开实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机、服务器、或者网络设备等）执行本公开各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器（Read OnlyMemory，ROM）、磁碟或者光盘等各种可以存储程序代码的介质。这样，本公开实施例不限制于任何特定的硬件、软件或固件，或者硬件、软件、固件三者之间的任意结合。

本公开实施例提供一种计算机设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法中的部分或全部步骤。

本公开实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述方法中的部分或全部步骤。所述计算机可读存储介质可以是瞬时性的，也可以是非瞬时性的。

本公开实施例提供一种计算机程序，包括计算机可读代码，在所述计算机可读代码在计算机设备中运行的情况下，所述计算机设备中的处理器执行用于实现上述方法中的部分或全部步骤。

本公开实施例提供一种计算机程序产品，所述计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，所述计算机程序被计算机读取并执行时，实现上述方法中的部分或全部步骤。该计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一些实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一些实施例中，计算机程序产品具体体现为软件产品，例如软件开发包（Software Development Kit，SDK）等等。

这里需要指出的是：上文对各个实施例的描述倾向于强调各个实施例之间的不同之处，其相同或相似之处可以互相参考。以上设备、存储介质、计算机程序及计算机程序产品实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本公开设备、存储介质、计算机程序及计算机程序产品实施例中未披露的技术细节，请参照本公开方法实施例的描述而理解。

需要说明的是，图10为本公开实施例中计算机设备的一种硬件实体示意图，如图10所示，该计算机设备1000的硬件实体包括：处理器1001、通信接口1002和存储器1003，其中：

处理器1001通常控制计算机设备1000的总体操作。

通信接口1002可以使计算机设备通过网络与其他终端或服务器通信。

存储器1003配置为存储由处理器1001可执行的指令和应用，还可以缓存待处理器1001以及计算机设备1000中各模块待处理或已经处理的数据（例如，图像数据、音频数据、语音通信数据和视频通信数据），可以通过闪存（FLASH）或随机访问存储器（Random AccessMemory，RAM）实现。处理器1001、通信接口1002和存储器1003之间可以通过总线1004进行数据传输。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本公开的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本公开的各种实施例中，上述各步骤/过程的序号的大小并不意味着执行顺序的先后，各步骤/过程的执行顺序应以其功能和内在逻辑确定，而不应对本公开实施例的实施过程构成任何限定。上述本公开实施例序号仅仅为了描述，不代表实施例的优劣。

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

在本公开所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个***，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本公开各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器（Read Only Memory，ROM）、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本公开上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机、服务器、或者网络设备等）执行本公开各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

本公开所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

若本公开实施例涉及个人信息，应用本公开实施例的产品在处理个人信息前，已明确告知个人信息处理规则，并取得个人自主同意。若本公开实施例涉及敏感个人信息，应用本公开实施例的产品在处理敏感个人信息前，已取得个人单独同意，并且同时满足“明示同意”的要求。

以上所述，仅为本公开的实施方式，但本公开的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本公开的保护范围之内。

Claims (14)

1.一种业务执行方法，其特征在于，包括：

从预设服务网络中的数据生产端获取待处理业务；其中，所述服务网络包括数据中心集群和至少两个所述数据生产端，所述待处理业务携带业务参数；

基于所述业务参数，确定所述待处理业务的业务类型；

确定与所述业务类型匹配的初始执行模式；其中，所述待处理业务的执行模式包括整体执行和分割执行，所述整体执行表征所述待处理业务由所述数据中心集群中的一个数据中心或一个所述数据生产端执行，所述分割执行表征所述待处理业务由至少两个所述数据中心和或所述数据生产端执行；

在所述初始执行模式表征为所述整体执行的情况下，基于所述业务参数，对所述待处理业务进行优化处理，得到优化结果；

基于所述优化结果，确定所述待处理业务的目标执行模式。

2.根据权利要求1所述的方法，其特征在于，所述待处理业务的业务类型包括：第一轻载型业务、第一重载型业务、第二轻载型业务和第二重载型业务；所述基于所述业务参数，确定所述待处理业务的业务类型，包括：

基于所述业务参数，分别确定所述数据中心的针对所述待处理业务的第一松弛时间和所述数据生产端针对所述待处理业务的第二松弛时间；

在所述第一松弛时间大于或等于零的情况下，确定所述待处理业务为所述第一轻载型业务；

在所述第一松弛时间小于零的情况下，确定所述待处理业务为所述第一重载型业务；

在所述第二松弛时间大于或等于零的情况下，确定所述待处理业务为所述第二轻载型业务；

在所述第二松弛时间小于零的情况下，确定所述待处理业务为所述第二重载型业务。

3.根据权利要求2所述的方法，其特征在于，所述业务参数包括：生成时刻、机器周期、输入数据量和完成时刻；所述基于所述业务参数，分别确定所述数据中心的针对所述待处理业务的第一松弛时间和所述数据生产端针对所述待处理业务的第二松弛时间，包括：

基于所述机器周期、所述输入数据量和预设的第一设备参数，确定所述待处理业务的第一执行时延；

基于所述机器周期和预设的第二设备参数，确定所述待处理业务的第二执行时延；

基于所述完成时刻、所述第一执行时延和所述生成时刻，确定所述第一松弛时间；

基于所述完成时刻、所述第二执行时延和所述生成时刻，确定所述第二松弛时间。

4.根据权利要求1所述的方法，其特征在于，所述确定与所述业务类型匹配的初始执行模式，包括：

在所述业务类型为第一轻载型业务或第二轻载型业务的情况下，确定所述待处理业务的初始执行模式为所述整体执行；

在所述业务类型为第一重载型业务和第二重载型业务的情况下，确定所述待处理业务的初始执行模式为所述分割执行。

5.根据权利要求1所述的方法，其特征在于，所述在所述初始执行模式表征为所述整体执行的情况下，基于所述业务参数，对所述待处理业务进行优化处理，得到优化结果，包括：

基于所述业务参数，构造所述待处理业务的整体优化函数；其中，所述整体优化函数用于表征所述待处理业务执行时延的耗时程度以及能耗的消费程度；

基于预设的第一约束条件，对所述整体优化函数进行处理，得到所述整体优化函数的求解结果；

将所述整体优化函数的求解结果确定为所述优化结果；

所述基于所述优化结果，确定所述待处理业务的目标执行模式，包括：

在所述优化结果表征所述整体优化函数无解的情况下，确定所述待处理业务的目标执行模式为所述分割执行。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在所述目标执行模式为所述整体执行的情况下，从所述服务网络中确定一个目标调度对象；其中，所述目标调度对象用于执行所述待处理业务，所述目标调度对象为所述数据生产端或所述数据中心；

在所述目标执行模式或所述初始执行模式为所述分割执行的情况下，从所述服务网络中确定至少两个所述目标调度对象。

7.根据权利要求6所述的方法，其特征在于，所述在所述目标执行模式或所述初始执行模式为所述分割执行的情况下，从所述服务网络中确定至少两个所述目标调度对象，包括：

在所述目标执行模式或所述初始执行模式为所述分割执行的情况下，对所述待处理业务进行分割，得到至少两个子业务；

基于每一所述子业务的业务参数，构造所述子业务的分割优化函数；其中，所述分割优化函数用于表征所述子业务执行时延的耗时程度；

基于预设的第二约束条件，对所述分割优化函数进行处理，得到每一所述子业务所对应的目标调度对象。

8.根据权利要求7所述的方法，其特征在于，所述基于预设的第二约束条件，对所述分割优化函数进行处理，得到每一所述子业务所对应的目标调度对象，包括：

基于所述第二约束条件，确定所述子业务对应的有向无环图；

基于所述有向无环图，确定每一所述子业务的优先级；

基于所述优先级，确定所述子业务所对应的动态调度列表；

基于所述动态调度列表，确定每一所述子业务所对应的目标调度对象。

9.根据权利要求8所述的方法，其特征在于，所述基于所述优先级，确定所述子业务所对应的动态调度列表，包括：

获取所述优先级最高的子业务；

基于所述优先级最高的子业务，生成所述动态调度列表；

所述基于所述动态调度列表，确定每一所述子业务所对应的目标调度对象，包括：

确定所述动态调度列表中的子业务的执行模式为所述整体执行；

在所述动态调度列表中的子业务的执行模式为所述整体执行的情况下，确定所述动态调度列表中的子业务所对应的目标调度对象。

10.根据权利要求9所述的方法，其特征在于，所述方法还包括：

在存在所述优先级相等的至少两个同级子业务的情况下，分别确定每一所述同级子业务所对应的目标调度对象；

采用并行执行的方式，基于每一所述同级子业务所对应的目标调度对象对所有所述同级子业务进行处理。

11.根据权利要求9所述的方法，其特征在于，所述方法还包括：

在所述动态调度列表中的子业务处理完成的情况下，获取下一优先级的子业务；

基于所述下一优先级的子业务，对所述动态调度列表进行更新，得到更新后的动态调度列表；其中，所述更新后的动态调度列表用于确定所述下一优先级的子业务所对应的目标调度对象。

12.一种业务执行装置，其特征在于，包括：

第一获取模块，用于从预设服务网络中的数据生产端获取待处理业务；其中，所述服务网络包括数据中心集群和至少两个所述数据生产端，所述待处理业务携带业务参数；

第一确定模块，用于基于所述业务参数，确定所述待处理业务的业务类型；

第二确定模块，用于确定与所述业务类型匹配的初始执行模式；其中，所述待处理业务的执行模式包括整体执行和分割执行，所述整体执行表征所述待处理业务由所述数据中心集群中的一个数据中心或一个所述数据生产端执行，所述分割执行表征所述待处理业务由至少两个所述数据中心和或所述数据生产端执行；

第一处理模块，用于在所述初始执行模式表征为所述整体执行的情况下，基于所述业务参数，对所述待处理业务进行优化处理，得到优化结果；

第三确定模块，用于基于所述优化结果，确定所述待处理业务的目标执行模式。

13.一种计算机设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至11任一项所述方法中的步骤。

14.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至11任一项所述方法中的步骤。

Images