一种多服务级联启动方法、装置及计算机可读存储介质

摘要

根据本申请方案所提供的多服务级联启动方法、装置及计算机可读存储介质，对docker服务是否存在第一开机自启脚本进行一级判断；当docker服务存在第一开机自启脚本时，对docker容器是否存在第二开机自启脚本进行二级判断；当docker容器存在第二开机自启脚本时，通过宿主机的预设开机自启脚本调用docker容器的级联服务启动脚本；根据级联服务启动脚本控制docker容器内相应的应用服务级联启动。通过本申请方案的实施，通过宿主机的预设开机自启脚本调用级联服务启动脚本，控制相应的应用服务级联启动，降低人力资源消耗，提高应用服务的启动效率，唯一的级联服务启动脚本可以有效减少应用服务启动失败的问题。

权利要求

1.一种多服务级联启动方法，其特征在于，包括：对docker服务是否存在第一开机自启脚本进行一级判断；

当所述docker服务存在所述第一开机自启脚本时，对docker容器是否存在第二开机自启脚本进行二级判断；

当所述docker容器存在所述第二开机自启脚本时，通过宿主机的预设开机自启脚本调用所述docker容器的级联服务启动脚本；

获取所有应用服务之间的关联关系；

根据所述关联关系对所述应用服务进行级联分组；

将不同分组的所述应用服务导入不同所述docker容器；

根据各组之间的级联关系确定不同所述docker容器之间的级联关系；

根据不同所述docker容器之间的级联关系，确定不同所述docker容器执行所述级联服务启动脚本启动所述应用服务的顺序；

根据所述级联服务启动脚本控制所述docker容器内相应的应用服务级联启动；其中，所述级联服务启动脚本中设计有应用服务启动顺序。

2.根据权利要求1所述的多服务级联启动方法，其特征在于，所述对docker服务是否存在第一开机自启脚本进行一级判断的步骤之后，还包括：当所述docker服务不存在所述第一开机自启脚本时，在所述docker服务中设置第一开机自启脚本文件；

根据所述第一开机自启脚本文件控制所述docker服务开机自启。

3.根据权利要求1所述的多服务级联启动方法，其特征在于，所述对docker容器是否存在第二开机自启脚本进行二级判断的步骤之后，还包括：当所述docker容器不存在所述第二开机自启脚本时，在所述docker容器中设置第二开机自启脚本文件；

根据所述第二开机自启脚本文件控制所述docker容器开机自启。

4.根据权利要求1所述的多服务级联启动方法，其特征在于，通过预设开机自启脚本调用所述docker容器的级联服务启动脚本的步骤之前，还包括：获取根据所述应用服务的启动顺序编辑的所述级联服务启动脚本；

将所述级联服务启动脚本导入所述docker容器。

5.根据权利要求1所述的多服务级联启动方法，其特征在于，所述根据所述级联服务启动脚本控制所述docker容器内相应的应用服务级联启动的步骤之后，还包括：在所述应用服务全部级联启动成功之后，重启宿主机；

再次根据所述级联服务启动脚本控制所述docker容器内所述应用服务级联启动；

若所有所述应用服务全部级联启动成功，则确定所述级联服务启动脚本设置成功。

6.根据权利要求5所述的多服务级联启动方法，其特征在于，所述重启宿主机的步骤之后，还包括：当存在相应的所述应用服务级联启动失败时，检测所述级联服务启动脚本对应于级联启动失败的应用服务的脚本文件是否存在代码缺陷；

若所述脚本文件存在代码缺陷，则根据所述代码缺陷对所述脚本文件进行修复；

基于修复后的级联服务启动脚本再次执行所述重启宿主机的步骤。

7.一种多服务级联启动装置，其特征在于，包括：第一判断模块，用于对docker服务是否存在第一开机自启脚本进行一级判断；

第二判断模块，用于当所述docker服务存在所述第一开机自启脚本时，对docker容器是否存在第二开机自启脚本进行二级判断；

调用模块，用于当所述docker容器存在所述第二开机自启脚本时，通过预设开机自启脚本执行所述docker容器的级联服务启动脚本；

获取模块，用于获取所有应用服务之间的关联关系；

分组模块，用于根据所述关联关系对所述应用服务进行级联分组；

导入模块，用于将不同分组的所述应用服务导入不同所述docker容器；

确定模块，用于根据各组之间的级联关系确定不同所述docker容器之间的级联关系；

根据不同所述docker容器之间的级联关系，确定不同所述docker容器执行所述级联服务启动脚本启动所述应用服务的顺序；

控制模块，用于根据所述级联服务启动脚本控制所述docker容器内相应的应用服务级联启动；其中，所述级联服务启动脚本中设计有应用服务启动顺序。

8.一种电子装置，包括：存储器、处理器及总线，其特征在于，所述总线用于实现所述存储器、处理器之间的连接通讯；所述处理器用于执行存储在所述存储器上的计算机程序，所述处理器执行所述计算机程序时，实现权利要求1至6中任意一项所述方法中的步骤。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，实现权利要求1至6中的任意一项所述方法中的步骤。

说明书

一种多服务级联启动方法、装置及计算机可读存储介质

技术领域

[0001] 本申请涉及网络安全技术领域，尤其涉及一种多服务级联启动方法、装置及计算机可读存储介质。

背景技术

[0002] 当前主流docker部署采用的是Dockerfile部署系统，在实现自动化部署方便提供了极大的便利，但是在某些特定的生产环境中，往往受限于网络本身，导致Dockerfile方式受到局限性。同时在小型项目交付过程中，因为多个服务之间的级联关系，往往会将多个中间件和应用服务打包在一个容器内运行，存在不同的中间件和应用服务之间启动顺序会有一定限制的问题。在生产环境遇到突发事件(如断电、设备维护、重启系统等)时，容器内部的服务往往不能及时的恢复运行，导致生产任务无法及时完成，将会产生极其严重的后果。

[0003] 在故障修复后，人工收到进入容器逐一启动服务，但是这样既耗损人力资源，又影响效率。在部署服务时，在容器内给每个服务设置为开机自启动，这样在docker容器启动后，可以根据级联要求逐一启动服务。但是systemd管理器要求启动服务参数ExecStart需要输入绝对路径命令，实际环境存在一些服务(如elasticsearch)需要切换到普通用户账户执行启动命令，这样就无法直接使用这种方式。

发明内容

[0004] 本申请实施例提供了一种多服务级联启动方法、装置及计算机可读存储介质，至少能够解决相关技术中人工逐一启动多个应用服务，既耗损人力资源，又影响应用服务启动效率，以及多个应用服务自启动文件可能存在启动失败的问题。

[0005] 本申请实施例第一方面提供了一种多服务级联启动方法，包括：

[0006] 对docker服务是否存在第一开机自启脚本进行一级判断；

[0007] 当所述docker服务存在所述第一开机自启脚本时，对docker容器是否存在第二开机自启脚本进行二级判断；

[0008] 当所述docker容器存在所述第二开机自启脚本时，通过宿主机的预设开机自启脚本调用所述docker容器的级联服务启动脚本；

[0009] 根据所述级联服务启动脚本控制所述docker容器内相应的应用服务级联启动。

[0010] 本申请实施例第二方面提供了一种多服务级联启动装置，包括：

[0011] 第一判断模块，用于对docker服务是否存在第一开机自启脚本进行一级判断；

[0012] 第二判断模块，用于当所述docker服务存在所述第一开机自启脚本时，对docker容器是否存在第二开机自启脚本进行二级判断；

[0013] 调用模块，用于当所述docker容器存在所述第二开机自启脚本时，通过预设开机自启脚本执行所述docker容器的级联服务启动脚本；

[0014] 控制模块，用于根据所述级联服务启动脚本控制所述docker容器内相应的应用服务级联启动。

[0015] 本申请实施例第三方面提供了一种电子装置，包括：存储器、处理器及总线，所述总线用于实现所述存储器、处理器之间的连接通讯；所述处理器用于执行存储在所述存储器上的计算机程序，所述处理器执行所述计算机程序时上述本申请实施例第一方面提供的多服务级联启动方法中的各步骤。

[0016] 本申请实施例第四方面提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时，实现上述本申请实施例第一方面提供的多服务级联启动方法中的各步骤。

[0017] 由上可见，根据本申请方案所提供的多服务级联启动方法、装置及计算机可读存储介质，对docker服务是否存在第一开机自启脚本进行一级判断；当所述docker服务存在所述第一开机自启脚本时，对docker容器是否存在第二开机自启脚本进行二级判断；当所述docker容器存在所述第二开机自启脚本时，通过宿主机的预设开机自启脚本调用所述docker容器的级联服务启动脚本；根据所述级联服务启动脚本控制所述docker容器内相应的应用服务级联启动。通过本申请方案的实施，依次判断docker服务和docker容器是否存在开机自启脚本，当都存在开机自启脚本时，通过宿主机的预设开机自启脚本调用docker容器的级联服务启动脚本，控制docker容器内相应的应用服务级联启动，通过级联服务启动脚本，降低人力资源消耗的同时提高应用服务的启动效率，唯一的级联服务启动脚本可以有效减少应用服务启动失败的问题。

附图说明

[0018] 图1为本申请第一实施例提供的多服务级联启动方法的基本流程示意图；

[0019] 图2为本申请第二实施例提供的多服务级联启动方法的细化流程示意图；

[0020] 图3为本申请第三实施例提供的多服务级联启动装置的程序模块示意图；

[0021] 图4为本申请第四实施例提供的电子装置的结构示意图。

[0022] 具体实施内容

[0023] 为使得本申请的发明目的、特征、优点能够更加的明显和易懂，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而非全部实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

[0024] 为了解决相关技术中人工逐一启动多个应用服务，既耗损人力资源，又影响应用服务启动效率，以及多个应用服务自启动文件可能存在启动失败的问题，本申请第一实施例提供了一种多服务级联启动方法，如图1为本实施例提供的多服务级联启动方法的基本流程图，该多服务级联启动方法包括以下步骤：

[0025] 步骤101、对docker服务是否存在第一开机自启脚本进行一级判断。

[0026] 具体的，本实施例中docker是一个开源的应用容器引擎，docker服务指的是docker.service服务，在实际应用中，docker服务往往需要负责运维的相关技术人员手动开启，在本实施例中，开启采用docker部署的宿主机之后，对docker服务进行一级判断，判断docker服务是否存在能够实现开机自启的第一开机自启脚本，docker服务开机自启能够有效降低人力资源消耗。

[0027] 在本实施例一种可选的实施方式中，对docker服务是否存在第一开机自启脚本进行一级判断的步骤之后，还包括：当docker服务不存在第一开机自启脚本时，在docker服务中设置第一开机自启脚本文件；根据第一开机自启脚本文件控制docker服务开机自启。

[0028] 具体的，在本实施例中，当经过一级判断确定docker服务不存在第一开机自启脚本时，在docker服务中设置第一开机自启脚本文件，根据第一开机自启脚本文件，在宿主机开机时自动启动docker服务，docker服务开机自启能够有效降低人力资源消耗。

[0029] 步骤102、当docker服务存在第一开机自启脚本时，对docker容器是否存在第二开机自启脚本进行二级判断。

[0030] 具体的，在实际应用中，docker部署系统将应用服务部署在docker容器中，所以在启动应用服务之前必须先启动docker容器，而启动docker容器又需要在docker服务开启之后，在本实施例中，当docker服务存在第一开机自启脚本能够开机自启时，对docker容器进行二级判断，判断docker容器是否存在能够实现开机自启的第二开机自启脚本，docker容器开机自启也能够有效降低人力资源消耗。

[0031] 在本实施例一种可选的实施方式中，对docker容器是否存在第二开机自启脚本进行二级判断的步骤之后，还包括：当docker容器不存在第二开机自启脚本时，在docker容器中设置第二开机自启脚本文件；根据第二开机自启脚本文件控制docker容器开机自启。

[0032] 具体的，在本实施例中，当经过二级判断确定docker容器不存在第二开机自启脚本时，在docker容器中设置第二开机自启脚本文件，根据第二开机自启脚本文件，在docker服务开机自动启动之后，启动docker容器，docker容器开机自启能够有效降低人力资源消耗。

[0033] 步骤103、当docker容器存在第二开机自启脚本时，通过宿主机的预设开机自启脚本调用docker容器的级联服务启动脚本。

[0034] 具体的，在本实施例中，在docker服务和docker容器都可以正常开机自启之后，检测宿主机中是否存在用于启动级联服务启动脚本的预设开机自启脚本，通过宿主机的预设开机自启脚本调用docker容器的级联服务启动脚本，无需多个启动服务文件，只需要一个级联启动脚本和开机自启该脚本服务文件，使docker部署系统更加简便，提高检测效率。应当说明的是，宿主机的开机自启脚本可以控制宿主机在遇到突发事件(如断电、设备维护、重启系统等)时自主重启。

[0035] 在本实施例一种可选的实施方式中，通过预设开机自启脚本调用docker容器的级联服务启动脚本的步骤之前，还包括：获取根据应用服务的启动顺序编辑的级联服务启动脚本；将级联服务启动脚本导入docker容器。

[0036] 具体的，在实际应用中，在部署服务时，在容器内给每个服务设置为开机自启动，这样在docker容器启动后，可以根据级联要求逐一启动服务。但是systemd管理器要求启动服务参数ExecStart需要输入绝对路径命令，实际环境存在一些服务，例如elasticsearch，需要切换到普通用户账户执行启动命令，这样就无法直接使用这种方式，在本实施例中，根据应用服务的之间的映射关系确定应用服务的优先级，并根据优先级确定应用服务的启动顺序，再根据需要启动的应用服务的启动顺序编辑级联服务启动脚本，将级联服务启动脚本导入到docker容器，只需通过级联关系就可以控制应用服务按启动顺序依次启动。

[0037] 步骤104、根据级联服务启动脚本控制docker容器内相应的应用服务级联启动。

[0038] 具体的，在本实施例中，根据级联服务启动脚本中设计的应用服务启动顺序，控制docker容器内相应的应用服务级联启动。

[0039] 在本实施例一种可选的实施方式中，根据级联服务启动脚本控制docker容器内相应的应用服务级联启动的步骤之前，还包括：获取所有应用服务之间的关联关系；根据关联关系对应用服务进行级联分组；将不同分组的应用服务导入不同docker容器；根据各组之间的级联关系确定不同docker容器之间的级联关系；根据不同docker容器之间的级联关系，确定不同所述docker容器执行所述级联服务启动脚本启动应用服务的顺序。

[0040] 具体的，在实际应用中，若docker容器的应用服务非常多，则可能在应用服务启动的过程中出现卡顿或者启动失败的情况，在本实施例中，获取所有应用服务之间的关联关系，根据关联关系对应用服务进行级联分组，将相互关联的应用服务分在同一组并打包导入docker容器中，应当理解的是，在docker运行时，可以同时存在多个docker容器，并根据各组之间的级联关系确定不同docker容器之间的级联关系，根据不同docker容器之间的级联关系确定在应用服务启动时，不同docker容器执行级联服务启动脚本对docker容器内整体的应用服务启动操作的顺序。应当说明的是，相关技术人员可以根据实际环境调整级联服务启动脚本的内容，控制不同docker容器中实际需要启动的应用服务进行级联启动，使应用服务级联启动更加灵活。

[0041] 在本实施例一种可选的实施方式中，根据级联服务启动脚本控制docker容器内相应的应用服务级联启动的步骤之后，还包括：在应用服务全部级联启动成功之后，重启宿主机；再次根据级联服务启动脚本控制docker容器内应用服务级联启动；若所有应用服务全部级联启动成功，则确定级联服务启动脚本设置成功。

[0042] 具体的，在本实施例中，在初次部署系统时，应用服务全部级联启动成功之后，控制宿主机自主重启确定级联服务启动脚本是否设置成功，在重启宿主机之后，再次根据级联服务启动脚本控制docker容器内应用服务级联启动，若所有应用服务全部启动成功，则确定级联服务启动脚本设置成功。

[0043] 应当说明的是，在相应的应用服务全部级联启动成功之后，重启宿主机的步骤之后，还包括：当存在相应的应用服务级联启动失败时，检测级联服务启动脚本对应于级联启动失败的应用服务的脚本文件是否存在代码缺陷；若脚本文件存在代码缺陷，则根据代码缺陷对脚本文件进行修复；基于修复后的级联服务启动脚本再次执行重启宿主机的步骤。

[0044] 具体的，在本实施例中，在宿主机重启之后，若存在需要启动的应用服务启动失败，则检测级联服务启动脚本中对应于该启动失败的应用服务的脚本文件是否存在代码缺陷，在确定级联服务启动脚本的代码缺陷之后，对该代码缺陷进行修复，修复完成之后重启宿主机，再次对级联服务启动脚本进行验证。

[0045] 基于上述申请的实施例方案，对docker服务是否存在第一开机自启脚本进行一级判断；当docker服务存在第一开机自启脚本时，对docker容器是否存在第二开机自启脚本进行二级判断；当docker容器存在第二开机自启脚本时，通过宿主机的预设开机自启脚本调用docker容器的级联服务启动脚本；根据级联服务启动脚本控制docker容器内相应的应用服务级联启动。通过本申请方案的实施，依次判断docker服务和docker容器是否存在开机自启脚本，当都存在开机自启脚本时，通过宿主机的预设开机自启脚本调用docker容器的级联服务启动脚本，控制docker容器内相应的应用服务级联启动，通过级联服务启动脚本，降低了人力资源消耗的同时提高了应用服务的启动效率，唯一的级联服务启动脚本可以有效减少应用服务启动失败的问题。

[0046] 图2中的方法为本申请第二实施例提供的一种细化的多服务级联启动方法，该多服务级联启动方法包括：

[0047] 步骤201、对docker服务是否存在第一开机自启脚本进行一级判断。

[0048] 具体的，本实施例中docker是一个开源的应用容器引擎，docker服务指的是docker.service服务，在实际应用中，docker服务往往需要负责运维的相关技术人员手动开启，在本实施例中，开启采用docker部署的宿主机之后，对docker服务进行一级判断，判断docker服务是否存在能够实现开机自启的第一开机自启脚本，docker服务开机自启能够有效降低人力资源消耗。

[0049] 步骤202、当docker服务存在第一开机自启脚本时，对docker容器是否存在第二开机自启脚本进行二级判断。

[0050] 具体的，在实际应用中，docker部署系统将应用服务部署在docker容器中，所以在启动应用服务之前必须先启动docker容器，而启动docker容器又需要在docker服务开启之后，在本实施例中，当docker服务存在第一开机自启脚本能够开机自启时，对docker容器进行二级判断，判断docker容器是否存在能够实现开机自启的第二开机自启脚本，docker容器开机自启也能够有效降低人力资源消耗。

[0051] 步骤203、当docker容器存在第二开机自启脚本时，通过宿主机的预设开机自启脚本调用docker容器的级联服务启动脚本。

[0052] 步骤204、根据级联服务启动脚本控制docker容器内相应的应用服务级联启动。

[0053] 步骤205、在应用服务全部级联启动成功之后，重启宿主机。

[0054] 步骤206、再次根据级联服务启动脚本控制docker容器内应用服务级联启动。

[0055] 步骤207、若所有应用服务全部级联启动成功，则确定级联服务启动脚本设置成功。

[0056] 具体的，在本实施例中，在初次部署系统时，应用服务全部级联启动成功之后，控制宿主机自主重启确定级联服务启动脚本是否设置成功，在重启宿主机之后，再次根据级联服务启动脚本控制docker容器内应用服务级联启动，若所有应用服务全部启动成功，则确定级联服务启动脚本设置成功。

[0057] 应当理解的是，本实施例中各步骤的序号的大小并不意味着步骤执行顺序的先后，各步骤的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成唯一限定。

[0058] 根据本申请方案所提供的多服务级联启动方法，对docker服务是否存在第一开机自启脚本进行一级判断；当docker服务存在第一开机自启脚本时，对docker容器是否存在第二开机自启脚本进行二级判断；当docker容器存在第二开机自启脚本时，通过宿主机的预设开机自启脚本调用docker容器的级联服务启动脚本；根据级联服务启动脚本控制docker容器内相应的应用服务级联启动；在应用服务全部级联启动成功之后，重启宿主机；再次根据级联服务启动脚本控制docker容器内应用服务级联启动；若所有应用服务全部级联启动成功，则确定级联服务启动脚本设置成功，通过本申请方案的实施，通过宿主机的预设开机自启脚本调用级联服务启动脚本，控制相应的应用服务级联启动，在初次级联启动成功时重启宿主机，验证级联服务启动脚本的准确性，保证应用服务需要级联启动时的运行效率。

[0059] 图3为本申请第三实施例提供的一种多服务级联启动装置。该多服务级联启动装置可用于实现前述实施例中的多服务级联启动方法。如图3所示，该多服务级联启动装置主要包括：

[0060] 第一判断模块301，用于对docker服务是否存在第一开机自启脚本进行一级判断；

[0061] 第二判断模块302，用于当docker服务存在第一开机自启脚本时，对docker容器是否存在第二开机自启脚本进行二级判断；

[0062] 调用模块303，用于当docker容器存在第二开机自启脚本时，通过预设开机自启脚本执行docker容器的级联服务启动脚本；

[0063] 控制模块304，用于根据级联服务启动脚本控制docker容器内相应的应用服务级联启动。

[0064] 在本实施例一种可选的实施方式中，该多服务级联启动装置还包括：设置模块。设置模块用于：当docker服务不存在第一开机自启脚本时，在docker服务中设置第一开机自启脚本文件。控制模块还用于：根据第一开机自启脚本文件控制docker服务开机自启。

[0065] 在本实施例一种可选的实施方式中，设置模块还用于：当docker容器不存在第二开机自启脚本时，在docker容器中设置第二开机自启脚本文件。控制模块还用于：根据第二开机自启脚本文件控制docker容器开机自启。

[0066] 在本实施例一种可选的实施方式中，该多服务级联启动装置还包括：获取模块、导入模块。获取模块用于：获取根据应用服务的启动顺序编辑的级联服务启动脚本。导入模块用于：将级联服务启动脚本导入docker容器。

[0067] 在本实施例一种可选的实施方式中，该多服务级联启动装置还包括：重启模块、确定模块。重启模块用于：在应用服务全部级联启动成功之后，重启宿主机。控制模块还用于：再次根据级联服务启动脚本控制docker容器内应用服务级联启动。确定模块用于：若所有应用服务全部级联启动成功，则确定级联服务启动脚本设置成功。

[0068] 进一步的，在本实施例一种可选的实施方式中，该多服务级联启动装置还包括：检测模块、修复模块。检测模块用于：当存在相应的应用服务级联启动失败时，检测级联服务启动脚本对应于级联启动失败的应用服务的脚本文件是否存在代码缺陷。修复模块用于：若脚本文件存在代码缺陷，则根据代码缺陷对脚本文件进行修复。重启模块还用于：基于修复后的级联服务启动脚本再次执行重启宿主机的步骤。

[0069] 在本实施例一种可选的实施方式中，该多服务级联启动装置还包括：分组模块。获取模块还用于：获取所有应用服务之间的关联关系。分组模块用于：根据关联关系对应用服务进行级联分组。导入模块还用于：将不同分组的应用服务导入不同docker容器。确定模块还用于：根据各组之间的级联关系确定不同docker容器之间的级联关系；根据不同docker容器之间的级联关系，确定不同所述docker容器执行所述级联服务启动脚本启动应用服务的顺序。

[0070] 应当说明的是，第一、二实施例中的多服务级联启动方法均可基于本实施例提供的多服务级联启动装置实现，所属领域的普通技术人员可以清楚的了解到，为描述的方便和简洁，本实施例中所描述的多服务级联启动装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

[0071] 根据本申请方案所提供的多服务级联启动装置，对docker服务是否存在第一开机自启脚本进行一级判断；当docker服务存在第一开机自启脚本时，对docker容器是否存在第二开机自启脚本进行二级判断；当docker容器存在第二开机自启脚本时，通过宿主机的预设开机自启脚本调用docker容器的级联服务启动脚本；根据级联服务启动脚本控制docker容器内相应的应用服务级联启动。通过本申请方案的实施，依次判断docker服务和docker容器是否存在开机自启脚本，当都存在开机自启脚本时，通过宿主机的预设开机自启脚本调用docker容器的级联服务启动脚本，控制docker容器内相应的应用服务级联启动，通过级联服务启动脚本，降低了人力资源消耗的同时提高了应用服务的启动效率，唯一的级联服务启动脚本可以有效减少应用服务启动失败的问题。

[0072] 图4为本申请第四实施例提供的一种电子装置。该电子装置可用于实现前述实施例中的多服务级联启动方法。如图4所示，该电子装置主要包括：

[0073] 存储器401、处理器402、总线403及存储在存储器401上并可在处理器402上运行的计算机程序，存储器401和处理器402通过总线403连接。处理器402执行该计算机程序时，实现前述实施例中的多服务级联启动方法。其中，处理器的数量可以是一个或多个。

[0074] 存储器401可以是高速随机存取记忆体(RAM，Random Access Memory)存储器，也可为非不稳定的存储器(non‑volatile memory)，例如磁盘存储器。存储器401用于存储可执行程序代码，处理器402与存储器401耦合。

[0075] 进一步的，本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质可以是设置于上述各实施例中的电子装置中，该计算机可读存储介质可以是前述图4所示实施例中的存储器。

[0076] 该计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现前述实施例中的多服务级联启动方法。进一步的，该计算机可存储介质还可以是U盘、移动硬盘、只读存储器(ROM，Read‑Only Memory)、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

[0077] 在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或模块的间接耦合或通讯连接，可以是电性，机械或其它的形式。

[0078] 作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

[0079] 另外，在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

[0080] 集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个可读存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的可读存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

[0081] 需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请所必须的。

[0082] 在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

[0083] 以上为对本申请所提供的多服务级联启动方法、装置及计算机可读存储介质的描述，对于本领域的技术人员，依据本申请实施例的思想，在具体实施方式及应用范围上均会有改变之处，综上，本说明书内容不应理解为对本申请的限制。