任务处理方法、装置、电子设备及可读存储介质与流程

1.本申请涉及任务处理技术领域，具体而言，本申请涉及一种任务处理方法、装置、电子设备及可读存储介质。


背景技术：

2.随着互联网通信技术的发展，互联网在人们日常的学习、工作和生活中得到广泛的应用，大量事务在线上进行处理。随着业务的不断增长，对互联网业务系统中设备的处理性能也提出了巨大的挑战。
3.现有的业务系统的的容器操作平台中，通过不同的执行器分别执行不同的任务，当业务高峰期任务数量较大，执行器的数量已经不能满足业务要求时，任务控制器会根据任务数量对执行器的数量进行调整，但创建新的执行器需要消耗一定的时间，会造成任务的延时处理，降低任务处理效率。


技术实现要素：

4.本申请的目的旨在至少能解决上述的技术缺陷之一，特提出以下技术方案：第一方面，提供了一种任务处理方法，包括：监听调用接口服务；所述调用接口服务用于接收用户终端发送的资源池创建请求，基于所述创建请求创建资源池；所述资源池中包括至少一个执行器；若监听到所述调用接口服务创建资源池，则对所述资源池进行维护；针对维护中的所述资源池，监测所述资源池的实时状态信息；所述实时状态信息包括所述资源池中执行器的实时数量以及每一执行器的实时工作状态；基于所述资源池的实时状态信息针对所述资源池中的执行器的实时数量进行调节，以使所述资源池中的至少一个执行器对分别处理对应的任务。
5.第二方面，提供了一种任务处理装置，包括：监听模块，用于监听调用接口服务；所述调用接口服务用于接收用户终端发送的资源池创建请求，基于所述创建请求创建资源池；所述资源池中包括至少一个执行器；维护模块，用于若监听到所述调用接口服务创建资源池，则对所述资源池进行维护；监测模块，用于针对维护中的所述资源池，监测所述资源池的实时状态信息；所述实时状态信息包括所述资源池中执行器的实时数量以及每一执行器的实时工作状态；调节模块，用于基于所述资源池的实时状态信息针对所述资源池中的执行器的实时数量进行调节，以使所述资源池中的至少一个执行器对分别处理对应的任务。
6.第三方面，提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时实现本申请第一方面所示的任务处理方法。
7.第四方面，提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现本申请第一方面所示的任务处理方法。
8.本申请提供的技术方案带来的有益效果是：资源池控制器通过监测所述资源池的实时状态信息，即监测资源池中的执行器的实时数量以及每一执行器的实时工作状态，判断资源池是否处于繁忙情况，根据资源池的实时状态信息对资源池中的执行器的实时数量进行调节，可以在资源池中执行器处于满负荷之前，对执行器的数量进行增加，避免在执行器的数量已经不能满足业务要求时再对执行器的数量进行调整，从而节省满负荷后创建新的执行器所消耗的时间，有效避免任务的延时处理，提高任务的处理效率。
9.进一步的，根据资源池的实时状态信息对资源池中的执行器的实时数量进行调节，还可以在资源池处于空闲状态时减少执行器的数量，有效节省任务处理资源。
10.本申请附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本申请的实践了解到。
附图说明
11.本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：图1为现有技术进行任务处理的方案的流程示意图；图2为本申请实施例提供的一种任务处理方法的应用场景图；图3为本申请实施例提供的一种任务处理方法的流程示意图；图4为本申请实施例提供的一种任务处理方法的流程示意图；图5为本申请一个示例中执行器的结构示意图；图6为本申请一个示例提供的任务处理方案的示意图；图7为本申请一个示例提供的容器操作平台的结构示意图；图8为本申请一个示例提供的任务处理方案的示意图；图9为本申请实施例提供的一种任务处理装置的结构示意图；图10为本申请实施例提供的一种任务处理的电子设备的结构示意图。
具体实施方式
12.下面详细描述本申请的实施例，实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本申请的限制。
13.本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。
14.为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。
15.云技术（cloud technology）是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。
16.云技术（cloud technology）基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。
17.云计算(cloud computing)是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。
18.作为云计算的基础能力提供商，会建立云计算资源池(简称云平台，一般称为iaas(infrastructure as a service，基础设施即服务)平台，在资源池中部署多种类型的虚拟资源，供外部客户选择使用。云计算资源池中主要包括：计算设备(为虚拟化机器，包含操作系统)、存储设备、网络设备。
19.按照逻辑功能划分,在iaas（infrastructure as a service，基础设施即服务）层上可以部署paas(platform as a service,平台即服务)层，paas层之上再部署saas (software as a service,软件即服务)层，也可以直接将saas部署在iaas上。paas为软件运行的平台，如数据库、web容器等。saas为各式各样的业务软件，如web门户网站、短信群发器等。一般来说，saas和paas相对于iaas是上层。
20.本申请实施例提供的方案，涉及云计算的任务处理技术。
21.区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链（blockchain），本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性（防伪）和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。
22.区块链底层平台可以包括用户管理、基础服务、智能合约以及运营监控等处理模块。其中，用户管理模块负责所有区块链参与者的身份信息管理，包括维护公私钥生成（账户管理）、密钥管理以及用户真实身份和区块链地址对应关系维护（权限管理）等，并且在授权的情况下，监管和审计某些真实身份的交易情况，提供风险控制的规则配置（风控审计）；基础服务模块部署在所有区块链节点设备上，用来验证业务请求的有效性，并对有效请求完成共识后记录到存储上，对于一个新的业务请求，基础服务先对接口适配解析和鉴权处理（接口适配），然后通过共识算法将业务信息加密（共识管理），在加密之后完整一致的传输至共享账本上（网络通信），并进行记录存储；智能合约模块负责合约的注册发行以及合约触发和合约执行，开发人员可以通过某种编程语言定义合约逻辑，发布到区块链上（合约注册），根据合约条款的逻辑，调用密钥或者其它的事件触发执行，完成合约逻辑，同时还提供对合约升级注销的功能；运营监控模块主要负责产品发布过程中的部署、配置的修改、合约设置、云适配以及产品运行中的实时状态的可视化输出，例如：告警、监控网络情况、监控
节点设备健康状态等。
23.平台产品服务层提供典型应用的基本能力和实现框架，开发人员可以基于这些基本能力，叠加业务的特性，完成业务逻辑的区块链实现。应用服务层提供基于区块链方案的应用服务给业务参与方进行使用。
24.本申请的任务处理方案中，可以将任务处理结果存储于区块链中。
25.以下将对本申请方案涉及的名词进行解释。
26.kubernetes，可称为k8s，是一款开源的容器操作平台，其可以实现将若干个容器组合成一个服务及动态地分配容器运行的主机等功能，为用户使用容器提供了极大的便利。
27.job：作为kubernetes中的资源对象，可以定义并启动一个批处理任务job，job也控制一组短暂运行的pod，其中，pod是封装有一个或多个容器的高级结构；其中的每个docker容器都仅仅运行一次。当job控制的所有pod副本都运行结束时，对应的job也就结束了。
28.kubernetes原生提供的job工作负载可以定义并启动一个批处理任务job。原生提供的hpa（horizontal pod autoscaler，pod自动弹性伸缩）目前可以实现为基于自定义指标的扩缩容。job controller（任务控制器）负责创建相对应的pod，并跟踪job的状态，及时根据pod的一些配置重试或者继续创建。每个pod都有对应的标签跟踪它所属的任务控制器。用户可以使用hpa自定义指标，定义扩缩容策略。任务控制器会检查是否有指定数量运行的pod，如果没有的话，通过扩容把这个pod创建出来；如果有或者大于这个值，会对多余的pod进行缩容。
29.hpa是kubernetes的一种资源对象，能够根据某些指标对pod数量进行动态伸缩，使运行在上面的服务对指标的变化有一定的自适应能力。
30.crd（customresourcedefinition，自定义资源类型）是kubernetes中已定义的资源对象可以满足大多数分布式系统部署的需求。
31.但是在不同应用业务环境下，对于平台可能有一些特殊的需求，这些需求可以抽象为 kubernetes 的扩展资源，而 kubernetes 的 crd为这样的需求提供了轻量级的机制，保证新的资源的快速注册和使用。
32.用户可以向 kubernetes api（application programming interface，应用程序接口）服务注册一个带特定的资源，并定义相关 api。将扩展资源的数据存储到 kubernetes 的集群，并借助 kubernetes 提供的控制器模式开发框架，实现新的控制器，并借助 api服务监听集群关于该资源的状态并定义状态变化的处理逻辑。
33.kubernetes中的controller（控制器）模式：kubernetes借鉴了传统控制器模式的思想，包含一组内置控制器。一种控制器至少追踪一种类型的kubernetes资源，这些对象有一个代表期望状态的指定字段，控制器负责确保其追踪的资源对象的当前状态接近期望状态。在kubernetes内部，所有的资源对象均包含对象元数据，spec(期望)，status(运行状态)。通过kubernetes api创建/更新/删除资源对象，控制器会监听资源对象事件（创建/更新/删除），并通过循环控制来协调资源对象趋向期望状态。
34.以处理图片地址的场景为例，如图1所示，用户拍照后，使用客户端就近上传至对
象存储服务cos（cloud object service，对象存储服务），使用cos存储地址，配合其他参数，请求后端服务，将针对图片地址的处理请求发送至负载均衡（cloud load balancer，clb），由clb提供安全快捷的流量分发服务，访问流量经由 clb 可以自动分配到云中的多台云服务器上，扩展系统的服务能力并消除单点故障。后端服务包括多个cvm（云服务器），每一cvm中设置有application容器（应用容器），即图中所示的cvm1至cvmn。该后端服务qps（query per second，每秒请求数）较低，为0.1，即处理一个请求需要10s。另外，该业务应用没有实现队列等待，应用服务无法并行处理多个请求，如果两个请求落到同一个后端服务器上，且前一个任务未处理完的话，会返回内部错误响应消息。
35.针对上述情况，现有的kubernetes集群上，业务应用采用容器化pod的形式部署，任务请求陡增，服务过载，开发者发现后对该业务进行紧急扩容，但是其业务应用镜像很大，镜像拉取花费较长时间，且业务应用程序本身初始化时间也较长。因此无法做到临时快速扩容来应对业务高峰。另外，该应用无法做到并行处理请求。
36.本申请提供的任务处理方法、装置、电子设备及计算机可读存储介质，旨在解决现有技术的如上技术问题。
37.下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。
38.如图2所示，本申请的任务处理方法，可以应用于图2所示的场景中，具体的，服务器20中的资源池控制器201监听调用接口服务202，调用接口服务202接收用户终端10发送的资源池创建请求，基于所述创建请求创建资源池203，所述资源池中包括至少一个执行器2031；资源池控制器201对所述资源池203进行维护，确定所述资源池203的实时状态信息；调用接口服务202接收用户终端10发送的任务处理请求，资源池控制器201基于所述资源池的实时状态信息针对所述资源池中的执行器2031的数量进行调节，资源池203中的执行器2031对分别处理对应的任务。
39.本技术领域技术人员可以理解，这里所使用的“终端”可以是手机、平板电脑、pda（personal digital assistant，个人数字助理）、mid（mobile internet device，移动互联网设备）等；“服务器”可以用独立的服务器或者是多个服务器组成的服务器集群来实现。
40.本申请实施例中提供了一种可能的实现方式，如图3所示，提供了一种任务处理方法，该方法可以应用于容器操作平台中的资源池控制器，可以包括以下步骤：步骤s301，监听调用接口服务。
41.具体的，调用接口服务用于接收用户终端发送的资源池创建请求，基于创建请求创建资源池（executor pool），资源池中包括至少一个执行器，执行器用于对任务进行处理。
42.以容器操作平台为kubernetes集群为例，调用接口服务可以为kube
‑
apiserver，其中，kube
‑
apiserver为kubernetes集群的进程。
43.具体的，用户终端可以指定创建的资源池属性，属性可以包括资源池的名称、资源池的类型、执行器的初始数量、最大数量等等。
44.步骤s302，若监听到调用接口服务创建资源池，则对资源池进行维护。
45.在具体实施过程中，资源池控制器（executor pool controller）可以持续监听调
用接口服务，等待需要处理的资源池。
46.具体的，若资源池控制器监听到新建的资源池，则根据预定义的配置参数维护新建的资源池。
47.步骤s303，针对维护中的资源池，监测资源池的实时状态信息。
48.其中，实时状态信息包括资源池中执行器的实时数量以及每一执行器的实时工作状态。
49.具体的，步骤s303的监测资源池的实时状态信息可以基于如下至少一种条件触发：（1）检测到当前时间位于预设时间段或预设周期中；（2）接收到状态确定指令。
50.也就是说，资源池控制器可以定时轮询资源池中的执行器的数量，以及每一执行器的实时工作状态，确定资源池的繁忙情况；资源池控制器还可以响应于接收到的状态确定指令，确定资源池的繁忙情况和执行器的数量。
51.步骤s304，基于资源池的实时状态信息针对资源池中的执行器的实时数量进行调节，以使资源池中的至少一个执行器对分别处理对应的任务。
52.具体的，若资源池的实时状态信息反映资源池处于繁忙情况中，则可以对资源池进行扩容，即增加资源池中的执行器的实时数量；若资源池的实时状态信息反映资源池处于空闲情况中，则可以对资源池进行缩容，即减少资源池中的执行器的实时数量，这样可以维持资源池中有足够的执行器处理任务，且避免过多的执行器处于空闲状态而造成资源浪费。
53.针对执行器的实时数量调节的具体方式将在下文进行详细阐述。
54.上述实施例中，资源池控制器通过监测资源池的实时状态信息，即监测资源池中的执行器的实时数量以及每一执行器的实时工作状态，判断资源池是否处于繁忙情况，根据资源池的实时状态信息对资源池中的执行器的实时数量进行调节，可以在资源池中执行器处于满负荷之前，对执行器的数量进行增加，避免在执行器的数量已经不能满足业务要求时再对执行器的数量进行调整，从而节省满负荷后创建新的执行器所消耗的时间，有效避免任务的延时处理，提高任务的处理效率。
55.以下将结合附图和实施例进一步阐述针对资源池中的执行器的实时数量进行调节的具体过程。
56.在一种实施方式中，可以结合扩缩容规则信息和实时状态信息对执行器的数量进行调节。
57.本申请实施例中提供了一种可能的实现方式，资源池创建请求中携带有资源池的扩缩容规则信息；步骤s304的基于资源池的实时状态信息针对资源池中的执行器的实时数量进行调节，可以包括：基于扩缩容规则信息以及实时状态信息，针对资源池中的执行器的实时数量进行调节。
58.在一种实施方式中，扩缩容规则信息可以包括若资源池处于繁忙状态，即处于工作状态的执行器的数量大于第一预设占比，例如，处于工作状态的执行器的数量大于80%，或者是处于工作状态的执行器的数量大于第一预设数量，则进行扩容；若资源池处于空闲
状态，即处于工作状态的执行器的数量小于第二预设占比，例如，处于工作状态的执行器数量小于20%，或者是处于工作状态的执行器的数量小于第二预设数量，则进行缩容。
59.具体的，基于扩缩容规则信息以及实时状态信息，针对资源池中的执行器的实时数量进行调节，可以包括：若基于实时状态信息确定处于工作状态的执行器的数量与资源池中的执行器的当前总数量之间的比值大于或等于第一预设阈值，则基于扩缩容规则信息增加资源池中的执行器的实时数量；若基于实时状态信息确定处于工作状态的执行器的数量与资源池中的执行器的当前总数量之间的比值小于第二预设阈值，则基于扩缩容规则信息减少资源池中的执行器的实时数量。
60.在具体实施过程中，扩缩容规则信息中该可以包括若处于工作状态的执行器的数量与资源池中的执行器的当前总数量之间的比值在不同的范围区间，则对应增加或减少的执行器的实施数量的范围。
61.例如，若处于工作状态的执行器的数量与资源池中的执行器的当前总数量之间的比值大于80%，则对应增加当前总数量的20%数量的执行器；若处于工作状态的执行器的数量与资源池中的执行器的当前总数量之间的比值小于80%，则对应减少当前总数量的20%数量的执行器。
62.在另一种实施方式中，可以结合历史状态记录和实时状态信息对执行器的数量进行调节。
63.本申请实施例中提供了一种可能的实现方式，步骤s303的基于资源池的实时状态信息针对资源池中的执行器的实时数量进行调节之前，还可以包括：获取资源池的历史状态记录。
64.其中，历史状态记录包括资源池中的执行器的历史数量变化记录以及对应的执行器的历史工作状态记录。
65.例如，历史状态记录可以包括资源池中的执行器在不同的时间段分别对应的历史数量变化，以及在每一时间段内每一执行器的工作状态记录。
66.步骤s304的基于资源池的实时状态信息针对资源池中的执行器的实时数量进行调节，可以包括：基于历史状态记录与实时状态信息，针对资源池中的执行器的实时数量进行调节。
67.如图4所示，基于历史状态记录与实时状态信息，针对资源池中的执行器的实时数量进行调节，可以包括：步骤s410，基于历史状态记录预测执行器的下一时间段的预测状态信息；步骤s420，基于预测状态信息与实时状态信息，针对资源池中的执行器的实时数量进行调节。
68.具体的，可以结合不同时间段的历史状态记录的变化规律，来预测下一时间段的预测状态信息，例如，每天晚上9点至11点之间执行器的数量均增加50%，则可以在8点50即预先将执行器的数量增加50%。
69.在具体实施过程中，还可以结合神经网络模型预测下一时间段的预测状态信息，
可以将不同时间段的历史状态记录、不同历史时间段作为训练样本对神经网络模型进行预测，得到预测模型，再将当前时间对应的执行器数量和当前时间输入到预测模型，即可得到下一时间段的预测状态信息。
70.具体的，若预测状态信息中预测的处于工作的执行器的数量大于实时状态信息中处于工作状态的执行器的数量，则可以增加执行器的数量；若预测状态信息中预测的处于工作的执行器的数量小于实时状态信息中处于工作状态的执行器的数量，则可以减少执行器的数量。
71.在另一些实施方式中，还可以结合扩缩容规则信息、预测状态信息和实时状态信息，对执行器的实时数量进行调节。
72.本申请实施例中提供了一种可能的实现方式，还包括：将实时状态信息更新至历史状态记录中。
73.具体的，可以将实时状态信息更新至历史状态记录中，以对历史状态记录进行不断完善，从而提高预测状态信息的准确性，以便于更加准确的对执行器的实时数量进行调节。
74.在另一种实施方式中，还可以先判断资源池的类型，然后再对执行器的数量进行调节。
75.本申请实施例中提供了一种可能的实现方式，资源池创建请求中携带有资源池的类型；资源池的类型包括动态资源池（dynamic executor pool）或固定资源池（fixed executor pool）。
76.步骤s304的基于资源池的实时状态信息针对资源池中的执行器的实时数量进行调节，可以包括：若资源池的类型为动态资源池，则基于资源池的实时状态信息针对资源池中的执行器的实时数量进行调节。
77.具体的，动态资源池中的执行器的实时数量可以调节，若资源池的类型为动态资源池，则针对实时数量进行调节。
78.上述实施例中阐述了针对资源池中的执行器的数量进行调节的多种方式，以下将结合具体实施例阐述执行器对任务处理的具体过程。
79.具体的，执行器（可以为pod）中设置有第一容器和第二容器，如图5所示，以容器操作平台为kubernetes集群为例，第一容器可以是边车容器，第二容器可以是应用容器。
80.在具体实施过程中，执行器可以基于如下方式处理对应的任务：（1）第一容器监听到任务控制器分配的任务，将任务序列化到本地文件中；（2）第二容器检测到序列化的任务文件，执行任务，得到任务结果；（3）第一容器将任务结果发送到数据库中存档。
81.以容器操作平台为kubernetes集群为例，用户终端发送任务处理请求到调用接口服务（即kube
‑
apiserver），调用接口服务创建任务资源（task crd资源）；任务控制器（task controller）监听到待处理的任务时，开始调度任务；任务控制器根据任务处理请求中指定的资源池，从指定的资源池中确定一个适用的执行器，将任务分配给该执行器处理。
82.执行器中的第一容器，可以为边车容器（sidecar容器）监听到待处理的任务时，解析任务后序列化到本地文件中；其中，边车容器也可称为边斗容器；执行器中的第二容器，
即应用容器监听到存在任务文件后，则根据业务逻辑，开始处理任务，得到对应的任务处理结果，边车容器将任务处理结果输出到数据存储平台中持久化归档。
83.为了更好地理解上述任务处理方法，如图6所示，以下详细阐述一个本发明的任务处理方法的示例：在一个示例中，本申请提供的任务处理方法，可以应用于图像地址处理场景，具体可以包括如下步骤：用户终端上传图像对象存储服务，取得图像对象存储服务地址；用户终端请求转化为调用调用接口服务，创建任务资源，任务中包括图片对象存储服务地址和用户自定义参数；任务被任务控制器分配到由资源池控制器维护的资源池中一个空闲的执行器中；执行器中的边车容器监听到后，将任务取出，序列化到执行器本地文件中；应用容器发现文件存在后，开始执行任务；任务执行完后，边车容器将任务结果输出到数据存储平台中持久化归档。
84.在上述过程中，资源池控制器周期性监听调用接口服务，当业务高峰期出现时，根据历史数据和最近前几个周期资源池的繁忙情况，做资源池的扩缩容，可以实现执行器的预拉起以及资源池的动态管理，既能实时支持任务执行，又可以在业务高峰期自动扩容，在业务低谷期缩容，合理利用资源。
85.以容器操作平台为kubernetes集群为例，以下将对容器操作平台的具体结构进行具体阐述。
86.在一个示例中，如图7所示，容器操作平台可以包括如下结构：控制器：包括任务控制器和资源池控制器；其中资源池控制器又可以包括动态资源池控制器和固定资源池控制器；动态资源池控制器用于维护动态资源池，定时轮询动态资源池的实时状态信息；固定资源池控制器用于维护固定资源池；调用接口服务（kube
‑
apiserver）：用于根据用户终端的资源创建请求创建任务资源；根据用户的资源池创建请求创建资源池；动态资源池：包括至少一个执行器，即包括至少一个执行器，每一个执行器中包括边车容器和应用容器；固定资源池：包括至少一个执行器，每一个执行器中包括边车容器和应用容器。
87.其中，动态资源池和固定资源池中的边车容器和应用容器均相同；边车容器用于监听到待处理的任务时，解析任务后序列化到本地文件中；应用容器用于监听到存在任务文件后，则根据业务逻辑，开始处理任务，得到对应的任务处理结果，边车容器再将任务处理结果输出到数据存储平台中持久化归档。
88.为了更好地理解上述任务处理方法，如图8所示，以下详细阐述一个本发明的任务处理方法的示例：在一个示例中，容器操作平台为kubernetes集群为例，本申请提供的任务处理方法，具体可以包括如下步骤：用户终端调用调用接口服务创建一个执行池资源，指定资源池的类型（动态资源池或固定资源池）、名称和初始化参数配置（应用容器的镜像、执行器的初始数量、最大数量、扩缩容规则信息等）；
资源池控制器持续监听调用接口服务，等待需要处理的资源池；资源池控制器监听到新建的资源池后，根据定义中的配置来维护一个资源池，定时轮询资源池中执行器的数量和繁忙情况；如果是动态执行器池，则根据资源池的繁忙情况和扩缩容规则信息做扩缩容调整；其中，每个执行器是一个封装有一个或多个容器的高级结构，其中包括两个容器：应用容器和边车容器。边车容器通过调用接口服务获取自身执行器信息，等待分配的任务后写到本地文件中。应用容器则持续监听这个本地文件是否存在；用户终端调用调用接口服务创建任务资源，指定可以执行该任务的资源池的名称和任务相关的参数，此时状态为pending（待处理）；任务控制器监听到待处理的任务，开始调度任务；任务控制器根据指定的资源池，获取对应资源池中执行器的情况，从中挑选一个合适、空闲的执行器，把任务写到该执行器的annotation（注解）中，分配给该执行器执行；该执行器中的边车容器监听到注解中存在任务名称，则根据任务名称通过调用接口服务获取任务的参数信息；边车容器解析任务后序列化到本地文件中；应用容器监听到存在任务文件后，则根据业务逻辑，开始处理任务，根据任务处理情况，顺利完成则exit code （退出码）0退出，异常退出则退出码非0。执行完后执行器状态完成；资源池控制器监听资源池中存在状态为完成执行器，开始处理；资源池控制器根据执行器中应用容器的退出码，将对应的任务状态改为成功或失败；任务控制器将状态为成功或失败的任务归档。
89.上述的任务处理方法，资源池控制器通过监测资源池的实时状态信息，即监测资源池中的执行器的实时数量以及每一执行器的实时工作状态，判断资源池是否处于繁忙情况，根据资源池的实时状态信息对资源池中的执行器的实时数量进行调节，可以在资源池中执行器处于满负荷之前，对执行器的数量进行增加，避免在执行器的数量已经不能满足业务要求时再对执行器的数量进行调整，从而节省满负荷后创建新的执行器所消耗的时间，有效避免任务的延时处理，提高任务的处理效率。
90.进一步的，根据资源池的实时状态信息对资源池中的执行器的实时数量进行调节，还可以在资源池处于空闲状态时减少执行器的数量，有效节省任务处理资源。
91.本申请实施例中提供了一种可能的实现方式，如图9所示，提供了一种任务处理装置90，该任务处理装置90可以包括：监听模块901、维护模块902、监测模块903和调节模块904，其中，监听模块901，用于监听调用接口服务；调用接口服务用于接收用户终端发送的资源池创建请求，基于创建请求创建资源池；资源池中包括至少一个执行器；维护模块902，用于若监听到调用接口服务创建资源池，则对资源池进行维护；监测模块903，用于针对维护中的资源池，监测资源池的实时状态信息；实时状态信息包括资源池中执行器的实时数量以及每一执行器的实时工作状态；
调节模块904，用于基于资源池的实时状态信息针对资源池中的执行器的实时数量进行调节，以使资源池中的至少一个执行器对分别处理对应的任务。
92.本申请实施例中提供了一种可能的实现方式，监测模块903在监测资源池的实时状态信息基于如下至少一种条件触发：检测到当前时间位于预设时间段或预设周期中；接收到状态确定指令。
93.本申请实施例中提供了一种可能的实现方式，资源池创建请求中携带有资源池的扩缩容规则信息；调节模块904在基于资源池的实时状态信息针对资源池中的执行器的实时数量进行调节时，具体用于：基于扩缩容规则信息以及实时状态信息，针对资源池中的执行器的实时数量进行调节。
94.本申请实施例中提供了一种可能的实现方式，调节模块904在基于扩缩容规则信息以及实时状态信息，针对资源池中的执行器的实时数量进行调节时，具体用于：若基于实时状态信息确定处于工作状态的执行器的数量与资源池中的执行器的当前总数量之间的比值大于或等于第一预设阈值，则基于扩缩容规则信息增加资源池中的执行器的实时数量；若基于实时状态信息确定处于工作状态的执行器的数量与资源池中的执行器的当前总数量之间的比值小于第二预设阈值，则基于扩缩容规则信息减少资源池中的执行器的实时数量。
95.本申请实施例中提供了一种可能的实现方式，还包括记录获取模块，用于：获取资源池的历史状态记录；历史状态记录包括资源池中的执行器的历史数量变化记录以及对应的执行器的历史工作状态记录；调节模块904在基于资源池的实时状态信息针对资源池中的执行器的实时数量进行调节时，具体用于：基于历史状态记录与实时状态信息，针对资源池中的执行器的实时数量进行调节。
96.本申请实施例中提供了一种可能的实现方式，调节模块904在基于历史状态记录与实时状态信息，针对资源池中的执行器的实时数量进行调节时，具体用于：基于历史状态记录预测执行器的下一时间段的预测状态信息；基于预测状态信息与实时状态信息，针对资源池中的执行器的实时数量进行调节。
97.本申请实施例中提供了一种可能的实现方式，还包括更新模块，用于：将实时状态信息更新至历史状态记录中。
98.本申请实施例中提供了一种可能的实现方式，资源池创建请求中携带有资源池的类型；资源池的类型包括动态资源池或固定资源池；调节模块904在基于资源池的实时状态信息针对资源池中的执行器的实时数量进行调节时，具体用于：若资源池的类型为动态资源池，则基于资源池的实时状态信息针对资源池中的执
行器的实时数量进行调节。
99.本申请实施例中提供了一种可能的实现方式，执行器中设置有第一容器和第二容器；执行器基于如下方式处理对应的任务：第一容器监听到任务控制器分配的任务，将任务序列化到本地文件中；第二容器检测到序列化的任务文件，执行任务，得到任务结果；第一容器将任务结果发送到数据库中存档。
100.上述的任务处理装置，资源池控制器通过监测资源池的实时状态信息，即监测资源池中的执行器的实时数量以及每一执行器的实时工作状态，判断资源池是否处于繁忙情况，根据资源池的实时状态信息对资源池中的执行器的实时数量进行调节，可以在资源池中执行器处于满负荷之前，对执行器的数量进行增加，避免在执行器的数量已经不能满足业务要求时再对执行器的数量进行调整，从而节省满负荷后创建新的执行器所消耗的时间，有效避免任务的延时处理，提高任务的处理效率。
101.进一步的，根据资源池的实时状态信息对资源池中的执行器的实时数量进行调节，还可以在资源池处于空闲状态时减少执行器的数量，有效节省任务处理资源。
102.本公开实施例的图片的任务处理装置可执行本公开的实施例所提供的一种图片的任务处理方法，其实现原理相类似，本公开各实施例中的图片的任务处理装置中的各模块所执行的动作是与本公开各实施例中的图片的任务处理方法中的步骤相对应的，对于图片的任务处理装置的各模块的详细功能描述具体可以参见前文中所示的对应的图片的任务处理方法中的描述，此处不再赘述。
103.基于与本公开的实施例中所示的方法相同的原理，本公开的实施例中还提供了一种电子设备，该电子设备可以包括但不限于：处理器和存储器；存储器，用于存储计算机操作指令；处理器，用于通过调用计算机操作指令执行实施例所示的任务处理方法。与现有技术相比，本申请中的任务处理方法可以有效避免任务的延时处理，提高任务的处理效率。
104.在一个可选实施例中提供了一种电子设备，如图10所示，图10所示的电子设备4000包括：处理器4001和存储器4003。其中，处理器4001和存储器4003相连，如通过总线4002相连。可选地，电子设备4000还可以包括收发器4004。需要说明的是，实际应用中收发器4004不限于一个，该电子设备4000的结构并不构成对本申请实施例的限定。
105.处理器4001可以是cpu（central processing unit，中央处理器），通用处理器，dsp（digital signal processor，数据信号处理器），asic（application specific integrated circuit，专用集成电路），fpga（field programmable gate array，现场可编程门阵列）或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器4001也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，dsp和微处理器的组合等。
106.总线4002可包括一通路，在上述组件之间传送信息。总线4002可以是pci（peripheral component interconnect，外设部件互连标准）总线或eisa（extended industry standard architecture，扩展工业标准结构）总线等。总线4002可以分为地址总线、数据总线、控制总线等。为便于表示，图10中仅用一条粗线表示，但并不表示仅有一根总
线或一种类型的总线。
107.存储器4003可以是rom（read only memory，只读存储器）或可存储静态信息和指令的其他类型的静态存储设备，ram（random access memory，随机存取存储器）或者可存储信息和指令的其他类型的动态存储设备，也可以是eeprom（electrically erasable programmable read only memory，电可擦可编程只读存储器）、cd
‑
rom（compact disc read only memory，只读光盘）或其他光盘存储、光碟存储（包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等）、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。
108.存储器4003用于存储执行本申请方案的应用程序代码，并由处理器4001来控制执行。处理器4001用于执行存储器4003中存储的应用程序代码，以实现前述方法实施例所示的内容。
109.其中，电子设备包括但不限于：移动电话、笔记本电脑、数字广播接收器、pda（个人数字助理）、pad（平板电脑）、pmp（便携式多媒体播放器）、车载终端（例如车载导航终端）等等的移动终端以及诸如数字tv、台式计算机等等的固定终端。图10示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
110.本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，当其在计算机上运行时，使得计算机可以执行前述方法实施例中相应内容。与现有技术相比，本申请中的任务处理方法可以有效避免任务的延时处理，提高任务的处理效率。
111.应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
112.需要说明的是，本公开上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器（ram）、只读存储器（rom）、可擦式可编程只读存储器（eprom或闪存）、光纤、便携式紧凑磁盘只读存储器（cd
‑
rom）、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的
程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、rf（射频）等等，或者上述的任意合适的组合。
113.上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。
114.上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使得该电子设备执行上述实施例所示的方法。
115.本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行时实现如下情况：监听调用接口服务；调用接口服务用于接收用户终端发送的资源池创建请求，基于创建请求创建资源池；资源池中包括至少一个执行器；若监听到调用接口服务创建资源池，则对资源池进行维护；针对维护中的资源池，监测资源池的实时状态信息；实时状态信息包括资源池中执行器的实时数量以及每一执行器的实时工作状态；基于资源池的实时状态信息针对资源池中的执行器的实时数量进行调节，以使资源池中的至少一个执行器对分别处理对应的任务。
116.可以以一种或多种程序设计语言或其组合来编写用于执行本公开的操作的计算机程序代码，上述程序设计语言包括面向对象的程序设计语言—诸如java、smalltalk、c++，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(lan)或广域网(wan)—连接到用户计算机，或者，可以连接到外部计算机（例如利用因特网服务提供商来通过因特网连接）。
117.附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
118.描述于本公开实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，模块的名称在某种情况下并不构成对该模块本身的限定，例如，调节模块还可以被描述为“用于调节资源池中执行器的实时数量的模块”。
119.以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术
方案，同时也应涵盖在不脱离上述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的（但不限于）具有类似功能的技术特征进行互相替换而形成的技术方案。