应用启动方法、装置及服务器与流程

本申请涉及互联网技术领域，尤其涉及应用启动方法、装置及服务器。

背景技术：

应用是部署在服务器上，并用于支持业务运行的系统，一个业务可能包括多个应用，而每个应用也可能包含多个模块。

现有技术中，在使用虚拟机(kernel-basedvirtualmachine，kvm)模式启动应用时，需要将整个应用的所有模块全部启动。

但是，当应用体量很大时，由于该应用包含的模块较多，则该应用启动会比较慢，并且若其中有一个模块未能启动成功，则将导致整个应用启动异常。

技术实现要素：

本申请提供应用启动方法、装置及服务器，以解决现有技术中当应用体量很大时，容易导致整个应用启动异常的问题。

根据本申请实施例的第一方面，提供一种应用启动方法，该方法应用于服务器上，包括：

接收应用启动请求；

根据所述应用启动请求确定对应的起始模块；

根据启动依赖树确定所述起始模块之后的各个依赖模块；

启动所述起始模块和所述各个依赖模块。

根据本申请实施例的第二方面，提供一种应用启动装置，所述装置应用 于服务器上，包括：

接收单元，用于接收应用启动请求；

第一确定单元，用于根据所述应用启动请求确定对应的起始模块；

第二确定单元，用于根据启动依赖树确定所述起始模块之后的各个依赖模块；

启动单元，用于启动所述起始模块和所述各个依赖模块。

根据本申请实施例的第三方面，提供一种服务器，所述服务器包括：

处理器；用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为：

接收应用启动请求；

根据所述应用启动请求确定对应的起始模块；

根据启动依赖树确定所述起始模块之后的各个依赖模块；

启动所述起始模块和所述各个依赖模块。

应用本申请实施例，通过接收应用启动请求，根据应用启动请求确定对应的起始模块，根据启动依赖树确定起始模块之后的各个依赖模块，启动起始模块和该起始模块之后的各个依赖模块，使得服务器在保证应用正常启动的前提下，所需要启动的模块数量达到最小，从而实现了应用最小化启动，节省了启动成本和启动时间，还增加了应用的稳定性。

附图说明

图1a为本申请实施例的应用启动场景示意图；

图1b为本申请实施例的应用启动的一示意图；

图1c为本申请实施例的应用启动的另一示意图；

图2为本申请应用启动方法的一个实施例流程图；

图3为本申请应用启动装置所在设备的一种硬件结构图；

图4为本申请应用启动装置的一个实施例框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

参见图1a，为本申请实施例的应用启动场景示意图：

图1a场景中包括：分层设计的各个应用层的所有模块。其中，分层设计的各个应用层包括自顶向下的展示层、业务层、服务层和数据交互层。展示层包括3个模块，分别是：展示功能1模块、展示功能2模块、展示功能3模块；业务层包括4个模块，分别是：业务1模块、业务2模块、业务3模块和业务4模块；服务层包括2个模块，分别是基础服务1模块和基础服务2模块；数据交换层包括1个模块，该模块用于数据库访问、以及外围应用数据引入。

本申请实施例中，接收到应用启动请求后，可以无需启动图1a中的所有模块，而是只启动与应用启动请求对应的起始模块、以及该起始模块之后的各个依赖模块。其中，依赖模块指的是与起始模块具有依赖关系的模块。这里的依 赖关系可以是直接或间接的依赖关系。

比如：需要使用业务1时，则只需要启动业务1模块、基础服务1模块、以及用于数据库访问、以及外围应用数据引入的模块即可，如图1b中的阴影部分。其中，业务1模块与基础服务1模块有直接的依赖关系；业务1模块于用于数据库访问、以及外围应用数据引入的模块有间接的依赖关系。

又比如：需要使用展示功能3时，则只需要启动展示功能3模块、业务3模块和、业务4模块、基础服务2模块、以及用于数据库访问、以及外围应用数据引入的模块即可，如图1c中的阴影部分。

上述只启动起始模块、以及与该起始模块之后的各个依赖模块，表明实现了应用的最小化启动。其中，最小化启动指定的是保证应用正常启动的前提下，所需要启动的模块数量达到最小。也就是说起始模块、以及该起始模块之后的各个依赖模块是最小化启动中的必须启动的模块。

由此可见，本申请可以实现最小化启动，这样可以节省启动成本和启动时间，从而增加了应用的稳定性。

另外，本申请中涉及到的应用指的是软件领域内，可以部署在服务器上，能够独立运行并提供服务的一组源码、数据和配置文件的集合。其中，服务器指的是已经运行基本操作系统的物理机。

下面对本申请实施例进行详细说明。

参见图2，为本申请应用启动方法的一个实施例的流程图，该方法可以应用于服务器上，包括以下步骤：

步骤210：接收应用启动请求。

本申请实施例中，应用启动请求可以是测试人员发起的启动请求，也可以是客户端向服务器发送的启动请求。

步骤220：根据应用启动请求确定对应的起始模块。

本申请实施例中，服务器接收到应用启动请求后，不是启动各个应用层中的所有模块，而是先确定该应用启动请求对应的起始模块。

比如：如图1b所示，接收到的应用启动请求是需要使用业务1时，则业务 1模块为起始模块。

至于如何实现根据应用启动请求确定对应的起始模块，其包括但不限于以下这种方式：

根据匹配应用类标识或应用包标识来确定，具体包括：

(1)根据应用启动请求确定对应的应用类标识或应用包标识。

本申请实施例中，若应用启动请求携带有应用类标识或应用包标识，可以从应用启动请求中解析得到其对应的应用类标识或应用包标识。

其中，应用类标识可以是启动类的类名，应用包标识可以是启动类的包名。

另外，还可以先确定接收到应用启动请求的启动入口，再将该启动入口的类名确定为应用启动请求对应的应用类标识、或者将该启动入口的包名确定为应用启动请求对应的应用包标识。

(2)获取与应用类标识或应用包标识匹配的模块集合。

本申请实施例中，可以通过贪婪算法或最长前缀匹配算法获取与应用类标识或应用包标识匹配的模块集合，但也不限于这两种算法。

(3)若模块集合中包括一个模块，则将模块集合包括的模块确定为起始模块。

(4)若模块集合中包括至少两个模块，则确定模块集合中的各个模块的依赖关系，并根据各个模块的依赖关系确定起始模块。

在一个例子中，通过最长前缀匹配算法获取应用包标识匹配的模块集合时，其过程可以包括：

(1)确定应用包标识为：abcdefg。并且，服务器提供的与应用包标识进行匹配的包名集合为：{abc；abcf；abcdefgh；abcdefgi；abcdefk}。

(2)匹配出的模块集合为{abcdefgh；abcdefgi}。

(3)检测abcdefgh、abcdefgi所在的模块，得到了abcdefgh所在的模块a和abcdefgi所在的模块b；

(4)检测模块a和模块b的模块依赖关系。

(5)根据模块a和模块b的模块依赖关系确定起始模块。

如果模块a依赖模块b，那么从模块a开始启动，则模块a为起始模块；如果模块b依赖模块a，那么从模块b开始启动，则模块b为起始模块，即从依赖关系中的顶层模块开始启动。

步骤230：根据启动依赖树确定起始模块之后的各个依赖模块。其中，该启动依赖树可以指的是系统内存中的一个多叉树，用于指示系统中各个模块之间的依赖关系。

本申请实施例中，同一个应用的各个模块之间往往具有依赖关系。具体来说，在应用正常启动和提供服务的过程中，处于不同应用层的模块具有执行上的依赖关系。比如：展示层中的展示功能模块所展示的内容，需要依赖数据交互层从数据库中获取。

其中，上述依赖关系可以预先保存在启动依赖树中，通过起始模块查询该启动依赖树，即可获取到与该起始模块具有直接或间接依赖关系的各个依赖模块。

比如：如图1b所示，业务1模块依赖于基础服务1模块，而基础服务1模块依赖于用于数据库访问、以及外围应用数据引入的模块，故此业务1模块之后的依赖模块分别为：基础服务1模块和用于数据库访问、以及外围应用数据引入的模块。

至于如何实现根据启动依赖树确定起始模块之后的各个依赖模块，其包括但不限于以下这种方式：

根据启动依赖树中的模块依赖关系来确定，具体包括：

(1)获取起始模块所处于的应用层。

(2)根据启动依赖树中的模块依赖关系，确定起始模块所处于的应用层之外的各个应用层中与该起始模块具有直接或间接的模块依赖关系的依赖模块。

本申请实施例中，启动依赖树可以包括系统中分层设计的各个应用层的所有模块之间的模块依赖关系。

并且，启动依赖树中的模块依赖关系来源可以来自于系统中每个模块的配置文件，具体包括：

(1)获取系统中每个模块的配置文件，该配置文件包括与自身模块对应的模块依赖关系。

(2)根据各个配置文件中的模块依赖关系，得到系统中所有模块之间的模块依赖关系，并将系统中所有模块之间的模块依赖关系保存至启动依赖树中。

上述方式可以根据启动依赖树中的模块依赖关系直接得到起始模块之后的各个依赖模块，这样可以提高最小化应用启动的效率，还可以提高应用的稳定性。

步骤240：启动起始模块和该起始模块之后的各个依赖模块。

本申请实施例中，若启动依赖树包括系统中分层设计的各个应用层的所有模块之间的模块依赖关系，服务器可以根据启动依赖树中的模块依赖关系获取起始模块和各个依赖模块的启动次序，并根据该启动次序依次启动起始模块和各个依赖模块。

其中，系统内存中的启动依赖树可以包括叶子模块和树干模块，在应用启动时，一般从叶子模块的最底层开始启动，按照每层都要依次启动的方式，最终启动到树干模块。

比如：如图1b所示，假设起始模块为业务1模块，且业务1模块依赖于基础服务1模块，基础服务1模块依赖于用于数据库访问、以及外围应用数据引入的模块，并且，根据系统内存中的启动依赖树获知业务1模块是最底层叶子模块，基础服务1模块是上一层叶子模块，用于数据库访问、以及外围应用数据引入的模块是树干模块，因此，获取到的启动次序依次为：业务1模块、基础服务1模块和用于数据库访问、以及外围应用数据引入的模块。

由上述实施例可见，通过接收应用启动请求，根据应用启动请求确定对应的起始模块，根据启动依赖树确定起始模块之后的各个依赖模块，启动起始模块和该起始模块之后的各个依赖模块，使得服务器在保证应用正常启动的前提下，所需要启动的模块数量达到最小，从而实现了应用最小化启动，节省了启动成本和启动时间，还增加了应用的稳定性。

与本申请应用启动方法的实施例相对应，本申请还提供了应用启动装置的实施例。

本申请应用启动装置的实施例可以分别应用在服务器上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图3所示，为本申请应用启动装置所在设备的一种硬件结构图，除了图3所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的设备通常根据该设备的实际功能，还可以包括其他硬件，如对于终端来说，可能包括摄像头、触摸屏子、通信组件等，对于服务器来说，可能包括负责处理报文的转发芯片等等。

参见图4，为本申请应用启动装置的一个实施例框图，该应用启动装置可以应用在服务器上，并可以用于执行图2所示的应用启动方法，该装置包括：接收单元41、第一确定单元42、第二确定单元43和启动单元44。

其中，接收单元41，用于接收应用启动请求；

第一确定单元42，用于根据所述应用启动请求确定对应的起始模块；

第二确定单元43，用于根据启动依赖树确定所述起始模块之后的各个依赖模块；

启动单元44，用于启动所述起始模块和所述各个依赖模块。

在一个可选的实现方式中：第一确定单元42可以包括：第一确定子单元、第一获取子单元、第二确定子单元和第三确定子单元(图4中未标出)。

其中，第一确定子单元，用于根据所述应用启动请求确定对应的应用类标识或应用包标识；

第一获取子单元，用于获取与所述应用类标识或所述应用包标识匹配的模块集合；

第二确定子单元，用于若所述模块集合中包括一个模块，则将所述模块集合包括的模块确定为所述起始模块；

第三确定子单元，用于若所述模块集合中包括至少两个模块，则确定所述模块集合中的各个模块的依赖关系，并根据所述各个模块的依赖关系确定所述起始模块。

在另一个可选的实现方式中：第一确定子单元包括确定模块(图4中未标出)。

其中，确定模块，用于确定接收到所述应用启动请求的启动入口，并将所述启动入口的类名确定为所述应用启动请求对应的应用类标识、或者将所述启动入口的包名确定为所述应用启动请求对应的应用包标识。

在另一个可选的实现方式中：第一获取子单元可以包括：获取模块(图4中未标出)。

其中，获取模块，用于获取模块，用于通过贪婪算法或最长前缀匹配算法获取与所述应用类标识或所述应用包标识匹配的模块集合。

在另一个可选的实现方式中：所述启动依赖树包括系统中分层设计的各个应用层的所有模块之间的模块依赖关系；所述第二确定单元43包括：第二获取子单元和第四确定子单元(图4中未标出)。

其中，第二获取子单元，用于获取所述起始模块所处于的应用层；

第四确定子单元，用于根据所述启动依赖树中的模块依赖关系，确定所述起始模块所处于的应用层之外的各个应用层中与所述起始模块具有直接或间接的模块依赖关系的依赖模块。

在另一个可选的实现方式中：所述分层设计的各个应用层包括自顶向下的展示层、业务层、服务层和数据交互层。

在另一个可选的实现方式中：所述启动单元44包括：第三获取子单元和第五确定子单元(图4中未标出)。

其中，第三获取子单元，用于根据所述启动依赖树中的模块依赖关系获取所述起始模块和所述各个依赖模块的启动次序；

第五确定子单元，用于根据所述启动次序依次启动所述起始模块和所述各个依赖模块。

在另一个可选的实现方式中：所述装置还包括：获取单元和保存单元(图4中未标出)。

获取单元，用于获取系统中每个模块的配置文件，所述配置文件包括与自身模块对应的模块依赖关系；

保存单元，用于根据各个配置文件中的模块依赖关系，得到系统中所有模块之间的模块依赖关系，并将所述系统中所有模块之间的模块依赖关系保存至所述启动依赖树中。上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本请求方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本申请实施例还提供了一种服务器，所述服务器包括：

处理器；用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为：

接收应用启动请求；

根据所述应用启动请求确定对应的起始模块；

根据启动依赖树确定所述起始模块之后的各个依赖模块；

启动所述起始模块和所述各个依赖模块。

由上述实施例可见，通过接收应用启动请求，根据应用启动请求确定对应的起始模块，根据启动依赖树确定起始模块之后的各个依赖模块，启动起始模块和该起始模块之后的各个依赖模块，使得服务器在保证应用正常启动的前提下，所需要启动的模块数量达到最小，从而实现了应用最小化启动，节省了启动成本和启动时间，还增加了应用的稳定性。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。