CN115794335A - 算力网络任务调度引擎方法及装置 - Google Patents

Abstract

本发明提供一种算力网络任务调度引擎方法及装置，该方法包括：获取待部署微服务、部署算法、待部署微服务需求以及各集群信息，基于待部署微服务需求以及各集群信息筛选与待部署微服务匹配的第一集群集合；基于第一集群集合和部署算法确定部署策略，部署策略包括副本的数量以及部署集群的名称，部署集群属于第一集群集合，基于部署策略对待部署微服务进行部署；获取待调度任务、调度算法以及待调度任务需求，基于待调度任务需求从部署集群集合中筛选第二集群集合；基于第二集群集合和调度算法确定调度策略，调度策略包括调度集群的名称和各调度集群对应的任务请求数量，调度集群属于第二集群集合，基于调度策略对待调度任务请求进行调度。

Description

算力网络任务调度引擎方法及装置

技术领域

本发明涉及互联网技术领域，尤其涉及一种算力网络任务调度引擎方法及装置。

背景技术

随着互联网进入下半场逐渐由消费型应用向生产型应用转变，各行业数字化发展催生了诸如自动驾驶、AR/VR、超高清视频等新型业务。这些业务不同于传统互联网时代的邮件分发、网页浏览、文件传送等业务，它们具有最核心的特征即属于计算密集型业务且要求网络具备提供超低时延、超大规模连接、超强算力等高质量、差异化服务的能力。

由于传统的任务处理方式和能力逐渐难以满足上述业务需求，业界探索了云计算、边缘计算、SD-WAN、云网融合等解决方案使得网络与计算融合以满足计算密集型业务的算力需求。尤其近些年随着IT与CT的深度融合，由云网融合逐渐向以算力网络为代表的算网融合演进已成为重要发展方向。基于云计算集群的算网平台则是算力网络实现各类计算密集型任务处理的系统，它不仅能够对算力和网络资源、业务和用户状态进行感知，还可以实现任务调度处理和扩缩容等能力。其中，算网任务部署与调度是实现高效任务处理的关键步骤。目前，算网平台具有集中式和分布式两种设计方案，其中分布式方案虽然具有灵活性、可扩展性等优点，但存在着难以管理、安全薄弱以及运维机构无法统一运维和计费等问题，因此分布式方案不满足实际部署的技术和商业需求。集中式部署方案与各运营商现有的分级网络架构兼容性更好，且更容易管理运维和服务交付，因此现有已落地实现的算网平台都采用集中式的方式进行部署和任务调度。

然而，上述集中式算网平台还存在着以下问题，制约着任务调度的能力和效率：(1)现有算网平台大多采用各功能一体化的设计方案，这虽然实现了集中式的任务调度，但各模块之间的关系不够清晰，存在不同功能被耦合在一起，同一功能又被分割到多处的问题。这种架构下的调度引擎既不能做到调度工作模块化独立运行，也不能减少调度引擎与其他模块的冗余交互。(2)现有算网平台对任务调度引擎的具体功能设计不够细致。对于基于云集群的算网平台，任务调度应包括应用的初始部署和用户请求的调度等不同过程，另外对于有扩缩容功能的算网平台还应该包含应用的扩容和缩容过程。然而现有的算网平台往往对任务调度不加详细区分，仅设计一套简单共用的调度流程。(3)现有的算网平台任务调度引擎在执行调度工作过程中所使用的调度策略往往是固定而内嵌的。然而，不同的用户应用服务具有不同的QoS需求，这就意味着不同业务需要使用的调度策略及算法应该是多种多样的。目前产业界和相关学者针对算网平台中任务调度引擎的设计和优化提出了一些方案，但仍处于研究的初期探索阶段，不能完全解决上述的问题，距离实际部署应用还有较大理论与技术缺口，还需要更具创新性的大量细致研究使之形成一个完善的技术体系。

具体的，现有技术中存在一种集群资源调度方法，该方法包括以下步骤：获取预设时间段内各租户的资源调度任务；根据各所述资源调度任务与匹配的预设资源调度阈值范围确定各资源调度任务对应的调度优先级；根据各调度优先级和预设调度优先级顺序确定各调度优先级中各资源调度任务对应的集群调度资源；对各资源调度任务对应的集群调度资源进行调度。但是该方法存在以下缺点：根据预先设定的阈值设置调度优先级的方案不具备可行性，该方法不适用于基于云集群的微服务部署场景，调度任务的分类不清晰。因为在实际的算力网络平台中，接入的计算设备异构、用户业务需求各异，预先设定阈值的方法无法精确地保证业务需求，另外，在大规模的算网平台中为所有业务和用户设定优先级的做法会大大增加计算量和存储量；并且该方法对应用业务先分级后再直接部署，然而在微服务场景中平台需要将一个整体应用拆分为多个微服务并分别部署到不同的集群中，如果不同微服务被设置为不同的优先级，则可能会造成应用无法及时在各个集群运行的问题；本方法对用户业务的调度没有区分应用部署过程和请求调度过程，更未考虑扩缩容时涉及的调度问题。

除上述之外，现有技术中还存在一种多工作流下微服务调度与自动伸缩系统与方法，该方法对微服务工作流进行系统建模，在工作流截止日期约束下，提出一种微服务调度与自动伸缩优化方法对服务器资源使用成本进行优化，给出微服务执行映射关系以及容器的自适应配置资源。但是该方法将调度与扩缩容联合优化的思想虽然可以在一定程度上解决互相影响的问题，但是极大地增加了计算量。另外，调度和扩缩容的决策模块完全耦合在了一起，使得相关功能不再具备便于扩展、灵活组合的优点。并且，该方法主要用于相对稳定的虚拟机环境中，但是对于具备范围大、动态性、异构性特征的基于多种云集群的算网平台却很难落地实现。除上述之外，该方法中既没有对集群和微服务的部署/调度前的检查筛选机制，也没有错误处理机制，在实际应用中系统健壮性较差。

综上所述，对于算力网络任务调度引擎方法及系统，现有技术中普遍存在着对算力任务请求的处理能力差的确定，因此如何提高算力任务请求的处理能力是亟待解决的技术问题。

发明内容

有鉴于此，本发明提供了一种算力网络任务调度引擎方法及装置，以解决现有技术中存在的一个或多个问题。

根据本发明的一个方面，本发明公开了一种算力网络任务调度引擎方法，所述方法包括：

获取待部署微服务、部署算法、待部署微服务需求以及各集群信息，基于所述待部署微服务需求以及各集群信息筛选与所述待部署微服务匹配的第一集群集合；

基于所述第一集群集合和部署算法确定部署策略，所述部署策略包括微服务副本的数量以及部署集群的名称，所述部署集群属于第一集群集合，基于所述部署策略对所述待部署微服务进行部署；

获取待调度任务、调度算法以及待调度任务需求，基于所述待调度任务需求从所述部署集群集合中筛选第二集群集合；

基于所述第二集群集合和调度算法确定调度策略，所述调度策略包括调度集群的名称和各调度集群对应的任务请求数量，所述调度集群属于所述第二集群集合，基于所述调度策略对所述待调度任务中的请求进行调度。

在本发明的一些实施例中，基于所述待部署微服务需求以及各集群信息筛选与所述待部署微服务匹配的第一集群集合，包括：

基于所述待部署微服务需求对所有集群进行预筛选得到备选集群；

基于各所述备选集群的算力能力、存储资源和网络资源筛选与所述待部署微服务匹配的第一集群，形成第一集群集合。

在本发明的一些实施例中，基于所述部署策略对所述待部署微服务进行部署，包括：

为各所述待部署微服务对应的部署集群设置预留状态；所述预留状态包括预留成功、预留失败或待批准；

在所述预留状态为预留成功时，将所述待部署微服务与对应的所述部署集群进行绑定，并将所述待部署微服务的微服务镜像发送至对应的所述部署集群完成部署。

在本发明的一些实施例中，为各所述待部署微服务对应的部署集群设置预留状态，包括：

基于第一许可插件检验所述部署集群是否许可相应的待部署微服务被绑定；

在允许被绑定时，所述预留状态为预留成功；

在拒绝被绑定时，所述预留状态为预留失败；

在等待被绑定时，所述预留状态为待批准。

在本发明的一些实施例中，所述部署算法和/或所述调度算法为自定义算法。

在本发明的一些实施例中，所述方法还包括：

接收动态扩缩容模块发送的扩缩容策略，所述扩缩容策略包括扩缩容集群名称以及需要扩缩的微服务实例副本数量；

基于接收到的所述扩缩容策略执行相应的扩容操作或缩容操作。

在本发明的一些实施例中，基于所述调度策略对所述待调度任务中的请求进行调度，包括：

基于第二许可插件检验所述调度集群是否允许被调用；

在允许被调用时，将所述待调度任务的任务请求与对应的所述调度集群匹配；

在拒绝被调用时，将所述待调度任务的任务请求保存至调度缓存队列；

在等待被调用时，将所述待调度任务的任务请求保存至等待请求列表，并且当等待时间超过预设时间后，将所述待调度任务的任务请求保存至调度缓存队列。

在本发明的一些实施例中，所述方法还包括：

接收业务需求感知模块发送的待部署微服务需求信息及待调度任务需求信息，接收网络资源感知模块发送的网络链路信息，接收算力资源感知模块发送的各计算节点的算力资源状态，接收注册信息模块发送的集群注册信息；

将所述待部署微服务需求信息、待调度任务需求信息、网络链路信息、各计算节点的算力资源状态、集群注册信息、部署策略及调度策略存储至信息表。

根据本发明的另一方面，还公开了一种算力网络任务调度引擎系统，该系统包括处理器和存储器，所述存储器中存储有计算机指令，所述处理器用于执行所述存储器中存储的计算机指令，当所述计算机指令被处理器执行时该系统实现如上任一实施例方法的步骤。

根据本发明的再一方面，还公开了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上任一实施例所述方法的步骤。

本发明所公开的算力网络任务调度引擎方法及装置，首先基于第一集群集合和部署算法确定部署策略，并且在确定部署策略后进一步对待部署微服务进行部署；进而基于第二集群集合和调度算法确定调度策略，并基于调度策略对待调度任务完成调度。该方法中部署与调度分属于不同的流程处理，从而可通过一个调度引擎完成部署和调度工作，进而通过高效的各流程的互相配合以完成整个调度工作；在该方法中，与调度独立执行的部署步骤可进行多次复用，因而便于对微服务进行部署；从而该方法及装置提高了对算力任务请求的处理能力以及减小了系统计算量。

本发明的附加优点、目的，以及特征将在下面的描述中将部分地加以阐述，且将对于本领域普通技术人员在研究下文后部分地变得明显，或者可以根据本发明的实践而获知。本发明的目的和其它优点可以通过在书面说明及其权利要求书以及附图中具体指出的结构实现到并获得。

本领域技术人员将会理解的是，能够用本发明实现的目的和优点不限于以上具体所述，并且根据以下详细说明将更清楚地理解本发明能够实现的上述和其他目的。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，并不构成对本发明的限定。附图中的部件不是成比例绘制的，而只是为了示出本发明的原理。为了便于示出和描述本发明的一些部分，附图中对应部分可能被放大，即，相对于依据本发明实际制造的示例性装置中的其它部件可能变得更大。在附图中：

图1为本发明一实施例的算力网络任务调度引擎方法的流程示意图。

图2为本发明一实施例的算力网络任务调度引擎系统的结构示意图。

图3为本发明一实施例的算力网络任务调度引擎与各模块数据交互示意图。

图4a为本发明一实施例的部署过程中的流程示意图。

图4b为本发明一实施例的调度过程中的流程示意图。

图4c为本发明一实施例的扩缩容过程中的流程示意图。

图5a为本发明一实施例的调度引擎在微服务部署阶段的运行机制示意图。

图5b为本发明一实施例的调度引擎在请求调度阶段的运行机制示意图。

图5c为本发明一实施例的调度引擎在扩缩容阶段的运行机制示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚明白，下面结合附图对本发明实施例做进一步详细说明。在此，本发明的示意性实施例及其说明用于解释本发明，但并不作为对本发明的限定。

在此，需要说明的是，为了避免因不必要的细节而模糊了本发明，在附图中仅仅示出了与根据本发明的方案密切相关的结构和/或处理步骤，而省略了与本发明关系不大的其他细节。

应该强调，术语“包括/包含/具有”在本文使用时指特征、要素、步骤或组件的存在，但并不排除一个或更多个其它特征、要素、步骤或组件的存在或附加。

针对目前算网平台中任务调度引擎存在的一系列问题，本发明提出了一种算力网络任务调度引擎方法及装置，在下文中，将以算力网络任务调度引擎方法及装置中的调度引擎组成结构、调度引擎在算网平台中的整体运行机制、调度引擎与算网平台中其他模块的数据交互机制，以及算力网络任务调度引擎分别在微服务部署阶段、请求调度阶段和扩缩容阶段的具体运行步骤和操作等方面论述本申请，本申请的算力网络任务调度引擎方法及装置为算网任务调度引擎的进一步优化和发展提供关键思路和技术基础。

在下文中，将参考附图描述本发明的实施例。在附图中，相同的附图标记代表相同或类似的部件，或者相同或类似的步骤。

图1为本发明一实施例的算力网络任务调度引擎方法的流程示意图，如图1所示，该方法至少包括步骤S10至S40。

步骤S10：获取待部署微服务、部署算法、待部署微服务需求以及各集群信息，基于所述待部署微服务需求以及各集群信息筛选与所述待部署微服务匹配的第一集群集合。

步骤S20：基于所述第一集群集合和部署算法确定部署策略，所述部署策略包括微服务副本的数量以及部署集群的名称，所述部署集群属于第一集群集合，基于所述部署策略对所述待部署微服务进行部署；

步骤S30：获取待调度任务、调度算法以及待调度任务需求，基于所述待调度任务需求从所述部署集群集合中筛选第二集群集合；

步骤S40：基于所述第二集群集合和调度算法确定调度策略，所述调度策略包括调度集群的名称和各调度集群对应的任务请求数量，所述调度集群属于所述第二集群集合，基于所述调度策略对所述待调度任务中的请求进行调度。

在上述步骤S10至S20中是基于接收到的待部署微服务需求对待部署微服务进行部署，而步骤S30至步骤S40是基于接收到的待调度任务需求以及待调度任务对待调度任务中的请求进行调度。在该实施例中，待部署微服务需求以及待调度任务需求均可为用户输入的。

在步骤S10中，主要是从一系列集群中筛选出与用户的待部署微服务相匹配的第一集群集合，即从一系列集群中筛选出可执行微服务部署的集群。示例性的，与待部署微服务相匹配的第一集群集合中的各集群匹配用户输入的待部署微服务需求。待部署微服务需求中包含的具体条件不做具体限定，可根据用户的实际需求进行改变。

在一实施例中，基于所述待部署微服务需求以及各集群信息筛选与所述待部署微服务匹配的第一集群集合，包括：基于所述待部署微服务需求对所有集群进行预筛选得到备选集群；基于各所述备选集群的算力能力、存储资源和网络资源筛选与所述待部署微服务匹配的第一集群，形成第一集群集合。在该实施例中，确定与待部署微服务匹配的第一集群集合的步骤包括预筛选和筛选，经过两次筛选使得第一集群集合中的集群高度匹配于待部署微服务对应的待部署微服务需求。其中，各集群的算力能力、存储资源和网络资源等均是基于各集群的集群信息获取到的。

在步骤S20中，首先确定部署策略，进而基于确定的部署策略对待部署微服务进行具体部署；其中，具体的部署算法可根据平台/用户/应用的需求进行自定义设置。具体的，基于所述部署策略对所述待部署微服务进行部署，包括：为各所述待部署微服务对应的部署集群设置预留状态；所述预留状态包括预留成功、预留失败或待批准；在所述预留状态为预留成功时，将所述待部署微服务与对应的所述部署集群进行绑定，并将所述待部署微服务的微服务镜像发送至对应的所述部署集群完成部署。在该实施例中，部署集群为根据第一集群集合以及部署算法最终确定的用来完成待部署微服务部署的集群，为部署集群设置预留状态是为了防止在调度引擎等待绑定时发生资源竞争的情况，从而确保待部署微服务与对应的部署集群可有效的绑定。

而为各所述待部署微服务对应的部署集群设置预留状态，示例性的可包括：基于第一许可插件检验所述部署集群是否许可相应的待部署微服务被绑定；在允许被绑定时，所述预留状态为预留成功；在拒绝被绑定时，所述预留状态为预留失败；在等待被绑定时，所述预留状态为待批准。当预留成功时，则进一步可将待部署微服务与对应的部署集群进行绑定；当预留失败后，则可将待部署微服务存储至部署缓存队列中；而在等待被绑定时，可进一步的将待部署微服务存储至等待队列中等待一定时间，当等待时间到达预设时间后若还是未被允许绑定，则进一步的与预留失败状态类似，将待部署微服务存储至部署缓存队列中。

在步骤S30中，待调度任务和待调度任务需求可为用户输入的，则此时首先对部署集群进行检查，检查部署集群是否具有处理待调度任务的能力，从而并从部署集群集合中挑选出为处理调度任务请求需满足一定条件的集群生成第二集群集合。其中，若检查到部署集群集合中没有满足条件的第二集群时，则此时可向平台直接反馈该任务请求无法调度/调度失败的信息。

在步骤S40中，首先确定调度策略，进而基于该调度策略对待调度任务进行调度；其中，具体的调度算法可根据平台/用户/应用的需求进行自定义设置。示例性的，基于所述调度策略对所述待调度任务中的请求进行调度，包括：基于第二许可插件检验所述调度集群是否允许被调用；在允许被调用时，将所述待调度任务的任务请求与对应的所述调度集群匹配；在拒绝被调用时，将所述待调度任务的任务请求保存至调度缓存队列；在等待被调用时，将所述待调度任务的任务请求保存至等待请求列表，并且当等待时间超过预设时间后，将所述待调度任务的任务请求保存至调度缓存队列。

在另一实施例中，算力网络任务调度引擎方法还包括以下步骤：接收动态扩缩容模块发送的扩缩容策略，所述扩缩容策略包括扩缩容集群名称以及需要扩缩的微服务实例副本数量；基于接收到的所述扩缩容策略执行相应的扩容操作或缩容操作。

任务调度引擎是算力网络任务处理的核心模块，对于算网平台的运行以及用户服务的处理起着至关重要的作用。图2为本发明一实施例的算力网络任务调度引擎系统的结构示意图，如图2所示，在一实施例中，算力网络任务调度引擎系统具体的可以包括调度器、执行器以及信息表，调度引擎依托这些组件通过异步工作的方式参与微服务部署(初始部署应用实例)、服务请求调度(部署实例后的用户请求调度)和动态扩缩容(增加/减少微服务实例)三个流程。其中，调度器主要负责对微服务部署、服务请求调度等过程的决策以及对扩缩容相关信息的记录，执行器则负责执行调度器做出的决策，信息表则用于维护调度引擎与其他模块交互的信息以及调度引擎内部产生的数据信息。

而在算力网络平台中，为了实现平台的运维和用户业务的处理，则算力网络平台除了包括调度引擎之外，还包括业务需求感知模块、网络资源感知模块、算力资源感知模块、注册信息模块以及动态扩缩容模块等。业务需求感知模块用于获取用户的需求信息，网络资源感知模块用于实时感知网络链路信息，算力资源感知模块用于实时感知各计算节点的算力资源状态，注册信息模块用于记录云集群和用户的注册信息；而动态扩缩容模块用于根据实时的资源量和业务量，以决定进一步部署微服务以增加服务处理能力实现扩容，或者解除一部分微服务以减少冗余的处理能力实现缩容。

参考图3，信息表用于实现各模块数据信息的存储和交互。即业务需求感知模块、网络资源感知模块、算力资源感知模块和注册信息模块实时获取到的数据被输送至调度引擎的信息表中进行存储，而部署算法、调度算法的运行结果以及动态扩缩容模块的扩缩容策略也被存储至调度引擎的信息表中。另外，信息表中还存储调度引擎输出的信息，如向部署算法和调度算法提供所需的参数，向动态扩缩容模块周期性地输入其必要的数据等；由于部署算法和调度算法均可为自定义算法，因此向部署算法和调度算法提供的参数类型基于自定义算法的改变而变化；示例性的向部署算法和调度算法提供的参数如网络感知指标中的延迟、抖动、带宽等；而向动态扩缩容模块周期性地输入其必要的数据如内存负载率、磁盘带宽负载率等。除上述之外，调度引擎的信息表还可存储或记录调度器、执行器等交互过程中产生的交互数据。

具体的，在一实施例中，算力网络任务调度引擎方法则还包括以下步骤：接收业务需求感知模块发送的待部署微服务需求信息及待调度任务需求信息，接收网络资源感知模块发送的网络链路信息，接收所述算力资源感知模块发送的各计算节点的算力资源状态，接收注册信息模块发送的集群注册信息；将所述待部署微服务需求信息、待调度任务需求信息、网络链路信息、各计算节点的算力资源状态、集群注册信息、部署策略及调度策略存储至信息表。

图4a、4b和4c分别为本发明一实施例的部署过程、调度过程和扩缩容过程中的流程示意图，调度引擎通过异步工作的方式实现了微服务部署、服务请求调度、执行动态扩缩容策略等相关能力。如图4a所示，在应用的初始部署时，调度引擎对此微服务应用进行部署。具体来说，调度器将调用部署算法(具体使用的部署算法可自定义)获得部署决策，部署决策例如包括部署到的集群名称，以及每个集群需要部署的实例副本数量等，之后由执行器来执行该部署决策。执行器将部署决策、相应的微服务镜像发送至目标集群，各目标集群上的Master节点(即主节点)就可以执行部署，最终在本集群上生成并运行微服务实例。

在微服务部署完成后，各集群上则运行有相应应用的实例。如图4b所示，在服务请求调度时，各客户端发起服务请求，这些请求被存至请求消息缓存队列中，之后调度引擎将对这些请求进行处理。具体来说，调度器将调用调度算法(具体采用的调度算法可自定义设置)获得调度策略，调度策略例如包括调度到的集群名称以及每个集群接收的请求数量等，之后由执行器来执行该调度策略。执行器将根据调度策略将相应的请求异步下发到目标集群中，然后各集群上正在运行的微服务实例就可以处理这些请求。

参考图4c，在动态扩缩容时，动态扩缩容模块首先向调度引擎传入其制定的扩缩容策略，扩缩容策略例如包括执行扩缩容的集群名称以及相应集群需要扩缩的实例副本数量等，之后执行器将对扩缩容策略进行处理。具体来说，对于扩容决策，执行器将把扩容部署决策、相应的微服务镜像都下发到目标集群，然后各目标集群的Master节点就可以执行扩容部署；对于缩容决策，执行器将直接将该决策下发至目标集群，然后各目标集群的Master节点就可以直接执行副本缩容。在该实施例中，调度引擎需要周期性地向动态扩缩容模块输入其运行所需要的数据，此传输周期不受调度引擎的部署/请求周期影响，而应该是根据动态扩缩容模块的需要决定，而动态扩缩容模块的需要可由用户手动输入或系统自动制定。

其中，动态扩缩容模块可为本发明的调度引擎组成模块，也可为调度引擎外部的模块；例如，动态扩缩容决策由平台中的动态扩缩容模块制定，而此时调度引擎只负责执行该决策。应当理解的是，在一些实施例中，平台或调度引擎也可均不包含动态扩缩容模块，则此时一些实施例中的算力网络任务调度引擎方法及系统也可以不执行动态扩缩容步骤。

为了更好的体现本发明，以下将调度器和执行器的操作流程抽象为模块化的插件，按执行顺序具体介绍各步骤对应的插件的功能与作用。

图5a为本发明一实施例的调度引擎在微服务部署阶段的运行机制示意图，参考图5a，在部署阶段，具体的应用到“微服务队列”插件、“预筛选”插件、“筛选”插件、“无可用”插件、“部署策略”插件、“预留”插件、“许可”插件、“预绑定”插件、“绑定”插件、“绑定扩展口”插件、“预留未响应”插件以及“集群”插件。

具体的，首先通过“微服务队列”插件将待部署队列中的待部署微服务实例进行排序，每次执行只能启动一个“微服务队列”插件。进而利用“预筛选”插件预处理微服务的相关信息，或者检查集群或Pod(即要部署的微服务副本)必须满足的某些条件。如果“预筛选”插件返回的为错误信息，则部署进程将跳转至下述的“无可用”插件。“筛选”插件用于过滤出不能执行微服务部署的集群；对于每个集群，调度器将按照其配置顺序调用该“筛选”插件；如果某个“筛选”插件将集群标记为不可用，则调度器不会为该集群调用其余的“筛选”插件(若存在多个筛选步骤)；如果“筛选”插件返回的为错误信息，则部署进程将跳转至下述的“无可用”插件；在该筛选步骤中，调度器需要依照待调度的微服务的需求与集群的算力资源、存储资源、网络资源相匹配的原则筛选出符合条件的集群。

“无可用”插件在“筛选”阶段后调用，但仅在对该Pod没有可用的集群时调用；“无可用”插件将标记集群为“不可调度”的状态，则此时其余的后续插件都不会调用；其中，针对“不可调度”状态存在以下两种处理方式：1)向平台反馈无法部署/部署失败的信息；2)实施抢占，试图通过抢占其他微服务的资源使该微服务可以被部署。“部署策略”插件调用预先配置好的部署策略，并运行其核心代码，返回部署的云集群名称、部署微服务副本的数量等信息；具体的部署算法可根据平台/用户/应用的需求进行自定义设置，在本发明的调度引擎中不做特别指定；另外，运行部署算法所需的输入参数则由调度引擎中的信息表提供。

“预留”插件所执行的预留步骤是一个信息性的扩展步骤，以便调度器在节点给指定Pod预留了资源时能够通知该插件；此步骤在执行器真正将Pod绑定到集群之前进行，并且它的存在是为了防止在调度引擎等待绑定过程中发生资源竞争的情况；其中，当Pod处于“预留”状态时，它将在执行器的绑定周期结束时根据执行情况触发不同插件；具体来说，在执行失败时触发“预留未响应”插件，而在执行成功时触发“绑定扩展点”插件。

“许可”插件在每个Pod的调度器执行周期的最后被调用，用于防止或延迟Pod的绑定。“许可”插件可以做以下操作之一：1)批准：一旦所有“许可”插件批准Pod后，该Pod将被发送到执行器以进行绑定；2)拒绝：如果任何“许可”插件拒绝Pod，则该Pod将被返回到待编排队列，这将触发“预留未响应”插件；3)等待(带有超时)：如果一个“许可”插件返回“等待”结果，则Pod将被送入一个内部的“等待中Pod”列表，同时该Pod的绑定周期将直接阻塞，直到得到批准才能继续进行；如果超时发生，等待状态将变成拒绝状态，并且Pod将返回待编排队列，并触发“预留未响应”插件。

“预绑定”插件用于执行Pod绑定前所需的所有工作；如果任何“预绑定”插件返回错误，则Pod将被拒绝并且退回到待部署队列中。“绑定”插件用于将Pod绑定到集群上；当所有的“预绑定”插件都完成后，“绑定”插件才会被调用。“绑定扩展点”插件是一个信息性的扩展步骤；“绑定扩展点”插件在Pod成功绑定后被调用；这是执行器的绑定周期的结尾，可用于清理相关的资源。

“预留未响应”插件是一个信息性的扩展步骤；如果Pod被“预留”，然后在后续步骤中被拒绝，则该“预留未响应”插件将被通知；“预留未响应”插件应该清楚保留Pod的相关状态，另外在该“预留未响应”可以引入进一步必要的处理机制(例如相关的错误处理机制)。“集群插件”为一种可选插件，“集群插件”用于实现Pod部署和绑定等任何在集群内部进行的操作。

图5b为本发明一实施例的调度引擎在请求调度阶段的运行机制示意图，如图5所示，在请求调度阶段，其应用的插件具体包括“请求队列”插件、“检查”插件、“无可用”插件、“调度策略”插件、“许可”插件、“匹配”插件、“匹配扩展点”插件、“响应失败”插件、“集群”插件。

具体的，首先通过“请求队列”插件将待调度队列中的用户服务请求(待调度任务)进行排序，每次执行只能启动一个“请求队列”插件。进而通过“检查”插件预处理请求的相关信息，并检查集群为处理该请求必须满足的某些条件；如果“检查”插件返回的为错误信息，或者发现无任何集群可以支撑该请求，则调度进程将跳转至“无可用”插件。

“无可用”插件在“检查”流程后被调用，但仅在对该请求没有可行的处理集群时调用；“无可用”插件将标记该请求为“不可调度”的状态，则其余的后续插件都不会调用；针对请求过程中触发“无可用”的处理方式可为：直接向平台反馈该请求无法调度/调度失败的信息。

“调度策略”插件调用预先配置好的调度策略，并运行其核心代码，返回调度的云集群名称、集群接收的请求数量等信息；具体的，调度算法可根据平台/用户/应用的需求进行自定义设置，在本调度引擎中不做特别指定；另外，运行调度算法所需的输入参数则由调度引擎中的信息表提供。

“许可”插件在每个请求通过调度器执行时的最后被调用，用于防止或延迟请求的匹配。“许可”插件可以做以下操作之一：1)批准：一旦所有“许可”插件批准请求后，该请求将被发送到执行器以进行匹配(之后由执行器发送到调度策略指定的集群)；2)拒绝：如果任何“许可”插件拒绝请求，该请求将返回调度缓存队列，并触发“响应失败”插件；3)等待(带有超时)：如果一个“许可”插件返回“等待”结果，则请求将被送入一个内部的“等待中请求”列表，同时该请求的匹配周期将直接阻塞(即延迟发送)，直到得到批准才能继续进行；如果超时发生，等待状态将变成拒绝状态，请求将返回调度缓存队列，并触发“响应失败”插件。

“匹配”插件用于将请求匹配并发送到指定集群上。“匹配扩展点”插件是一个信息性的扩展步骤；“匹配扩展点”插件在请求成功匹配并发送后被调用，这是执行器执行过程的结尾，可用于清理相关的资源。而“响应失败”插件是一个信息性的扩展步骤；“响应失败”插件应该引入进一步必要的错误处理机制，以解决在调度引擎周期中未能正常调度的请求。“集群”插件为一种可选插件，“集群插件”用于实现Pod部署和绑定等任何在集群内部进行的操作。

图5c为本发明一实施例的调度引擎在扩缩容阶段的运行机制示意图，如图5所示，在动态扩缩容阶段，具体的应用到“记录”插件、“预留”插件、“许可”插件、“预绑定”插件、“绑定”插件、“绑定扩展口”插件、“预留未响应”插件以及“集群”插件。其中“记录”插件用来记录动态扩缩容模块向调度引擎输出的扩缩容策略及配置等相关信息。而“预留”插件、“许可”插件、“预绑定”插件、“绑定”插件、“绑定扩展口”插件、“预留未响应”插件以及“集群”插件与微服务部署阶段的相应插件的功能完全相同，因而在动态扩缩容阶段，可直接复用微服务部署阶段的相应插件。

另外，调度引擎在扩缩容阶段的工作需要注意三点：1)调度引擎通过其内部维护的信息表周期性地向动态扩缩容模块提供输入参数，而该周期的长短一般则以动态扩缩容模块的操作周期为准，或者由系统或用户指定；2)在扩容时，调度引擎按照动态扩缩容模块给出的部署方案(例如执行扩容的集群名称，扩容的实例副本数量等)进行部署操作即可；3)在缩容时，调度引擎只需直接将具体的缩容数量发送到待缩容的集群中由Master节点直接执行缩容操作即可。

以下内容以AI智慧交通业务为例，进一步的对调度引擎的各阶段流程进行详细说明。例如，首先在集群部署该业务(即微服务部署阶段)：在算网平台上将AI智慧交通业务的全部微服务进行部署，即算网平台中的调度引擎将这些待部署的微服务，根据业务需求、算网资源等数据并调用部署算法，最终选择多个云集群进行部署。在微服务部署完成后，这些云集群都运行有可以处理AI智慧交通业务的微服务实例。

之后，当参与交通活动的各方用户(例如网联车辆、交通管理部门等)需要访问该服务时，这些用户向算网平台发出服务请求，则进入了请求调度阶段。在此阶段，调度引擎将用户的服务请求调度到部署有微服务实例的集群上，使得这些用户请求可以被微服务实例处理。调度引擎将根据这些请求的具体需求，以及各微服务的运行状态，节点算网资源等数据信息，调用调度算法以选择相应的云集群，然后将这些请求调度过去，使得用户请求可以被运行在这些云集群上的微服务实例处理。

而在该AI智慧管理应用运行期间，算网平台的动态扩缩容模块周期性地收集各类业务数据和算网资源数据以判断该应用是否满载或者空闲。当部分微服务实例空闲时就做出缩容决策，当微服务都繁忙甚至过载时，则做出扩容决策。扩缩容决策被发送到调度引擎中，调度引擎就直接执行相应决策，比如执行缩容决策就直接通知相应集群解除并释放该AI智慧交通业务的微服务实例，执行扩容决策就直接对相应的集群再部署指定数量的AI智慧交通业务的微服务实例。

通过上述实施例可以发现，本申请的算力网络任务调度引擎方法及系统主要包括以下四个方面：

(1)算力网络任务调度引擎在算网平台中的整体架构、工作流程方案以及与其他模块的数据交互机制。本申请的集中式、模块化的任务调度引擎，其作为算网平台的核心组件，承担了包括微服务部署、服务请求调度、动态扩缩容策略执行等功能在内的全流程算网任务调度。

(2)算力网络任务调度引擎在微服务部署阶段的具体运行步骤。本申请通过在云集群按需部署微服务实例，实现集群通过微服务实例来处理用户服务请求的能力。其中，可以理解的是，本申请所提的云集群可为私有云集群、公有云集群(并且可以是单一云商或者跨多云商)以及混合云集群。

(3)算力网络任务调度引擎在请求调度阶段的具体运行步骤。本申请在微服务部署阶段完成之后，集群已经运行有微服务实例并可以处理相应服务请求的情况下，设计针对用户发起的服务请求的调度阶段的具体操作步骤，实现调度器和执行器利用调度算法/策略把用户发起的服务请求根据业务需求和资源状态等信息，调度到已经运行有相应微服务实例的集群上处理。

(4)算力网络任务调度引擎在扩缩容阶段的具体运行步骤。本申请针对当前算网平台常用的动态扩缩容功能，一方面为动态扩缩容模块提供必要的周期性数据支撑，另一方面承接动态扩缩容模块做出的扩缩容策略，并据此对相应的集群进行扩缩容操作，实现微服务实例数量的按需增加或减少。

本申请的算力网络任务调度引擎方法采用的为集中式、模块化的算力网络任务调度引擎，且该模块化的算力网络任务调度引擎不仅可以以调度流程为纽带将现有算网平台中的各模块连接起来实现各模块插件化灵活组合，高效的互相配合完成整个调度工作；还囊括了微服务部署、服务请求调度、动态扩缩容策略执行等调度工作中的各流程，实现通过一个引擎可以完成全部类型调度任务的便捷化方案。另外，该算力网络任务调度引擎方法将各部署步骤抽象化为一个插件，既便于各部署步骤的灵活组合调用，也便于同一部署步骤的多次复用，部分的步骤还支撑了扩缩容阶段的运行步骤。除上述之外，本申请的算力网络任务调度引擎方法面向现有算网平台中的利用动态扩缩容模块实现微服务实例的增加/减少的情况，使用调度引擎承接动态扩缩容模块输出的扩缩容策略，并利用执行器等组件完成策略指定的扩缩容操作；调度引擎执行扩缩容决策的大多数步骤复用了微服务部署阶段的部分步骤，在具体执行时提高了便捷性。

相应的，本发明还提供了一种算力网络任务调度引擎系统，该系统包括处理器和存储器，所述存储器中存储有计算机指令，所述处理器用于执行所述存储器中存储的计算机指令，当所述计算机指令被处理器执行时该系统实现上任一实施例所述方法的步骤

另外，该发明还公开了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上任一实施例所述方法的步骤。

本发明所公开的算力网络任务调度引擎方法及装置，首先基于第一集群集合和部署算法确定部署策略，并且在确定部署策略后进一步对待部署微服务进行部署；进而基于第二集群集合和调度算法确定调度策略，并基于调度策略对待调度任务完成调度。该方法中部署与调度分属于不同的流程处理，从而可通过一个调度引擎完成部署和调度工作，进而通过高效的各流程的互相配合以完成整个调度工作；在该方法中，与调度独立执行的部署步骤可进行多次复用，因而便于对待部署微服务进行部署；从而该方法及装置提高了对算力任务请求的处理能力以及减小了系统计算量。

本领域普通技术人员应该可以明白，结合本文中所公开的实施方式描述的各示例性的组成部分、系统和方法，能够以硬件、软件或者二者的结合来实现。具体究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本发明的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质、射频(RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。

还需要说明的是，本发明中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本发明不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。

本发明中，针对一个实施方式描述和/或例示的特征，可以在一个或更多个其它实施方式中以相同方式或以类似方式使用，和/或与其他实施方式的特征相结合或代替其他实施方式的特征。

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

Claims (10)

1.一种算力网络任务调度引擎方法，其特征在于，所述方法包括：

获取待部署微服务、部署算法、待部署微服务需求以及各集群信息，基于所述待部署微服务需求以及各集群信息筛选与所述待部署微服务匹配的第一集群集合；

基于所述第一集群集合和部署算法确定部署策略，所述部署策略包括微服务副本的数量以及部署集群的名称，所述部署集群属于第一集群集合，基于所述部署策略对所述待部署微服务进行部署；

获取待调度任务、调度算法以及待调度任务需求，基于所述待调度任务需求从所述部署集群集合中筛选第二集群集合；

基于所述第二集群集合和调度算法确定调度策略，所述调度策略包括调度集群的名称和各调度集群对应的任务请求数量，所述调度集群属于所述第二集群集合，基于所述调度策略对所述待调度任务中的请求进行调度。

2.根据权利要求1所述的算力网络任务调度引擎方法，其特征在于，基于所述待部署微服务需求以及各集群信息筛选与所述待部署微服务匹配的第一集群集合，包括：

基于所述待部署微服务需求对所有集群进行预筛选得到备选集群；

基于各所述备选集群的算力能力、存储资源和网络资源筛选与所述待部署微服务匹配的第一集群，形成第一集群集合。

3.根据权利要求1所述的算力网络任务调度引擎方法，其特征在于，基于所述部署策略对所述待部署微服务进行部署，包括：

为各所述待部署微服务对应的部署集群设置预留状态；所述预留状态包括预留成功、预留失败或待批准；

在所述预留状态为预留成功时，将所述待部署微服务与对应的所述部署集群进行绑定，并将所述待部署微服务的微服务镜像发送至对应的所述部署集群完成部署。

4.根据权利要求3所述的算力网络任务调度引擎方法，其特征在于，为各所述待部署微服务对应的部署集群设置预留状态，包括：

基于第一许可插件检验所述部署集群是否许可相应的待部署微服务被绑定；

在允许被绑定时，所述预留状态为预留成功；

在拒绝被绑定时，所述预留状态为预留失败；

在等待被绑定时，所述预留状态为待批准。

5.根据权利要求1至4中任意一项所述的算力网络任务调度引擎方法，其特征在于，所述部署算法和/或所述调度算法为自定义算法。

6.根据权利要求5所述的算力网络任务调度引擎方法，其特征在于，所述方法还包括：

接收动态扩缩容模块发送的扩缩容策略，所述扩缩容策略包括扩缩容集群名称以及需要扩缩的微服务实例副本数量；

基于接收到的所述扩缩容策略执行相应的扩容操作或缩容操作。

7.根据权利要求1所述的算力网络任务调度引擎方法，其特征在于，基于所述调度策略对所述待调度任务中的请求进行调度，包括：

基于第二许可插件检验所述调度集群是否允许被调用；

在允许被调用时，将所述待调度任务的任务请求与对应的所述调度集群匹配；

在拒绝被调用时，将所述待调度任务的任务请求保存至调度缓存队列；

在等待被调用时，将所述待调度任务的任务请求保存至等待请求列表，并且当等待时间超过预设时间后，将所述待调度任务的任务请求保存至调度缓存队列。

8.根据权利要求1所述的算力网络任务调度引擎方法，其特征在于，所述方法还包括：

接收业务需求感知模块发送的待部署微服务需求信息及待调度任务需求信息，接收网络资源感知模块发送的网络链路信息，接收算力资源感知模块发送的各计算节点的算力资源状态，接收注册信息模块发送的集群注册信息；

将所述待部署微服务需求信息、待调度任务需求信息、网络链路信息、各计算节点的算力资源状态、集群注册信息、部署策略及调度策略存储至信息表。

9.一种算力网络任务调度引擎系统，该系统包括处理器和存储器，其特征在于，所述存储器中存储有计算机指令，所述处理器用于执行所述存储器中存储的计算机指令，当所述计算机指令被处理器执行时该系统实现如权利要求1至8中任意一项所述方法的步骤。

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

Images