集群调度方法和装置与流程

本申请涉及通信技术领域，具体涉及一种集群调度方法和装置。

背景技术：

集群调度是指将处理请求转发到集群中不同的服务器上以实现资源的有效利用和实时处理，以此实现集群的负载均衡。然而现有的集群调度方式一般紧耦合于一套完整的调度系统，主要为了解决某些特定场景下的复杂问题而设计，存在较多的组件依赖和环境依赖，会引入额外的系统性能开销。同时，由于只适用某些特定需求场景，通用性、可移植性和可扩展性都较差。此外，对于使用者的学习和使用成本也较高。

技术实现要素：

有鉴于此，本申请实施例提供了一种集群调度方法和装置，解决了现有集群调度方式的系统开销大、通用性差、可移植性差、可扩展性差以及学习和使用成本高的问题。

根据本申请的一个方面，本申请一实施例提供的一种集群调度方法，包括：加载配置文件，其中所述配置文件包括用户指定的调度策略；根据所述用户指定的调度策略确定目标服务器；以及将当前处理请求分配给所述目标服务器执行。

根据本申请的另一个方面，本申请一实施例提供的一种集群调度装置，包括：配置加载模块，配置为加载配置文件，其中所述配置文件包括用户指定的调度策略；目标服务器确定模块，配置为根据所述用户指定的调度策略确定目标服务器；以及请求分配模块，配置为将当前处理请求分配给所述目标服务器执行。

本申请另一实施例提供一种电子设备，包括：处理器；以及存储器，在所述存储器中存储有计算机程序指令，所述计算机程序指令在被所述处理器运行时使得所述处理器执行如前所述的集群调度方法。

本申请另一实施例一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行如前所述的集群调度方法。

本申请实施例提供的一种集群调度方法和装置，通过设置可加载的配置文件以获取用户指定的调度策略，将集群调度的执行逻辑划分为位于上层的调度策略层和位于底层的调度框架层，实现了一种调度策略的配置/执行和调度框架的配置/执行完全解耦的集群调度方式。这样用户可以通过调度框架层建立通用的通信交互框架配置，而不必考虑调度框架层的配置变化对于调度策略的影响，使得调度过程的执行摆脱了对应用场景的组件依赖和环境依赖，减少了额外的系统性能开销。同时，用户还可通过加载配置文件对调度策略进行自由配置，不必考虑对调度框架层已有配置的影响，从而大大提高了调度策略的可移植性和可扩展性。此外，由于用户还可根据实际场景需求对调度策略进行自定义配置，这样也节省掉了用户的学习和使用成本。

附图说明

图1所示为本申请一实施例提供的一种集群调度方法的流程示意图。

图2所示为本申请另一实施例提供的一种集群调度方法中确定用户指定的调度策略的流程示意图。

图3所示为本申请一实施例提供的一种集群调度方法中无状态轮询调度策略的流程示意图。

图4所示为本申请一实施例提供的一种集群调度方法中有状态调度策略的流程示意图。

图5所示为本申请一实施例提供的一种集群调度方法中基于响应时间调度策略的流程示意图。

图6所示为本申请一实施例提供的一种集群调度方法中基于剩余计算能力调度策略的流程示意图。

图7所示为本申请一实施例提供的一种集群调度方法的原理示意图。

图8所示为本申请一实施例提供的一种集群调度装置的结构示意图。

图9所示为本申请另一实施例提供的一种集群调度装置的结构示意图。

图10所示为本申请另一实施例提供的一种集群调度装置的结构示意图。

图11所示为本申请一实施例提供的电子设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

申请概述

如前所述，现有集群调度方式之所以存在系统开销大、通用性差、可移植性差、可扩展性差以及学习和使用成本高的问题，主要是因为现有的集群调度方式一般设计为只适用于某些特定需求场景，调度策略的配置与调度框架的配置紧密耦合以形成一套完整的调度系统。因此为了解决现有集群调度方式的上述问题，就需要建立一种调度策略层和调度框架层完全解耦的集群调度系统，使得调度策略的配置/执行和调度框架的配置/执行互不影响，从而使得调度策略的执行摆脱对应用场景的组件依赖和环境依赖。

针对上述的技术问题，本申请的基本构思是提出一种集群调度方法和装置，将集群调度的执行逻辑划分为位于上层的调度策略层和位于底层的调度框架层。调度策略层通过设置可加载的配置文件以确定用户指定的调度策略，并根据调度策略确定目标服务器；调度框架层负责在将当前的处理请求分配给该目标服务器时的通信交互实现，并不干涉调度策略层的调度策略执行，由此提供了一种“可插拔”的调度模型。这里的“可插拔”意为调度策略层的配置/执行相对于调度框架层的配置/执行是可自由切换或替换的，由此实现了调度策略层和调度框架层的完全解耦。

需要说明的是，本申请所提供的集群调度方法可以应用于任何应用场景下的任何集群系统。具体而言，集群系统由相互独立的并通过网络互联的计算资源构成，这些计算资源可通过带有计算和/或存储功能的服务器实现，集群系统中的服务器通过并行计算以高效地完成特定应用场景的计算任务。集群中服务器之间调度策略的执行是保证集群系统高效工作的核心。本申请对集群系统所针对的应用场景、所要完成的整体计算任务内容以及其中各服务器所要完成的具体计算任务内容均不做限定。

在介绍了本申请的基本原理之后，下面将参考附图来具体介绍本申请的各种非限制性实施例。

示例性集群调度方法

图1所示为本申请一实施例提供的一种集群调度方法的流程示意图。如图1所示，该集群调度方法包括：

步骤101：加载配置文件，其中配置文件包括用户指定的调度策略。

配置文件中包括调度策略，该调度策略可体现为一个基于预设调度规则维护的目标服务器列表，依据该目标服务器列表即可确定分配给当前处理请求的目标服务器。配置文件中用户指定的调度策略可以是从预设的多个调度策略中选择的一个调度策略，也可以是用户根据实际场景需求而自定义的调度策略，本申请对调度策略的具体内容并不做限定。

步骤102：根据用户指定的调度策略确定目标服务器。

目标服务器则对应为当前处理请求分配的服务器，用于执行当前处理请求的具体计算任务。应当理解，当获取到新的处理请求时，该目标服务器需要根据用户指定的调度策略而更新。前述的配置文件加载和确定目标服务器的过程可被认为是由位于上层的调度策略层完成，调度策略层将所确定的目标服务器输出给位于底层的调度框架层。

步骤103：将当前处理请求分配给目标服务器执行。

具体而言，将当前处理请求分配给目标服务器的过程可被认为是由位于底层的调度框架层完成，调度框架层负责在将当前的处理请求分配给该目标服务器时的通信交互实现。调度框架层从调度策略层获取到对应当前处理请求的目标服务器，而并不直接参与调度策略的确定过程。应当理解，除了将当前处理请求分配给目标服务器以执行对当前处理请求的处理过程外，还可能需要完成一些调度框架层的初始化配置以适应具体的应用场景需求，用户可以通过调整这些初始化配置来完成调度框架层的配置。

在本申请一实施例中，可以通过提供给用户开放的api接口(applicationprogramminginterface，应用程序编程接口)的方式来完成上述的请求分配过程以及初始化配置过程。例如，上述将当前处理请求分配给目标服务器执行的过程的api接口就可定义为callservice()调度请求函数，上述初始化配置的过程的api接口就可定义为loadconf()加载配置函数。

应当理解，虽然在上面的描述中将集群调度的执行逻辑划分为位于上层的调度策略层和位于底层的调度框架层，但这种逻辑划分并不意味着调度策略层和调度框架层一定位于两个不同的软件程序实体，实际上调度策略层和调度框架层可集成在同一个软件程序实体中。

由此可见，本申请实施例提供的一种集群调度方法，通过设置可加载的配置文件以获取用户指定的调度策略，将集群调度的执行逻辑划分为位于上层的调度策略层和位于底层的调度框架层，实现了一种调度策略的配置/执行和调度框架的配置/执行完全解耦的集群调度方式。这样用户可以通过调度框架层建立通用的通信交互框架配置，而不必考虑调度框架层的配置变化对于调度策略的影响，使得调度过程的执行摆脱了对应用场景的组件依赖和环境依赖，减少了额外的系统性能开销。同时，用户还可通过加载配置文件对调度策略进行自由配置，不必考虑对调度框架层已有配置的影响，从而大大提高了调度策略的可移植性和可扩展性。此外，由于用户还可根据实际场景需求对调度策略进行自定义配置，这样也节省掉了用户的学习和使用成本。

在本申请一实施例中，在根据用户指定的调度策略确定目标服务器时，要参考过往处理请求的反馈信息。即，需要根据过往处理请求的反馈信息以及用户指定的调度策略确定目标服务器。过往处理请求的反馈信息用于表征过往处理请求所对应的目标服务器对于过往处理请求的处理情况。当要确定当前处理请求所对应的目标服务器时，要参考这些反馈信息以提高调度质量。过往处理请求的反馈信息由调度框架层提供给调度策略层。在本申请一实施例中，该调度策略可体现为一个基于预设调度规则维护的目标服务器列表，该目标服务器列表可以是根据过往处理请求的反馈信息而实时更新的。

在本申请一实施例中，反馈信息可包括以下信息中的一种或多种组合：处理是否成功和响应请求时间。当反馈信息包括处理是否成功时，若反馈信息指示为处理不成功时，可直接判定与过往处理请求对应的目标服务器出现故障，从而将该与过往处理请求对应的目标服务器从目标服务器列表中去除，并根据更新后的目标服务器列表选择新的目标服务器。当反馈信息包括响应请求时间时，且该响应请求时间过长时，可判断该与过往处理请求对应的目标服务器可能负荷过大或本身计算能力有限，此时则可降低该与过往处理请求对应的目标服务器在目标服务器列表中的优先级，并从目标服务器列表选择新的目标服务器。然而应当理解，反馈信息的具体内容与加载配置文件中的调度策略的具体配置有关，本申请对该反馈信息的具体内容不做限定。

应当理解，在将当前处理请求分给目标服务器执行后，调度框架层可根据该目标服务器的执行结果确定当前处理请求的反馈信息，并将该反馈信息反馈给调度策略层。调度策略层便可根据收到的反馈信息和调度策略确定对应下一个处理请求的目标服务器。

由此可见，通过建立调度策略层与调度框架层之间的反馈机制，使得调度策略层的调度策略可以更加智能和准确，有助于提高集群调度的效率和负载平衡效果，同时也可避免由于某些服务器故障而导致的调度失败。

图2所示为本申请另一实施例提供的一种集群调度方法中确定用户指定的调度策略的流程示意图。如图2所示，该确定目标服务器的过程可包括如下步骤：

步骤201：接收用户的选择指令。

步骤202：基于选择指令从至少一种预设调度策略中选择一个作为用户指定的调度策略。

具体而言，可在配置文件中设置至少一种预设调度策略，以应对不同应用场景的不同需求。用户可从该至少一种预设调度策略中选择一个以满足当前应用场景的需求，当应用场景发生变化时，用户还可选择另一个以满足新的应用场景的需求。在本申请一实施例中，用户对于预设调度策略的选择时机可以是在整个集群调度流程开始之前进行，这样当集群调度流程开始进行时，便会按照用户选择的调度策略确定每个处理请求的目标服务器。在另一实施例中，用户对于预设调度策略的选择时机可以是在集群调度流程的过程中进行，例如当用户发现之前选择的预设调度策略并不能很好的满足当前应用场景的需求时，用户也可以实时选择更换预设调度策略。

应当理解，集群调度模型中的预设调度策略可以由开发人员根据常用的应用场景需求而预先定义，也可由用户根据当前应用场景的需求而自定义，本申请对集群调度模型中的预设调度策略的具体内容和数量均不做严格限定。在本申请一实施例中，配置文件中可包括如下预设调度策略中的一种或多种组合：无状态轮询调度策略、有状态调度策略、基于响应时间调度策略和基于剩余计算能力调度策略。

由此可见，通过在集群调度模型中建立预设调度策略的选择机制，可快速地满足用户对于调度策略的不同需求，同时也可满足用户的自定义需求，不仅能够进一步提高集群调度的效率和负载平衡效果，还提高了用户对于集群调度过程的控制的灵活性。

在本申请一实施例中，为了进一步提高集群调度的效率和质量，需要根据当前处理请求所对应的待处理数据的数据结构来确定合适的调度策略。具体而言，待处理数据是由多个数据包构成，根据应用场景的不同，所获取到的待处理数据的数据包之间可能存在一定逻辑连接关系，也可能并不存在逻辑连接关系，需要根据数据包之间是否存在一定逻辑连接关系来确定合适的调度策略。因此可先确定待处理数据的数据包构成方式，然后基于待处理数据的数据包构成方式，从至少一种预设调度策略中选择一个作为用户指定的调度策略。

图3所示为本申请一实施例提供的一种集群调度方法中无状态轮询调度策略的流程示意图。考虑到在一些应用场景下，待处理数据可能包括多个数据包，但这些数据包之间可能并没有必然的逻辑连接关系，例如大流量高并发的大型网站的数据处理场景。此时可通过以下无状态轮询的调度策略以保证数据处理的效率。如图3所示，该无状态轮询调度策略可包括：

步骤301：当处理待处理数据的第一个数据包时，从可用服务器列表中随机选取一个作为处理第一个数据包的目标服务器。

可用服务器列表为集群中可以用于完成处理请求的服务器的列表。如前所述，当要处理第一个数据包时，由于此时可用服务器列表中的服务器可能都是空闲的，因此可从可用服务器列表中随机选择一个作为处理该第一个数据包的目标服务器。

在本申请一实施例中，该随机选择的方式可通过如下步骤实现：首先获取第一个数据包的摘要信息，将该摘要信息转为整数值，然后基于整数值与可用服务器列表中的可用服务器的数量，从可用服务器列表中确定一个可用服务器作为处理该第一个数据包的目标服务器。在一进一步实施例中，可将整数值对可用服务器列表中的可用服务器的数量进行取余，以获取第一余数；然后根据第一余数确定可用服务器列表中的一个可用服务器作为处理第一个数据包的目标服务器。例如，获取到的第一个数据包的摘要信息可以是字符串的形式，根据字符串的类型可选择通过如下函数中的一种转为十进制的整数值：bkdrhash、aphash、djbhash、jshash、rshash、sdbmhash、pjwhash和elfhash等。例如，当转化得到的十进制的整数值为13，而可用服务器的数量为10时，取余获得的第一余数就是3，此时则可选择可用服务器列表中的第三个可用服务器作为处理第一个数据包的目标服务器。由于数据包的摘要信息有随机性，因此摘要信息转化为的整数值也有一定随机性，进而使得该第一余数也有随机性，由此实现了随机选择。然而本申请对随机选择第一个数据包的目标服务器的方式并不做严格限定。

步骤302：当处理待处理数据的其他数据包时，按照其他数据包的连接顺序从可用服务器列表中轮询选择可用服务器作为处理其他数据包的目标服务器。

具体而言，由于第一个数据包所对应的目标服务器已经处于工作状态，此时可按照其他数据包的连接顺序，以轮询的方式从可用服务器列表中选择下一个服务器作为处理下一个数据包的目标服务器。当可用服务器列表中的服务器被轮询完毕时，若还有数据包需要处理，可再循环至可用服务器列表中与第一个数据包对应的目标服务器，直至待处理数据的所有数据包都被处理完毕。

在本申请一实施例中，当处理待处理数据的其他数据包时，若第一个数据包采用前述的基于摘要信息的整数转化值对可用服务器的数量取余的方式选择目标服务器，可将上一个其他数据包的摘要信息对应的整数值进行自增，自增的步长为1；然后将自增后的整数值对可用服务器列表中的可用服务器数量进行取余，以获取第二余数；根据该第二余数确定可用服务器列表中的一个可用服务器作为处理当前其他数据包的目标服务器。自增的过程使得该第二余数也实现了自增，由此实现了对可用服务器列表的轮询选择机制。

由此可见，当待处理数据的数据包之间并无必然的逻辑连接关系时，通过无状态轮询调度策略可方便地实现集群中服务器间的负载均衡。例如在人脸识别领域，当工业摄像机抓拍到一张人脸的抓拍图时，便可将该抓拍图的抓拍帧信息作为当前处理请求的一个数据包，随机向集群中的一台目标服务器请求基于该抓拍帧信息识别人脸。当抓拍到下一张抓拍图时，则可以轮询的方式从可用服务器列表选择下一个可用服务器作为基于该下一张抓拍图进行人脸识别的目标服务器

图4所示为本申请一实施例提供的一种集群调度方法中有状态调度策略的流程示意图。考虑到在一些应用场景下，待处理数据包括依次连接的多个数据包，这些数据包之间存在着一定的逻辑连接关系时，可通过一个有状态调度策略以将这些数据包需要发送给同一个服务器进行处理，以提高数据处理的效果和准确性。例如在语音识别等与人工智能相关的技术领域，视频或语音信息经常是分成多个片段的，而这些片段之间一般在时间维度上是存在前后联系的。在对这些片段进行智能处理时往往要结合上一个片段和/或下一个片段才能够做出综合判断，因此需要将这些片段发送给同一个服务器处理。如图4所示，该有状态调度策略可包括：

步骤401：当处理待处理数据的第一个数据包时，从可用服务器列表中随机选取一个作为处理第一个数据包的目标服务器。

虽然数据包之间存在一定的逻辑连接关系，但当要处理第一个数据包时，由于此时可用服务器列表中的服务器可能都是空闲的，因此仍可从可用服务器列表中随机选择一个作为处理该第一个数据包的目标服务器。随机选择的方式仍可采用前述的基于摘要信息的整数转化值对可用服务器的数量取余的选择方式，在此不再赘述。

步骤402：当处理待处理数据的其他数据包时，选择处理第一个数据包的目标服务器作为处理其他数据包的目标服务器。

由于数据包之间存在逻辑连接关系，因此需要将其他数据包的处理请求都分配给该处理第一个数据包的目标服务器，这样该目标服务器才能连续地获取到所有的数据包，以完成对待处理数据的处理。

由此可见，当待处理数据的数据包之间存在一定的逻辑连接关系时，通过有状态轮询调度策略可更好地保证待处理数据处理的准确性。例如，在语音识别领域，往往需要对一个人的一段话进行语音识别。然而，一段话可能很长，会被语音的客户端拆分成多个语音片段，此时便可每次将一个片段的语音信息作为当前处理请求的一个数据包，将同一段话的所有语音片段发往集群的同一台服务器请求语音识别，这样这台服务器会收到所有完整的语音片段，就能更准确地识别出说话人身份。

图5所示为本申请一实施例提供的一种集群调度方法中基于响应时间调度策略的流程示意图。如图5所示，该基于响应时间调度策略包括：

步骤501：获取可用服务器列表中每个可用服务器的平均响应请求时间。

可用服务器每接收到一次处理请求，响应请求时间就会被累计。平均响应请求时间由累计响应请求时间除以总响应请求次数计算得到。

步骤502：选择可用服务器列表中平均响应请求时间最短的作为目标服务器。

平均响应请求时间最短的可用服务器的计算能力相对较强。随着更多处理请求的进行，各可用服务器的平均响应请求时间也是不断更新的。如果一个计算能力很强的可用服务器接收到了过多的处理请求，平均响应请求时间也会增长，那么该可用服务器在可用服务器列表中被选择的优先级也会降低，因此可总是选择可用服务器列表中平均响应请求时间最短的作为处理当前处理请求的目标服务器。

在本申请一实施例中，当一个过往处理请求对应的目标服务器的反馈信息中包括处理未成功的信息时，则可将该目标服务器对该过往处理请求的响应请求时间作为该目标服务器的平均响应请求时间。由于处理未成功，该目标服务器的平均响应请求时间会更新为无限大，因而保证有故障的服务器不会再被选择为目标服务器。

由此可见，通过基于响应时间调度策略可更合理且高效地实现集群间服务器的负载均衡。例如在搜索领域，当用户发起一个网页请求，搜索客户端可将本次搜索条件作为当前处理请求的内容，选取集群中响应速度最快的服务器作为目标服务器，由该响应速度最快的服务器为用户提供本次搜索查询服务。

图6所示为本申请一实施例提供的一种集群调度方法中基于剩余计算能力调度策略的流程示意图。如图6所示，该基于剩余计算能力调度策略包括：

步骤601：获取可用服务器列表中每个可用服务器的剩余计算能力参数。

剩余计算能力参数用于表征可用服务器的剩余计算能力。在本申请一实施例中，可用服务器列表中可包括cpu服务器和gpu服务器任一类型的服务器。cpu服务器的剩余计算能力参数可为cpu服务器的线程池中的空闲线程数量，gpu服务器的剩余计算能力参数可为gpu服务器能够处理的视频信号路数。然而，本申请对剩余计算能力参数的具体内容不做限定。

步骤602：选择可用服务器列表中剩余计算能力参数最大的作为目标服务器。

通过基于剩余计算能力调度策略可更合理且高效地实现集群间服务器的负载均衡，充分调用集群中相对空闲的服务器的计算能力。例如，在视频信号处理领域，有些视频信号处理部分需要cpu来处理，有些视频信号处理部分需要gpu来计算。此时可将视频信号信息的处理作为当前处理请求，视频信号处理客户端可以选取集群中最空闲的cpu和最空闲的gpu来完成该当前处理请求，以获得最快的处理速度。由此可见，本申请所提供的集群调度方法其实支持同构和异构两种工作模式。当处于异构工作模式时，cpu可实时上报线程池可用空闲资源，gpu可实时上报计算资源，通过获取cpu和gpu的剩余计算能力参数，可实现异构工作模式下处理请求的动态调度。

在本申请一实施例中，用户指定的调度策略也可为自定义调度策略，基于用户自定义配置的服务器获取接口函数来确定目标服务器。具体而言，可基于用户自定义配置的反馈获取接口函数strategyfeedback()获取过往处理请求的反馈信息，然后将反馈信息输入服务器获取接口函数getserver()，以确定目标服务器。这样用户只需对该上述接口函数做逻辑功能实现，然后调用调度框架层的开放api接口并指定调度策略，即可完成新的调度策略的集成。

在本申请一实施例中，配置文件可包括外部服务注册中心的预设监控路径，通过监控外部服务注册中心的预设监控路径即可获取实时更新的可用服务器列表，然后根据用户指定的调度策略从可用服务器列表中选取目标服务器。该外部服务注册中心根据所获取的集群中各服务器的心跳信息实时更新可用服务器列表。

具体而言，如图7所示，本申请实施例所提供的集群调度方法可通过sdk(软件开发工具包)的形式实现，该sdk可被安装在服务消费端以使得服务消费端具备执行该集群调度方法的功能。集群中的服务器作为服务提供者向该外部服务注册中心上报心跳信息；服务消费端通过监听外部服务注册中心的预设监控路径以获取实时更新的可用服务器列表；当服务消费端确定了对应当前处理请求的目标服务器时，便会将当前处理请求分配给集群中的该目标服务器处理。

应当理解，外部服务注册中心可通过单个服务器或集群的形式实现，服务消费端的具体设备形态跟具体的应用场景有关。例如对于人脸识别或视频信号处理应用场景，服务消费端的设备形态就可以是摄像机、安装有摄像头的手机或个人电脑等，集群中的服务器则配置为可执行人脸识别任务。例如对于语音识别领域，服务消费端就可为安装有收音装置的智能移动终端，集群中的服务器则配置为可执行声纹识别任务。再例如对于搜索应用场景，服务消费端就可为带有供用户输入搜索条件的装置的智能移动终端，集群中的服务器则配置为可执行互联网搜索任务。然而，本申请对服务消费端的具体设备形态不做限定。

在一进一步实施例中，该外部服务注册中心可通过单个服务器或集群的形式实现，通过在该单个服务器或集群上安装zookeeper组件，便可实现对用于提供请求处理服务的集群中各服务器的心跳信息的监听功能。zookeeper组件是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

示例性集群调度装置

图8所示为本申请一实施例提供的一种集群调度装置的结构示意图。如图8所示，该集群调度装置80包括：配置加载模块801，配置为加载配置文件，其中配置文件包括用户指定的调度策略；目标服务器确定模块802，配置为根据用户指定的调度策略确定目标服务器；以及请求分配模块803，配置为将当前处理请求分配给目标服务器执行。

由此可见，本申请实施例提供的一种集群调度装置80，通过设置可加载的配置文件以获取用户指定的调度策略，将集群调度的执行逻辑划分为位于上层的调度策略层和位于底层的调度框架层，实现了一种调度策略的配置/执行和调度框架的配置/执行完全解耦的集群调度方式。这样用户可以通过调度框架层建立通用的通信交互框架配置，而不必考虑调度框架层的配置变化对于调度策略的影响，使得调度过程的执行摆脱了对应用场景的组件依赖和环境依赖，减少了额外的系统性能开销。同时，用户还可通过加载配置文件对调度策略进行自由配置，不必考虑对调度框架层已有配置的影响，从而大大提高了调度策略的可移植性和可扩展性。此外，由于用户还可根据实际场景需求对调度策略进行自定义配置，这样也节省掉了用户的学习和使用成本。

在本申请一实施例中，目标服务器确定模块802进一步配置为：根据过往处理请求的反馈信息以及用户指定的调度策略确定目标服务器。

在本申请一实施例中，如图9所示，集群调度装置80进一步包括：选择指令接收模块804，配置为接收用户的选择指令；以及选择指令执行模块805，配置为基于选择指令从至少一种预设调度策略中选择一个作为用户指定的调度策略。

在本申请一实施例中，如图9所示，集群调度装置80进一步包括：数据构成确定模块806，配置为确定待处理数据的数据包构成方式；其中，选择指令执行模块805进一步配置为：基于待处理数据的数据包构成方式，从至少一种预设调度策略中选择一个作为用户指定的调度策略。

在本申请一实施例中，待处理数据包括多个数据包，用户指定的调度策略为无状态轮询调度策略，目标服务器确定模块802进一步配置为：当处理待处理数据的第一个数据包时，从可用服务器列表中随机选取一个作为处理第一个数据包的目标服务器；以及当处理待处理数据的其他数据包时，按照其他数据包的连接顺序从可用服务器列表中轮询选择可用服务器作为处理其他数据包的目标服务器。

在本申请一实施例中，待处理数据包括依次连接的多个数据包，用户指定的调度策略为有状态调度策略，目标服务器确定模块802进一步配置为：当处理待处理数据的第一个数据包时，从可用服务器列表中随机选取一个作为处理第一个数据包的目标服务器；以及当处理待处理数据的其他数据包时，选择处理第一个数据包的目标服务器作为处理其他数据包的目标服务器。

在本申请一实施例中，从可用服务器列表中随机选取一个作为处理第一个数据包的目标服务器包括：获取第一个数据包的摘要信息；将摘要信息转为整数值；基于整数值与可用服务器列表中的可用服务器的数量，从可用服务器列表中确定一个可用服务器作为处理第一个数据包的目标服务器。

在本申请一实施例中，用户指定的调度策略为基于响应时间调度策略，目标服务器确定模块802进一步配置为：获取可用服务器列表中每个可用服务器的平均响应请求时间；以及选择可用服务器列表中平均响应请求时间最短的作为目标服务器。

在本申请一实施例中，如图9所示，集群调度装置80进一步包括：反馈获取模块807，配置为获取过往处理请求的反馈信息，其中反馈信息包括以下信息：处理是否成功、以及当前处理请求响应时间；以及反馈处理模块808，配置为当一个过往处理请求对应的反馈信息中包括处理未成功的信息时，将该过往处理请求对应的目标服务器的当前处理请求响应时间作为该过往处理请求对应的目标服务器的平均响应请求时间。

在本申请一实施例中，用户指定的调度策略为基于剩余计算能力调度策略，目标服务器确定模块802进一步配置为：获取可用服务器列表中每个可用服务器的剩余计算能力参数；选择可用服务器列表中剩余计算能力参数最大的作为目标服务器。

在本申请一实施例中，用户指定的调度策略为自定义调度策略，目标服务器确定模块802进一步配置为：基于用户自定义配置的反馈获取接口函数获取过往处理请求的反馈信息；将反馈信息输入服务器获取接口函数，以确定目标服务器。

在本申请一实施例中，如图10所示，配置文件包括外部服务注册中心810的预设监控路径，集群调度装置80进一步包括：监控模块809，配置为通过监控外部服务注册中心810的预设监控路径以获取实时更新的可用服务器列表；其中，目标服务器确定模块802进一步配置为：根据用户指定的调度策略从可用服务器列表中选取目标服务器；其中，外部服务注册中心810配置为：根据所获取的集群中各服务器的心跳信息实时更新可用服务器列表。

在本申请一实施例中，外部服务注册中心810基于zookeeper组件实现。

上述集群调度装置80中的各个模块的具体功能和操作已经在上面参考图1到图6描述的集群调度方法中进行了详细介绍，因此，这里将省略其重复描述。

需要说明的是，根据本申请实施例的集群调度装置80可以作为一个软件模块和/或硬件模块而集成到电子设备110中，换言之，该电子设备110可以包括该集群调度装置80。例如，该集群调度装置80可以是该电子设备110的操作系统中的一个软件模块，或者可以是针对于其所开发的一个应用程序；当然，该集群调度装置80同样可以是该电子设备110的众多硬件模块之一。

在本申请另一实施例中，该集群调度装置80与该电子设备110也可以是分立的设备(例如，服务器)，并且该集群调度装置80可以通过有线和/或无线网络连接到该电子设备110，并且按照约定的数据格式来传输交互信息。

示例性电子设备

图11所示为本申请一实施例提供的电子设备的结构示意图。如图11所示，该电子设备110包括：一个或多个处理器1101和存储器1102；以及存储在存储器1102中的计算机程序指令，计算机程序指令在被处理器1101运行时使得处理器1101执行如上述任一实施例的集群调度方法。

处理器1101可以是中央处理单元(cpu)或者具有数据处理能力和/或指令执行能力的其他形式的处理单元，并且可以控制电子设备中的其他组件以执行期望的功能。

存储器1102可以包括一个或多个计算机程序产品，所述计算机程序产品可以包括各种形式的计算机可读存储介质，例如易失性存储器和/或非易失性存储器。所述易失性存储器例如可以包括随机存取存储器(ram)和/或高速缓冲存储器(cache)等。所述非易失性存储器例如可以包括只读存储器(rom)、硬盘、闪存等。在所述计算机可读存储介质上可以存储一个或多个计算机程序指令，处理器1101可以运行所述程序指令，以实现上文所述的本申请的各个实施例的集群调度方法中的步骤以及/或者其他期望的功能。在所述计算机可读存储介质中还可以存储诸如光线强度、补偿光强度、滤光片的位置等信息。

在一个示例中，电子设备110还可以包括：输入装置1103和输出装置1104，这些组件通过总线系统和/或其他形式的连接机构(图11中未示出)互连。

例如，在该电子设备是如工业生产线上的机器人时，该输入装置1103可以是摄像头，用于捕捉待加工零件的位置。在该电子设备是单机设备时，该输入装置1103可以是通信网络连接器，用于从外部的可移动设备接收所采集的输入信号。此外，该输入设备1103还可以包括例如键盘、鼠标、麦克风等等。

该输出装置1104可以向外部输出各种信息，例如可以包括例如显示器、扬声器、打印机、以及通信网络及其所连接的远程输出设备等等。

当然，为了简化，图11中仅示出了该电子设备110中与本申请有关的组件中的一些，省略了诸如总线、输入装置/输出接口等组件。除此之外，根据具体应用情况，电子设备110还可以包括任何其他适当的组件。

示例性计算机程序产品和计算机可读存储介质

除了上述方法和设备以外，本申请的实施例还可以是计算机程序产品，包括计算机程序指令，计算机程序指令在被处理器运行时使得处理器执行如上述任一实施例的集群调度方法中的步骤。

计算机程序产品可以以一种或多种程序设计语言的任意组合来编写用于执行本申请实施例操作的程序代码，所述程序设计语言包括面向对象的程序设计语言，诸如java、c++等，还包括常规的过程式程序设计语言，诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。

此外，本申请的实施例还可以是计算机可读存储介质，其上存储有计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本说明书上述“示例性集群调度方法”部分中描述的根据本申请各种实施例的集群调度方法中的步骤。

所述计算机可读存储介质可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以包括但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器((ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。

以上结合具体实施例描述了本申请的基本原理，但是，需要指出的是，在本申请中提及的优点、优势、效果等仅是示例而非限制，不能认为这些优点、优势、效果等是本申请的各个实施例必须具备的。另外，上述公开的具体细节仅是为了示例的作用和便于理解的作用，而非限制，上述细节并不限制本申请为必须采用上述具体的细节来实现。

本申请中涉及的器件、装置、设备、系统的方框图仅作为例示性的例子并且不意图要求或暗示必须按照方框图示出的方式进行连接、布置、配置。如本领域技术人员将认识到的，可以按任意方式连接、布置、配置这些器件、装置、设备、系统。诸如“包括”、“包含”、“具有”等等的词语是开放性词汇，指“包括但不限于”，且可与其互换使用。这里所使用的词汇“或”和“和”指词汇“和/或”，且可与其互换使用，除非上下文明确指示不是如此。这里所使用的词汇“诸如”指词组“诸如但不限于”，且可与其互换使用。

还需要指出的是，在本申请的装置、设备和方法中，各部件或各步骤是可以分解和/或重新组合的。这些分解和/或重新组合应视为本申请的等效方案。

提供所公开的方面的以上描述以使本领域的任何技术人员能够做出或者使用本申请。对这些方面的各种修改对于本领域技术人员而言是非常显而易见的，并且在此定义的一般原理可以应用于其他方面而不脱离本申请的范围。因此，本申请不意图被限制到在此示出的方面，而是按照与在此公开的原理和新颖的特征一致的最宽范围。

为了例示和描述的目的已经给出了以上描述。此外，此描述不意图将本申请的实施例限制到在此公开的形式。尽管以上已经讨论了多个示例方面和实施例，但是本领域技术人员将认识到其某些变型、修改、改变、添加和子组合。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换等，均应包含在本申请的保护范围之内。