应用程序迁移方法和装置、电子设备和可读存储介质与流程

1.本技术属于计算机技术领域，具体涉及一种应用程序迁移方法和装置、电子设备和可读存储介质。


背景技术：

2.在相关技术中，企业的业务可能会部署在不支持云原生的操作系统中，针对上述情况，需要将应用程序从云原生环境迁移到物理机上进行部署。但是，在迁移过程中可能存在很多的不确定性，影响迁移业务，具体包括：
3.(1)当前云原生环境依赖各种其他软件，在离线环境下很难做到开箱即用。
4.(2)当前从云原生中进行应用提取过程存在困难，针对不同种类应用软件和特殊应用需要有针对性的处理，严重依赖人工准确性，容易出现迁移失误等问题。
5.(3)跨平台、跨架构需要解决应用是否支持以及重新生成新架构软件的情况。


技术实现要素：

6.本技术实施例的目的是提供一种应用程序迁移方法和装置、电子设备和可读存储介质，能够解决从云原生中进行应用提取过程困难，针对不同种类应用程序和特殊应用程序需要有针对性的处理，严重依赖人工，准确性低，容易出现迁移失误等问题的问题。
7.第一方面，本技术实施例提供了一种应用程序迁移方法，包括：设定应用程序的清单。解析应用程序的清单中的参数，确定应用程序的应用类型。基于应用类型，获取应用数据包和可执行文件包。创建rpm(redhat package manager，redhat软件包管理工具)包的缓存目录，生成spec文件模板，在应用程序依赖外部软件的情况下，将外部软件添加到rpm包的源码包中。导入可执行文件包，基于部署目标系统架构，构建rpm包，得到应用安装包。将应用数据包发送至服务器指定路径，安装应用安装包。
8.第二方面，本技术实施例提供了一种应用程序迁移装置，包括设定模块、获取模块、创建模块、构建模块和安装模块。设定模块用于设定应用程序清单。获取模块用于解析应用程序清单中的参数，确定应用类型，基于应用类型，获取应用数据包和可执行文件包。创建模块用于创建rpm包的缓存目录，生成spec文件模板，在应用程序依赖外部软件的情况下，将外部软件添加到rpm包的源码包中。构建模块用于导入可执行文件包，基于部署目标系统架构，构建rpm包，得到应用安装包。安装模块用于将应用数据包发送至服务器指定路径，安装应用安装包。
9.第三方面，本技术实施例提供了一种电子设备，该电子设备包括处理器和存储器，存储器存储可在处理器上运行的程序或指令，程序或指令被处理器执行时实现如第一方面的应用程序迁移方法的步骤。
10.第四方面，本技术实施例提供了一种可读存储介质，可读存储介质上存储程序或指令，程序或指令被处理器执行时实现如第一方面的应用程序迁移方法的步骤。
11.本实施例可以自动化的判断应用程序的类型，避免采用人工操作进行判断，可以
降低人力成本，避免出现操作失误。本实施例在应用程序依赖外部软件的情况下，将外部软件添加到rpm包的源码包中，无需用户安装任何其他软件，即可进行应用软件的使用，解决了应用程序依赖问题，极大的提高了应用程序的完整性。
附图说明
12.图1示出了本技术实施例提供的应用程序迁移方法的流程示意图之一；
13.图2示出了本技术实施例提供的应用程序迁移方法的流程示意图之二；
14.图3示出了本技术实施例提供的应用程序迁移方法的流程示意图之三；
15.图4示出了本技术实施例提供的应用程序迁移方法的流程示意图之四；
16.图5示出了本技术实施例提供的应用程序迁移方法的流程示意图之五；
17.图6示出了本技术实施例提供的应用程序迁移装置的结构框图；
18.图7示出了本技术实施例提供的电子设备的结构框图；
19.图8示出了本技术实施例提供的应用程序迁移方法的流程示意图之五；
20.图9示出了本技术实施例提供的应用程序迁移方法的流程示意图之六。
21.其中，图6和图7中附图标记与部件名称之间的对应关系为：
22.100：应用程序迁移装置；110：设定模块；120：获取模块；130：创建模块；140：构建模块；150：安装模块；1000：电子设备；1002：处理器；1004：存储器。
具体实施方式
23.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员获得的所有其他实施例，都属于本技术保护的范围。
24.本技术的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便本技术的实施例能够以除了在这里图示或描述的那些以外的顺序实施，且“第一”、“第二”等所区分的对象通常为一类，并不限定对象的个数，例如第一对象可以是一个，也可以是多个。此外，说明书以及权利要求中“和/或”表示所连接对象的至少其中之一，字符“/”，一般表示前后关联对象是一种“或”的关系。
25.下面结合附图1至图9，通过具体的实施例及其应用场景对本技术实施例提供的应用程序迁移方法和装置、电子设备和可读存储介质进行详细地说明。
26.在本技术实施例提供了一种应用程序迁移方法，图1示出了本技术实施例提供的应用程序迁移方法的流程示意图之一，如图1所示，应用程序迁移方法包括：
27.步骤102，设定应用程序的清单。
28.步骤104，解析应用程序的清单中的参数，确定应用程序的应用类型。
29.步骤106，基于应用类型，获取应用数据包和可执行文件包。
30.步骤108，创建rpm包的缓存目录，生成spec文件模板，在应用程序依赖外部软件的情况下，将外部软件添加到rpm包的源码包中。
31.步骤110，导入可执行文件包，基于部署目标系统架构，构建rpm包，得到应用安装包。
32.步骤112，将应用数据包发送至服务器指定路径，安装应用安装包。
33.可以理解的是，spec文件为配置规范性文件，是rpm软件包编译过程的核心，其说明了软件软件包如何被配置、打哪些补丁、安装哪些文件、安装到哪里、安装过程需要哪些系统级别活动。
34.可以理解的是，应用程序可以为在saas(software-as-a-service，软件即服务)平台中的应用程序，将应用程序从云原生部署迁移至信创物理机部署，在应用程序迁移过程中存在技术难点，包括稳定性差、需要跨平台、需要跨架构、难以开箱即用。
35.可以理解的是，在企业拥有众多业务的情况下，每个业务线采用的技术栈可能存在差异，如何自动化判断应用程序的类型，并从云原生环境提取之后部署到信创物理机环境，成为一个待解决的技术难点，如果采用人工操作，工作量巨大，成本高，还可能存在操作失误等问题。采用人工操作还可能会导致从云原生环境提取应用程序时数据内容不完整，到了部署阶段后出现应用程序启动失败，排查问题困难，延误项目进度，增加成本。
36.本实施例中，预先设置应用程序的清单模板，应用程序研发人员以网页提交的形式将应用相关信息补充完整，自动生成应用程序的清单。针对应用程序的清单，可以采用应用提取工具，将清单作为参数传入，进行解析后，开始从云原生环境提取应用程序，并且通过指令和清单中设置的应用类型比对一致后才能确认应用类型，按照不同种类应用进行应用数据包和可执行文件包生成。本实施例可以自动化的判断应用程序的类型，避免采用人工操作进行判断，可以降低人力成本，避免出现操作失误。
37.本实施例通过确定应用类型，获取应用数据包，可以避免采用人工操作导致从云原生环境提取应用程序时数据内容不完整的情况。进而避免到了部署阶段后出现应用程序启动失败，排查问题困难，延误项目进度，增加成本的情况。
38.本实施例可以采用信创应用制作工具，自动识别或手动设置目标物理机架构(即目标系统架构)，进而实现跨平台架构的应用程序编译和rpm包的制作，屏蔽底层架构影响，以无感的方式部署应用到目标物理机服务器。
39.本实施例针对一些离线环境无法安装软件，并且应用程序依赖外部软件的情况下，将外部软件添加到rpm包的源码包中，即在制作应用rpm包时内置了很多环境运行依赖插件，通过将外部软件内嵌到应用软件中，无需用户安装任何其他软件，即可进行应用软件的使用，解决了应用程序依赖问题，极大的提高了应用程序的完整性，开箱即一套完整的可运行环境。
40.本实施例可以应用在信创新部署、业务架构优化、软件使用资源缩减、底层应用架构调整等特殊常场景。
41.本实施例可以简化应用程序从云原生部署迁移到信创物理机部署的过程。本实施例可以从云原生环境提取应用，并直接在信创物理机进行部署，去除容器技术依赖，且不依赖特殊应用软件，实现自动化提取，减少人为操作失误，通过重新编译软件包可以实现跨平台部署。
42.本实施例提供了将应用从云原生环境迁移到信创物理机部署的完整方案，不依赖其他的软件包，简化迁移过程带来的风险，实现了开箱即用，并且，实现了跨架构制作应用安装包，解决了不同架构应用安装兼容性问题。
43.本实施例极大的降低从云原生环境迁移到信创物理机部署过程中带来的不可确
定性因素，尤其在信创领域本实施例的优势更加明显，本实施例属于通用版方案，可以屏蔽底层架构带给应用软件的影响。
44.在本技术的一些实施例中，清单包括以下之一或其组合：
45.应用名称、应用编码、应用端口号、应用所在应用器地址、应用类型、应用占用内存、应用健康检查、应用访问upstream。
46.可以理解的是，upstream表示上游服务器。
47.本实施例中，针对不同的应用程序，可以设定不同的清单内容。通过设定清单，在对清单内容进行解析，可以准确的获取应用程序的相关信息，为后续获取应用数据包、可执行文件包、应用类别以及制作安装文件包提供基础。
48.在本技术的一些实施例中，图2示出了本技术实施例提供的应用程序迁移方法的流程示意图之二，如图2所示，解析应用程序的清单中的参数，确定应用程序的应用类型，具体包括：
49.步骤202，采用应用程序清单中的参数作为参数传入，对应用程序清单中的参数进行参数解析。
50.步骤204，基于应用程序不是定制化应用，通过应用程序清单中的参数判定应用程序的第一应用类型。
51.步骤206，通过应用类型检测指令对应用程序进行检测，得到应用程序的第二应用类型。
52.步骤208，基于第一应用类型与第二应用类型相同，确定应用程序的应用类型为第一应用类型。
53.可以理解的是，应用程序可以分为定制化应用和非定制化应用，针对定制化应用，在进行迁移的过程中，通过设定的方式或形式进行，不在本实施例的讨论范围之内。
54.本实施例中，通过清单中的参数可以获取应用程序的第一应用类型，通过检测指令对应用程序进行检测，可以获取应用程序的第二应用类型，将两次的结果进行对比，只有结果一致时，设定应用程序的应用类型是第一应用类型。
55.本实施例中，通过指令获取的应用类型与清单中设置的应用类型进行对比，比对一致后才能确认应用类型，进而按照不同种类应用进行应用数据包提取和可执行文件包生成。
56.在本技术的一些实施例中，图3示出了本技术实施例提供的应用程序迁移方法的流程示意图之三，如图3所示，基于应用类型，获取应用数据包和可执行文件包，具体包括：
57.步骤302，在应用类型为tomcat类型的情况下，调用通信指令提取应用程序的war包，生成tomcat启动文件和配置信息。
58.其中，war包为应用数据包，tomcat启动文件和配置信息为可执行文件包。
59.步骤304，在应用类型为java类型的情况下，调用通信指令提取应用程序的jar包和相关依赖jar包，生成启动脚本、关闭脚本、服务脚本和配置信息。
60.其中，jar包(java archive)和相关依赖jar包为应用数据包，启动脚本(startup.sh)、关闭脚本(shutdown.sh)、服务脚本(service)和配置信息为可执行文件包。
61.步骤306，在应用类型为node类型的情况下，调用通信指令提取应用程序的js文件，生成启动脚本、关闭脚本、服务脚本、配置信息和可执行二进制文件。
62.其中，js(javascriptt文件的扩展名)文件为应用数据包，启动脚本(startup.sh)、关闭脚本(shutdown.sh)、服务脚本(service)、配置信息和可执行二进制文件为可执行文件包。
63.步骤308，在应用类型为其他类型的情况下，调用通信指令提取应用程序的应用文件，生成可执行文件。
64.其中，应用文件为应用数据包，可执行文件为可执行文件包。
65.可以理解的是，tomcat是免费的web(world wide web，即全球广域网，也称为万维网)服务器。war包是sun提出的一种web应用程序格式，java是计算机编程语言。jar包(jar，java archive，java归档)是一种与平台无关的文件格式，可将多个文件合成一个文件。node是计算机编程语言。js文件是指储存了javascript代码的文本文件，后缀名为“.js”。
66.本实施例将应用类型进行了分类，分别为tomcat类型、java类型、node类型和其他类型。针对每种类型，给出获取应用数据包和可执行文件包的具体方法。本实施例通过对不同的应用类型，生成不同的应用数据包和可执行文件包，可以增加提取的应用程序数据内容的完整性以及可执行文件包的准确性。
67.在本技术的一些实施例中，图4示出了本技术实施例提供的应用程序迁移方法的流程示意图之四，如图4所示，在应用程序依赖外部软件的情况下，将外部软件添加到rpm包的源码包中，具体包括：
68.步骤402，在应用程序依赖java的情况下，将java软件包添加到rpm包的源码包中；
69.步骤404，在应用程序依赖node的情况下，将node软件包添加到rpm包的源码包中；
70.步骤406，在应用程序依赖python的情况下，将python软件包添加到rpm包的源码包中；
71.步骤408，在应用程序依赖go的情况下，将go软件包添加到rpm包的源码包中；
72.步骤410，在应用程序依赖php的情况下，将php软件包添加到rpm包的源码包中；
73.步骤412，在应用程序依赖nginx的情况下，将nginx软件包添加到rpm包的源码包中；
74.步骤414，在应用程序依赖ruby的情况下，将ruby软件包添加到rpm包的源码包中。
75.可以理解的是，在信创物理机环境部署软件系统时，只需要在原生操作系统的基础上安装软件包，而不安装其他任何软件，做到开箱即用是目前软件系统从云原生环境迁移到信创物理机环境的过程中遇到的一大挑战。比如：java应用在运行时依赖的jdk(针对java开发员的软件开发工具包)，需要在应用部署之前进行安装等类似问题。
76.可以理解的是，java、node、python、go、php、nginx或ruby分别表示不同的计算机编程语言。
77.本实施例中，在应用程序依赖java、node、python、go、php、nginx或ruby时，可以将相关软件包添加到rpm包的资源包中，在离线环境无法安装相关依赖软件时，通过在rpm包时内置环境运行依赖插件，实现用户无需安装任何其他软件，即可进行应用软件的使用，可以降低应用程序对外部软件的依赖。
78.在本技术的一些实施例中，图5示出了本技术实施例提供的应用程序迁移方法的流程示意图之五，如图5所示，基于部署目标系统架构，构建rpm包，得到应用安装包，具体包括：
79.步骤502，在部署目标系统架构为x86架构的情况下，追加x86架构参数，通过指令构建rpm包。
80.步骤504，在部署目标系统架构为aarch架构的情况下，追加aarch架构参数，通过指令构建rpm包。
81.步骤506，在部署目标系统架构为其他架构的情况下，通过指令构建rpm包。
82.可以理解的是，x86架构泛指一系列由英特尔公司开发的处理器的架构。aarch架构是arm的一种执行状态，arm(英文为advanced risc machine，或acorn risc machine)也是一个架构，非常适用于移动通信这种低成本，高性能，低耗电的领域。
83.可以理解的是，当应用程序从云原生环境迁移到信创物理机部署时，针对不同物理机的架构，会面临应用类型的转换的问题，例如物理机的架构可以为x86(the x86 architecture)或aarch架构，如何从x86架构转aarch架构，或者从aarch架构转x86架构为需要解决的问题。
84.本实施例可以采用信创应用制作工具，自动识别或手动设置目标物理机架构(即目标系统架构)，通过追加架构参数，实现跨平台架构的应用程序编译和rpm包制作，本实施例可以屏蔽底层架构影响，以无感的方式部署应用到目标物理机服务器。并且，本实施例可以提高应用程序的兼容性和易用性，防止系统类型和应用架构成为应用程序发展的瓶颈。
85.在本技术的一些实施例中，应用程序迁移方法，还包括：
86.在安装应用安装包后，执行应用启动指令，启动应用程序。
87.本实施例中，在信创物理机环境部署软件系统时，只需要在原生操作系统的基础上安装软件包，而不安装其他任何软件，即在安装应用安装包后，可以开箱即用，极大的简化了应用程序迁移的过程，提高了用户体验。
88.本技术实施例提供的应用程序迁移方法，执行主体可以为应用程序迁移装置。本技术实施例中以应用程序迁移装置执行应用程序迁移方法为例，说明本技术实施例提供的应用程序迁移装置。
89.在本技术的一些实施例中提供了一种应用程序迁移装置，图6示出了本技术实施例提供的应用程序迁移装置的结构框图之一，如图6所示，应用程序迁移装置100，包括设定模块110、获取模块120、创建模块130、构建模块140和安装模块150。设定模块110用于设定应用程序清单。获取模块120用于解析应用程序清单中的参数，确定应用类型，基于应用类型，获取应用数据包和可执行文件包。创建模块130用于创建rpm包的缓存目录，生成spec文件模板，在应用程序依赖外部软件的情况下，将外部软件添加到rpm包的源码包中。构建模块140用于导入可执行文件包，基于部署目标系统架构，构建rpm包，得到应用安装包。安装模块150用于将应用数据包发送至服务器指定路径，安装应用安装包。
90.本实施例可以自动化的判断应用程序的类型，避免采用人工操作进行判断，可以降低人力成本，避免出现操作失误。本实施例在应用程序依赖外部软件的情况下，将外部软件添加到rpm包的源码包中，无需用户安装任何其他软件，即可进行应用软件的使用，解决了应用程序依赖问题，极大的提高了应用程序的完整性。
91.本技术实施例提供的应用程序迁移装置100可以实现上述应用程序迁移方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
92.如图7所示，本技术实施例还提供一种电子设备1000，电子设备1000包括处理器
1002和存储器1004，存储器1004上存储有可在处理器1002上运行的程序或指令，该程序或指令被处理器1002执行时实现上述方法实施例的各个步骤，且能达到相同的技术效果，为避免重复，这里不再赘述。
93.举例说明，电子设备1000可以为服务器。
94.本技术实施例还提供一种可读存储介质，可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述应用程序迁移方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
95.其中，处理器为上述实施例中的电子设备中的处理器。可读存储介质，包括计算机可读存储介质，如计算机只读存储器rom、随机存取存储器ram、磁碟或者光盘等。
96.具体实施例：
97.为了从云原生环境提取应用部署到信创物理机，本实施例设计了应用提取工具。该工具包设计理念如下：提前定制一个应用清单的模板文件，各应用研发人员以网页提交的形式将应用相关信息补充完整，然后会自动生成一个应用的清单。接下来使用应用提取工具将应用清单作为参数传入，并解析后，开始从云原生环境提取应用软件，并且通过指令和清单中设置的应用类型比对一致后才能确认应用类型，然后按照不同种类应用进行软件包提取和可执行文件生成。如图8所示，应用数据包和可执行文件包的步骤包括：
98.步骤602，获取应用程序的清单；
99.预先准备一个应用程序的清单，清单包括应用名称、应用编码、应用端口号、应用所在应用器ip、应用类型(java、tomcat、node等)、应用占用内存、应用健康检查uri、应用访问upstream；
100.步骤604，进行应用提取；
101.具体包括：
102.步骤6042，采用应用程序的清单作为参数传入；
103.步骤6044，对应用程序的清单进行参数解析；
104.使用应用提取工具，将步骤6042中的应用清单做参数解析，通过应用编码匹配到是否存在定制化应用，如果是定制化的应用，单独走定制应用流程，否则继续执行步骤6046。
105.步骤6046，判断应用类型；
106.通过应用参数判断应用类型，同时调用kubectl exec指令进入到云原生应用内部(kubectl exec进程：当在计算机上运行kubectl exec
…
时，进程开始可以访问k8s(kubernetes，容器编排器)服务器的任何节点上运行的容器)，执行应用类型检测指令(node-v java-version等)，只有俩者匹配时，才能确认应用类型。
107.在应用类型为tomcat类型的情况下，进入步骤6048。
108.在应用类型为java类型的情况下，进入步骤6050。
109.在应用类型为node类型的情况下，进入步骤6052。
110.在应用类型为其他类型的情况下，进入步骤6054。
111.步骤6048，在应用类型为tomcat类型的情况下，调用kubectl提取应用程序的war包，生成tomcat启动文件、service文件和env.conf。其中，war包为应用数据包，tomcat启动文件、service文件和env.conf为可执行文件包。
112.其中，kubectl是官方的cli(命令行界面)命令行工具。
113.步骤6050，在应用类型为java类型的情况下，调用kubectl提取应用程序的jar包和相关依赖jar包，生成startup.sh、shutdown.sh、service文件和env.conf。其中，jar包和相关依赖jar包为应用数据包，startup.sh、shutdown.sh、service文件和env.conf为可执行文件包。
114.步骤6052，在应用类型为node类型的情况下，调用kubectl提取应用程序的js文件，生成startup.sh、shutdown.sh、service文件和env.conf，提取可执行文件。其中，js文件为应用数据包，启动脚本、关闭脚本、服务脚本、配置信息和可执行二进制文件为可执行文件包。
115.步骤6054，在应用类型为其他类型的情况下，调用kubectl提取应用程序的应用文件，提取可执行文件。其中，应用文件为应用数据包，可执行文件为可执行文件包。
116.步骤6056，产出应用数据包；
117.步骤6058，产出可执行文件包；
118.其中，通过步骤6048至步骤6054可以生成的应用数据包和可执行文件包，作为参数向后传入，为下一阶段应用包制作使用。
119.详细的设计流程如下：
120.如图9所示，生成应用安装包的步骤包括：
121.步骤702，触发制作rpm包流程；
122.步骤704，创建构建rpm缓存目录；
123.步骤706，生成spec文件；
124.步骤708，判断是否依赖外部软件；
125.如果依赖，进入步骤710；否则进入步骤712，其中，外部软件包括java、node、python、go、php、nginx或ruby等。
126.步骤710，加入相关软件包；
127.加入相关软件包到rpm包的源码包中。
128.步骤712，导入可执行文件包；
129.可执行文件包为x86或aarch。
130.步骤714，触发rpmbuild指令；
131.步骤716，判断是否为x86架构；
132.如果是进入步骤718，如果否，进入步骤720；
133.步骤718，追加x86参数；
134.进入步骤724。
135.步骤720，判断是否为aarch架构；
136.如果是进入步骤722，如果否，判定为其他框架，进入步骤724；
137.步骤722，追加aarch参数；
138.进入步骤724。
139.步骤724，得到rpm包产品；
140.得到rpmbuild指令执行结束后的产物xxx.rpm应用安装包；
141.步骤726，将应用数据包发送到服务器指定路径；
142.步骤728，安装rpm包；
143.步骤730，启动应用。
144.本实施例可以解决从云原生环境迁移到物理机部署时，自动识别或手动设置目标物理机架构，可以跨平台架构实现应用编译和rpm包的制作，屏蔽底层架构影响，以无感的方式部署应用到目标物理机服务器。
145.针对一些离线环境无法安装软件，本实施例在制作应用rpm包时内置了很多环境运行依赖插件，可以实现内嵌到应用软件中，从而实现可以不安装任何其他软件，解决了应用依赖问题，极大的提高了应用的完整性，开箱即一套完整的可运行环境。
146.需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。此外，需要指出的是，本技术实施方式中的方法和装置的范围不限按示出或讨论的顺序来执行功能，还可包括根据所涉及的功能按基本同时的方式或按相反的顺序来执行功能，例如，可以按不同于所描述的次序来执行所描述的方法，并且还可以添加、省去、或组合各种步骤。另外，参照某些示例所描述的特征可在其他示例中被组合。
147.通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本技术的技术方案本质上或者说对相关技术做出贡献的部分可以以计算机软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，或者网络设备等)执行本技术各个实施例的方法。
148.上面结合附图对本技术的实施例进行了描述，但是本技术并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本技术的启示下，在不脱离本技术宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本技术的保护之内。