一种微服务自动部署方法、装置及存储介质与流程

1.本技术涉及计算机处理领域，尤其涉及一种微服务自动部署方法、装置及存储介质。


背景技术：

2.微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。一个大型复杂软件应用由一个或多个微服务组成，springcloud(一种微服务架构)是一系列框架的有序集合，是目前为止使用最为广泛的微服务架构。它的开发便利性巧妙地简化了分布式系统基础设施的开发，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
3.然而，现有技术中，开发者在使用springcloud部署多个微服务时，通常需要手动对每个微服务进行部署，从而导致部署时间较长，存在部署效率较低的问题。


技术实现要素：

4.本技术实施例提供一种微服务自动部署方法、装置及存储介质，用以提高部署多个微服务的部署效率。
5.第一方面，本技术实施例提供一种微服务自动部署方法，该方法包括：
6.接收用户上传的微服务集合；其中，所述微服务集合包括至少两个微服务文件；
7.对所述微服务集合进行解析，得到每个微服务文件的配置文件；
8.响应配置指令，对每个微服务文件的所述配置文件进行配置；
9.响应部署指令，将配置好的微服务文件上传到目标服务器中，并按照预设的顺序启动所述微服务集合中的微服务文件。
10.上述方法，通过对微服务集合进行配置，并根据预设的顺序启动微服务文件，可以较为快速的部署多个微服务，极大的提高springcloud微服务系统的部署效率，节省人力成本。
11.在一种可能的实现方式中，所述响应配置指令，对每个微服务文件的所述配置文件进行配置，包括：
12.响应配置指令，显示配置界面；其中，所述配置界面包括各所述配置文件的配置参数和待配置参数；
13.若响应应用指令，则将各所述配置文件的配置参数替换为所述待配置参数。
14.上述方法，在对配置文件进行配置时，通过显示界面进行显示，并根据应用指令完成一键配置，提高了配置时的效率。
15.在一种可能的实现方式中，所述按照预设的启动顺序启动所述微服务集合中的微服务文件，包括：
16.执行所述微服务集合中的数据库脚本，确定所述微服务集合中各微服务文件的启动顺序；
17.根据所述启动顺序启动所述微服务集合中的各微服务文件。
18.上述方法，通过执行数据库脚本确定各微服务的执行顺序，并按照执行顺序进行执行，可以较为快速的部署多个微服务，极大的提高springcloud微服务系统的部署效率。
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.图1为本技术实施例中微服务自动部署方法的流程示意图；
51.图2为本技术实施例中微服务集合的目录结构的示意图；
52.图3为本技术实施例中微服务自动化部署系统架构图；
53.图4为本技术实施例中各微服务的目录结构的示意图；
54.图5为本技术实施例中微服务自动部署的结构示意图；
55.图6为根据本技术实施方式的计算装置的结构示意图。
具体实施方式
56.为了提高部署多个微服务的部署效率，本技术实施例中提供一种微服务自动部署方法、装置及存储介质。为了更好的理解本技术实施例提供的技术方案，这里对该方案的基本原理做一下简单说明。
57.本技术实施例中术语“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
58.本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例能够以除了在这里图示或描述的那些以外的顺序实施。
59.微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。一个大型复杂软件应用由一个或多个微服务组成，springcloud是一系列框架的有序集合，是目前为止使用最为广泛的微服务架构。它利用springboot的开发便利性巧妙地简化了分布式系统基础设施的开发，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
60.springcloud微服务根据业务规则对原有系统的服务进行解耦，从一个单一的服务包分隔为由多个springcloud微服务，虽然增加了系统的可维护性、扩展性，但同时也增加了部署的过程中的时间和难度。现有的微服务框架系统在部署过程中，存在诸多类似服务依赖启动、端口冲突、修改配置文件繁琐、版本控制等问题。
61.有鉴于此，为了解决上述问题，提高部署多个微服务的部署效率，本技术实施例中提供一种微服务自动部署方法、装置及存储介质，通过对微服务集合进行配置，并根据预设的顺序启动微服务文件，可以较为快速的部署多个微服务，极大的提高springcloud微服务系统的部署效率，节省人力成本。
62.以下结合说明书附图对本技术的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本技术，并不用于限定本技术，并且在不冲突的情况下，本技术实施例中的实施例及实施例中的特征可以相互组合。
63.下面对本技术实施例提供的微服务自动部署方法进行进一步的解释说明。如图1所示，包括以下步骤：
64.s101：接收用户上传的微服务集合；其中，所述微服务集合包括至少两个微服务文件。
65.在本技术实施例中，用户通常是将所有的微服务打包到一个压缩包中，并将这个压缩包上传到springcloud微服务系统中。这样，通过对微服务进行压缩，可以使上传的数据变少，提高上传的传输效率；且将压缩包上传到系统中，简化了用户的操作，避免用户将各微服务一个一个的上传到系统中。
66.s102：对所述微服务集合进行解析，得到每个微服务文件的配置文件。
67.若接收到的微服务集合是压缩包，则对该压缩包进行解压，得到各微服务文件。
68.如图2所示，其为微服务集合的目录结构。微服务系统对接收到的压缩包自动进行解压缩，解析出所有的微服务，包括前端文件和后端文件，系统会根据目录名称自动分析出是sql(structured query language，结构化查询语言)脚本目录、前端目录、后端微服务目录还是更新说明(如图2所示，其中0-sql文件夹为sql脚本目录，1-frontend文件夹为前端目录，2-backend文件夹为后端目录)。
69.在本技术实施例中，为了完成微服务自动部署，通常需要完成四个步骤，如图3所示，其为微服务自动化部署系统架构图，分别为服务器管理、包管理、配置管理以及服务部署。下面分别对这四个步骤进行解释说明。
70.在本技术实施例中，s101-s102为包管理步骤。其主要作用是对接收到的微服务进行解析，从而得到各微服务文件的配置文件。如图4所示，其为各微服务的目录结构。在解析出所有的前端和后端微服务后，会根据系统配置文件自动的解析出服务内部的配置文件，例如yml配置文件、xml配置文件、js文件等，并从配置文件中读取端口信息，服务名称信息，并记录文件路径信息等，在下一步的配置管理和部署服务时使用；同时会记录0-sql目录下
的sql脚本文件路径，在配置完数据库连接后，执行sql脚本。
71.s103：响应配置指令，对每个微服务文件的所述配置文件进行配置。
72.s103为配置管理步骤，在现有技术中，若对配置文件进行配置，需要通过点开这一配置文件，并对里面的参数进行手动修改，其中会有修改出现错误的情况。
73.在本技术实施例中，在包管理步骤中获取到每个微服务的配置文件后，将各配置文件读取到前端进行配置，主要涉及微服务端口、eureka(一种用于实现服务注册和发现的工具)注册中心地址，数据库地址、用户名、密码，redis(一种数据库)地址、用户名、密码等。具体可实施为：
74.响应配置指令，显示配置界面；其中，所述配置界面包括各所述配置文件的配置参数和待配置参数；若响应应用指令，则将各所述配置文件的配置参数替换为所述待配置参数。
75.即在本技术实施例中，将各参数预先设置好，在对配置文件进行配置时，通过替换，将预先设置好的参数替换为待修改的参数，这样，在对配置文件进行配置时，通过显示界面进行显示，并根据应用指令完成一键配置，避免了因手动配置出现参数错误的情况，提高了配置时的效率。
76.需要说明的是，在保存配置时，会自动检查每个服务的端口地址是否和其他微服务的端口地址有冲突，如果有冲突，会进行相应的提示操作，只有在各端口地址没有冲突的情况下，才能够保存配置。
77.s104：响应部署指令，将配置好的微服务文件上传到目标服务器中，并按照预设的顺序启动所述微服务集合中的微服务文件。
78.在本技术实施例中，在进行s104之前，需要进行服务器管理步骤。由于微服务最终需要在服务器进行部署，因此需要设置一个用于部署微服务的服务器。可通过设置服务器的参数来设置一个目标服务器，其中，主要的服务器参数包括服务器名称、ip(互联网协议)、ssh端口(22端口)、用户名、密码等。目标服务器信息保存之后，就可以通过shell(计算机命令行)脚本来获取服务器的基本信息，如版本、环境等，以及判断服务器是否在线。这样，目标服务器便配置完成了。
79.在配置完成目标服务器后，便需要将配置好的微服务文件上传到目标服务器中进行部署，因此s104为服务部署步骤。
80.在本技术实施例中，进行微服务文件部署之前，需要进行端口地址冲突检测，具体可实施为：
81.检测各微服务文件的端口地址；若各所述微服务文件的端口地址与所述目标服务器中已启用的端口地址不同，则根据所述启动顺序启动所述微服务集合中的各微服务文件。
82.其中，开始部署时，会先检查一下所有的微服务配置文件中的端口和服务器上已启用的端口是否有冲突，如果微服务配置文件中的端口已在目标服务器上被占用，则终止部署任务，修改相应配置文件端口后，再行部署，这可以避免微服务在启动过程中的端口冲突问题。
83.端口地址冲突检测之后，为了能够使各微服务文件按照顺序进行执行部署，需要通过sql脚本确定各微服务文件的启动顺序，具体可实施为：
84.执行所述微服务集合中的数据库脚本，确定所述微服务集合中各微服务文件的启动顺序；根据所述启动顺序启动所述微服务集合中的各微服务文件。
85.在本技术实施例中，系统首先会将0-sql目录中的sql脚本在已配置的数据库中进行执行，创建表结构，初始化表数据。根据已确定的部署包和目标服务器，会找到已解压并编辑过的解压目录，使用scp(secure copy，传送命令)递归的传输到目标服务器的指定部署目录，此过程中，如果目标服务器的目录或者子目录不存在，会先进行创建，然后进行文件传输。传输过程中会根据文件的数量和大小，来记录传输进度。
86.传输进度到100％后，会根据目标服务器的部署目录和部署包的目录结构，确定每个微服务的路径信息。并根据目录结构中0,1,2,3
…
的目录结构，来顺序启动后端微服务和前端微服务。
87.这样，通过执行数据库脚本确定各微服务的执行顺序，并按照执行顺序进行执行，可以较为快速的部署多个微服务，极大的提高springcloud微服务系统的部署效率。
88.而按照顺序执行各微服务文件时，需要确定上一个微服务文件成功启动后，再启动下一个微服务文件。具体可实施为：
89.针对每个微服务文件，在所述微服务文件启动之后，向注册中心发送用于注册地址的注册信息；若在注册中心查询到所述注册信息，则按照预设的启动顺序启动所述微服务文件的下一个微服务文件。
90.在本技术实施例中，基于eureka注册中心的springcloud微服务在启动时，会依赖eureka注册地址，如果eureka服务未启动的话，会导致微服务启动失败；同理，微服务之间也有相互依赖，如果b微服务依赖a微服务，而b微服务在a微服务之前启动的话，会导致启动失败。所以此处会检查微服务的启动状态，一般判断微服务是否启动的方法是通过端口来判断，但是springcloud微服务用此方法进行判断并不准确，例如系统检测到a微服务端口已经启动了，但是有可能a微服务的应用程序并未完全启动并注册到eureka，这就会导致b微服务启动失败。
91.因此，在本技术实施例中通过查询注册信息来确定微服务是否成功启动。例如：eureka注册中心启动后，会轮询的来查询eureka的注册地址，如http://eureka-ip:33333/，如果返回的状态码是200，证明该地址可用，也就证明eureka注册中心服务启动成功；其他微服务在调用启动脚本后，会轮询如下地址http://eureka-ip:33333/apps/service-name。其中，service-name就是微服务的注册名称，比如网关服务zuul-gateway-service会轮询如下地址http://eureka-ip:33333/apps/zuul-gateway-service，网关服务成功启动后，会返回200的状态码。
92.同时为了保证轮询时间不会过长，保持在一个微服务正常启动的时间内，默认设置3分钟，每隔5s轮询一次eureka的api接口，3分钟内，状态码未返回200，就可以判断当前微服务启动失败。
93.同时，为了避免遇到其他特殊情况，系统会记录已成功启动的微服务，遇到某一个微服务启动失败时，可以通过查看微服务启动日志来排查原因，此时再次重新启动部署时，跳过已成功启动的微服务，直接从上次失败的微服务开始启动。
94.这样，通过在微服务文件启动之后，再向注册中心发送注册信息，可以通过确定注册中心的注册地址来确定微服务文件是否成功启动，从而避免了因某一微服务启动失败而
导致后续微服务文件启动失败的问题。
95.通过对微服务集合进行配置，并根据预设的顺序启动微服务文件，可以较为快速的部署多个微服务，极大的提高springcloud微服务系统的部署效率，节省人力成本。
96.基于相同的发明构思，本技术实施例还提供了一种微服务自动部署装置。如图5所示，该装置包括：
97.接收模块501，用于接收用户上传的微服务集合；其中，所述微服务集合包括至少两个微服务文件；
98.解析模块502，用于对所述微服务集合进行解析，得到每个微服务文件的配置文件；
99.配置模块503，用于响应配置指令，对每个微服务文件的所述配置文件进行配置；
100.第一部署模块504，用于响应部署指令，将配置好的微服务文件上传到目标服务器中，并按照预设的顺序启动所述微服务集合中的微服务文件。
101.在一种可能的实现方式中，配置模块503包括：
102.显示单元，用于响应配置指令，显示配置界面；其中，所述配置界面包括各所述配置文件的配置参数和待配置参数；
103.配置单元，用于若响应应用指令，则将各所述配置文件的配置参数替换为所述待配置参数。
104.在一种可能的实现方式中，第一部署模块504包括：
105.执行单元，用于执行所述微服务集合中的数据库脚本，确定所述微服务集合中各微服务文件的启动顺序；
106.第一启动单元，用于根据所述启动顺序启动所述微服务集合中的各微服务文件。
107.在一种可能的实现方式中，所述装置还包括：
108.检测模块，用于第一启动单元根据所述启动顺序启动所述微服务集合中的各微服务文件之前，检测各微服务文件的端口地址；
109.第一启动单元具体用于若各所述微服务文件的端口地址与所述目标服务器中已启用的端口地址不同，则根据所述启动顺序启动所述微服务集合中的各微服务文件。
110.在一种可能的实现方式中，第一部署模块504包括：
111.注册单元，用于针对每个微服务文件，在所述微服务文件启动之后，向注册中心发送用于注册地址的注册信息；
112.第二启动单元，用于若在注册中心查询到所述注册信息，则按照预设的启动顺序启动所述微服务文件的下一个微服务文件。
113.基于同一技术构思，本技术实施例还提供了一种终端设备600，参照图6所示，终端设备600用于实施上述各个方法实施例记载的方法，例如实施图1所示的实施例，终端设备600可以包括存储器601、处理器602、输入单元603和显示面板604。
114.存储器601，用于存储处理器602执行的计算机程序。存储器601可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据终端设备600的使用所创建的数据等。处理器602，可以是一个中央处理单元(central processing unit，cpu)，或者为数字处理单元等。输入单元603，可以用于获取用户输入的用户指令。显示面板604，用于显示由用户输入的信息或提供给用户的信
息，本技术实施例中，显示面板604主要用于显示终端设备中各应用程序的显示界面以及各显示界面中显示的控件实体。可选的，显示面板604可以采用液晶显示器(liquid crystal display，lcd)或oled(organic light-emitting diode，有机发光二极管)等形式来配置显示面板604。
115.本技术实施例中不限定上述存储器601、处理器602、输入单元603和显示面板604之间的具体连接介质。本技术实施例在图6中以存储器601、处理器602、输入单元603、显示面板604之间通过总线605连接，总线605在图6中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。总线605可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
116.存储器601可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，ram)；存储器601也可以是非易失性存储器(non-volatile memory)，例如只读存储器，快闪存储器(flash memory)，硬盘(hard disk drive，hdd)或固态硬盘(solid-state drive，ssd)、或者存储器601是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器601可以是上述存储器的组合。
117.处理器602，用于实现如图1所示的实施例，包括：
118.处理器602，用于调用存储器601中存储的计算机程序执行如实施图1所示的实施例。
119.本技术实施例还提供了一种计算机可读存储介质，存储为执行上述处理器所需执行的计算机可执行指令，其包含用于执行上述处理器所需执行的程序。
120.在一些可能的实施方式中，本技术提供的一种微服务自动部署方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当程序产品在终端设备上运行时，程序代码用于使终端设备执行本说明书上述描述的根据本技术各种示例性实施方式的一种微服务自动部署方法中的步骤。例如，终端设备可以执行如实施图1所示的实施例。
121.程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
122.本技术的实施方式的用于一种微服务自动部署程序产品可以采用便携式紧凑盘只读存储器(cd-rom)并包括程序代码，并可以在计算设备上运行。然而，本技术的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
123.可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
124.可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于——无线、有线、光缆、rf等，或者上述的任意合适的组合。
125.可以以一种或多种程序设计语言的任意组合来编写用于执行本技术操作的程序代码，程序设计语言包括面向实体的程序设计语言—诸如java、c 等，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络——包括局域网(lan)或广域网(wan)—连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
126.应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本技术的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。
127.此外，尽管在附图中以特定顺序描述了本技术方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。
128.本领域内的技术人员应明白，本技术的实施例可提供为方法、系统、或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
129.本技术是参照根据本技术实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程文件处理设备的处理器以产生一个机器，使得通过计算机或其他可编程文件处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
130.这些计算机程序指令也可存储在能引导计算机或其他可编程文件处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
131.这些计算机程序指令也可装载到计算机或其他可编程文件处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
132.尽管已描述了本技术的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优
选实施例以及落入本技术范围的所有变更和修改。
133.显然，本领域的技术人员可以对本技术进行各种改动和变型而不脱离本技术的精神和范围。这样，倘若本技术的这些修改和变型属于本技术权利要求及其等同技术的范围之内，则本技术也意图包含这些改动和变型在内。