一种基于微服务的多运行时构架方法及系统

技术领域

本发明涉及微服务领域，具体而言，涉及一种基于微服务的多运行时构架方法及系统。

背景技术

随着智能化科技的不断发展，人们的生活、工作、学习之中越来越多地用到了智能化设备，使用智能化科技手段，提高了人们生活的质量，增加了人们学习和工作的效率。

微服务技术是近年来云计算的主流技术之一，微服务的容器化代表了云计算的云原生计算发展趋势。因此，许多新兴的软件架构都是基于微服务架构发展而来(国内外不完全统计有数百种，见阿里云和X-Lab联合发布的《2020年微服务领域开源数字化报告》)。于是，寻求可以兼容市场上主流或大多数微服务架构的“兼容性微服务架构”就成为了一个重要和关键难题；这好比是Linux系统帮助兼容了绝大多数零零总总的操作系统一样。

对现存的微服务架构专利技术、科研论文和应用产品分析表明，架构兼容的主要方式有如下三种：

要求微服务本身具备标准化接口，从而各个微服务架构可以交互调用：如CN112463211A“一种兼容多种开发架构的系统架构改造方法及系统架构”、CN112486466A“一种基于微服务架构的快速通用基础框架实现方法”等，“该方法包括根据预设需求，创建基于微服务通用型基础框架，并保存为微服务通用型基础架构，逐一进行单个微服务设计；对所述单个微服务进行标准化处理，合并为至少一个标准微服务。”它的缺点是很难形成这样的行业统一标准。

通过对某种微服务API产品(一般是应用接口里的服务注册中心)进行功能扩增，尽量兼容其它架构的微服务API调用：如CN111209127A“一种Dubbo框架集成Istio服务网格的方法”、CN111355743A“一种基于API网关的管理方法及其系统”、CN110990047A“用于多个微服务架构的融合方法及装置”等，“多个微服务架构通过统一注册中心达到了相互兼容的目的，从而实现了降低多个微服务架构集成和融合的难度的技术效果。”它要求对该API产品进行绑定。

通过软件插件或对虚机的镜像文件进行改动和管理，来实现架构间的调用兼容：如CN111596969A“一种基于微内核加插件式的软件架构方法”，“公开了一种基于微内核加插件式的软件架构方法，该软件架构方法建立动态插件模型基础上，首先构建一个基础的框架应用程序，用以加载插件并且为插件的运行提供必要的执行环境”。或CN111124430A“一种混合架构的微服务部署方法和装置”，它“采用镜像仓库存储一种或者多种类型的架构的镜像信息；动态读取所述镜像仓库中的镜像信息；根据读取的所述镜像信息确定对应的主机架构；根据所述主机架构实现服务互通。”它是典型的1对多模式，要求该类别的软件插件或镜像文件管理有“中央控制”的环境；但不可能对每种微服务架构都能快速实现兼容所需的插件或镜像文件。

运行时(runt ime)底层技术封装了软件应用程序运行时的环境，使应用程序能够与其运行的环境相连接。与运行时和微服务都关联的专利技术还比较稀少，我们找到的有CN111737033A“一种基于运行时图谱分析的微服务故障定位方法”，它属于微服务调用追踪领域，对架构兼容没有借鉴作用。

本专利“对微逻辑进行多运行时封装的技术”用底层运行时技术分析应用程序(通过微逻辑统一的微服务模块)的运行环境，动态加载各种架构调用兼容所需的程序、库或工具，实行了低侵入下最佳的兼容度。已有的三大类微服务架构兼容方法从表层调用(API接口)向底层架构机制的交互逐步深入，后两类都要求使用方选用它们指定的微服务架构产品(某特殊API网关或某特殊软件插件或文件管理虚机软件)，而且对不断涌现的新微服务架构都需要做修改应对方能实现兼容；而第一类寄希望于行业强标准的形成。它们从技术机制原理上都不够深入、没有接触到底层。机甲Mecha组件和微服务是一个类似于“客户端-服务器”架构的双组件模型。机甲组件替代和充当了太多微服务架构环境的角色(它本质上还只是网格化服务的一种而已，起不到跨微服务技术架构的功效)，而我们的微环境是与微服务架构环境相互补充和加强的。

本发明专利从微服务架构的底层运行时(runtime)角度进行技术发明(对微逻辑进行多运行时封装的技术)，对各类微服务架构做了侵入性小、易用性好的兼容。它是一种彻底遵循微服务分布式去中心思想的解决方式，是典型的多对多模式，不要求兼容和被兼容的微服务架构间有绑定关系。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种基于微服务的多运行时构架方法及系统，以至少解决过去微服务架构兼容技术机制原理上都不够深入、没有接触到底层的技术问题。

根据本发明实施例的一个方面，提供了一种基于微服务的多运行构架方法，包括：获取微服务原始数据；根据所述原始数据，确定目标应用程序；将所述目标应用程序进行运行时分析，得到分析结果。

可选的，所述微服务原始数据指的是微服务逻辑关系中用于表征应用程序运行场景的数据。

可选的，所述目标应用程序用于调整所述微服务中的架构兼容度。

可选的，在所述将所述目标应用程序进行运行时分析，得到分析结果之后，所述方法还包括：将所述分析结果进行展示。

根据本发明实施例的另一方面，还提供了一种基于微服务的多运行构架系统，包括：获取模块，用于获取微服务原始数据；确定模块，用于根据所述原始数据，确定目标应用程序；分析模块，用于将所述目标应用程序进行运行时分析，得到分析结果。

可选的，所述微服务原始数据指的是微服务逻辑关系中用于表征应用程序运行场景的数据。

可选的，所述目标应用程序用于调整所述微服务中的架构兼容度。

可选的，所述系统还包括：展示模块，用于将所述分析结果进行展示。

根据本发明实施例的另一方面，还提供了一种非易失性存储介质，所述非易失性存储介质包括存储的程序，其中，所述程序运行时控制非易失性存储介质所在的设备执行一种基于微服务的多运行构架方法。

根据本发明实施例的另一方面，还提供了一种电子装置，包含处理器和存储器；所述存储器中存储有计算机可读指令，所述处理器用于运行所述计算机可读指令，其中，所述计算机可读指令运行时执行一种基于微服务的多运行构架方法。

在本发明实施例中，采用获取微服务原始数据；根据所述原始数据，确定目标应用程序；将所述目标应用程序进行运行时分析，得到分析结果的方式，解决了过去微服务架构兼容技术机制原理上都不够深入、没有接触到底层的技术问题。

附图说明

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

图1是根据本发明实施例的一种基于微服务的多运行构架方法的流程图；

图2是根据本发明实施例的一种基于微服务的多运行构架系统的结构框图。

具体实施方式

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

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

根据本发明实施例，提供了一种基于微服务的多运行构架方法的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

实施例一

图1是根据本发明实施例的一种基于微服务的多运行构架方法的流程图，如图1所示，该方法包括如下步骤：

步骤S102，获取微服务原始数据

步骤S104，根据所述原始数据，确定目标应用程序

步骤S106，将所述目标应用程序进行运行时分析，得到分析结果

可选的，所述微服务原始数据指的是微服务逻辑关系中用于表征应用程序运行场景的数据。

可选的，所述目标应用程序用于调整所述微服务中的架构兼容度。

可选的，在所述将所述目标应用程序进行运行时分析，得到分析结果之后，所述方法还包括：将所述分析结果进行展示。

具体的，本发明的多运行时微服务体系结构由连个部分组成：1)微逻辑(Micrologic)部分：它是当下微服务中去除掉所有与周边运行环境相关之后的业务逻辑部分；2)微环境(Microniche)部分：让只有业务逻辑的微服务能够运行起来，有能力同周边微服务体系交互的运行时非功能技术部分。这两个部分的通讯和交互由声明式API完成。当微逻辑里的业务需要与其它业务交互或有可以暴露给外部的服务的时候，将调用声明式API予以明确。而这两部分结合(称之为绑定Binding过程)形成的整体，就是一个在某种微服务架构体系之下完整的传统微服务。

根据不同的IT硬件和操作系统环境，微环境代表的运行时Runtime甚至可以协助其运行的微服务技术环境与底层云环境及芯片特殊能力相结合，实现更强的微服务治理能力。可以这么认为，“微环境类”的多运行时能力的本质就是面向应用的分布式能力的抽象层。有了它，我们的业务微服务将能够嵌入不同的“运行时环境”，在多种异构的计算环境下顺滑交互运行。

微逻辑和微环境两部分一起构成一个完整的微服务，该微服务按照正常配置运行在某种微服务架构之下。微逻辑和微环境是“1对多”的关系。微环境根据进程内(in-process)、进程外(out-of-process)、平台内(in-platform)、跨平台(out-of-platform)、容器环境内(in-container)、跨容器环境(out-of-container)、云环境内(in-cloud)、跨云环境(out-of-cloud)等逐步宽泛化的环境范围，可以进行层层嵌套，从而让一个微逻辑可以通过跨不同环境的运行时与其外部的微服务架构环境相交互，最大限度地实现让业务逻辑只需实现一次(在微逻辑里)、而与之对应适配运行环境的微环境可以让包含业务逻辑的微服务在最广泛的微服务技术环境中正常运行。

例如，一个对图像做艺术风格渲染的微服务的算法逻辑将在微逻辑实现，这个微服务既可以放在Spring Cloud这类微服务架构环境运行，也可以在Istio这类网格化微服务架构环境运行，还可以移植到AWS中的Lamda无服务器微服务架构环境运行。适应不同微服务技术环境的功能由微环境予以实现。这里，艺术风格渲染微服务的微逻辑如果同适应于Istio网格化微服务体系的微环境进行绑定，这两者合在一起，是Istio环境之下的一个微服务。将传统微服务分成微逻辑和微环境两个目标独立的部分非常重要：通过本专利的以微逻辑和微环境为基础的多运行时技术解决方式(MMR，Microservice Multi-Runtime)，可以清晰地让业务逻辑部分独立出来，从而只通过调整微环境这个衔接部分(通常都可以通过我们提供的针对主要微服务技术流派的技术声明模板Templates)，就可以实现让该微服务业务逻辑在极广泛的微服务以及同微服务相关的云环境正常运行的能力，从而实现最广泛的微服务架构之间的兼容性。

我们提出的这种软件结构不是“再造轮子”：它是在分布式计算的“机甲”概念基础上，删繁就简优化而成的新技术；更重要的是，它和业界的主流标准协议相吻合的--微逻辑和微环境一起，与业界越来越流行的开放应用模型(OAM，Open Application Model)相结合(主要是运维Operator组件和部署Portor组件)，形成了一个有标准支持的多运行时微服务运行环境。MMR的“多运行时管理”功能模块能够让微服务及其组件更好地在各类微服务技术和云环境中部署和管理。

开放应用模型OAM是一种用于描述应用程序的范式，旨在将应用程序描述同应用程序在基础设施中的部署以及管理方式区分开来。从只针对Java语言的OSGi可重用和可协作的组件构建，到CNAB云端原生应用管理规范，再到OAM，它们的目标就是让简单的应用管理变得更加轻松，让复杂的应用交付变得更加可控。有了OAM这个规范，应用描述就可以彻底与基础设施部署和管理应用的细节分开。

微环境提供的是技术能力(以分布式计算体现的各种能力)，它属于开放应用模型OAM里的应用运维特征(Traits)。它们描述了微服务应用在具体部署环境中的运维特征，这些特征对于微服务应用的运维来说非常重要，但它们在不同的部署环境里却往往有着截然不同的实现方式。所以，适配于不同运维特征的微环境的部署模型，并不局限于网格化微服务的边车模式。微环境和微逻辑之间的协议体现在API上(而不是TCP通讯协议)，它们之间的交互可以是开放而有API标准的。它们可以用声明式的方式进行配置和控制，即符合云原生的理念。

运行时(Runtime)又称“运行时系统”(runtime system)，是一种把半编译的运行码在目标机器上运行的环境。运行环境是一种介乎编译器及直译器的运行方式。拿微服务编程常用的编程语言C/C++，Python，Java、C#、Objective-C等来说明。

C语言的printf、malloc、strcpy之类的底层函数，是系统实现好的，这套底层函数的实现就叫做C runtime。C++语言的时候，runtime中又多了cout、异常处理的支持函数、RTTI的支持函数等；这类runtime都是函数库形式，被应用程序静态链接或者动态链接。后来有了Python之类的动态脚本语言，它们的runtime就进阶了，不光提供标准库函数，还负责GC、解释脚本代码等等，管的事更多了。再后来有了Java、C#、Objective-C等静态编译型高级语言，runtime管的事更复杂了，比如JIT及时编译之类。

本专利中的多运行时实现是遵照Java、C#和Objective-C的运行时共同交集，只对最基础的Object等类做了最小的。一个由Java写的程序运行于安装了JVM的Java RuntimeEnvironment(JRE)上，一个由C#写的程序运行于Microsoft Windows的.NET CommonLanguage Runtime(CLR)上，一个由Objective-C写的程序运行于iOS的Foundation框架上。通过适当配置，它们也可以运行于一些Linux环境。这些runtime都是执行引擎的形式，我们的MMR主要通过Object类在两种层面上与Runtime系统进行交互：通过对Runtime库函数的直接调用；通过对JRE/CLR/Foundation框架里的Object类(以及选择Selector类等)定义新的方法。我们不对底层运行时库(Runtime library)进行源码或重新编译的改动。

以一个图像转化微服务为例(对图像做艺术风格渲染的微服务的算法逻辑将在微逻辑实现)，这个微服务的缺省运行时微环境将被设置为Spring Cloud Alibaba，配置示例如下：

业务微逻辑Micrologic部分和运行时微环境Microniche两个目标不同的部分，可以让微服务的业务在更广泛的异构计算环境中运行。以运行时(Runtime)原理实现的多运行时MMR形态的微环境Mocroniche，能够很好地与当前的主流微服务架构技术进行对接(通常只需在配置文件中做配置声明)，让微服务的良好兼容性实现能够：即依托微环境的运维特征声明搭载上开放应用模型OAM的业界标准力量，又可以通过微环境的多运行时实现去实现具体环境的适配性微调。

综上可以看出，本专利的微逻辑和微环境结合起来去实现传统微服务的发明有很强的操作性和兼容性。

通过上述实施例，解决了过去微服务架构兼容技术机制原理上都不够深入、没有接触到底层的技术问题。

实施例二

图2是根据本发明实施例的一种基于微服务的多运行构架系统的结构框图，如图2所示，该系统包括：

获取模块20，用于获取微服务原始数据

确定模块22，用于根据所述原始数据，确定目标应用程序

分析模块24，用于将所述目标应用程序进行运行时分析，得到分析结果

可选的，所述微服务原始数据指的是微服务逻辑关系中用于表征应用程序运行场景的数据。

可选的，所述目标应用程序用于调整所述微服务中的架构兼容度。

可选的，所述系统还包括：展示模块，用于将所述分析结果进行展示。

具体的，本发明的多运行时微服务体系结构由连个部分组成：1)微逻辑(Micrologic)部分：它是当下微服务中去除掉所有与周边运行环境相关之后的业务逻辑部分；2)微环境(Microniche)部分：让只有业务逻辑的微服务能够运行起来，有能力同周边微服务体系交互的运行时非功能技术部分。这两个部分的通讯和交互由声明式API完成。当微逻辑里的业务需要与其它业务交互或有可以暴露给外部的服务的时候，将调用声明式API予以明确。而这两部分结合(称之为绑定Binding过程)形成的整体，就是一个在某种微服务架构体系之下完整的传统微服务。

根据不同的IT硬件和操作系统环境，微环境代表的运行时Runtime甚至可以协助其运行的微服务技术环境与底层云环境及芯片特殊能力相结合，实现更强的微服务治理能力。可以这么认为，“微环境类”的多运行时能力的本质就是面向应用的分布式能力的抽象层。有了它，我们的业务微服务将能够嵌入不同的“运行时环境”，在多种异构的计算环境下顺滑交互运行。

微逻辑和微环境两部分一起构成一个完整的微服务，该微服务按照正常配置运行在某种微服务架构之下。微逻辑和微环境是“1对多”的关系。微环境根据进程内(in-process)、进程外(out-of-process)、平台内(in-platform)、跨平台(out-of-platform)、容器环境内(in-container)、跨容器环境(out-of-container)、云环境内(in-cloud)、跨云环境(out-of-cloud)等逐步宽泛化的环境范围，可以进行层层嵌套，从而让一个微逻辑可以通过跨不同环境的运行时与其外部的微服务架构环境相交互，最大限度地实现让业务逻辑只需实现一次(在微逻辑里)、而与之对应适配运行环境的微环境可以让包含业务逻辑的微服务在最广泛的微服务技术环境中正常运行。

例如，一个对图像做艺术风格渲染的微服务的算法逻辑将在微逻辑实现，这个微服务既可以放在Spring Cloud这类微服务架构环境运行，也可以在Istio这类网格化微服务架构环境运行，还可以移植到AWS中的Lamda无服务器微服务架构环境运行。适应不同微服务技术环境的功能由微环境予以实现。这里，艺术风格渲染微服务的微逻辑如果同适应于Istio网格化微服务体系的微环境进行绑定，这两者合在一起，是Istio环境之下的一个微服务。将传统微服务分成微逻辑和微环境两个目标独立的部分非常重要：通过本专利的以微逻辑和微环境为基础的多运行时技术解决方式(MMR，Microservice Multi-Runtime)，可以清晰地让业务逻辑部分独立出来，从而只通过调整微环境这个衔接部分(通常都可以通过我们提供的针对主要微服务技术流派的技术声明模板Templates)，就可以实现让该微服务业务逻辑在极广泛的微服务以及同微服务相关的云环境正常运行的能力，从而实现最广泛的微服务架构之间的兼容性。

我们提出的这种软件结构不是“再造轮子”：它是在分布式计算的“机甲”概念基础上，删繁就简优化而成的新技术；更重要的是，它和业界的主流标准协议相吻合的--微逻辑和微环境一起，与业界越来越流行的开放应用模型(OAM，Open Application Model)相结合(主要是运维Operator组件和部署Portor组件)，形成了一个有标准支持的多运行时微服务运行环境。MMR的“多运行时管理”功能模块能够让微服务及其组件更好地在各类微服务技术和云环境中部署和管理。

开放应用模型OAM是一种用于描述应用程序的范式，旨在将应用程序描述同应用程序在基础设施中的部署以及管理方式区分开来。从只针对Java语言的OSGi可重用和可协作的组件构建，到CNAB云端原生应用管理规范，再到OAM，它们的目标就是让简单的应用管理变得更加轻松，让复杂的应用交付变得更加可控。有了OAM这个规范，应用描述就可以彻底与基础设施部署和管理应用的细节分开。

微环境提供的是技术能力(以分布式计算体现的各种能力)，它属于开放应用模型OAM里的应用运维特征(Traits)。它们描述了微服务应用在具体部署环境中的运维特征，这些特征对于微服务应用的运维来说非常重要，但它们在不同的部署环境里却往往有着截然不同的实现方式。所以，适配于不同运维特征的微环境的部署模型，并不局限于网格化微服务的边车模式。微环境和微逻辑之间的协议体现在API上(而不是TCP通讯协议)，它们之间的交互可以是开放而有API标准的。它们可以用声明式的方式进行配置和控制，即符合云原生的理念。

运行时(Runtime)又称“运行时系统”(runtime system)，是一种把半编译的运行码在目标机器上运行的环境。运行环境是一种介乎编译器及直译器的运行方式。拿微服务编程常用的编程语言C/C++，Python，Java、C#、Objective-C等来说明。

C语言的printf、malloc、strcpy之类的底层函数，是系统实现好的，这套底层函数的实现就叫做C runtime。C++语言的时候，runtime中又多了cout、异常处理的支持函数、RTTI的支持函数等；这类runtime都是函数库形式，被应用程序静态链接或者动态链接。后来有了Python之类的动态脚本语言，它们的runtime就进阶了，不光提供标准库函数，还负责GC、解释脚本代码等等，管的事更多了。再后来有了Java、C#、Objective-C等静态编译型高级语言，runtime管的事更复杂了，比如JIT及时编译之类。

本专利中的多运行时实现是遵照Java、C#和Objective-C的运行时共同交集，只对最基础的Object等类做了最小的。一个由Java写的程序运行于安装了JVM的Java RuntimeEnvironment(JRE)上，一个由C#写的程序运行于Microsoft Windows的.NET CommonLanguage Runtime(CLR)上，一个由Objective-C写的程序运行于iOS的Foundation框架上。通过适当配置，它们也可以运行于一些Linux环境。这些runtime都是执行引擎的形式，我们的MMR主要通过Object类在两种层面上与Runtime系统进行交互：通过对Runtime库函数的直接调用；通过对JRE/CLR/Foundation框架里的Object类(以及选择Selector类等)定义新的方法。我们不对底层运行时库(Runtime library)进行源码或重新编译的改动。

以一个图像转化微服务为例(对图像做艺术风格渲染的微服务的算法逻辑将在微逻辑实现)，这个微服务的缺省运行时微环境将被设置为Spring Cloud Alibaba，配置示例如下：

业务微逻辑Micrologic部分和运行时微环境Microniche两个目标不同的部分，可以让微服务的业务在更广泛的异构计算环境中运行。以运行时(Runtime)原理实现的多运行时MMR形态的微环境Mocroniche，能够很好地与当前的主流微服务架构技术进行对接(通常只需在配置文件中做配置声明)，让微服务的良好兼容性实现能够：即依托微环境的运维特征声明搭载上开放应用模型OAM的业界标准力量，又可以通过微环境的多运行时实现去实现具体环境的适配性微调。

综上可以看出，本专利的微逻辑和微环境结合起来去实现传统微服务的发明有很强的操作性和兼容性。

通过上述实施例，解决了过去微服务架构兼容技术机制原理上都不够深入、没有接触到底层的技术问题。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

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

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

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

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

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。