一种企业级微服务容器化应用管理方法、装置、设备及介质

技术领域

本发明涉及计算机技术领域，具体而言，涉及一种企业级微服务容器化应用管理方法、装置、设备及介质。

背景技术

随着信息技术的不断发展，企业级微服务容器化应用的管理变得愈加复杂。这些应用通常由多个微服务组成，每个微服务都有自己的代码仓库、依赖关系、版本要求，以及可能的部署需求。此外，微服务应用的频繁更新和部署，使得应用管理面临了更大的挑战。现有技术主要依赖于传统的持续集成/持续部署(CI/CD)系统工具，如GitLab CI/CD、Jenkins等，或通过IDEA插件配置相关镜像仓库和云平台接口，以实现微服务应用的部署和管理。这些方法存在以下问题：传统CI/CD工具部署流程较为复杂，需要手动编写配置文件；IDEA插件配置繁琐，不支持大规模微服务应用的统一管理，且在版本协同和回滚方面存在限制。

基于上述现有技术的缺点，现亟需一种企业级微服务容器化应用管理方法、装置、设备及介质。

发明内容

本发明的目的在于提供一种企业级微服务容器化应用管理方法、装置、设备及介质，以改善上述问题。为了实现上述目的，本发明采取的技术方案如下：

第一方面，本申请提供了一种企业级微服务容器化应用管理方法，包括：

获取第一信息和第二信息，所述第一信息包括至少一个代码仓库信息以及对应的微服务注册名，所述第二信息包括微服务应用部署命令；

根据所述第一信息和第二信息进行关联分析得到自动化部署流程，所述自动化部署流程包括微服务应用部署的配置参数和顺序；

根据所述自动化部署流程执行依赖校验和版本协同校验处理得到校验结果；

根据所述自动化部署流程和所述校验结果执行部署命令将微服务应用部署至目标环境中得到部署结果；

根据所述部署结果定期对已部署的微服务应用进行健康状态检查，并对未通过健康状态检查的微服务进行回滚处理。

第二方面，本申请还提供了企业级微服务容器化应用管理装置，包括：

获取模块，用于获取第一信息和第二信息，所述第一信息包括至少一个代码仓库信息以及对应的微服务注册名，所述第二信息包括微服务应用部署命令；

关联模块，用于根据所述第一信息和第二信息进行关联分析得到自动化部署流程，所述自动化部署流程包括微服务应用部署的配置参数和顺序；

校验模块，用于根据所述自动化部署流程执行依赖校验和版本协同校验处理得到校验结果；

部署模块，用于根据所述自动化部署流程和所述校验结果执行部署命令将微服务应用部署至目标环境中得到部署结果；

回滚模块，用于根据所述部署结果定期对已部署的微服务应用进行健康状态检查，并对未通过健康状态检查的微服务进行回滚处理。

第三方面，本申请还提供了一种企业级微服务容器化应用管理设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现所述企业级微服务容器化应用管理方法的步骤。

第四方面，本申请还提供了一种介质，所述介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述企业级微服务容器化应用管理方法的步骤。

本发明的有益效果为：

本发明通过自动分析微服务容器化应用的版本信息，能够确保不同微服务之间的版本协同，从而降低了版本兼容性问题的风险；本发明对微服务工程的依赖关系进行自动化检查，能够在早期阶段发现依赖关系的冲突问题，从而降低了后续开发和部署过程中的错误率。

本发明的其他特征和优点将在随后的说明书阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明实施例了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

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

图1为本发明实施例中所述的企业级微服务容器化应用管理方法流程示意图；

图2为本发明实施例中所述的企业级微服务容器化应用管理装置结构示意图；

图3为本发明实施例中所述的企业级微服务容器化应用管理设备结构示意图。

图中标记：1、获取模块；2、关联模块；21、第一提取单元；22、第二提取单元；23、第一关联单元；24、第一计算单元；3、校验模块；31、第一构建单元；32、第一检验单元；321、第三提取单元；322、第一判断单元；323、第二判断单元；324、第三判断单元；325、第二检验单元；33、第一整合单元；4、部署模块；41、第一编码单元；42、第一制作单元；43、第一部署单元；5、回滚模块；51、第二计算单元；52、第四判断单元；53、第一回滚单元；800、企业级微服务容器化应用管理设备；801、处理器；802、存储器；803、多媒体组件；804、I/O接口；805、通信组件。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本发明的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

实施例1：

本实施例提供了一种企业级微服务容器化应用管理方法。

参见图1，图中示出了本方法包括步骤S100、步骤S200、步骤S300、步骤S400和步骤S500。

步骤S100、获取第一信息和第二信息，第一信息包括至少一个代码仓库信息以及对应的微服务注册名，第二信息包括微服务应用部署命令。

可以理解的是，代码仓库信息指存储微服务应用代码的地方，可以是版本控制系统(例如Git)中的特定代码仓库。微服务注册名则是标识微服务的唯一名称，用于在整个系统中识别和定位微服务。第二信息则包括微服务应用部署命令，即在目标环境中部署微服务所需的指令集。这些命令涉及代码编译、镜像制作、容器部署等操作，旨在将微服务应用从开发阶段成功地部署到目标环境，使其可以在实际运行中提供服务。

步骤S200、根据第一信息和第二信息进行关联分析得到自动化部署流程，自动化部署流程包括微服务应用部署的配置参数和顺序。

可以理解的是，本步骤是创建一个自动化部署流程，包括微服务应用部署所需的配置参数和执行顺序。这个流程是根据项目中的不同工程的特定需求和关联关系生成的，确保每个微服务应用能够按照正确的配置和顺序部署到目标环境中。具体地，管理平台预先绑定各个工程的代码仓库以及对应的微服务注册名，代码仓库可以为gitlab或者github；绑定内容为工程的id及工程的git地址，用于唯一标识该仓库下的工程，若有多个工程则需要绑定多个id到该平台上，用于后续的统一应用部署，该步骤主要是对项目下所有工程纳入统一管理，在对代码工程进行标签或者分支创建时，均通过该平台进行创建，从而触发相关的CICD流水线功能。这有助于实现微服务容器化应用的统一管理和自动化部署。

步骤S300、根据自动化部署流程执行依赖校验和版本协同校验处理得到校验结果。

可以理解的是，本步骤中，依赖校验用于检查微服务应用所依赖的其他包是否存在冲突或者废弃的情况。通过分析项目中的依赖树，系统可以判断是否存在依赖冲突，如果存在，则直接返回校验失败，防止不兼容的依赖关系导致部署问题。版本协同校验用于验证依赖的其他微服务工程的版本是否处于可用状态，并且与当前项目的部署环境兼容。系统会检查依赖包的版本状态标记位、版本可用环境等多维度信息，确保引用的其他工程的接口包版本是可用的且适用于当前部署环境。如果版本不可用或者不兼容，校验结果将返回失败，强制引用方进行版本升级，避免了在部署后出现接口兼容性问题。

步骤S400、根据自动化部署流程和校验结果执行部署命令将微服务应用部署至目标环境中得到部署结果。

可以理解的是，在本步骤中管理平台按照预定的自动化部署流程，自动执行各项部署任务，包括代码编译、镜像制作等步骤。同时，结合之前的校验结果，确保部署的微服务应用符合依赖关系和版本兼容性的要求。只有在依赖关系和版本兼容性通过校验的情况下，系统才会执行部署命令。这样可以避免因为依赖问题或者版本不兼容性导致的部署失败或者系统异常。实现了自动化、智能化的微服务应用部署，确保了部署过程的高效性和稳定性。

步骤S500、根据部署结果定期对已部署的微服务应用进行健康状态检查，并对未通过健康状态检查的微服务进行回滚处理。

可以理解的是，本步骤通过定期执行健康状态检查操作，以验证已部署的微服务应用是否仍然正常运行；回滚操作的目标是将当前版本的微服务应用回滚到上一个稳定状态的版本，这可以防止不稳定版本的微服务对整个系统造成问题。具体地，回滚操作会重新部署之前的版本，确保系统的可用性和业务连续性。

需要说明的是，步骤S200包括步骤S210、步骤S220、步骤S230和步骤S240。

步骤S210、根据代码仓库信息进行提取处理得到代码仓库地址。

可以理解的是，本步骤从预先绑定的代码仓库信息中提取出相应的代码仓库地址，具体地，代码仓库地址通常是代码存储库在GitLab或GitHub等版本控制系统中的具体位置。

步骤S220、根据微服务注册名进行提取处理得到微服务注册信息。

可以理解的是，微服务注册名是在整个系统中唯一标识某个微服务的名称或ID。

步骤S230、根据代码仓库地址和注册信息进行关联处理得到关联结果。

可以理解的是，关联结果包括了代码仓库和微服务的具体关联信息，将两者进行绑定，为后续的自动化部署提供了必要的数据。

步骤S240、基于微服务应用部署命令和关联结果，计算各个微服务工程的依赖关系和相关配置信息得到自动化部署流程。

可以理解的是，本步骤通过分析各个微服务工程之间的依赖关系，并确定相关的配置信息，最终得到自动化部署流程。这个流程描述了微服务应用在特定环境下的部署顺序和配置参数，以确保微服务应用能够正确地部署和运行。

需要说明的是，步骤S300包括步骤S310、步骤S320和步骤S330。

步骤S310、根据自动化部署流程中所有项目的依赖关系构建得到依赖树，并通过检索依赖树中的冲突关键字判断项目中是否存在依赖冲突，得到依赖校验结果。

可以理解的是，本步骤通过构建一个依赖树，包括所有项目的依赖关系，并在依赖树中检索冲突关键字，以确定项目是否存在依赖冲突。依赖冲突是指不同项目或模块之间的依赖关系可能导致不一致或冲突的情况。该步骤的结果是依赖校验的一部分，用于确定是否有依赖冲突存在。具体地，依赖冲突校验主要通过mvn dependency tree实现，通过打印依赖树结果，进行依赖分析，通过对打印的依赖树进行conflict关键字寻找判断项目中是否存在依赖冲突，若存在冲突，则直接返回流水线失败结果。开发人员可以在pom文件中使用来统一管理子模块的版本一致性，使用去除多余的依赖，从而解决依赖冲突问题。

步骤S320、根据自动化部署流程中每个项目具有依赖关系的依赖数据包进行可用状态检验得到版本协同校验结果。

可以理解的是，可用状态通常指的是版本可用性、环境兼容性等因素。如果某个依赖数据包不可用，可能意味着该版本已经废弃或不适用于当前环境，需要引入新版本。

步骤S330、根据依赖校验结果和版本协同校验结果进行整合处理得到校验结果。

可以理解的是，最终的校验结果包括了依赖校验和版本协同校验的各种信息，用于确定是否允许继续自动化部署流程。如果任何一项校验失败，可能会导致整个流水线失败，需要开发人员进行必要的修复或升级操作。通过构建依赖树、检查依赖包的可用状态，并整合依赖校验和版本协同校验的结果，以确定是否继续自动化部署流程，有助于确保部署的微服务应用不会受到依赖冲突或版本兼容性问题的影响。

需要说明的是，步骤S320包括步骤S321、步骤S322、步骤S323、步骤S324和步骤S325。

步骤S321、根据自动化部署流程中每个项目的依赖关系进行特征提取得到对应的依赖数据包信息。

步骤S322、根据依赖数据包信息进行可用状态检验，判断依赖数据包信息是否处于可用状态得到可用状态检验结果。

步骤S323、根据可用状态检验结果，判断项目是否需要进行版本协同校验。

步骤S324、若需要进行版本协同校验，判断对应的依赖数据包的版本状态标记为是否为可用状态。

步骤S325、若版本状态标记为可用状态，检验依赖数据包可用环境是否适用于当前部署环境。

具体地，关于版本协同校验，主要是对一个工程中依赖的其他包是否处于可用状态进行校验，若状态不可用则表明该版本已经废弃，需要引入新版本进行强制升级；每个工程的依赖版本数据会始终记录到数据库的依赖表中，该表主要维护整个项目下所有的依赖版本数据，包括依赖包的GAV坐标、版本状态标记位、版本创建时间、版本可用环境等多维度信息；在当前项目下，当某个微服务工程引用了其他微服务工程对外发布的接口包时，在该平台进行标签或者分支创建时，会触发该步骤进行版本协同校验，即对当前工程所引用的其他工程所发布的接口包的信息进行校验，核验版本状态标记位是否可用，若标志位是废弃状态，则该步骤的版本协同校验失败，平台返回失败结果，强制该微服务工程负责人对当前引用的接口包进行升级处理；若标志位为成功状态，则表明该版本可以使用，进一步校验版本可用环境，版本可用环境必须大于当前部署环境，比如，若当前微服务是要部署至验证环境，而版本可用环境标志位仅为测试环境，则校验结果仍为失败，若当前微服务是要部署至测试环境，而版本可用环境标志位仅为验证环境，则校验返回成功。该功能主要是为了解决版本兼容性问题，若引用的其他工程的接口包进行升级了，可能不兼容老版本，则需要将上一个版本的状态标记位置为废弃，这样其他引用了该接口包的工程在创建标签或者分支时触发平台的版本协同校验功能时，能直接返回失败，强制引用方进行版本升级。避免了引用方使用老版本接口导致部署后出现的接口兼容性问题，降低生产发生事故的概率。同时发布方在进行接口包发布时也同样通过该管理平台进行发布，发布的时候写入版本状态标记位、版本创建时间、版本可用环境等信息，这样引用方在创建标签或者分支时利用这些信息进行版本协同校验。

需要说明的是，步骤S400包括步骤S410、步骤S420和步骤S430。

步骤S410、基于预设的代码编译数学模型对自动化部署流程和校验结果进行编译处理得到微服务应用代码。

可以理解的是，编译包括将各个项目的代码、依赖关系以及配置信息整合为可执行的代码。

步骤S420、根据微服务应用代码进行镜像制作得到镜像文件。

可以理解的是，镜像文件通常包括了应用程序以及其依赖的所有组件和配置，以确保应用在目标环境中能够正确运行。

步骤S430、根据镜像文件执行部署命令将微服务应用部署至目标环境中得到部署结果，其中，若存在多个待部署的微服务容器应用，根据指定的部署环境，选择相应的部署流程，并同时触发并行部署，若微服务应用对启动有先后顺序要求，根据指定的部署顺序，单独按顺序进行部署。

可以理解的是，整个部署流程均为自动化实现，对接相应的流水线脚本完成部署，由于在步骤S100中对当前项目下多个微服务工程进行了绑定，因此该步骤同时支持多应用、多环境自动化部署，若待部署的微服务容器应用没有启动先后顺序，则可用同时进行批量部署，通过该平台选择多个待部署的项目工程，指定部署环境，触发对应的部署流程，这样达到并行部署的效果；若多个微服务应用对启动有先后顺序要求，则单独按顺序进行部署。

需要说明的是，步骤S500包括步骤S510、步骤S520和步骤S530。

步骤S510、根据部署结果中已部署的微服务应用状态，通过计算健康状态检查接口的当前健康度值得到接口检查结果。

可以理解的是，本步骤会对应用部署后的状态进行检查，通过调用健康状态检查接口判断微服务状态。具体地，该接口基于springboot开源组件actuator将活性探针配置为HTTP GET请求，能够返回当前服务状态。

步骤S520、根据接口检查结果判断微服务是否成功注册到注册中心得到注册判断结果。

步骤S530、若注册判断结果连续两次或两次以上均为失败结果，则进行微服务版本回滚操作。

具体地，若当前微服务未成功注册到注册中心时，接口返回为指定错误码DOWN，之后进行2次重试，重试结果仍为失败则自动触发该步骤的回滚操作，回滚操作主要是进行对当前版本的应用进行回滚调用，自动重新部署上一个稳定状态的版本；若存在多个微服务版本关联性较强，某个微服务当前最新版本出现问题，需要回滚至上一个版本，其他关联的微服务需要同步回滚至上一个版本的情况，则需要进行批量回滚操作，否则可能出现回滚后的老版本不兼容其他新版本微服务应用的情况。进一步地，可完成多个工程的批量回滚部署操作。这个步骤的目的是实现自动化的健康状态监测和回滚操作，以应对微服务在部署后可能出现的问题。通过定期检查微服务的健康状态并自动触发回滚操作，可以提高系统的可用性和稳定性。此外，如果多个微服务之间存在关联性，该流程还支持批量回滚操作，以确保各微服务版本的一致性。这对于保障生产系统的正常运行非常重要。

实施例2：

如图2所示，本实施例提供了一种企业级微服务容器化应用管理装置，装置包括：

获取模块1，用于获取第一信息和第二信息，第一信息包括至少一个代码仓库信息以及对应的微服务注册名，第二信息包括微服务应用部署命令。

关联模块2，用于根据第一信息和第二信息进行关联分析得到自动化部署流程，自动化部署流程包括微服务应用部署的配置参数和顺序。

校验模块3，用于根据自动化部署流程执行依赖校验和版本协同校验处理得到校验结果。

部署模块4，用于根据自动化部署流程和校验结果执行部署命令将微服务应用部署至目标环境中得到部署结果。

回滚模块5，用于根据部署结果定期对已部署的微服务应用进行健康状态检查，并对未通过健康状态检查的微服务进行回滚处理。

在本公开的一种具体实施方式中，关联模块2包括：

第一提取单元21，用于根据代码仓库信息进行提取处理得到代码仓库地址。

第二提取单元22，用于根据微服务注册名进行提取处理得到微服务注册信息。

第一关联单元23，用于根据代码仓库地址和注册信息进行关联处理得到关联结果。

第一计算单元24，基于微服务应用部署命令和关联结果，计算各个微服务工程的依赖关系和相关配置信息得到自动化部署流程。

在本公开的一种具体实施方式中，校验模块3包括：

第一构建单元31，用于根据自动化部署流程中所有项目的依赖关系构建得到依赖树，并通过检索依赖树中的冲突关键字判断项目中是否存在依赖冲突，得到依赖校验结果。

第一检验单元32，用于根据自动化部署流程中每个项目具有依赖关系的依赖数据包进行可用状态检验得到版本协同校验结果。

第一整合单元33，用于根据依赖校验结果和版本协同校验结果进行整合处理得到校验结果。

在本公开的一种具体实施方式中，第一检验单元32包括：

第三提取单元321，用于根据自动化部署流程中每个项目的依赖关系进行特征提取得到对应的依赖数据包信息。

第一判断单元322，用于根据依赖数据包信息进行可用状态检验，判断依赖数据包信息是否处于可用状态得到可用状态检验结果。

第二判断单元323，用于根据可用状态检验结果，判断项目是否需要进行版本协同校验。

第三判断单元324，若需要进行版本协同校验，判断对应的依赖数据包的版本状态标记为是否为可用状态。

第二检验单元325，若版本状态标记为可用状态，检验依赖数据包可用环境是否适用于当前部署环境。

在本公开的一种具体实施方式中，部署模块4包括：

第一编码处理，基于预设的代码编译数学模型对自动化部署流程和校验结果进行编译处理得到微服务应用代码。

第一制作单元42，用于根据微服务应用代码进行镜像制作得到镜像文件。

第一部署单元43，用于根据镜像文件执行部署命令将微服务应用部署至目标环境中得到部署结果，其中，若存在多个待部署的微服务容器应用，根据指定的部署环境，选择相应的部署流程，并同时触发并行部署，若微服务应用对启动有先后顺序要求，根据指定的部署顺序，单独按顺序进行部署。

在本公开的一种具体实施方式中，回滚模块5包括：

第二计算单元51，用于根据部署结果中已部署的微服务应用状态，通过计算健康状态检查接口的当前健康度值得到接口检查结果。

第四判断单元52，用于根据接口检查结果判断微服务是否成功注册到注册中心得到注册判断结果。

第一回滚单元53，若注册判断结果连续两次或两次以上均为失败结果，则进行微服务版本回滚操作。

实施例3：

相应于上面的方法实施例，本实施例中还提供了一种企业级微服务容器化应用管理设备，下文描述的一种企业级微服务容器化应用管理设备与上文描述的一种企业级微服务容器化应用管理方法可相互对应参照。

图3是根据示例性实施例示出的一种企业级微服务容器化应用管理设备800的框图。如图3所示，该企业级微服务容器化应用管理设备800可以包括：处理器801，存储器802。该企业级微服务容器化应用管理设备800还可以包括多媒体组件803，I/O接口804，以及通信组件805中的一者或多者。

其中，处理器801用于控制该企业级微服务容器化应用管理设备800的整体操作，以完成上述的企业级微服务容器化应用管理方法中的全部或部分步骤。存储器802用于存储各种类型的数据以支持在该企业级微服务容器化应用管理设备800的操作，这些数据例如可以包括用于在该企业级微服务容器化应用管理设备800上操作的任何应用程序或方法的指令，以及应用程序相关的数据，例如联系人数据、收发的消息、图片、音频、视频等等。该存储器802可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，例如静态随机存取存储器(Static Random Access Memory，简称SRAM)，电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，简称EEPROM)，可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，可编程只读存储器(Programmable Read-Only Memory，简称PROM)，只读存储器(Read-Only Memory，简称ROM)，磁存储器，快闪存储器，磁盘或光盘。多媒体组件803可以包括屏幕和音频组件。其中屏幕例如可以是触摸屏，音频组件用于输出和/或输入音频信号。例如，音频组件可以包括一个麦克风，麦克风用于接收外部音频信号。所接收的音频信号可以被进一步存储在存储器802或通过通信组件805发送。音频组件还包括至少一个扬声器，用于输出音频信号。I/O接口804为处理器801和其他接口模块之间提供接口，上述其他接口模块可以是键盘，鼠标，按钮等。这些按钮可以是虚拟按钮或者实体按钮。通信组件805用于该企业级微服务容器化应用管理设备800与其他设备之间进行有线或无线通信。无线通信，例如Wi-Fi，蓝牙，近场通信(Near FieldCommunication，简称NFC)，2G、3G或4G，或它们中的一种或几种的组合，因此相应的该通信组件805可以包括：Wi-Fi模块，蓝牙模块，NFC模块。

在一示例性实施例中，企业级微服务容器化应用管理设备800可以被一个或多个应用专用集成电路(Application Specific Integrated Circuit，简称ASIC)、数字信号处理器(DigitalSignal Processor，简称DSP)、数字信号处理设备(Digital SignalProcessing Device，简称DSPD)、可编程逻辑器件(Programmable Logic Device，简称PLD)、现场可编程门阵列(Field Programmable Gate Array，简称FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述的企业级微服务容器化应用管理方法。

在另一示例性实施例中，还提供了一种包括程序指令的计算机可读存储介质，该程序指令被处理器执行时实现上述的企业级微服务容器化应用管理方法的步骤。例如，该计算机可读存储介质可以为上述包括程序指令的存储器802，上述程序指令可由企业级微服务容器化应用管理设备800的处理器801执行以完成上述的企业级微服务容器化应用管理方法。

实施例4：

相应于上面的方法实施例，本实施例中还提供了一种可读存储介质，下文描述的一种可读存储介质与上文描述的一种企业级微服务容器化应用管理方法可相互对应参照。

一种可读存储介质，可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现上述方法实施例的企业级微服务容器化应用管理方法的步骤。

该可读存储介质具体可以为U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可存储程序代码的可读存储介质。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

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