一种应用容器扩展引擎平台的制作方法

1.本发明涉及应用容器扩展技术领域，特别涉及一种应用容器扩展引擎平台。


背景技术：

2.目前，扩展引擎可以将一个应用拆分成多个独立的、具有业务属性的服务，每个服务运行在独立的进程中，服务间通过轻量级的通信机制互相协作，从而为终端用户提供业务价值；
3.作为开源的应用容器引擎，docker容器使得开发人员能够把应用及其依赖包封装至可移植的docker容器中，然后将docker容器发布到存在docker容器环境的linux机器上；
4.基于目前现有的docker容器编排部署技术构建的docker容器集群，并不能根据实时的docker容器负载情况自动调整资源，导致docker容器集群在运行阶段负载能力不足。而部署docker容器的过程包含下载镜像，部署镜像，启动docker容器等一系列操作。当发现当前docker容器资源不能满足负载需求时才开始申请资源，由于下载镜像等操作会导致部署新docker容器的过程非常耗费时间，那么，在这段时间里，应用的可用性将无法得到保证。
5.因此，本发明提供了一种应用容器扩展引擎平台，通过根据实时监测到的服务器的负载运行数据，快速对应用容器进行扩展或缩减，同时及时将内部的资源进行部署，节省了大量时间，为应用的可用性提供了保障。


技术实现要素：

6.本发明提供一种应用容器扩展引擎平台，用以通过根据实时监测到的服务器的负载运行数据，快速对应用容器进行扩展或缩减，同时及时将内部的资源进行部署，节省了大量时间，为应用的可用性提供了保障。
7.本发明提供了一种应用容器扩展引擎平台，包括：
8.数量确定模块，用于获取服务器的当前运行负载数据，并基于所述当前运行负载数据确定扩展副本量；
9.扩展模块，用于通过扩展引擎根据所述扩展副本量对初始应用容器进行复制扩展，得到目标应用容器；
10.检测模块，用于对所述目标应用容器的运行数据进行检测，并基于检测结果对所述目标应用容器进行调整，完成对初始应用容器的扩展。
11.优选的，一种应用容器扩展引擎平台，数量确定模块，包括：
12.指令获取单元，用于获取管理终端发送的数据采集指令，其中，所述数据采集指令包括目标服务器类型以及待采集数据类型；
13.运行状态确定单元，用于基于所述数据采集指令获取所述目标服务器的运行状态，并基于所述运行状态判断所述目标服务器是否正常运行；
14.数据采集单元，用于当判定所述目标服务器正常运行时，基于所述数据采集指令
对所述目标服务器的运行负载数据进行采集，否则，判定运行负载数据采集失败。
15.优选的，一种应用容器扩展引擎平台，数量确定模块，还包括：
16.数据获取单元，用于获取服务器的当前运行负载数据，并将所述当前运行负载数据分为测试集和训练集；
17.模型搭建单元，用于构建神经网络模型，并基于所述训练集对所述神经网络模型进行训练，得到目标神经网络模型；
18.负载值确定单元，用于基于所述目标神经网络模型对所述测试集进行分析处理，得到所述测试集对应的负载值，其中，所述负载值用于表征当前请求访问服务器的访问量。
19.优选的，一种应用容器扩展引擎平台，负载值确定单元，包括：
20.负载值比较单元，用于获取得到的负载值，同时，获取服务器内初始应用容器的最大负载值，并将得到的负载值与所述最大负载值进行比较；
21.扩展确定单元，用于基于比较结果确定得到的负载值与所述最大负载值之间的大小关系；
22.当得到的负载值大于所述最大负载值时，判定需对所述服务器内初始应用容器进行扩展；
23.否则，保持当前初始应用容器数量不变；
24.副本量计算单元，用于当判定需对所述服务器内初始应用容器进行扩展时，基于得到的负载值与所述最大负载值之间的目标差值确定需对所述初始应用容器进行扩展的副本量，其中，所述副本量用于表征对初始应用容器的扩展数量。
25.优选的，一种应用容器扩展引擎平台，副本量计算单元，包括：
26.副本量核验单元，用于获取对所述初始应用容器进行扩展的副本量，并将所述副本量与预设阈值进行比较；
27.若所述副本量大于所述预设阈值，判定对所述初始应用容器进行扩展的副本量超标，并将所述预设阈值作为对所述初始应用容器进行扩展的目标副本量；
28.否则，判定对所述初始应用容器进行扩展的副本量合格。
29.优选的，一种应用容器扩展引擎平台，扩展模块，包括：
30.扩展指令获取单元，用于基于所述扩展引擎接收服务器发送的扩展指令，且所述扩展引擎对所述扩展指令进行分析，得到对所述初始应用容器进行复制扩展对应的扩展副本量；
31.扩展任务确定单元，用于基于所述扩展副本量创建应用容器扩展任务，并基于所述扩展任务获取所述初始应用容器的服务配置参数，同时，确定对所述初始应用容器扩展后的存放路径；
32.扩展单元，用于基于所述初始应用容器的服务配置参数对所述初始应用容器进行扩展，得到目标应用容器，并基于所述存放路径将所述目标应用容器进行存放，其中，所述目标应用容器的数量与所述扩展副本量一致；
33.资源部署单元，用于获取所述初始应用容器内部的资源配置信息，并基于所述资源配置信息从预设资源部署模式库中选取目标资源部署模式；
34.所述资源部署单元，用于基于所述目标资源部署模式将所述初始应用容器内部的资源在所述目标应用容器进行部署，其中，所述目标应用容器中的资源属于初始应用容器；
35.资源调度确定单元，用于监测所述目标应用容器在资源部署完成后的用户访问量，并基于所述用户访问量判断所述目标应用容器是否需要进行资源重调度；
36.资源调度单元，用于当判定需要进行资源重调度时，基于所述用户访问量制定资源重调度策略，并基于所述资源重调度策略确定每个目标应用容器的资源集合；
37.所述资源调度单元，用于基于所述每个目标应用容器的资源集合确定每个目标应用容器对资源的目标调度量，并基于所述目标调度量对每个目标应用容器进行资源重调度，得到最终的目标应用容器，其中，每个应用容器对应一个目标调度量。
38.优选的，一种应用容器扩展引擎平台，资源调度确定单元，包括：
39.资源利用率确定单元，用于实时监测所述目标应用容器的资源负载系数，并基于所述资源负载系数确定所述目标应用容器的资源利用率；
40.空闲应用容器确定单元，用于将所述资源利用率与预设资源利用率进行比较，且当所述资源利用率小于所述预设资源利用率，判定目标应用容器中存在空闲应用容器，否则，判定目标应用容器中不存在空闲应用容器；
41.容器缩减单元，用于当判定目标应用容器中存在空闲应用容器时，基于所述资源利用率确定目标空闲应用容器，并停止所述目标空闲应用容器的服务进程；
42.所述容器缩减单元，还用于在所述服务进程停止完毕后回收所述目标空闲应用容器，完成对空闲应用容器的缩减。
43.优选的，一种应用容器扩展引擎平台，资源部署单元，包括：
44.资源检测单元，用于获取资源部署完毕的目标应用容器，并将获取所述目标应用容器内部的资源层，生成对应的记录文件；
45.所述资源检测单元，用于基于预设资源部署检验方法根据所述记录文件对所述目标应用容器内部的资源层逐层进行检测，并得到检测结果；
46.合理性判断单元，用于基于所述检测结果判定所述目标容器内部的资源部署是否合理；
47.若判定资源部署合理，完成对目标应用容器内部资源的部署；
48.否则，重新对所述目标应用容器内部的资源进行部署，直至判定所述目标应用容器内部的资源部署合理。
49.优选的，一种应用容器扩展引擎平台，检测模块，包括：
50.数据获取单元，用于获取所述目标应用容器的运行数据，并将所述运行数据输入标签值确定模型，得到所述运行数据对应的标签值，其中，所述标签值包括正常标签值和异常标签值；
51.训练数据确定单元，用于基于所述标签值将所述运行数据分为训练数据集和测试数据集，并基于所述训练数据集对预设数据清洗模型进行训练；
52.数据清洗模型校验单元，用于基于所述测试数据对训练后的预设数据清洗模型进行测试，并当测试结果满足预设条件时，判定所述预设数据清洗模型合格；
53.数据清洗单元，用于基于所述预设数据清洗模型对所述目标应用容器的运行数据进行处理，去除所述运行数据中的错误数据，得到待分析数据，其中，所述错误数据包括空值和非数据类型数据；
54.故障检测单元，用于基于预设故障检测方法对所述待分析数据进行检测，判断所
述目标应用容器是否存在故障；
55.故障类型检测单元，用于当判定所述目标应用容器存在故障时，基于预设故障类型检测模型对所述待分析数据进行分析处理，确定所述目标应用容器的故障类型；
56.故障处理方案确定单元，用于判断所述故障类型是否在本地预先存储的可解决故障列表中；
57.若所述故障类型在所述可解决故障列表中，获取所述故障类型对应的目标解决方案，并基于所述目标解决方案对所述目标应用容器的故障进行解决；
58.否则，基于所述故障类型重新制定解决方案，直至完成所述目标应用容器的故障的解决。
59.优选的，一种应用容器扩展引擎平台，故障处理方案确定单元，包括：
60.性能检验单元，用于在对所述目标应用容器存在的故障解决完毕后，实时检测所述目标应用容器的性能值，并将所述性能值与预设性能值进行比较；
61.若所述性能值大于或等于所述预设性能值，判定对所述目标应用容器存在故障解决达到目标要求；
62.否则，判定对所述目标应用容器存在故障解决未达到目标要求，并重新制定目标解决方案，直至判定对所述目标应用容器存在故障解决达到目标要求，完成对目标应用容器故障的解决。
63.本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。
64.下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。
附图说明
65.附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：
66.图1为本发明实施例中一种应用容器扩展引擎平台的结构图；
67.图2为本发明实施例中一种应用容器扩展引擎平台中数量确定模块的第一结构图；
68.图3为本发明实施例中一种应用容器扩展引擎平台中数量确定模块的第二结构图。
具体实施方式
69.以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。
70.实施例1：
71.本实施例提供了一种应用容器扩展引擎平台，如图1所示，包括：
72.数量确定模块，用于获取服务器的当前运行负载数据，并基于所述当前运行负载数据确定扩展副本量；
73.扩展模块，用于通过扩展引擎根据所述扩展副本量对初始应用容器进行复制扩
展，得到目标应用容器；
74.检测模块，用于对所述目标应用容器的运行数据进行检测，并基于检测结果对所述目标应用容器进行调整，完成对初始应用容器的扩展。
75.该实施例中，当前运行负载数据指的是服务器在受到用户访问或使用时，当前服务器的运行数据。
76.该实施例中，扩展副本量指的是根据用户的访问量需要对初始应用容器进行复制扩展的数量。
77.该实施例中，扩展引擎是提前设置好的，用于对初始应用容器进行复制扩展。
78.该实施例中，初始应用容器指的是服务器中作为基准存在的应用容器，是作为应用容器的复制扩展源头存在的。
79.上述技术方案的有益效果是：通过根据实时监测到的服务器的负载运行数据，快速对应用容器进行扩展或缩减，同时及时将内部的资源进行部署，节省了大量时间，为应用的可用性提供了保障。
80.实施例2：
81.在上述实施例1的基础上，本实施例提供了一种应用容器扩展引擎平台，如图2所示，数量确定模块，包括：
82.指令获取单元，用于获取管理终端发送的数据采集指令，其中，所述数据采集指令包括目标服务器类型以及待采集数据类型；
83.运行状态确定单元，用于基于所述数据采集指令获取所述目标服务器的运行状态，并基于所述运行状态判断所述目标服务器是否正常运行；
84.数据采集单元，用于当判定所述目标服务器正常运行时，基于所述数据采集指令对所述目标服务器的运行负载数据进行采集，否则，判定运行负载数据采集失败。
85.该实施例中，目标服务器指的是需要进行应用容器扩展操作对应的服务器。
86.该实施例中，运行状态包括目标服务器正常运行或异常运行。
87.上述技术方案的有益效果是：通过确定数据采集指令中对应的服务器类型以及待采集数据的数据类型，便于对服务器进行准确的数据采集，从而为准确确定初始应用容器的扩展副本量提供了方便，便于快速对应用容器进行扩展或缩减。
88.实施例3：
89.在上述实施例1的基础上，本实施例提供了一种应用容器扩展引擎平台，如图3所示，数量确定模块，还包括：
90.数据获取单元，用于获取服务器的当前运行负载数据，并将所述当前运行负载数据分为测试集和训练集；
91.模型搭建单元，用于构建神经网络模型，并基于所述训练集对所述神经网络模型进行训练，得到目标神经网络模型；
92.负载值确定单元，用于基于所述目标神经网络模型对所述测试集进行分析处理，得到所述测试集对应的负载值，其中，所述负载值用于表征当前请求访问服务器的访问量。
93.该实施例中，目标神经网络模型指的是对构建的神经网络模型进行训练和测试后得到的神经网络模型，该神经网络模型可直接服务器的运行数据进行分析，从而确定当前访问服务器的数量。
94.该实施例中，负载值指的是服务器当前接收用户访问请求后，自身的运行负载程度值，通过该值可准确计算当前访问服务器的客户数量。
95.上述技术方案的有益效果是：通过对服务器的运行负载数据进行准确的分析，从而准确确定访问服务器的用户量，为确定初始应用容器的扩展副本量提供了便利。
96.实施例4：
97.在上述实施例3的基础上，本实施例提供了一种应用容器扩展引擎平台，负载值确定单元，包括：
98.负载值比较单元，用于获取得到的负载值，同时，获取服务器内初始应用容器的最大负载值，并将得到的负载值与所述最大负载值进行比较；
99.扩展确定单元，用于基于比较结果确定得到的负载值与所述最大负载值之间的大小关系；
100.当得到的负载值大于所述最大负载值时，判定需对所述服务器内初始应用容器进行扩展；
101.否则，保持当前初始应用容器数量不变；
102.副本量计算单元，用于当判定需对所述服务器内初始应用容器进行扩展时，基于得到的负载值与所述最大负载值之间的目标差值确定需对所述初始应用容器进行扩展的副本量，其中，所述副本量用于表征对初始应用容器的扩展数量。
103.该实施例中，初始应用容器的最大负载值指的是初始应用容器所允许的最大访问量。
104.该实施例中，扩展副本量的确定方法还可以是工作人员通过对后台程序进行编码，人为设置需要对初始应用容器进行扩展的数量。
105.上述技术方案的有益效果是：通过将初始应用容器的最大负载值与分析得到的负载值进行比较，准确得到初始应用容器是否需要进行扩展，且在需要扩展时，根据扩展副本量对初始应用容器进行快速准确的扩展，节省了大量时间，为应用的可用性提供了保障。
106.实施例5：
107.在上述实施例4的基础上，本实施例提供了一种应用容器扩展引擎平台，副本量计算单元，包括：
108.副本量核验单元，用于获取对所述初始应用容器进行扩展的副本量，并将所述副本量与预设阈值进行比较；
109.若所述副本量大于所述预设阈值，判定对所述初始应用容器进行扩展的副本量超标，并将所述预设阈值作为对所述初始应用容器进行扩展的目标副本量；
110.否则，判定对所述初始应用容器进行扩展的副本量合格。
111.该实施例中，预设阈值是提前设定好的，用于衡量对初始应用容器的扩展数量是否超高设定要求，如超过预设阈值，判定对初始应用容器的扩展量超出要求，容易造成对资源的恶意占用。
112.该实施例中，目标副本量指的是对初始应用容器的扩展量大于预设阈值时，将预设阈值作为对初始应用容器的扩展数量。
113.上述技术方案的有益效果是：通过对得到的初始应用容器的扩展数量进行校验，当扩展量大于预设阈值时，将预设阈值作为对初始应用容器的扩展数量，有利于放置对资
源的恶意占用，提高了应用的可用性。
114.实施例6：
115.在上述实施例1的基础上，本实施例提供了一种应用容器扩展引擎平台，扩展模块，包括：
116.扩展指令获取单元，用于基于所述扩展引擎接收服务器发送的扩展指令，且所述扩展引擎对所述扩展指令进行分析，得到对所述初始应用容器进行复制扩展对应的扩展副本量；
117.扩展任务确定单元，用于基于所述扩展副本量创建应用容器扩展任务，并基于所述扩展任务获取所述初始应用容器的服务配置参数，同时，确定对所述初始应用容器扩展后的存放路径；
118.扩展单元，用于基于所述初始应用容器的服务配置参数对所述初始应用容器进行扩展，得到目标应用容器，并基于所述存放路径将所述目标应用容器进行存放，其中，所述目标应用容器的数量与所述扩展副本量一致；
119.资源部署单元，用于获取所述初始应用容器内部的资源配置信息，并基于所述资源配置信息从预设资源部署模式库中选取目标资源部署模式；
120.所述资源部署单元，用于基于所述目标资源部署模式将所述初始应用容器内部的资源在所述目标应用容器进行部署，其中，所述目标应用容器中的资源属于初始应用容器；
121.资源调度确定单元，用于监测所述目标应用容器在资源部署完成后的用户访问量，并基于所述用户访问量判断所述目标应用容器是否需要进行资源重调度；
122.资源调度单元，用于当判定需要进行资源重调度时，基于所述用户访问量制定资源重调度策略，并基于所述资源重调度策略确定每个目标应用容器的资源集合；
123.所述资源调度单元，用于基于所述每个目标应用容器的资源集合确定每个目标应用容器对资源的目标调度量，并基于所述目标调度量对每个目标应用容器进行资源重调度，得到最终的目标应用容器，其中，每个应用容器对应一个目标调度量。
124.该实施例中，应用容器扩展任务指的是在接收到扩展指令时，根据需要扩展的数量确定对应的扩展任务，该扩展任务包括对扩展过程中扩展数量的校验。
125.该实施例中，初始应用容器的服务配置参数指的是初始应用容器对应的大小以及在与客户访问对接时，访问程序对用户访问设置的权限等。
126.该实施例中，存放路径是用来引导对初始应用容器扩展后得到的目标应用容器的存放位置，便于对扩展后的应用容器进行位置锁定，也便于用户根据路径进行访问。
127.该实施例中，目标应用容器指的是对服务器中的初始应用容器进行扩展后得到的，其中，目标应用容器可以是一个，也可以是多个。
128.该实施例中，资源配置信息指的是初始应用容器中存放的应用对应数据信息，例如数据在初始应用容器中的存放位置，存放方式等。
129.该实施例中，预设资源部署模式库是提前设定好的，内部存储有多种资源部署模式。
130.该实施例中，目标资源部署模式是预设资源部署模式库中的一种或多种组合，用来将初始应用容器中的资源在目标应用容器中进行部署。
131.该实施例中，资源重调度策略是用来在资源部署完成后，当目标应用容器中的资
源存在缺少或多余时，对目标应用容器中的资源进行调整。
132.该实施例中，资源集合指的是每个目标应用容器中存放的资源数量。
133.该实施例中，目标调度量指的是需要对每个目标应用容器进行资源调整的数量值。
134.该实施例中，目标应用容器中的资源属于初始应用容器中的一部分或全部。
135.上述技术方案的有益效果是：通过确定需要对初始应用容器扩展的数量，从而实现对初始应用容器进行快速准确的扩展，同时对根据初始应用容器中的资源配置信息确定对目标应用容器中资源进行部署时的部署策略，有利于对目标应用容器进行准确的扩展，提高应用的可用性，同时在资源部署结束后，实时监测每个应用容器中的资源运行情况，且在需要调整的时候，及时对目标应用容器中的资源进行调度，为确保应用可用性提供了保障。
136.实施例7：
137.在上述实施例6的基础上，本实施例提供了一种应用容器扩展引擎平台，资源调度确定单元，包括：
138.资源利用率确定单元，用于实时监测所述目标应用容器的资源负载系数，并基于所述资源负载系数确定所述目标应用容器的资源利用率；
139.空闲应用容器确定单元，用于将所述资源利用率与预设资源利用率进行比较，且当所述资源利用率小于所述预设资源利用率，判定目标应用容器中存在空闲应用容器，否则，判定目标应用容器中不存在空闲应用容器；
140.容器缩减单元，用于当判定目标应用容器中存在空闲应用容器时，基于所述资源利用率确定目标空闲应用容器，并停止所述目标空闲应用容器的服务进程；
141.所述容器缩减单元，还用于在所述服务进程停止完毕后回收所述目标空闲应用容器，完成对空闲应用容器的缩减。
142.该实施例中，资源负载系数是用来描述目标应用容器中部署的资源，在用户访问时，同一时间段内用户访问资源的数量。
143.该实施例中，预设资源利用率是提前设定好的，用于衡量目标应用容器内部的资源利用率是否达到预设要求。
144.该实施例中，空闲应用容器指的是扩展后的应用容器存在多余，即当前的用户访问量使用不了当前的应用容器数量。
145.该实施例中，目标空闲应用容器指的是众多目标应用容器中为空闲的应用容器。
146.该实施例中，服务进程指的是空闲应用容器在客户访问时，提供访问服务的应用程序。
147.该实施例中，实时监测所述目标应用容器的资源负载系数，并基于所述资源负载系数确定所述目标应用容器的资源利用率，包括：
148.基于预设时间间隔获取所述目标应用服务器的客户访问量，其中，所述客户访问量为多组；
149.基于所述客户访问量计算所述目标应用容器的资源负载系数，并基于所述资源负载系数计算预设时间段内所述目标应用容器中的资源利用率，具体步骤包括：
150.根据如下公式计算所述目标应用容器的资源负载系数：
[0151][0152]
其中，表示所述目标应用容器的资源负载系数；n表示获取到的客户访问量的组数；i表示当前获取到的客户访问量的组数；qi表示第i组客户访问量中的客户访问量值；q表示n组客户访问量中取值最大的客户访问量值；
[0153]
根据如下公式计算预设时间段内所述目标应用容器中的资源利用率：
[0154][0155]
其中，η表示所述目标应用容器中的资源利用率，且取值范围为(0，1)；表示所述目标应用容器的资源负载系数；z表示访问所述目标应用容器的当前用户，且z的取值为[1，m]；m表示访问所述目标应用容器的最大用户个数；xz表示预设时间段内第z个用户需要访问资源的数量值，且的取值小于s；s表示所述目标应用容器中的资源总量值；r表示误差系数，且取值范围为(0.05，0.15)；
[0156]
将计算得到的资源利用率与预设阈值进行比较；
[0157]
若所述资源利用率大于或等于所述预设阈值，判定目标应用容器中资源被充分利用；
[0158]
否则，判定目标应用容器中的资源未被充分利用，且将每一目标应用容器的资源利用率进行记录；
[0159]
基于记录结果确定目标应用容器中需要进行缩减的目标应用容器，并将需要进行缩减的目标应用容器进行缩减回收。
[0160]
上述预设时间段是提前设定好的，例如可以是1小时、2小时等。
[0161]
上述预设阈值是提前设定好的，用于衡量计算得到的资源利用率是否达到预期设定的要求，是可以人为修改的。
[0162]
上述公式中，若n的取值为3，q1取值为5，q2取值为6，q3取值为2，q取值为6，则计算得到的为72.2％。
[0163]
上述公式中，若取值为72.2％，m取值为2，x1取值为15，x2取值为18，s取值为35，则计算得到的η为61.3％。
[0164]
上述技术方案的有益效果是：通过实时监测目标应用容器内部的资源利用率，并在资源利用率不达标时，判断扩展后的应用容器内部是否存在空闲应用容器，且在存在空闲应用容器的情况下实现对扩展后的应用容器进行缩减，提高了对应用容器实时调整的目的，节省了大量时间，提高了应用的可用性。
[0165]
实施例8：
[0166]
在上述实施例6的基础上，本实施例提供了一种应用容器扩展引擎平台，资源部署单元，包括：
[0167]
资源检测单元，用于获取资源部署完毕的目标应用容器，并将获取所述目标应用容器内部的资源层，生成对应的记录文件；
[0168]
所述资源检测单元，用于基于预设资源部署检验方法根据所述记录文件对所述目标应用容器内部的资源层逐层进行检测，并得到检测结果；
[0169]
合理性判断单元，用于基于所述检测结果判定所述目标容器内部的资源部署是否合理；
[0170]
若判定资源部署合理，完成对目标应用容器内部资源的部署；
[0171]
否则，重新对所述目标应用容器内部的资源进行部署，直至判定所述目标应用容器内部的资源部署合理。
[0172]
该实施例中，资源层指的是应用容器内部用来存在应用数据的数据层。
[0173]
该实施例中，记录文件用于记录应用容器中每一层资源层的数据类型以及数据量。
[0174]
该实施例中，预设资源部署检验方法是提前设定好的，用于检验容器内部的资源部署是否合理，例如可以是根据要实现的功能对数据的完整性等进行校验。
[0175]
上述技术方案的有益效果是：通过对应用容器内部部署好的资源进行校验，便于确保应用容器内部的资源正常运行，为确保应用容器在运行时不出现错误提供了便利，同时为确保应用的可用性提供了保障。
[0176]
实施例9：
[0177]
在上述实施例1的基础上，本实施例提供了一种应用容器扩展引擎平台，检测模块，包括：
[0178]
数据获取单元，用于获取所述目标应用容器的运行数据，并将所述运行数据输入标签值确定模型，得到所述运行数据对应的标签值，其中，所述标签值包括正常标签值和异常标签值；
[0179]
训练数据确定单元，用于基于所述标签值将所述运行数据分为训练数据集和测试数据集，并基于所述训练数据集对预设数据清洗模型进行训练；
[0180]
数据清洗模型校验单元，用于基于所述测试数据对训练后的预设数据清洗模型进行测试，并当测试结果满足预设条件时，判定所述预设数据清洗模型合格；
[0181]
数据清洗单元，用于基于所述预设数据清洗模型对所述目标应用容器的运行数据进行处理，去除所述运行数据中的错误数据，得到待分析数据，其中，所述错误数据包括空值和非数据类型数据；
[0182]
故障检测单元，用于基于预设故障检测方法对所述待分析数据进行检测，判断所述目标应用容器是否存在故障；
[0183]
故障类型检测单元，用于当判定所述目标应用容器存在故障时，基于预设故障类型检测模型对所述待分析数据进行分析处理，确定所述目标应用容器的故障类型；
[0184]
故障处理方案确定单元，用于判断所述故障类型是否在本地预先存储的可解决故障列表中；
[0185]
若所述故障类型在所述可解决故障列表中，获取所述故障类型对应的目标解决方案，并基于所述目标解决方案对所述目标应用容器的故障进行解决；
[0186]
否则，基于所述故障类型重新制定解决方案，直至完成所述目标应用容器的故障
的解决。
[0187]
该实施例中，运行数据指的是在对初始应用容器进行扩展后，得到的目标应用容器在接收用户访问时的运行参数。
[0188]
该实施例中，标签值确定模型是提前设定好的，用于确定目标应用容器在运行时具体运行数据的取值大小。
[0189]
该实施例中，运行数据对应的标签值指的是用于表示运行数据的具体取值。
[0190]
该实施例中，预设数据清洗模型是提前设定好的，用来对目标运行数据中的错误数据进行清洗，确保对目标应用容器的运行状态进行准确分析。
[0191]
该实施例中，预设条件是提前设定好的，例如可以是通过测试数据测得预设数据清洗模型清洗的准确率达到95％以上。
[0192]
该实施例中，预设故障检测方法是提前设定好的，用于通过对目标应用容器的运行数据进行分析，从而判断目标应用容器中是否存在故障，例如可以是将当前的运行数据与目标应用容器无故障时的运行数据进行比较，从而确定目标应用容器是否存在故障。
[0193]
该实施例中，预设故障类型检测模型是提前设定好的。
[0194]
该实施例中，目标解决方案指的是用来解决目标应用容器中存在的故障问题所对应的故障解决方法。
[0195]
上述技术方案的有益效果是：通过对目标应用容器的运行数据进行清洗并分析，便于根据运行数据准确判断目标应用容器中是否存在故障，同时在存在故障时，对故障类型进行准确的判断，从而实现对故障解决方案进行准确的制定，提高了对目标应用容器故障的解决效率，也为确保应用可用性提供了保障。
[0196]
实施例10：
[0197]
在上述实施例9的基础上，本实施例提供了一种应用容器扩展引擎平台，故障处理方案确定单元，包括：
[0198]
性能检验单元，用于在对所述目标应用容器存在的故障解决完毕后，实时检测所述目标应用容器的性能值，并将所述性能值与预设性能值进行比较；
[0199]
若所述性能值大于或等于所述预设性能值，判定对所述目标应用容器存在故障解决达到目标要求；
[0200]
否则，判定对所述目标应用容器存在故障解决未达到目标要求，并重新制定目标解决方案，直至判定对所述目标应用容器存在故障解决达到目标要求，完成对目标应用容器故障的解决。
[0201]
该实施例中，性能值是用来描述对目标应用容器存在的故障处理后，目标应用容器在工作时的工作性能情况。
[0202]
该实施例中，预设性能值是提前设定好的，用于衡量故障处理完毕后的目标应用容器的工作性能值是否达标预期要求，是可以人为修改的。
[0203]
该实施例中，目标要求指的是对目标应用容器存在的故障解决后，对目标应用容器的工作性能的要求值。
[0204]
上述技术方案的有益效果是：通过再对目标应用容器的故障解决后，对目标应用容器的工作性能值进行校验，确保通过目标解决方案对目标应用容器存在的问题进行彻底解决，为确保初始应用容器扩展后得到的目标应用容器正常运行提供了保障，确保了应用
的可用性。
[0205]
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。