插件管理方法、装置、存储介质及计算机设备

技术领域

本申请涉及计算机领域，具体而言，涉及一种插件管理方法、装置、存储介质及宿主设备。

背景技术

宿主程序提供使插件能够工作的各项服务，并提供插件的加载方式，使插件可以加载到应用程序中，并通过预设的交互协议和插件进行数据交换。因此，插件是一种遵循一定规范的应用程序接口编写出来的程序。

在软件的设计和研发过程中，将软件的需求和功能进行划分，使程序分为宿主程序和插件两部分。其中，把基础的功能要求设计在宿主程序中，其他可选地的功能设计成插件。如此，当需要某项功能时，则将相对应的插件加载到内存中。

然而，目前的插件的使用过程中并未同时考虑资源消耗与插件业务性能以及插件与宿主程序之间的隔离。

发明内容

为了克服现有技术中的至少一个不足，本申请提供一种插件管理方法、装置、存储介质及宿主设备，用于在内存消耗与插件性能之间找到平衡点。

具体包括：

第一方面，本申请提供一种插件管理方法，应用于计算机设备，所述方法包括：

获取当前时刻以及目标业务插件最近一次被调用的历史时刻，其中，所述目标业务插件表示已加载的任意业务插件，所述目标业务插件运行在工作进程提供的内存空间中，所述工作进程不同于所述目标业务插件的宿主程序所属的进程；

根据所述历史时刻以及所述当前时刻，获得所述目标业务插件的空闲时长；

判断所述空闲时长是否大于时长阈值；

若所述空闲时长大于所述时长阈值，则回收所述目标业务插件在所述内存空间中占据的内存资源。

第二方面，本申请提供一种插件管理装置，所述装置包括：

时长模块，用于获取当前时刻以及目标业务插件最近一次被调用的历史时刻，其中，所述目标业务插件表示已加载的任意业务插件，所述目标业务插件运行在工作进程提供的内存空间中，所述工作进程不同于所述目标业务插件的宿主程序所属的进程；

根据所述历史时刻以及所述当前时刻，获得所述目标业务插件的空闲时长；

回收模块，用于判断所述空闲时长是否大于所述目标业务插件的时长阈值；

所述回收模块，还用于若所述空闲时长大于所述时长阈值，则回收所述目标业务插件在所述内存空间中占据的内存资源。

第三方面，本申请提供一种存储介质，所述存储介质存储有计算机程序，所述计算机程序被处理器执行时，实现所述的插件管理方法。

第四方面，本申请提供一种计算机设备，所述计算机设备包括处理器以及存储器，所述存储器存储有计算机程序，所述计算机程序被处理器执行时，实现所述的插件管理方法。

相对于现有技术而言，本申请具有以下有益效果：

本申请提供的插件管理方法、装置、存储介质及宿主设备中，宿主设备获取目标业务插件的空闲时长，其中，目标业务插件表示已被加载到内存中的业务插件；判断空闲时长是否大于目标业务插件的时长阈值；若空闲时长大于时长阈值，则回收目标业务插件占据的内存资源。如此，通过设置时长阈值，为目标业务插件在内存中预留一定的驻留时长，当目标业务插件的空闲的时长大于该时长阈值，则意味着该目标业务插件在时长阈值内未被调用过，更意味着所处理的业务并不需要过多的目标业务插件驻留在内存中，因此，可以将目标业务插件占据的内存资源进行回收，以达到同时兼顾资源消耗与插件业务性能的目的，并且，目标业务插件运行在于宿主程序进程不同的工作进程中，避免了目标业务插件执行期间影响到宿主程序的正常运行。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的插件管理方法的流程示意图之一；

图2为本申请实施例提供的插件管理方法的流程示意图之二；

图3为本申请实施例提供的插件管理方法的流程示意图之三；

图4为本申请实施例提供的插件管理方法的流程示意图之四；

图5为本申请实施例提供的插件管理装置的结构示意图之一；

图6为本申请实施例提供的插件管理装置的结构示意图之二；

图7为本申请实施例提供的宿主设备的结构示意图。

图标：101-时长模块；102-回收模块；103-请求模块；104-加载模块；201-存储器；202-处理器；203-通信单元；204-系统总线。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

在本申请的描述中，需要说明的是，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。此外，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

基于上述声明，为使本申请实施例的目的、技术方案和优点更加清楚，在介绍本实施例提供的插件管理方法之前，先就本实施例涉及术语进行解释说明。

Node.js，是一个基于Chrome V8引擎的JavaScript运行环境，使得原本运行在客户端浏览器中的JavaScript代码能够运行在服务端的开发平台，进而让JavaScript语言成为与PHP、Python、Perl、Ruby等服务端语言平起平坐的脚本语言。其中，V8引擎基于C++开发，在运行JavaScript之前，V8将其编译成原生机器码(IA-32、x86-64、ARM、MIPS)，并且使用了如内联缓存等方法来提高性能。如此使得JavaScript程序在V8引擎下的运行速度媲美二进制程序。

V8虚拟机(Virtual Machine，VM)，是Node.js默认就提供的内建模块，支撑了require方法和Node.js的运行机制。其中，equire方法是Node.js用来加载并执行其它文件导出的模块。即在Node.js中，当需要引入一模块所对应一个Module实例时，可以使用require方法包含对应的入口文件。并且，V8虚拟机模块提供了一系列API用于在V8虚拟机环境中编译和运行代码，而代码的执行上下文是与当前进程隔离的。

eval函数，是全局对象的一个函数属性，可以用于执行JavaScript编写的插件，执行的代码拥有着和应用中其它正常代码一样的权限，它能访问执行上下文中的局部变量，也能访问所有全局变量；因此，对稳定新要求很高的场景中，eval函数是一个非常危险的函数。

进程，是计算机资源分配的最小单位，每个进程都拥有自己的虚拟地址空间，并与其他进程的虚拟地址空间相互隔离，也就是说，一个进程只能访问自己的虚拟地址空间，不能访问其他进程的虚拟地址空间，从而实现资源隔离。

进程池，进程池里面有预先指定好的进程数供用户使用；当很多任务一起提交过来时，则将这些任务交由进程池中的进程进行处理；如果进程池中的进程被调用完，其他任务则一直等着，直到有空闲的进程。如此，能够减少了进程的创建和销毁所花的时间和资源。

正如背景技术所介绍的，将基础的功能要求设计在宿主程序中，其他可选地的功能设计成插件。如此，当需要某项功能时，则将相对应的插件加载到内存中。基于这一构思，在开发业务系统时，为了动态适应不同行业的业务需要，可以将不同行业共有的业务需求设计为宿主程序，将行业之间差异化的业务需求设计为业务插件形式。从而在为目标行业提供业务系统时，将宿主程序与适配该目标业务的业务插件一起提供给客户。应理解的是，上述目标行业的业务插件可以包括多种类型；并且，为了提升业务处理效率，同一类型的多个业务插件可以同时并行运行。

研究发现，相关技术中，每进行一次业务处理，则加载一次相应的业务插件，并在业务处理完之后将业务插件销毁；由于业务插件的加载需要耗费一定的时间，这就导致该方式虽然能够在一定程度上节省内存资源，但会严重影响业务的执行效率。

而其他相关技术中，每进行一次业务处理时，先检测内存中是否存在有能够处理该业务并处于空闲状态的业务插件；若不存在，则在内存中加载相应的业务插件，并在业务处理完成之后将业务插件驻留在内存中，以便下次处理相同类型的业务；若存在，则调用该业务插件进行业务处理。由于该方式需要将业务插件长期驻留在内存中，导致需要消耗大量的内存资源。

并且，研究还发现，由于宿主程序为业务插件的执行提供支持，因此，相关技术中通常将业务插件与宿主程序运行在同一进程空间，使得业务插件能够轻松访问宿主程序的一些支撑业务插件运行的变量，这也导致宿主程序可能运行出现异常，尤其是业务插件是未经过严格测试的第三方插件。

示例性的，以基于Node.js的业务插件为例。相关技术方式中，可以通过Node.js中提供的eval函数将业务插件加载到内存中。然而，eval函数执行的业务插件拥有着与宿主程序相同的权限，能够访问执行上下文中的局部变量以及全局变量。因此，设计不合理的业务插件在运行时可能会导致宿主程序运行出现异常。

又例如，其他相关技术中，利用Node.js的虚拟机提供的沙箱机制隔绝业务插件的运行环境。虚拟机作为Node.js的内建模块，虽然提供了一些隔离机制用于隔绝业务插件的运行环境，但宿主程序与插件程序实际还是属于同一进程，这就导致在实际业务场景中，一些来自第三方开发者的业务插件恶意突破隔绝业务插件的运行环境，进而同样会影响宿主程序的正常执行。

因此，目前的插件的使用过程中并未同时考虑资源消耗与插件业务性能以及插件与宿主程序之间的隔离。需要注意的是，以上现有技术中的方案所存在的缺陷，均是发明人在经过实践并仔细研究后得出的结果，因此，上述问题的发现过程以及下文中本申请实施例针对上述问题所提出的解决方案，都应该是发明人在发明创造过程中对本申请做出的贡献，而不应当理解为本领域技术人员所公知的技术内容。

鉴于此，本申请提供一种插件管理方法，用于在插件使用过程中兼顾到资源消耗与插件业务性能。其中，该插件管理方法可以应用于计算机设备。该计算机设备运行有宿主程序，并与目标行业的业务插件相互配合，从而处理目标行业的业务事项。其中，运行有宿主程序的计算机设备又被称为宿主设备，该宿主设备可以是单个服务器，也可以是服务器组。服务器组可以是集中式的，也可以是分布式的(例如，服务器可以是分布式系统)。在一些实施例中，服务器相对于用户终端，可以是本地的、也可以是远程的。在一些实施例中，服务器可以在云平台上实现；仅作为示例，云平台可以包括私有云、公有云、混合云、社区云(Community Cloud)、分布式云、跨云(Inter-Cloud)、多云(Multi-Cloud)等，或者它们的任意组合。在一些实施例中，服务器可以在具有一个或多个组件的电子设备上实现。

基于上述介绍，下面结合图1就本实施例的插件管理方法进行详细介绍。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。如图1所示，该方法包括：

S107，获取当前时刻以及目标业务插件最近一次被调用的历史时刻。

S108，根据历史时刻以及当前时刻，获得目标业务插件的空闲时长。

其中，目标业务插件表示已被加载到内存中的任意业务插件，其数量可以是一个或者多个。当数量为多个是，多个目标业务插件可以用于处理不同类型的业务，或者用于处理相同类型的业务；并且，对于所有的目标业务插件，均在空闲时长超过时长阈值后，回收其占据内存资源。

本实施例中，为了获得目标业务插件的空闲时长，宿主设备记录有目标业务插件最近一次被调用的历史时刻。并且，该目标业务插件每调用一次，宿主设备则将目标业务插件的历史时刻进行一次更新。如此，在每次检测目标业务插件的空闲时长是否超过时长阈值时，则将目标业务插件最近一次被调用的历史时刻与当前时刻相减，从而获得该目标业务插件的空闲时长。

并且，目标业务插件运行在工作进程提供的内存空间中，工作进程不同于目标业务插件的宿主程序所属的进程。如此，由于进程是计算机资源分配的最小单位，每个进程都拥有自己的虚拟地址空间，并与其他进程的虚拟地址空间相互隔离，从而避免目标业务插件加载到内存后，其执行期间影响到宿主程序的正常运行。

基于上述关于空闲时长的介绍，继续参见图1，该插件管理方法还包括：

S109，判断空闲时长是否大于时长阈值。

若是，则执行步骤S110，收目标业务插件在内存空间中占据的内存资源。

如此，通过设置时长阈值，为目标业务插件在内存中预留一定的驻留时长，当目标业务插件的空闲的时长大于该时长阈值，则意味着该目标业务插件在时长阈值内未被调用过，更意味着所处理的业务并不需要过多的目标业务插件驻留在内存中，因此，可以将目标业务插件占据的内存资源进行回收，以达到同时兼顾资源消耗与插件业务性能的目的，并且，目标业务插件运行在于宿主程序进程不同的工作进程中，避免了目标业务插件执行期间影响到宿主程序的正常运行。

继续参见图1，该插件管理方法还包括：

若否，则返回步骤执行S107，从而继续检测该目标业务插件的空闲时长是否超过时长阈值，直到该目标业务插件的空闲时长大于时长阈值后，将目标业务插件占据的内存资源从内存中回收。

研究还发现，由于本实施例采取按需加载的方式进行业务处理，而不同类型的业务之间会产生不同的业务压力，这就导致对于每种类型的业务，驻留在内存中用于处理该业务的目标业务插件的数量需要能够与该业务的业务压力相匹配。而目标业务插件的数量与用户回收目标业务插件的时长阈值相关；因此，在本实施例中，计算机设备可以获取目标业务插件对应业务的业务压力，并根据该业务压力为目标业务插件设置新的时长阈值，其中，该时长阈值与业务压力成正相关。因此，如图2所示，该插件管理方法还包括：

S111，获取目标业务插件处理的目标业务在统计时段内的业务请求量。

S112，计算业务请求量与参考请求量之间的比值。

S113，将比值与时长阈值相乘，获得新的时长阈值。

示例性的，假定将业务请求量作为业务压力，则在每个统计时段内，计算机设备统计与目标业务插件相对应的业务在统计时段内的业务请求量，然后，计算该业务请求量与参考请求量之间的比值；将该比值作为调整因子，用于调整目标业务插件的时长阈值。

例如，假定在30分钟为一个统计时段，目标业务插件所处理的目标业务的业务请求量达到120，而参考请求量为100，则调整因子为120/100＝1.2。若此时目标业务插件的时长阈值为10分钟，则新的时长阈值为1.2*10＝12分钟。

如此，通过上述实施方式，能够根据业务的业务压力，动态调整处理该业务的目标业务插件在内存中驻留时的时长阈值，从而自适应业务压力的变化，使得在业务压力较大时，增加内存中缓存的目标业务插件的数量，在业务压力较小时，减少内存中缓存的目标业务插件的数量。

为了提高业务处理效率，本实施中的业务插件采取按需加载的方式进行业务处理，即接收到目标业务的处理请求后，优先从已加载的业务插件中查找相匹配的业务插件，然后，才考虑为该处理请求再次加载业务插件。因此，如图3所示，该插件管理方法还包括：

S104，接收目标业务的处理请求。

S105，若已加载的业务插件中未剩余有能够处理目标业务的目标业务插件，则从待加载的业务插件中获取与目标业务相匹配的业务插件。

正如上述实施例中所介绍的，内存中的目标业务插件可以在内存中以空闲状态驻留到超过时长阈值，因此，当在驻留期间，计算机设备接收到目标业务的处理请求，并且，恰好内存中缓存有够处理该目标业务的目标业务插件，则调用该目标业务插件处理目标业务；反之，则意味着所有已加载的目标业务插件中未剩余能够处理该目标业务的目标业务插件。例如，所有已加载的目标业务插件能处理的业务均与目标业务不相匹配，或者，能够处理该目标业务的目标业务插件均处于繁忙状态。

为了提高业务处理效率，当所有已加载的目标业务插件中未剩余能够处理该目标业务的空闲插件，计算机设备则从待加载的业务插件中，获取与目标业务相匹配的目标业务插件。例如，计算机设备可以根据目标业务的业务类型，从待加载的业务插件确定出与业务标识相匹配的目标业务插件。由于此时的目标业务插件处于待加载状态，因此，该插件管理方法还包括：

S106，将与目标业务相匹配的业务插件加载到工作进程提供的内存空间中，以作为目标业务插件。

将目标业务插件加入到内存中后，该目标业务插件即进入运行状态，然后，将目标业务的待处理数据交由该目标业务插件处理。如此，当内存中恰好缓存有够处理目标业务的目标业务插件，则调用该目标业务插件处理目标业务；反之，则往内存中加载能够处理该目标业务的目标业务插件，从而减少目标业务的等待时间，提高了业务处理效率。

而考虑到进程的创建与销毁需要消耗一定的时间以及计算资源，因此，本实施例事先提供有进程池，通过进程池降低进程来回创建和销毁的开销，也能确保不过度抢占宿主程序的资源。如图4所示，基于该进程池，步骤S106的具体实施方式包括：

S106-1，根据预设的负载均衡策略，从进程池中选取工作进程。

示例性的，假定将执行目标业务插件的进程我们称为Work进程，用于分配目标业务的进程称为Master进程。计算机设备中的Master进程在接收到加载目标业务插件的请求时，会根据负载均衡算法从进程池中选择一个进程作为Worker进程去执行目标业务插件。

另外，本实施例提供的一负载均衡算法中，宿主进程可以获取每个进程已加载业务插件的数量，然后，从中选取数量最少的进程作为目标业务插件的工作进程。然而，研究发现，一些进程虽然加载了较多数量的业务插件，但业务插件均处于空闲状态，本实施例将这一类进程称为空闲进程；而一些进程虽然加载了较少数量的业务插件，但所有的业务插件均处于工作状态。基于这一发现，在提供的另一负载均衡算法中，该计算机设备可以先判断进程池中是否存在有处于空闲状态的进程，若存在，则从空闲进程中选取平均空闲时长最长的作为目标业务插件的工作进程；若不存在，则选取插件数量最少的作为目标业务插件的工作进程。

鉴于以上介绍，本实施还可以同时考虑每个进程已加载业务插件的数量以及空闲时长，此时步骤S106-1的具体实施方式包括：

S106-1-1，获取进程池中每个进程剩余的插件数量以及空闲时长。

其中，每个进程剩余的插件数量表示进程最多能够再加载的业务进程的数量。由于单个进程里面加载了过多的业务插件，而业务插件之间会抢占进程中的资源，继而影响到各插件的执行效率，因此，对每个进程中最多能够加载的进程数量进行了限制。例如，假定一进程最多能够加载10个业务插件，并且，当前已经记载了3个插件，则该进程剩余的插件数量为7个。

S106-1-2，分别将每个进程剩余的插件数量以及空闲时长进行加权，获得每个进程的候选得分。

其中，考虑到插件数量与空闲时长分别具有不同的量纲，因此，在进行加权之前，可以将两者分别进行归一化处理；然后，将两者归一化后的结果进行加权。例如，假定将候选得分表示为P，则其表达式为：

P＝αS+βT

式中，S表示归一化后的剩余数量，α表示相应的权重；T表示归一化后的空闲时长，β表示相应的权重。其中，α与β的具体数值，本领域技术人员可以根据对剩余数量与空闲时长的侧重进行设置。例如，当在选取工作进程时侧重于每个进程中剩余的插件数量，则以上两权重的取值可以是α＝0.7，β＝0.3。

S106-1-3，根据每个进程的候选得分，选取得分最高的作为工作进程。

基于上述关于工作进程选取方式的介绍，继续参见图4，步骤S106还包括：

S106-2，将与目标业务相匹配的目标业务插件加载到工作进程的进程空间。

本实施例考虑到不同计算机设备计算资源存在一定的差异，为了自适应不同的计算机设备之间能够提供的计算资源的差异，继续参见图4，在步骤S104之前，该插件管理方法还包括：

S101，获取计算机设备的硬件资源。

其中，该硬件资源包括CPU数量及型号、内存容量、磁盘容量中的至少一种。

S102，根据硬件资源，确定进程池中的进程数量。

应理解，硬件资源提供的算力越充足，则可以在进程池中创建更多的进程，而不会给计算机设备带来过于明显的性能下降。

示例性的，进程池中进程数量可以与CPU数量一致。例如，若一计算机设备包括4个CPU，则可以将进程数量设置为4个。

S103，根据进程数量，创建进程池。

如此，依据计算机设备的硬件资源，确定进程池中所需进程的数量，从而能够自适应不同的计算机设备。

进一步地，为了对内存中的目标业务插件进行有效的管理，而避免挤占宿主程序的运行空间，需要限制目标业务插件运行过程中消耗的计算资源。但业务插件的加载机制导致无法对加载到内存中的目标业务插件直接进行限制，因此，本实施例对加载目标业务插件的工作进程进行直接限制，从而间接约束目标业务插件对计算资源的消耗。即步骤S103的具体实施方式包括：

S103-1，获取每个进程的资源约束条件。

S103-2，分别根据每个进程的资源约束条件，创建每个进程。

示例性的，对于Linux平台，可以利用Linux提供的Cgroups机制进行资源控制。所谓Cgroups，其全称为Control groups，是Linux内核提供的用于限制进程或者进程组的资源(例如，CPU、内存、磁盘IO等)的功能。因此，可以通过Cgroups在没创建一进程时，显示该进程的对CPU、内存等资源的消耗。例如，本实施例中将单个进程的内存限制到1.4G，CPU限制到为0.5个。

基于上述关于插件管理方法的介绍，在相同发明构思下，本实施例还提供一种插件管理装置，插件管理装置包括至少一个可以软件形式存储于存储器或固化在计算机设备的操作系统(Operating System，简称OS)中的软件功能模块。计算机设备中的处理器用于执行存储器中存储的可执行模块。例如，插件管理装置所包括的软件功能模块及计算机程序等。请参照图5，从功能上划分，插件管理装置可以包括：

时长模块101，用于获取当前时刻以及目标业务插件最近一次被调用的历史时刻，其中，目标业务插件表示已加载的任意业务插件，目标业务插件运行在工作进程提供的内存空间中，工作进程不同于目标业务插件的宿主程序所属的进程。

时长模块，还用于根据历史时刻以及当前时刻，获得目标业务插件的空闲时长。

在本实施例中，该时长模块101用于实现图1中的步骤S107、S108，关于该时长模块101的详细介绍可以参见步骤S107、S108的详细介绍。

回收模块102，用于判断空闲时长是否大于目标业务插件的时长阈值。

回收模块102，还用于若空闲时长大于时长阈值，则回收目标业务插件在内存空间中占据的内存资源。

在本实施例中，该回收模块102用于实现图1中的步骤S109、S110，关于该回收模块102的详细描述可以参见步骤S109、S110的详细介绍。

可选的实施方式中，该时长模块，还用于：

获取目标业务插件处理的目标业务在统计时段内的业务请求量；

计算业务请求量与参考请求量之间的比值；

将比值与时长阈值相乘，获得新的时长阈值。

可选的实施方式中，如图6所示，该插件回收装置还包括：

请求模块103，用于接收目标业务的处理请求；

加载模块104，用于若已加载的业务插件中未剩余有能够处理目标业务的目标业务插件，则从待加载的业务插件中获取与目标业务相匹配的业务插件；

加载模块104，还用于将与目标业务相匹配的业务插件加载到工作进程提供的内存空间中，以作为目标业务插件。

可选地实施方式中，加载模块104将与目标业务相匹配的业务插件加载到工作进程提供的内存空间中的方式，包括：

根据预设的负载均衡策略，从进程池中选取工作进程；

将与目标业务相匹配的目标业务插件加载到工作进程的进程空间。

可选的实施方式中，加载模块104根据预设的负载均衡策略，从进程池中选取工作进程的方式，包括：

获取进程池中每个进程剩余的插件数量以及空闲时长，其中，每个进程剩余的插件数量表示进程最多能够再加载的业务进程的数量；

分别将每个进程剩余的插件数量以及空闲时长进行加权，获得每个进程的候选得分；

根据每个进程的候选得分，选取得分最高的作为工作进程。

可选的实施方式中，加载模块104还用于：

获取计算机设备的硬件资源；

根据硬件资源，确定进程池中的进程数量；

根据进程数量，创建进程池。

可选地实施方式中，进程池中包括有多个进程，加载模块104根据进程数量，创建进程池的方式，包括：

获取每个进程的资源约束条件；

分别根据每个进程的资源约束条件，创建每个进程。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

还应理解的是，以上实施方式如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。

因此，本实施例还提供一种存储介质，该存储介质存储有计算机程序，该计算机程序被处理器执行时，实现本实施例提供的插件管理方法。其中，该存储介质可以是U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random AccessMemory)、磁碟或者光盘等各种可以存储程序代码的介质。

请参照图7，本实施例提供的一种计算机设备，包括处理器202及存储器201，存储器201存储有计算机程序，处理器通过读取并执行存储器201中与以上实施方式对应的计算机程序，实现本实施例所提供的插件管理方法。

继续参见图7，该计算机设备还包括通信单元203，通信单元203、处理器202与存储器201各元件相互之间系统总线204通信，以实现数据的传输或交互。

其中，该存储器201可以是基于任何电子、磁性、光学或其它物理原理的信息记录装置，用于记录执行指令、数据等。在一些实施方式中，该存储器201可以是，但不限于，易失存储器、非易失性存储器、存储驱动器等。

在一些实施方式中，该易失存储器可以是随机存取存储器(Random AccessMemory，RAM)；在一些实施方式中，该非易失性存储器可以是只读存储器(Read OnlyMemory，ROM)、可编程只读存储器(Programmable Read-Only Memory，PROM)、可擦除只读存储器(Erasable Programmable Read-Only Memory，EPROM)、电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，EEPROM)、闪存等；在一些实施方式中，该存储驱动器可以是磁盘驱动器、固态硬盘、任何类型的存储盘(如光盘、DVD等)，或者类似的存储介质，或者它们的组合等。

该通信单元203用于通过网络收发数据。在一些实施方式中，该网络可以包括有线网络、无线网络、光纤网络、远程通信网络、内联网、因特网、局域网(Local Area Network，LAN)、广域网(Wide Area Network，WAN)、无线局域网(Wireless Local Area Networks，WLAN)、城域网(Metropolitan Area Network，MAN)、广域网(Wide Area Network，WAN)、公共电话交换网(Public Switched Telephone Network，PSTN)、蓝牙网络、ZigBee网络、或近场通信(Near Field Communication，NFC)网络等，或其任意组合。在一些实施例中，网络可以包括一个或多个网络接入点。例如，网络可以包括有线或无线网络接入点，例如基站和/或网络交换节点，服务请求处理系统的一个或多个组件可以通过该接入点连接到网络以交换数据和/或信息。

该处理器202可能是一种集成电路芯片，具有信号的处理能力，并且，该处理器可以包括一个或多个处理核(例如，单核处理器或多核处理器)。仅作为举例，上述处理器可以包括中央处理单元(Central Processing Unit，CPU)、专用集成电路(ApplicationSpecific Integrated Circuit，ASIC)、专用指令集处理器(Application SpecificInstruction-set Processor，ASIP)、图形处理单元(Graphics Processing Unit，GPU)、物理处理单元(Physics Processing Unit，PPU)、数字信号处理器(Digital SignalProcessor，DSP)、现场可编程门阵列(Field Programmable Gate Array，FPGA)、可编程逻辑器件(Programmable Logic Device，PLD)、控制器、微控制器单元、简化指令集计算机(Reduced Instruction Set Computing，RISC)、或微处理器等，或其任意组合。

应该理解到的是，在上述实施方式中所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上所述，仅为本申请的各种实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。