CN109062658A - 实现计算资源服务化的调度方法、装置、介质、设备及系统 - Google Patents

Abstract

本发明涉及一种实现计算资源服务化的调度方法，包括：利用闲置物理机来申请CPU受限虚拟机，构建计算资源池；接收到任务请求时，使用容器镜像打包封装用户程序代码以及代码所依赖的运行环境和相关库；根据资源池中每个虚拟机的负载情况和任务繁忙程度来调度任务请求；根据实时并发调用量自动增加、减少容器的数量。与现有技术相比，本发明充分利用闲置资源，并通过容器的按需调度和自动伸缩，实现了计算资源服务化。此外，本发明还涉及一种实现计算资源服务化的调度装置、介质、设备及系统。

Description

实现计算资源服务化的调度方法、装置、介质、设备及系统

技术领域

本发明涉及一种实现计算资源服务化的调度方法、装置、介质、设备及系统。

背景技术

互联网产品运营生命周期中，既需要申请计算资源以应对业务增长，也需要释放计算资源以避免业务低谷期的闲置浪费。传统上，运维人员需要订购物理服务器，选择机房安置机架，调试硬件，然后部署服务端软件程序，最后产品才能如期上线。这种人工运维方式效率低下，重复劳动多，每个环节流程繁琐，产品上线和迭代缓慢。此外，由于物理计算资源通常并不能被充分利用，大量服务器在业务低谷期负载极低，资源严重浪费。

虚拟化技术的成熟和IAAS(Infrastructure as a Service，基础设施即服务)云平台的兴起让运维人员不再需要关注物理设备的采购和上架，通过在线操作控制台即可进行资源的按需申请和随时释放。而随着Serverless(无服务器)的概念的兴起和计算资源服务化的实践成熟，以AWS Lambda为代表的Serverless产品，让开发者只需要关注业务逻辑的代码实现，无需关心资源的扩容，缩容，并且真正实现按代码运行时间付费，杜绝资源浪费。

然而，IAAS平台虽然让运维人员从采购安装上架物理设备等繁琐劳动中解放出来，但开发者依然需要为虚拟机安装操作系统和各种软件，运维人员需要手动关注计算，网络，存储资源的扩容和缩容。此外，虚拟机依然存在低负载资源浪费的情况。同时，AWSLambda的使用场景存在严重的局限性，例如，仅支持部分语言编写的代码；任务运行最大时间仅为5分钟，无法支持长时间离线任务程序；不支持持久化服务任务，每个请求都需要创建容器，难以做到低延迟(10ms内)响应等。其他业内类似的产品如阿里云函数计算和腾讯云函数同样存在上述问题。

发明内容

本发明的目的在于通过使用虚拟化和容器技术，实现计算资源服务化。

本发明的第一方面提供了一种实现计算资源服务化的调度方法，包括：

利用闲置物理机来申请CPU受限虚拟机，构建计算资源池；

接收到任务请求时，使用容器镜像打包封装用户程序代码以及代码所依赖的运行环境和相关库；

根据资源池中每个虚拟机的负载情况和任务繁忙程度来调度任务请求；

根据实时并发调用量自动增加、减少容器的数量。

与现有技术相比，本发明充分利用闲置资源，并通过容器的按需调度和自动伸缩，实现了计算资源服务化。

进一步地，在首次收到镜像的任务请求时选择多个虚拟机预下载容器镜像，并将后续请求优先调度到已存储该容器镜像的虚拟机中，随着镜像容器的调用量的增大，增加预下载容器镜像的虚拟机数量，以提高后续请求的响应速度。

进一步地，还包括将常见的通用算法模板封装成常驻服务，并在计算资源池中预先拉起常驻服务容器的步骤。从而避免为每个算法请求创建容器，减少用户调用耗时和系统的资源消耗，满足用户的低延迟场景。

进一步地，该方法还包括在容器结束销毁前，统计每个任务容器运行所占用CPU核时的步骤。最精细粒度的按需收费

进一步地，每个任务由两个不同的虚拟机同时运行，从而大幅降低节点宕机导致的任务失败的概率。

进一步地，在调度任务请求时，采用统一接入层均衡负载，将任务请求跨可用区调度，实现跨可用区(跨地域、跨机房)容灾。

本发明的第二方面提供了一种实现计算资源服务化的调度装置，包括：

资源池构建单元，被配置为利用闲置物理机来申请CPU受限虚拟机，构建计算资源池；

封装单元，被配置为在接收到任务请求时，使用容器镜像打包封装用户程序代码以及其所依赖的运行环境和相关库；

任务调度单元，被配置为根据资源池中每个虚拟机的负载情况和任务繁忙程度来调度任务请求；和

任务容器伸缩单元，被配置为根据实时并发调用量自动增加、减少容器的数量。

进一步地，该装置还包括镜像预热单元，被配置为在首次收到镜像的任务请求时选择多个虚拟机预下载容器镜像，并将后续请求优先调度到已存储该容器镜像的虚拟机中，随着镜像容器的调用量的增大，增加预下载容器镜像的虚拟机数量。

进一步地，该装置还包括持久化任务调度单元，被配置为将常见的通用算法模板封装成常驻服务，并在计算资源池中预先拉起常驻服务容器。

进一步地，该装置还包括统计单元，被配置为在容器结束销毁前，统计每个任务容器运行所占用CPU核时。

进一步地，每个任务由两个不同的虚拟机同时运行。

进一步地，该装置任务调度单元在调度任务请求时，采用统一接入层均衡负载，将任务请求跨可用区调度。

本发明的第三方面提供了一种设备，该设备包括处理器、存储器，处理器与存储器建立通信连接；

处理器，用于读取存储器中的程序，以执行前述第一方面或第一方面的任一实现方式提供的方法。

本发明的第四方面提供了一种非易失性存储介质，该非易失性存储介质中存储了程序，该程序被计算设备运行时，计算设备执行前述第一方面或第一方面的任一实现方式提供的方法。

本发明第五方面提供了一种系统，该系统包括多台物理机和前述第二方面或第二方面的任一实现方式提供的装置。

与现有技术相比，本发明能够充分利用云平台的大量物理机闲置，通过容器按需调度和销毁算法，让客户通过直接向云服务商提交任务请求即可直接使用云资源，并且无需关心资源的扩容、缩容等问题，实现了计算资源服务化；同时，由于使用容器镜像打包业务算法代码，使得算法的开发语言不受限制；而持久化容器机制，能够轻松支持低延迟任务需求；最大程度地方便用户的同时，有效降低了用户的运维成本。

附图说明

图1是根据本发明的实施例的实现计算资源服务化的调度方法的流程图。

图2是根据本发明的实施例的实现计算资源服务化的调度装置框图。

图3是根据本发明的实施例的任务调度流程示意图。

具体实施方式

下面结合具体实施例和附图对本发明做进一步说明。可以理解的是，此处描述的具体实施例仅仅是为了解释本发明，而非对本发明的限定。此外，为了便于描述，附图中仅示出了与本发明相关的部分而非全部的结构或过程。

本发明提出了一种基于容器技术的计算资源服务化的实现方案，使云服务商能够以API的方式实现计算资源的交付和应用程序的部署，自动伸缩以及高可用容灾。

如图1所示，根据本发明的一个实施例，提供一种计算资源服务化系统，该系统可以包括由多台物理机组成的物理机群200和实现计算资源服务化的调度装置100。其中，装置100可以包括：资源池构建单元101、封装单元102、任务调度单元103和任务容器伸缩单元104。

其中，资源池构建单元101被配置为充分利用云平台上的闲置资源，利用闲置物理机来申请CPU受限虚拟机，构建计算海量廉价的资源池。封装单元102被配置为在接收到任务请求时，使用容器镜像打包封装用户程序代码以及其所依赖的运行环境和相关库。使用容器镜像来打包业务算法代码，可以使算法开发不限制编程语言，克服了现有的Lambda等对编程语言的限制缺陷。任务调度单元103被配置为根据资源池中每个虚拟机的负载情况和任务繁忙程度来调度任务请求，实现容器的按需调度。任务容器伸缩单元104能够根据实时并发调用量自动增加、减少容器的数量实现弹性扩容，无需人工干预，使用户能够进一步提高效率。与现有技术相比，该系统能够充分利用物理机的闲置资源，通过容器的按需调度和自动伸缩，实现计算资源服务化。利用上述系统来实现计算资源服务化的详细工作过程将在后文描述。

可选择地，在一些实施方式中，除以上单元外，装置100还可以包括镜像预热单元、持久化任务调度单元和统计单元中的任意一项或多项。以上单元能够进一步提升计算资源服务，满足用户的更高要求。

其中，镜像预热单元能够在首次收到镜像的任务请求时选择多个虚拟机预下载容器镜像，并将后续请求优先调度到已存储该容器镜像的虚拟机中，随着镜像容器的调用量的增大，增加预下载容器镜像的虚拟机数量。通过这种方式可以提高响应速度，降低延迟。

持久化任务调度单元可以将常见的通用算法模板封装成常驻服务，并在计算资源池中预先拉起常驻服务容器，以避免为每个算法请求创建容器，减少用户调用耗时和系统的资源消耗，满足用户的低延迟场景。

统计单元可以被配置为在容器结束销毁前，精确统计每个任务容器运行所占用CPU核时(例如，可以是毫秒级)，通过对计算任务的实时追踪和精确统计，让用户仅需为程序所消耗的实际核时付费。

在本实施例中，装置100可以被包含在任意用于处理数据的各种装置、设备和机器中，例如可编程处理器、计算机、工作站或服务器等。其中包含的各个单元模块可以是专用逻辑电路或用于实现相应功能的代码、软件、逻辑或例程等。

下面结合图2介绍利用上述系统实现计算资源服务化的具体方法的实例。

如图2所示，根据本发明的一个实施例，提供一种实现计算资源服务化的调度方法。

首先，步骤S101，利用闲置物理机来申请CPU受限虚拟机，构建计算资源池。

此处，可以通过Cgroup(control group，控制组)CPU权重控制实现申请受限计算节点(即，虚拟机)组建海量廉价计算资源池，可以将用于构建该计算资源池的虚拟机的资源限制在较低的优先级，这样这台虚拟机不会影响服务器上其他程序或其他虚拟机的正常使用，使得云平台的大量闲置计算资源能得到充分利用，同时在云平台负载繁忙的时候让出CPU使用权。在资源池中，可以将500-700个计算节点编为一个集合，使用Zookeeper来协同调度这些节点，并进行节点的实时数据收集、服务发现和故障自动剔除。每个计算节点可以运行Agent程序来用于创建和销毁任务容器。

随后，步骤S102，接收到任务请求时，使用容器镜像打包封装用户程序代码以及代码所依赖的运行环境和相关库。

例如，可以使用目前常用的开源的应用容器引擎Docker打包封装用户程序代码以及其所依赖的运行环境、相关库，并使用Docker镜像仓库实现算法镜像存储。使用这种容器镜像来打包业务算法代码，可以使算法开发不限制编程语言，克服了现有的Lambda等对编程语言的限制缺陷，用户只需关心自身业务代码的实现，开发语言不受任何限制。

随后，步骤S103，为资源池中每个计算节点调度任务请求；调度器可以根据每个节点的负载情况和任务繁忙程度将新的任务请求调度到最合适的节点上；同时，步骤S104，可以根据实时并发调用量自动增加、减少容器的数量。这样可以根据实时调用量自动伸缩，弹性扩容，而无需人工干预。

例如，提交任务请求协议可以是HTTP协议，系统能根据HTTP头部、URI(UniformResource Identifier，统一资源标识符)以及BODY(主体)中的任何自定义字段将请求流量调度到任意指定计算资源池，以实现自由可控的灰度发布和故障切换。通过调度器的实时调度和和局实时调用量自动伸缩容器，每个计算节点以及每个计算资源池的调度器均实现过载保护，在任务量突发暴增的极端情况下依然可以提供所承诺的计算资源服务能力。

在该实施例中，可选择地，每个同步任务可以由两个不同的计算节点同时运行，以大幅降低节点宕机导致的任务失败的概率。同时，接入层也可以使用负载均衡技术，将任务请求调度到分布在各个可用区的计算节点，实现高可用和跨可用区容灾。

下面结合图3说明根据本发明的实施例的任务调度流程。

如图3所示，根据本发明的一个实施例，计算系统的API网关将用户提交的HTTP请求报文转化后发给任务管理器，同时可以处理计费、鉴权等各种需要的上层业务。包含调度器的任务管理器调度并分发任务给XCT(Executor，执行器)节点，并将执行结果存储于UMEM，同时可以根据实时并发调用量自动增加、减少XCT节点中容器的数量。XCT节点执行用户提交的任务，并将任务返回给任务管理器，同时将自身负载情况以及当前运行任务数等信息定时汇报给Zookeeper集群。Zookeeper集群收集所有XCT节点的运行信息，例如负载、运行任务数等，并将所收集的信息发送给任务管理器，同时，系统中还包含备用任务管理器，用于容灾。

与现有技术相比，本发明能够充分利用云平台的大量物理机闲置，通过容器按需调度和自动伸缩，实现计算资源服务化，同时，由于使用容器镜像打包业务算法代码，使得算法的开发语言不受限制，更为方便易用，同时大幅降低了用户的运维成本。

需要注意的是，以上步骤编号仅仅是为了说明方便，并不是对步骤顺序的限制，在各种实施方式中，可以根据需要采用各种顺序来实现本发明。

在一些实施方式中，提供云平台的服务商需要对订购资源的用户进行收费，此时，在容器结束销毁前，可以精确追踪和统计每个容器运行所占用CPU核时(例如，毫秒级)，并依此收费，从而实现最细粒度的按需收费，使用户仅为实际程序运行的时间买单，同时杜绝了限制资源浪费。

此外，根据本发明的一个实施例，在上文所述的计算资源服务化实现方案中，为了避免节点运行任务前先要下载镜像，导致每次任务的响应延迟时间较长，难以满足低延迟需求，可以利用上文所述的镜像预热单元，使任务调度器在第一次收到某镜像的任务请求后先选择一批节点预下载该容器。这样除了第一次任务请求可能会有较高的响应时间，后续请求可以优先调度到本地已存储该镜像的节点中，有效降低了延迟。随着该镜像容器的调用量逐渐增大，可以随之逐渐增加被选择预热镜像的节点，通过这种方式，计算节点在收到后续创建任务请求时，无需再下载任务容器镜像，直接启动容器即可，能够有效提高响应速度。

同样为提高响应速度，在一些实施例中，本发明还可以通过持久化任务机制将常见的通用算法模板封装成常驻服务，避免为每个算法请求创建容器，减少用户调用耗时和系统的资源消耗，从而满足用户的低延迟场景。

在该持久化任务机制中，系统在各个计算资源池中预先拉起任务容器常驻程序，该程序能监听端口对外提供HTTP服务。程序收到请求后会自动执行相关算法程序并返回运行结果给调用方。用户通过HTTP API提交持久化容器任务请求后，请求流量通过负载均衡后进入路由服务，路由服务会根据用户请求中指定的资源配置将请求导入对应的资源池的入口。资源池入口收到任务请求后，根据用户指定的算法将请求流量转发到资源池里预先拉起的常驻算法容器服务，并将算法执行结果返回给用户。同时，系统会根据各个算法的实时调用频率和常驻服务容器的负载情况自动对常驻服务容器进行自动扩容和缩容。由此，系统无需为响应每个请求重复启动容器，实现了低延迟响应。除了HTTP以外，该持久化任务机制还能够支持Protubuf和GRPC等请求类型。

在一些实施方式中，本发明还可以使用异步任务机制来支持用户的离线长任务需求。去除了Lambda等平台中对程序最大运行时间仅为5分钟的限制。

根据本发明的另一个实施例，还提供了一种计算设备，包括处理器和存储器，处理器和存储器建立通信连接，所述处理器，用于读取存储器中的程序，以执行图2中的实现计算资源服务化的调度方法。

根据本发明的另一个实施例，还提供了一种非易失性存储介质，所述非易失性存储介质中存储了程序，该程序被计算设备运行时，所述计算设备执行图2中的实现计算资源服务化的调度方法。

上面结合附图对本发明的实施例做了详细说明，但本发明技术方案的使用不仅仅局限于本专利实施例中提及的各种应用，各种结构和变型都可以参考本发明技术方案轻易地实施，以达到本文中提及的各种有益效果。在本领域普通技术人员所具备的知识范围内，在不脱离本发明宗旨的前提下做出的各种变化，均应归属于本发明专利涵盖范围。

Claims (15)

1.一种实现计算资源服务化的调度方法，其特征在于，包括：

利用闲置物理机来申请CPU受限虚拟机，构建计算资源池；

接收到任务请求时，使用容器镜像打包封装用户程序代码以及代码所依赖的运行环境和相关库；

根据所述资源池中每个虚拟机的负载情况和任务繁忙程度来调度任务请求；

根据实时并发调用量自动增加、减少所述容器的数量。

2.根据权利要求1所述的实现计算资源服务化的调度方法，其特征在于，在首次收到镜像的任务请求时选择多个虚拟机预下载容器镜像，并将后续请求优先调度到已存储该容器镜像的虚拟机中，随着所述镜像容器的调用量的增大，增加预下载容器镜像的虚拟机数量。

3.根据权利要求1所述的实现计算资源服务化的调度方法，其特征在于，该方法还包括将常见的通用算法模板封装成常驻服务，并在所述计算资源池中预先拉起常驻服务容器的步骤。

4.根据权利要求1所述的实现计算资源服务化的调度方法，其特征在于，该方法还包括在容器结束销毁前，统计每个任务容器运行所占用CPU核时的步骤。

5.根据权利要求1所述的实现计算资源服务化的调度方法，其特征在于，每个任务由两个不同的虚拟机同时运行。

6.根据权利要求1所述的实现计算资源服务化的调度方法，其特征在于，在调度任务请求时，采用统一接入层均衡负载，将所述任务请求跨可用区调度。

7.一种实现计算资源服务化的调度装置，其特征在于，包括：

资源池构建单元，被配置为利用闲置物理机来申请CPU受限虚拟机，构建计算资源池；

封装单元，被配置为在接收到任务请求时，使用容器镜像打包封装用户程序代码以及其所依赖的运行环境和相关库；

任务调度单元，被配置为根据所述资源池中每个虚拟机的负载情况和任务繁忙程度来调度任务请求；和

任务容器伸缩单元，被配置为根据实时并发调用量自动增加、减少所述容器的数量。

8.根据权利要求7所述的实现计算资源服务化的调度装置，其特征在于，还包括镜像预热单元，被配置为在首次收到镜像的任务请求时选择多个虚拟机预下载容器镜像，并将后续请求优先调度到已存储该容器镜像的虚拟机中，随着所述镜像容器的调用量的增大，增加预下载容器镜像的虚拟机数量。

9.根据权利要求7所述的实现计算资源服务化的调度装置，其特征在于，还包括持久化任务调度单元，被配置为将常见的通用算法模板封装成常驻服务，并在所述计算资源池中预先拉起常驻服务容器。

10.根据权利要求7所述的实现计算资源服务化的调度装置，其特征在于，还包括统计单元，被配置为在容器结束销毁前，统计每个任务容器运行所占用CPU核时。

11.根据权利要求7所述的实现计算资源服务化的调度装置，其特征在于，每个任务由两个不同的虚拟机同时运行。

12.根据权利要求7所述的实现计算资源服务化的调度装置，其特征在于，所述任务调度单元在调度任务请求时，采用统一接入层均衡负载，将所述任务请求跨可用区调度。

13.一种设备，其特征在于，包括处理器、存储器，所述处理器与所述存储器建立通信连接；

所述处理器，用于读取所述存储器中的程序，以执行如权利要求1-6中任一项所述的方法。

14.一种非易失性存储介质，其特征在于，所述非易失性存储介质中存储了程序，该程序被计算设备运行时，所述计算设备执行如权利要求1-6中任一项所述的方法。

15.一种计算资源服务化系统，其特征在于，包括多台物理机和如权利要求7-12中任一项所述的装置。