基于Docker Compose的微服务系统编排可视化方法、设备及介质

摘要

本申请公开了基于Docker Compose的微服务系统编排可视化方法、设备及介质，用以解决现有技术只能通过手动执行命令行的方式对微服务系统进行部署的问题。包括：获取预先打包好的离线的镜像压缩包并基于待接入服务器的IP地址修改离线的镜像压缩包中各微服务对应的配置文件；根据待接入服务器对应导入需求确定待接入服务器的多个微服务；将多个微服务离线的镜像压缩包导入至待接入服务器并将多个微服务的防火墙端口开放；基于预先确定的多个微服务之间的依赖关系及启动顺序启动配置服务镜像包和基础服务镜像包并确定多个微服务中的应用服务；通过超链接配置应用服务的配置文件并启动应用服务镜像包以完成对微服务系统的部署实现微服务系统的编排可视化。

说明书

技术领域

本申请涉及计算机应用技术领域，尤其涉及基于Docker Compose的微服务系统编排可视化方法、设备及介质。

背景技术

Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化，容器是完全使用沙箱机制，相互之间不会有任何接口。基于Spring Cloud框架的微服务系统，包含路由网关服务gateway，安全认证服务security，业务应用服务wms、les、mes等，前端服务nginx，分布式日志服务plumelog，分布式事务服务seata，以及依赖的配置中心服务Nacos，数据缓存服务Redis，Java运行环境服务evn等，每个服务放在一个Docker容器中运行。

Docker Compose是Docker公司提供的一个开源命令行工具，使用YML文件定义和运行多容器(Docker)应用程序的编排部署工具。目前，现有技术在利用Docker Compose进行编排部署微服务系统时，只能在Xshell或者FinalShell命令窗口手动输入一个个命令行来实现，没有可视化的界面，操作非常不方便。并且，基于Spring Cloud框架的微服务系统随着业务开展的越来越广，微服务镜像的数量越来越多，相互之间的依赖关系及启动顺序也越来越复杂，无法执行正确的命令顺序保证微服务系统部署正常。

发明内容

本申请实施例提供了基于Docker Compose的微服务系统编排可视化方法、设备及介质，用以解决现有技术只能通过手动执行命令行的方式对微服务系统进行部署升级，对工作人员的命令掌握程度要求较高，且无法保证命令执行顺序正确的技术问题。

一方面，本申请实施例提供了基于Docker Compose的微服务系统编排可视化方法，包括：

获取预先打包好的离线的镜像压缩包，并基于待接入服务器的IP地址，修改所述离线的镜像压缩包中各微服务对应的配置文件；

接收所述待接入服务器对应的导入需求，并根据所述导入需求，确定所述待接入服务器对应的多个微服务；

将所述导入需求对应多个微服务的离线的镜像压缩包，导入至所述待接入服务器，并将所述待接入服务器中所述导入需求对应多个微服务的防火墙端口进行开放；

基于预先确定好的多个微服务之间的依赖关系以及启动顺序，将配置服务镜像包和基础服务镜像包进行启动，并确定所述多个微服务中的应用服务；

通过超链接配置所述应用服务的配置文件，并根据所述应用服务对应的配置文件，将所述应用服务对应的应用服务镜像包进行启动，以完成对微服务系统的部署，实现微服务系统的编排可视化。

在本申请的一种实现方式中，所述获取预先打包好的离线的镜像压缩包之前，所述方法还包括：

接收用户上传的应用程序，并将所述应用程序提交至Git数据库，以触发Jenkins自动构建所述应用程序对应的微服务镜像；

将所述微服务镜像存储至HARBOR仓库中，并将所述微服务镜像打包成离线的镜像压缩包。

在本申请的一种实现方式中，所述获取预先打包好的离线的镜像压缩包，具体包括：

从HARBOR仓库中获取离线的镜像压缩包，并确定待接入服务器是否安装Docker和Docker Compose运行环境；

在确定所述待接入服务器已安装Docker和Docker Compose运行环境的情况下，将所述离线的镜像压缩包拷贝至所述待接入服务器中。

在本申请的一种实现方式中，所述基于预先确定好的多个微服务之间的依赖关系以及启动顺序，将配置服务镜像包和基础服务镜像包进行启动之前，所述方法还包括：

确定出所有服务器对应的多个微服务，并分别确定出所述多个微服务对应的多个部署条件；

根据每个微服务对应的部署条件，确定出所述多个微服务之间的依赖关系，并根据所述多个微服务之间的依赖关系，确定出所述多个服务器对应的启动顺序。

在本申请的一种实现方式中，所述基于预先确定好的多个微服务之间的依赖关系以及启动顺序，将配置服务镜像包和基础服务镜像包进行启动，具体包括：

基于预先确定好的多个微服务之间的依赖关系以及启动顺序，确定配置服务镜像包中的Nacos镜像依赖于MySQL镜像，并通过Docker Compose对所述Nacos镜像和所述MySQL镜像进行编排；

通过Docker Compose编排，将所述MySQL镜像进行启动，并在所述MySQL镜像启动后，将所述Nacos镜像进行启动。

在本申请的一种实现方式中，所述基于预先确定好的多个微服务之间的依赖关系以及启动顺序，将配置服务镜像包和基础服务镜像包进行启动，具体包括：

基于预先确定好的多个微服务之间的依赖关系以及启动顺序，确定基础服务镜像包中的Redis镜像依赖于Java环境env镜像，并通过Docker Compose对所述Redis镜像和所述env镜像进行编排；

通过Docker Compose编排，将所述env镜像进行启动，并在所述env镜像启动后，将所述Redis镜像进行启动。

在本申请的一种实现方式中，所述基于待接入服务器的IP地址，修改所述离线的镜像压缩包中各微服务对应的配置文件，具体包括：

确定待接入服务器的IP地址，并确定所述离线的镜像压缩包中的微服务以及所述微服务对应的配置文件；

通过可视化界面接收所述待接入服务器的IP地址，并对所述微服务对应配置文件中前端请求后端的地址进行修改，以实现对所述待接入服务器后端的访问。

在本申请的一种实现方式中，所述对所述微服务对应配置文件中前端请求后端的地址进行修改之后，所述方法还包括：

通过Docker中的共享数据卷volume，将所述微服务对应的配置文件映射至容器中，以实现配置文件的自动化修改。

另一方面，本申请实施例还提供了基于Docker Compose的微服务系统编排可视化设备，所述设备包括：

至少一个处理器；

以及，与所述至少一个处理器通信连接的存储器；

其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如上述的基于Docker Compose的微服务系统编排可视化方法。

另一方面，本申请实施例还提供了一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：

如上述的基于Docker Compose的微服务系统编排可视化方法。

本申请实施例提供了基于Docker Compose的微服务系统编排可视化方法、设备及介质，至少包括以下有益效果：

通过待接入服务器的IP地址，对预先获取的离线镜像压缩包中的各微服务对应的配置文件进行修改，以便于根据配置文件中修改后的IP地址实现前端对后端服务器的访问；通过接收待接入服务器的导入需求，能够确定出待接入服务器对应的多个微服务，从而将多个微服务对应的离线的镜像压缩包导入至待接入服务器中，实现微服务的按需接入，然后再将多个微服务在待接入服务器中对应的防火墙端口进行开放；开放防火墙端口之后，基于预先确定好的多个微服务之间的依赖关系以及启动关系，首先将配置服务镜像包和基础服务镜像包进行启动，并通过超链接对多个微服务中应用服务的配置文件进行配置，进而将应用服务镜像包启动，完成对微服务系统的部署，实现对微服务系统的编排可视化。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的基于Docker Compose的微服务系统编排可视化方法的流程示意图；

图2为本申请实施例提供的基于Docker Compose的微服务系统编排可视化设备的内部结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例提供了基于Docker Compose的微服务系统编排可视化方法、设备及介质，通过待接入服务器的IP地址，对预先获取的离线镜像压缩包中的各微服务对应的配置文件进行修改，以便于根据配置文件中修改后的IP地址实现前端对后端服务器的访问；通过接收待接入服务器的导入需求，能够确定出待接入服务器对应的多个微服务，从而将多个微服务对应的离线的镜像压缩包导入至待接入服务器中，实现微服务的按需接入，然后再将多个微服务在待接入服务器中对应的防火墙端口进行开放；开放防火墙端口之后，基于预先确定好的多个微服务之间的依赖关系以及启动关系，首先将配置服务镜像包和基础服务镜像包进行启动，并通过超链接对多个微服务中应用服务的配置文件进行配置，进而将应用服务镜像包启动，完成对微服务系统的部署，从而实现对微服务系统的编排可视化。解决了现有技术只能通过手动执行命令行的方式对微服务系统进行部署升级，对工作人员的命令掌握程度要求较高，且无法保证命令执行顺序正确的技术问题。

图1为本申请实施例提供的基于Docker Compose的微服务系统编排可视化方法的流程示意图。如图1所示，本申请实施例提供的基于Docker Compose的微服务系统编排可视化方法可以主要包括以下步骤：

101、获取预先打包好的离线的镜像压缩包，并基于待接入服务器的IP地址，修改离线的镜像压缩包中各微服务对应的配置文件。

本申请提供了一种可视化、智能化的微服务系统编排部署工具，通过提供友好的人机交互界面，使得工作人员在可视化界面中点击按钮，即可实现按钮对应的操作服务，替代了现有技术通过手动执行命令行的方式对微服务系统进行部署。并且，本申请支持工作人员在现场离线的情况下部署微服务系统，降低了对开发、测试和实施工作人员的技术要求，设定了微服务依赖关系和启动顺序，能够在保证系统部署健壮性的同时，还提高了系统部署的效率。

服务器首先获取到预先打包好的离线的镜像压缩包，并且，服务器还通过可视化界面接收工作人员输入的待接入服务器的IP地址，从而能够根据待接入服务器的IP地址，对离线的镜像压缩包中每个微服务对应的配置文件进行修改。

具体地，服务器在获取预先打包好的离线的镜像压缩包时，需要从HARBOR仓库中获取离线的镜像压缩包，并且还要确定出待接入服务器是否安装Docker和Docker Compose运行环境，然后在确定出待接入服务器已经安装Docker和Docker Compose运行环境的情况下，将离线的镜像压缩包拷贝至待接入服务器中。

服务器确定出待接入服务器的IP地址，并确定出离线的镜像压缩包中的微服务以及微服务对应的配置文件，然后根据工作人员在可视化界面中输入的内容，接收待接入服务器的IP地址，并对微服务对应配置文件中前端请求后端的地址进行修改，从而实现对待接入服务器后端的访问。

需要说明的是，本申请实施例中服务器对微服务对应配置文件中前端请求后端地址的修改，例如：修改分布式事务seata的配置文件registry.conf、前端nginx的配置文件webconfig.json等微服务的配置文件，这样能够避免工作人员通过手动输入命令行的方式修改微服务的配置文件。

在本申请的一个实施例中，服务器在对微服务对应配置文件中前端请求后端的地址进行修改之后，通过Docker中的共享数据卷volume，将微服务对应的配置文件映射至容器中，从而实现配置文件的自动化修改。

在本申请的一个实施例中，服务器在获取预先打包好的离线的镜像压缩包之前，接收用户上传的应用程序，并将获取到的应用程序提交至Git数据库，从而触发Jenkins自动构建应用程序对应的微服务镜像，然后将微服务镜像存储至HARBOR仓库中，并将微服务镜像打包成离线的镜像压缩包，以便于工作人员在离线的情况下也能对微服务系统进行编排可视化部署。

102、接收待接入服务器对应的导入需求，并根据导入需求，确定待接入服务器对应的多个微服务。

在向待接入服务器中导入镜像时，服务器接收用户上传的待接入服务器对应的导入需求，这样能够根据待接入服务器对应的导入需求，确定出待接入服务器所需的多个微服务。

103、将导入需求对应多个微服务的离线的镜像压缩包，导入至待接入服务器，并将待接入服务器中导入需求对应多个微服务的防火墙端口进行开放。

服务器将确定出的待接入服务器导入需求对应得多个微服务的离线的镜像压缩包导入至待接入服务器，并且，服务器还将待接入服务器中导入需求对应多个微服务的防火墙端口进行开放，便于执行后续操作。这样能够实现按需导入离线的镜像压缩包，避免现有技术通过手动输入执行命令行的方式导入离线的镜像压缩包。

需要说明的是，本申请实施例通过手动输入执行命令行的方式导入离线的镜像压缩包，例如基础数据镜像压缩包base.tar.gz，界面可视化执行的导入对应的Linux的命令为gunzip-c/home/install_images/base.tar.gz|docker load。

在本申请的一个实施例中，服务器在无法确定待接入服务器所需的微服务具体有哪些的情况下，能够实现一键全部导入所有服务器对应微服务的离线的镜像压缩包，在这种情况下，待接入服务器根据自身所需的微服务调用导入的对应镜像即可。

在本申请的一个实施例中，服务器在无法确定待接入服务器所需的微服务具体有哪些的情况下，也能够实现一键开放所有防火墙端口，此时，待接入服务器根据自身所需的微服务调用开放的对应防火墙端口即可。

需要说明的是，本申请实施例实现一键开放所有防火墙端口，是通过执行Shell脚本文件firewallopen.sh实现的。

104、基于预先确定好的多个微服务之间的依赖关系以及启动顺序，将配置服务镜像包和基础服务镜像包进行启动，并确定多个微服务中的应用服务。

本申请根据预先确定好的多个微服务之间的依赖关系以及启动顺序，设定多个微服务的部署步骤，从而解决了基于Spring Cloud框架的微服务系统所依赖的服务首先启动的技术问题。

具体地，由于基于Spring Cloud框架的微服务系统，采用开源组件Nacos作为微服务的配置中心和注册中心，并且配置信息需要进行持久化处理，存储于MySQL数据库里，所以服务器基于预先确定好的多个微服务之间的依赖关系以及启动顺序，能够确定出配置服务镜像包中的Nacos镜像依赖于MySQL镜像，从而通过Docker Compose对Nacos镜像和MySQL镜像进行编排，通过Docker Compose编排，首先将MySQL镜像进行启动，并在MySQL镜像启动后，将Nacos镜像进行启动。

需要说明的是，本申请实施例中的Nacos镜像包nacos.tar.gz中，包含压缩的MySQL镜像和Nacos镜像。

由于基于Spring Cloud框架的微服务系统，需要在Java环境中运行，使用Redis服务缓存登录Token等一些请求频繁的信息，所以服务器基于预先确定好的多个微服务之间的依赖关系以及启动顺序，能够确定出基础服务镜像包中的Redis镜像依赖于Java环境env镜像，从而通过Docker Compose对Redis镜像和env镜像进行编排，通过Docker Compose编排，首先将Java环境对应的env镜像进行启动，把Java环境jre通过镜像压缩到10.110.84.139:5000/base/env:latest镜像中，env容器启动时通过Docker的共享卷volume映射到服务器，并在env镜像启动后，将Redis镜像进行启动。

在本申请的一个实施例中，服务器在基于预先确定好的多个微服务之间的依赖关系以及启动顺序，将配置服务镜像包和基础服务镜像包进行启动之前，需要确定出所有服务器对应的多个微服务，并分别确定出多个微服务对应的多个部署条件，然后根据确定出的每个微服务对应的部署条件，确定出多个微服务之间的依赖关系，并根据多个微服务之间的依赖关系，确定出多个服务器对应的启动顺序。

105、通过超链接配置应用服务的配置文件，并根据应用服务对应的配置文件，将应用服务对应的应用服务镜像包进行启动，以完成对微服务系统的部署，实现微服务系统的编排可视化。

服务器通过超链接，登录Nacos服务Web浏览器界面，配置应用服务(wms、les、mes等)的配置文件，如与达梦数据库连接信息Datasource，与缓存服务连接信息Redis等。并且，服务器根据应用服务对应的配置文件，将应用服务对应的应用服务镜像包进行启动，从而完成对微服务系统的部署，实现微服务系统的编排可视化部署。

在本申请的一个实施例中，服务器在无法确定待接入服务器所需的应用服务具体有哪些的情况下，也能够实现一键启动所有的应用服务镜像包，此时，待接入服务器根据自身所需的应用服务调用对应的应用服务镜像包即可。

以上为本申请提出的方法实施例。基于同样的发明构思，本申请实施例还提供了基于Docker Compose的微服务系统编排可视化设备，其结构如图2所示。

图2为本申请实施例提供的基于Docker Compose的微服务系统编排可视化设备的内部结构示意图。如图2所示，设备包括：

至少一个处理器；

以及，与至少一个处理器通信连接的存储器；

其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够：

获取预先打包好的离线的镜像压缩包，并基于待接入服务器的IP地址，修改离线的镜像压缩包中各微服务对应的配置文件；

接收待接入服务器对应的导入需求，并根据导入需求，确定待接入服务器对应的多个微服务；

将导入需求对应多个微服务的离线的镜像压缩包，导入至待接入服务器，并将待接入服务器中导入需求对应多个微服务的防火墙端口进行开放；

基于预先确定好的多个微服务之间的依赖关系以及启动顺序，将配置服务镜像包和基础服务镜像包进行启动，并确定多个微服务中的应用服务；

通过超链接配置应用服务的配置文件，并根据应用服务对应的配置文件，将应用服务对应的应用服务镜像包进行启动，以完成对微服务系统的部署，实现微服务系统的编排可视化。

本申请实施例还提供了一种非易失性计算机存储介质，存储有计算机可执行指令，计算机可执行指令设置为：

获取预先打包好的离线的镜像压缩包，并基于待接入服务器的IP地址，修改离线的镜像压缩包中各微服务对应的配置文件；

接收待接入服务器对应的导入需求，并根据导入需求，确定待接入服务器对应的多个微服务；

将导入需求对应多个微服务的离线的镜像压缩包，导入至待接入服务器，并将待接入服务器中导入需求对应多个微服务的防火墙端口进行开放；

基于预先确定好的多个微服务之间的依赖关系以及启动顺序，将配置服务镜像包和基础服务镜像包进行启动，并确定多个微服务中的应用服务；

通过超链接配置应用服务的配置文件，并根据应用服务对应的配置文件，将应用服务对应的应用服务镜像包进行启动，以完成对微服务系统的部署，实现微服务系统的编排可视化。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本说明书实施例可提供为方法、系统、或计算机程序产品。因此，本说明书实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本说明书实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本说明书可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备、非易失性计算机存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

以上所述仅为本说明书的一个或多个实施例而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书的一个或多个实施例可以有各种更改和变化。凡在本说明书的一个或多个实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书的权利要求范围之内。