程序评测方法、装置及计算机可读存储介质与流程

1.本技术属于软件领域，具体涉及一种程序评测方法、装置及计算机可读存储介质。


背景技术：

2.在线评测系统的运行方式通常如下：用户在网页上提交文件(例如是完整的程序文件)，由在线评测系统运行该文件，并将运行的结果反馈给用户。常见的应用场景例如是在线答题系统、编程竞赛平台等。
3.常见的在线评测系统通常采用单服务器的结构，串行地完成对各个用户提交文件的评测。这种评测方式效率低下，对短时间内大量提交的待评测文件抗压能力差，且存在因恶意提交而导致在线评测系统崩溃的风险。


技术实现要素：

4.针对上述现有技术的问题。本技术实施例提出了一种程序评价方法、装置及计算机可读存储介质。利用这种方法及装置，能够至少部分解决上述问题。
5.本技术的实施例中提供了以下方案。
6.本技术的实施例提供一种程序评测方法，包括：确定待评测的程序文件；将所述程序文件打包成容器镜像；运行所述容器镜像；输出所述容器镜像的运行结果。
7.在一些可选的实施方式中，将所述程序文件打包成容器镜像，包括：采用docker容器引擎将所述程序文件打包成容器镜像。
8.在一些可选的实施方式中，运行所述容器镜像，包括：基于kubernetes容器集群管理系统创建pod，该pod引用所述容器镜像；将该pod分配至一个node；在该pod运行所述容器镜像。
9.在一些可选的实施方式中，确定待评测的程序文件，包括：获取更新文件；基于gitlab仓库管理工具，根据所述更新文件和主干创建分支，所述主干包括持续集成脚本和argo工作流引擎的配置文件，所述分支作为所述程序文件；将所述程序文件打包成容器镜像，包括：执行所述持续集成脚本，以将所述分支打包成所述容器镜像；运行所述容器镜像，包括：根据所述配置文件运行工作流，所述工作流包括：基于kubernetes容器集群管理系统创建pod，该pod引用所述容器镜像，将该pod分配至一个node；在该pod运行所述容器镜像。
10.本技术的实施例提供一种程序评测装置，包括：确定模块，用于确定待评测的程序文件；打包模块，用于将所述程序文件打包成容器镜像；运行模块，用于运行所述容器镜像；输出模块，用于输出所述容器镜像的运行结果。
11.在一些可选的实施方式中，所述打包模块具体用于：采用docker镜像引擎将所述程序文件打包成容器镜像。
12.在一些可选的实施方式中，所述运行模块具体用于：基于kubernetes容器集群管理系统创建pod，该pod中引用所述容器镜像；将该pod分配至一个node；在该node运行所述容器镜像。
13.在一些可选的实施方式中，所述确定模块具体用于：获取更新文件；基于gitlab仓库管理工具，根据所述更新文件和主干创建分支，所述主干包括持续集成脚本和argo工作流引擎的配置文件，所述分支作为所述程序文件；所述打包模块具体用于：执行所述持续集成脚本，以将所述分支打包成所述容器镜像；所述运行模块具体用于：根据所述配置文件运行工作流，所述工作流包括：基于kubernetes容器集群管理系统创建pod，该pod引用所述容器镜像，将该pod分配至一个node；在该pod运行所述容器镜像。
14.本技术的实施例一种程序评测装置，包括：至少一个处理器；以及，与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行上述的程序评价方法。
15.本技术的实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储有程序，当所述程序被多核处理器执行时，使得所述多核处理器执行上述的程序评价方法。
16.本技术实施例采用的上述至少一个技术方案能够达到以下有益效果：由于每一个待评测的程序文件都是在一个容器内运行的，容器与容器彼此隔离，一个容器运行崩溃不会影响整个程序评测装置的运行，程序评测的安全性得到提高。且容器与容器之间是并行运行的，程序评测的效率更高。
17.应当理解，上述说明仅是本技术技术方案的概述，以便能够更清楚地了解本技术的技术手段，从而可依照说明书的内容予以实施。为了让本技术的上述和其它目的、特征和优点能够更明显易懂，以下特举例说明本技术的具体实施方式。
附图说明
18.通过阅读下文的示例性实施例的详细描述，本领域普通技术人员将明白本文所述的优点和益处以及其他优点和益处。附图仅用于示出示例性实施例的目的，而并不认为是对本技术的限制。而且在整个附图中，用相同的标号表示相同的部件。在附图中：
19.图1为根据本技术一实施例的程序评测方法的流程示意图；
20.图2为根据本技术另一实施例的程序评测方法的流程示意图；
21.图3为根据本技术一实施例的程序评测装置的结构示意图；
22.图4为根据本技术另一实施例的程序评测装置的结构示意图。
23.图5为根据本技术的实施例的程序评测装置构成的系统硬件结构示意图。
24.在附图中，相同或对应的标号表示相同或对应的部分。
具体实施方式
25.下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
26.在本技术中，应理解，诸如“包括”或“具有”等术语旨在指示本说明书中所公开的特征、数字、步骤、行为、部件、部分或其组合的存在，并且不旨在排除一个或多个其他特征、数字、步骤、行为、部件、部分或其组合存在的可能性。
27.另外还需要说明的是，在不冲突的情况下，本技术中的实施例及实施例中的特征
可以相互组合。下面将参考附图并结合实施例来详细说明本技术。
28.图1为根据本技术一实施例的程序评测方法100的流程示意图，该方法100用于对多个待评测的程序文件进行并行且相对安全地评测，在该流程中，从设备角度而言，执行主体可以是一个或者多个电子设备；从程序角度而言，执行主体相应地可以是搭载于这些电子设备上的程序。
29.图1中的流程可以包括以下步骤101～步骤104。
30.步骤101、确定待评测的程序文件。
31.步骤102、将所述程序文件打包成容器镜像。
32.步骤103、运行所述容器镜像。
33.步骤104、输出所述容器镜像的运行结果。
34.其中，容器(container)是一种便携式、轻量级的操作系统级虚拟化技术。它隔离不同的软件运行环境，并通过镜像自包含软件的运行环境，从而使得容器可以很方便的在任何地方运行。
35.由于容器体积小且启动快，因此可以在每个容器镜像中打包一个应用程序。这种一对一的应用镜像关系拥有很多好处。使用容器，不需要与外部的基础架构环境绑定,因为每一个应用程序都不需要外部依赖，更不需要与外部的基础架构环境依赖。
36.由于待评测的程序文件是在容器内运行的，容器与容器之间彼此隔离，并行运行。即使是遇到恶意提交而使得一个容器运行崩溃，也不会影响其他容器。且能够实现多个带评测的程序文件的并行评测。
37.基于图1的程序评测方法，本技术的一些实施例还提供了该程序评测方法的一些具体实施方案，以及扩展方案，下面进行说明。
38.在一些可能的实施方式中，采用docker容器引擎将所述程序文件打包成容器镜像。docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的linux机器上，也可以实现虚拟化，容器是完全使用沙箱机制，相互之间不会有任何接口。
39.基于此，docker容器引擎更适用于需要同时对多个待评测程序文件进行评测的应用场景。
40.在一些可能的实施方式中，基于kubernetes容器集群管理系统运行容器镜像。详细的过程如下：创建pod，所述pod引用所述容器镜像；将所述pod分配至一个node；在所述pod运行所述容器镜像。
41.kubernetes容器集群管理系统使用pod来管理容器，每个pod可以包含一个或多个紧密关联的容器。pod内的多个容器共享网络和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。在kubernetes中，pod是最小的可被调度的原子单位。
42.由于是需要对各个待评测的程序文件分别进行评测，可以在每个pod中仅包含一个容器，也就是每个pod可以仅用于对一个程序文件进行评测。
43.node是pod真正运行的主机，可以是物理机，也可以是虚拟机。
44.由于kubernetes容器集管理系统具有负载均衡的功能，可以将各个容器镜像分配到不同的物理机(例如是服务器)上运行。物理机计算资源的扩增与实际程序评测能力的扩增近似呈线性关系，理论上程序评测能力可以无限扩增。
45.以上举例的实施方式中，待评测的程序文件均是由用户直接提交的，例如是用户通过在线评测系统的网页界面提交的完整的可运行的程序文件。当然，在另外一些实施例中，用户可以仅提供完整程序文件的部分更新，基于gitlab仓库管理工具实现待评测的程序文件的确定以及后续的步骤。
46.参考图2，该实施例提供的程序评测方法200包括以下步骤。
47.步骤201、获取更新文件。更新文件可以是完整的程序文件，也可以是其中部分内容的更新。
48.步骤202、基于gitlab仓库管理工具，根据所述更新文件和主干创建分支，所述主干包括持续集成脚本和argo工作流引擎的配置文件。
49.一旦程序文件出现更新，就会触发持续集成脚本的运行，持续集成脚本会通知gitlab runner去运行相关的脚本。argo工作流引擎是基于kubernets的工作流引擎。
50.至此得到的分支即待评测的程序文件。
51.步骤203、执行所述持续集成脚本，以将所述分支打包成所述容器镜像。显然，容器镜像中还应包含基础环境、用户文件、配置文件等信息。这部分可以按照常规设计进行配置。
52.步骤204、根据所述配置文件运行工作流。由于容器镜像中包含了argo工作流引擎的配置文件。kubernetes容器集群管理系统就会依照这个配置文件自动完成完整的工作流。该工作流具体例如是：基于kubernetes容器集群管理系统创建pod，所述pod引用所述容器镜像，将所述pod分配至一个node；在所述pod运行所述容器镜像。由此，完成了容器镜像的运行。
53.步骤205、输出所述容器镜像的运行结果。
54.基于相同的技术构思，本技术实施例还提供一种程序评测装置，用于执行上述任一实施例所提供的程序评测方法。图3为本技术实施例提供的一种程序评测装置结构示意图。
55.如图3所示，程序评测装置包括：确定模块1，用于确定待评测的程序文件；打包模块2，用于将所述程序文件打包成容器镜像；运行模块3，用于运行所述容器镜像；输出模块4，用于输出所述容器镜像的运行结果。
56.这样，根据本技术实施例的程序评测装置，即使是遇到恶意提交而使得一个容器运行崩溃，也不会影响其他容器。且能够实现多个带评测的程序文件的并行评测。
57.在一些可能的实施方式中，打包模块2具体用于：采用docker镜像引擎将所述程序文件打包成容器镜像。
58.在一些可能的实施方式中，运行模块3具体用于：基于kubernetes容器集群管理系统创建pod，所述pod中引用所述容器镜像；将所述pod分配至一个node；在该node运行所述容器镜像。
59.在一些可能的实施方式中，确定模块1具体用于：获取更新文件；基于gitlab仓库管理工具，根据所述更新文件和主干创建分支，所述主干包括持续集成脚本和argo工作流引擎的配置文件，所述分支作为所述程序文件；打包模块2具体用于：执行所述持续集成脚本，以将所述分支打包成所述容器镜像；运行模块3具体用于：根据所述配置文件运行工作流，所述工作流包括：基于kubernetes容器集群管理系统创建pod，该pod引用所述容器镜
像，将该pod分配至一个node；在该pod运行所述容器镜像。
60.需要说明的是，本技术实施例中的程序评测装置可以实现前述程序评测方法的实施例的各个过程，并达到相同的效果和功能，这里不再赘述。
61.图4为根据本技术一实施例的程序评测装置，用于执行图1或图2所示出的程序评测方法，该程序评测装置包括：至少一个处理器2000；以及，与至少一个处理器2000通信连接的存储器1000；其中，存储器1000存储有可被至少一个处理器2000执行的指令，指令被至少一个处理器2000执行，以使至少一个处理器1000能够执行：上述的程序评测方法。
62.参考图5，在一个具体的例子中，采用客户端-服务器架构实现上述的程序评测方法。上述的程序评测装置作为服务端，客户端采用web前端的模式。
63.web前端的主要功能是让用户可以在浏览器上参与比赛、提交并获取结果。服务端则负责数据的储存、处理，接收前端发出的请求，然后处理并反馈数据，比如提供比赛数据、处理参赛请求、处理提交文件请求、处理文件的自动评判并反馈结果等。
64.服务端的功能由一系列服务的集群实现。接口服务器(gateway服务器)是与客户端直接相连的服务器，接收用户的请求并分发给其他服务器。认证中心服务器用于验证用户的身份，处理登陆等信息。业务逻辑服务器是主要是处理业务逻辑的服务器，有一组相同的机器，由接口服务器根据负载均衡分配要处理的请求到不同的服务器。数据库服务器中储存了需要持久化的数据。kubernetes集群也是多个服务器组成的，有一台master服务器作为主节点，若干的node服务器来执行任务。业务逻辑服务器通过命令行接口(cli)与kubernetes集群的master服务器交互，部署任务。
65.一次用户在线提交并获得服务器自动评判的结果的过程如下。用户在浏览器提交文件。web前端向接口服务器发起请求，将用户提交的文件传递给接口服务器。接口服务器将用户提交的文件转发到某个业务逻辑服务器。业务逻辑服务器收到请求，将文件打包成docker镜像，上传到docker仓库。业务逻辑服务器通过命令行接口调用kubernetes集群的接口创建pod。kubernetes集群根据命令调用创建pod并将pod分配到某个node节点上运行。业务逻辑服务器调用命令行接口查询程序的运行结果。业务逻辑服务器将结果储存到数据库服务器。用户如需查看自己的成绩，在web前端发起请求，接口服务器将结果返回至web前端。用户便能够获取到了自己的成绩。
66.根据本技术的一些实施例，提供了方法的非易失性计算机存储介质，其上存储有计算机可执行指令，该计算机可执行指令设置为在由处理器运行时执行：上述的程序评测方法。
67.本技术中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备和计算机可读存储介质实施例而言，由于其基本相似于方法实施例，所以其描述进行了简化，相关之处可参见方法实施例的部分说明即可。
68.本技术实施例提供的装置、设备和计算机可读存储介质与方法是一一对应的，因此，装置、设备和计算机可读存储介质也具有与其对应的方法类似的有益技术效果，由于上面已经对方法的有益技术效果进行了详细说明，因此，这里不再赘述装置、设备和计算机可读存储介质的有益技术效果。
69.本领域内的技术人员应明白，本技术的实施例可提供为方法、系统或计算机程序
产品。因此，本技术可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
70.本技术是参照根据本技术实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
71.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
72.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
73.在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
74.内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
75.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。此外，尽管在附图中以特定顺序描述了本技术方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。
76.虽然已经参考若干具体实施方式描述了本技术的精神和原理，但是应该理解，本技术并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本技术旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。