本发明涉及计算机技术领域，具体而言，涉及一种灰度发布方法及系统。
背景技术：
随着微服务架构的流行，分布式系统架构的门槛也越来越低，采用该架构的系统也越来越多。分布式场景下，服务的部署更新越来越灵活，如何平稳的升级在线服务的问题日益突显。目前现有方案都是基于接入系统，通过接入系统来控制流量的分发，但这种方法会导致整个平台依赖于接入系统，使得接入系统成了整个平台的瓶颈，以及根据生产环境网络架构的不同甚至需要多个接入系统，加大了部署、运维和监控难度，同时接入层流量走向调整需要手动完成，步骤麻烦、容易出错。因此，现有技术存在部署、运维、监控难度较大和出错率高以及必须依赖接入系统等诸多问题。
技术实现要素：
本发明提供的一种灰度发布方法及系统，旨在改善上述技术问题。
本发明提供的一种灰度发布方法，包括：注册中心接收用户控制台发送的服务请求，所述服务请求包括用户的用户标识以及所述用户所请求的微服务的标识；所述注册中心根据所述微服务的标识判断所述微服务是否以灰度方式发布；若是，则所述注册中心根据所述用户标识判断所述用户是否为测试用户；若是，则所述注册中心将所述微服务的beta版本的服务地址返回给所述用户控制台，以使所述用户控制台根据所述服务地址调用所述beta版本。
可选地，在所述注册中心根据所述用户标识判断所述用户是否为测试用户之后，还包括：若所述用户不是测试用户，则所述注册中心向所述用户控制台返回所述微服务的正式在线版本的服务地址。
可选地，在所述注册中心将所述微服务的beta版本的服务地址返回给所述用户控制台之后，还包括：若所述beta版本通过测试，则所述注册中心下线原正式在线版本，并将所述beta版本升级为新的正式在线版本。
可选地，在所述注册中心将所述微服务的beta版本的服务地址返回给所述用户控制台之后，还包括：若所述beta版本没有通过测试，则所述注册中心下线所述beta版本。
可选地，在所述注册中心确定所述用户为测试用户之后，以及，在所述注册中心将所述beta版本的服务地址返回给所述用户控制台之前，还包括：所述注册中心确定所述beta版本的版本号高于所述正式在线版本的版本号。
可选地，所述注册中心根据所述用户标识判断所述用户是否为测试用户，包括：所述注册中心判断所述用户标识是否添加表示所述用户为测试用户的标签，所述标签由所述用户控制台在确定所述用户为测试用户后添加；若所述用户标识添加有所述标签，则所述注册中心确定所述用户为测试用户。
本发明提供的一种灰度发布系统，包括：注册中心和用户控制台，其中，
所述用户控制台用于：向所述注册中心发送服务请求，所述服务请求包括用户的用户标识以及所述用户所请求的微服务的标识；所述注册中心，用于接收所述服务请求；根据所述微服务的标识判断所述微服务是否以灰度方式发布；在所述微服务以灰度方式发布时，则根据所述用户标识判断所述用户是否为测试用户；以及在所述用户为测试用户时，将所述微服务的beta版本的服务地址返回给所述用户控制台；所述用户控制台还用于：根据所述服务地址调用所述beta版本。
可选地，所述注册中心还用于：在根据所述用户标识判断所述用户是否为测试用户之后，若判断出所述用户不是测试用户，则向所述用户控制台返回所述微服务的正式在线版本的服务地址。
可选地，所述注册中心还用于：在将所述微服务的beta版本的服务地址返回给所述用户控制台之后，若所述beta版本通过测试，则下线原正式在线版本，并将所述beta版本升级为新的正式在线版本；以及，若所述beta版本没有通过测试，则下线所述beta版本。
可选地，所述用户控制台还用于为测试用户的用户标识添加表示所述用户为测试用户的标签；所述注册中心用于：根据所述用户标识判断所述用户是否为测试用户，包括：判断所述用户标识是否添加表示所述用户为测试用户的标签，所述标签由所述用户控制台在确定所述用户为测试用户后添加；若所述用户标识添加有所述标签，则所述注册中心确定所述用户为测试用户。
上述本发明提供的一种灰度发布方法及系统，通过注册中心接收用户控制台发送的服务请求，其中，所述服务请求包括用户的用户标识以及所述用户所请求的微服务的标识。从而所述注册中心再根据所述微服务的标识判断所述微服务是否以灰度方式发布，在所述微服务以灰度方式发布时，则所述注册中心根据所述用户标识判断所述用户是否为测试用户。在所述用户为测试用户时，则所述注册中心将所述微服务的beta版本的服务地址返回给所述用户控制台，以使所述用户控制台根据所述服务地址调用所述beta版本。从而通过注册中心实现普通用户和测试用户维度的灰度发布，不依赖于传统的接入层，简化了微服务的架构，减少了部署和运维的投入。同时实现了单个微服务及多个微服务组合的灰度发布，且有效防止了误操作，进而克服了上述技术问题。进一步实现了降低部署、运维、监控的难度和出错率以及不需要在依赖接入系统的技术效果。
为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1为本发明较佳实施例提供的注册中心与用户控制台进行交互的示意图；
图2为本发明实施例提供的一种服务器的结构框图；
图3为本发明第一实施例提供的灰度发布方法的流程图；
图4为本发明第二实施例提供的灰度发布方法的流程图；
图5为本发明第三实施例提供的灰度发布系统的功能模块示意图；
图6为图5所示的灰度发布系统的一种实施示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
下面先介绍本发明实施例涉及的一些概念：
灰度发布：是指在发布应用产品或服务(如微服务)时，向测试用户发送beta版本，向其他用户发送正式在线版本，如果beta版本的测试结果较好，则可以逐步扩大beta版本的发布范围，直至把所有用户都迁移到beta版本上，此时beta版本升级为新的正式在线版本。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
如图1所示，是本发明较佳实施例提供的注册中心与用户控制台进行交互的示意图。所述注册中心200通过网络与用户控制台100进行通信连接，以进行数据通信或交互。
在本实施例中，所述注册中心200为设于服务器中的软件功能模块或计算机程序，所述注册中心200一方面用于实现用户的注册功能，另一方面用于以灰度的方式发布微服务，具体地，所述注册中心200，用于接收所述服务请求；根据所述微服务的标识判断所述微服务是否以灰度方式发布；在所述微服务以灰度方式发布时，则根据所述用户标识判断所述用户是否为测试用户；以及在所述用户为测试用户时，将所述微服务的beta版本的服务地址返回给所述用户控制台100。
作为一种实施方式，所述注册中心200还用于：在根据所述用户标识判断所述用户是否为测试用户之后，若判断出所述用户不是测试用户，则向所述用户控制台100返回所述微服务的正式在线版本的服务地址。
作为一种实施方式，在所述注册中心200还用于：将所述微服务的beta版本的服务地址返回给所述用户控制台100之后，若所述beta版本通过测试，则下线原正式在线版本，并将所述beta版本升级为新的正式在线版本；以及，若所述beta版本没有通过测试，则下线所述beta版本。
在本实施例中，所述用户控制台100为设于服务器中的软件功能模块或计算机程序，其中，所述用户控制台100一方面用于向所述注册中心200发送服务请求，所述服务请求包括用户的用户标识以及所述用户所请求的微服务的标识，另一方面所述用户控制台200还用于：根据所述服务地址调用所述beta版本。以及所述用户控制台200还用于在确定所述用户为测试用户后添加表示所述用户为测试用户的标签。
如图2所示，为本发明实施例提供的一种服务器的结构框图。所述服务器300包括灰度发布系统400、存储器302、存储控制器303、处理器304及外设接口305。
所述存储器302、存储控制器303、处理器304及外设接口305各元件相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。所述灰度发布系统400包括至少一个可以软件或固件(firmware)的形式存储于所述存储器302中或固化在所述服务器300的操作系统(operatingsystem，os)中的软件功能模块。所述处理器304用于执行存储器302中存储的可执行模块，例如所述灰度发布系统400包括的软件功能模块或计算机程序。
其中，存储器302可以是，但不限于，随机存取存储器(randomaccessmemory，ram)，只读存储器(readonlymemory，rom)，可编程只读存储器(programmableread－onlymemory，prom)，可擦除只读存储器(erasableprogrammableread－onlymemory，eprom)，电可擦除只读存储器(electricerasableprogrammableread－onlymemory，eeprom)等。其中，存储器302用于存储程序，所述处理器304在接收到执行指令后，执行所述程序，前述本发明实施例任一实施例揭示的流过程定义的服务器100所执行的方法可以应用于处理器304中，或者由处理器304实现。
处理器304可能是一种集成电路芯片，具有信号的处理能力。上述的处理器304可以是通用处理器，包括中央处理器(centralprocessingunit，简称cpu)、网络处理器(networkprocessor，简称np)等；还可以是数字信号处理器(dsp)、专用集成电路(asic)、现成可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
所述外设接口305将各种输入/输入装置耦合至处理器304以及存储器302。在一些实施例中，外设接口305、处理器304以及存储控制器303可以在单个芯片中实现。在其他一些实例中，他们可以分别由独立的芯片实现。
请参阅图3，是本发明第一实施例提供的灰度发布方法的流程图。下面将对图3所示的具体流程进行详细阐述。
步骤s101，注册中心接收用户控制台发送的服务请求。
其中，所述服务请求包括用户的用户标识以及所述用户所请求的微服务的标识。
在本实施例中，所述服务请求可以是用户注册请求，也可以是用户使用请求，还可以是其他请求，在此，不作具体限定。
在本实施例中，所述用户标识可以是用户账号，也可以是id或者是用户地址或者是与用户账号绑定的地址等。在此，不作具体限定。
其中，所述微服务的标识可以是用于表征所述微服务的一字符串，也可以是一字符等。在此，不作具体限定。
作为一种实施方式，注册中心接收用户基于用户控制台发送的服务请求，其中，所述用户可以是非普通用户，如开发人员、测试人员或管理员等，也可以是普通用户。在此，不作具体限定。
在本实施例中，所述注册中心用于接收用户控制台发送的服务请求；所述用户控制台用于发送服务请求至所述注册中心。
其中，优选地，所述用户控制台可通过webportal来操作，以实现降低用户使用门槛。
步骤s102，所述注册中心根据所述微服务的标识判断所述微服务是否以灰度方式发布。
其中，所述的灰度方式发布是指分布式架构中软件服务渐进更新的方法，即以灰度方式发布的微服务为灰度服务。所述微服务包括将要更新或者首次发布的微服务。
在本实施例中，所述注册中心用于根据所述微服务的标识判断所述微服务是否以灰度方式发布。
在本实施例中，所述注册中心可以以灰度方式发布单个微服务或多个微服务组合的微服务。
作为一种实施方式，所述注册中心查询与所述微服务的标识所匹配的存储信息，例如，所述存储信息可以是微服务的类型信息，也可以是该微服务所对应的用户的类型信息，如该用户是普通用户，还是管理员等。从而根据所述存储信息判断所述微服务是否以灰度方式发布。例如，当所述存储信息显示为微服务为普通用户所请求的微服务时，则确定所述微服务不以灰度方式发布。
步骤s103，若是，则所述注册中心根据所述用户标识判断所述用户是否为测试用户。
在所述微服务以灰度方式发布时，所述微服务不直接对除测试用户以外的其他用户提供服务，仅供测试用户使用，则所述注册中心根据所述用户标识判断所述用户是否为测试用户。
其中，所述测试用户是指非普通用户，如所述测试用户可以是开发人员、测试人员或管理员等。
在本实施例中，所述注册中心用于根据所述用户标识判断所述用户是否为测试用户。
在本实施例中，优选地，所述注册中心判断所述用户标识是否添加表示所述用户为测试用户的标签，例如，所述注册中心通过预先设定的解析方法解析所述用户标识，以识别所述用户标识是否添加表示所述用户为测试用户的标签，所述标签由所述用户控制台在确定所述用户为测试用户后添加；若所述用户标识添加有所述标签，则所述注册中心确定所述用户为测试用户。其中，所述标签可以是一字符串，也可以是一字符等，例如，所述用户控制台在确定所述用户为测试用户后为所述用户标识添加testtag，或者是为测试用户的流量添加testtag，通过识别流量中是否添加testtag来进行判断该用户是否为测试用户，如当流量中有testtag时，表示该用户为测试用户。在此，不作具体限定。
步骤s104，若是，则所述注册中心将所述微服务的beta版本的服务地址返回给所述用户控制台，以使所述用户控制台根据所述服务地址调用所述beta版本。
在本实施例中，在所述用户为测试用户时，则所述注册中心将所述微服务的beta版本的服务地址返回给所述用户控制台，以使所述用户控制台根据所述服务地址调用所述beta版本。即所述注册中心用于在所述用户为测试用户时，将所述微服务的beta版本的服务地址返回给所述用户控制台，以使所述用户控制台根据所述服务地址调用所述beta版本。所述用户控制台用于接收所述注册中心所发送的所述微服务的beta版本的服务地址，并根据所述微服务的beta版本的服务地址调用所述beta版本。
在本实施例中，若所述用户不是测试用户，则所述注册中心向所述用户控制台返回所述微服务的正式在线版本的服务地址。其中，所述正式在线版本为已经发布供非测试用户所使用的版本。
作为一种实施方式，在用户控制台获取到微服务的beta版本的服务地址后，所述用户控制台根据所述服务地址从注册中心获取对应的微服务，所述注册中心确定是否存在以灰度方式发布的微服务，若存在以灰度方式发布的微服务，则所述注册中心确定所述beta版本的版本号高于所述正式在线版本的版本号。若不存在以灰度方式发布的微服务，则所述注册中心向所述用户控制台返回所述微服务的正式在线版本的服务地址。
本发明实施例提供的灰度发布方法，注册中心通过接收用户控制台发送的服务请求，并基于服务请求中的微服务的标识判断所述微服务是否以灰度方式发布，在所述微服务以灰度方式发布时，则所述注册中心根据所述用户标识判断所述用户是否为测试用户。在所述用户为测试用户时，则所述注册中心将所述微服务的beta版本的服务地址返回给所述用户控制台，以使所述用户控制台根据所述服务地址调用所述beta版本。从而通过注册中心实现普通用户和测试用户维度的灰度发布，不依赖于传统的接入层，简化了微服务的架构，减少了部署和运维的投入。同时实现了单个微服务及多个微服务组合的灰度发布，且有效防止了误操作，进而实现了降低部署、运维、监控的难度和降低出错率的技术效果。
请参阅图4，是本发明第二实施例提供的灰度发布方法的流程图。下面将对图4所示的具体流程进行详细阐述。
步骤s201，注册中心接收用户控制台发送的服务请求。
步骤s202，所述注册中心根据所述微服务的标识判断所述微服务是否以灰度方式发布。
步骤s203，若是，则所述注册中心根据所述用户标识判断所述用户是否为测试用户。
步骤s201至步骤s203的具体实施方式请参照第一实施例中所对应的步骤，在此，不再赘述。
作为一种实施方式，在步骤s203之后，以及，步骤s204之前还包括步骤s203a，具体如下：
步骤s203a，所述注册中心确定所述beta版本的版本号高于所述正式在线版本的版本号。
在本实施例中，所述注册中心通过判断所述beta版本的版本号是否高于所述正式在线版本的版本号，进而使得当beta版本的版本号高于所述正式在线版本的版本号时，通过所述beta版本来替换所述正式在线版本。
其中，在本实施例中，所述注册中心用于确定所述beta版本的版本号是否高于所述正式在线版本的版本号。
步骤s204，若是，则所述注册中心将所述微服务的beta版本的服务地址返回给所述用户控制台，以使所述用户控制台根据所述服务地址调用所述beta版本。
步骤s204的具体实施方式请参照第一实施例中所对应的步骤，在此，不再赘述。
步骤s205，若所述beta版本通过测试，则所述注册中心下线原正式在线版本，并将所述beta版本升级为新的正式在线版本。
作为一种实施方式，可以通过用户控制台所返回的测试信息来判断所述beta版本是否通过测试，如当测试信息显示为通过时，判定所述beta版本通过测试。其中，所述测试信息可以是测试用户基于用户控制台所输入的信息或指令。在此，不作具体限定。
步骤s206，若所述beta版本没有通过测试，则所述注册中心下线所述beta版本。
在本实施例中，当所述beta版本没有通过测试时，所述注册中心下线所述beta版本，即所述注册中心下线所述beta版本所对应的灰度服务，以进行重新部署。
本发明实施例提供的灰度发布方法，注册中心通过接收用户控制台发送的服务请求，并基于服务请求中的微服务的标识判断所述微服务是否以灰度方式发布，在所述微服务以灰度方式发布时，则所述注册中心根据所述用户标识判断所述用户是否为测试用户。以及所述注册中心确定所述beta版本的版本号高于所述正式在线版本的版本号。以使得在所述用户为测试用户时，则所述注册中心将所述微服务的beta版本的服务地址返回给所述用户控制台，以使所述用户控制台根据所述服务地址调用所述beta版本。从而通过注册中心实现普通用户和测试用户维度的灰度发布，不依赖于传统的接入层，简化了微服务的架构，减少了部署和运维的投入。同时实现了单个微服务及多个微服务组合的灰度发布，且有效防止了误操作，以及确保了所发布的beta版本的版本号是高于正式在线版本的版本号的，进一步实现了降低部署、运维、监控的难度和降低出错率的技术效果。
请参阅图5，是本发明第三实施例提供的灰度发布系统的功能模块示意图。所述灰度发布系统400包括注册中心410和用户控制台420。
所述用户控制台420用于：向所述注册中心410发送服务请求，所述服务请求包括用户的用户标识以及所述用户所请求的微服务的标识；
所述注册中心410，用于接收所述服务请求；
根据所述微服务的标识判断所述微服务是否以灰度方式发布；
在所述微服务以灰度方式发布时，则根据所述用户标识判断所述用户是否为测试用户；以及在所述用户为测试用户时，将所述微服务的beta版本的服务地址返回给所述用户控制台420。
所述用户控制台420还用于：根据所述服务地址调用所述beta版本。
作为一种实施方式，所述用户控制台420还用于为测试用户的用户标识添加表示所述用户为测试用户的标签；所述注册中心410用于：根据所述用户标识判断所述用户是否为测试用户，包括：判断所述用户标识是否添加表示所述用户为测试用户的标签，所述标签由所述用户控制台420在确定所述用户为测试用户后添加；若所述用户标识添加有所述标签，则所述注册中心410确定所述用户为测试用户。如图6所示，所述用户控制台420为测试用户的用户标识添加表示所述用户为测试用户的标签后，所述注册中心410判断所述用户标识是否添加表示所述用户为测试用户的标签，若所述用户标识添加有所述标签，则所述注册中心410确定所述用户为测试用户，并返回所述微服务的beta版本的服务地址给所述用户控制台420，以使所述用户控制台420根据所述微服务的beta版本的服务地址调用灰度微服务，即调用所述beta版本所对应的微服务。
作为一种实施方式，所述注册中心410还用于：在根据所述用户标识判断所述用户是否为测试用户之后，若判断出所述用户不是测试用户，则向所述用户控制台420返回所述微服务的正式在线版本的服务地址。
作为一种实施方式，所述注册中心410还用于：在将所述微服务的beta版本的服务地址返回给所述用户控制台420之后，若所述beta版本通过测试，则下线原正式在线版本，并将所述beta版本升级为新的正式在线版本；若所述beta版本没有通过测试，则下线所述beta版本，即所述注册中心410下线所述beta版本所对应的灰度服务。
作为一种实施方式，在所述注册中心410用于根据所述用户标识判断所述用户是否为测试用户以及；所述注册中心410用于将所述beta版本的服务地址返回给所述用户控制台420之前，还包括：所述注册中心410确定所述beta版本的版本号高于所述正式在线版本的版本号。
本发明实施例提供的灰度发布系统，注册中心通过接收用户控制台发送的服务请求，并基于服务请求中的微服务的标识判断所述微服务是否以灰度方式发布，在所述微服务以灰度方式发布时，则所述注册中心根据所述用户标识判断所述用户是否为测试用户。以及所述注册中心确定所述beta版本的版本号高于所述正式在线版本的版本号。以使得在所述用户为测试用户时，则所述注册中心将所述微服务的beta版本的服务地址返回给所述用户控制台，以使所述用户控制台根据所述服务地址调用所述beta版本。从而通过注册中心实现普通用户和测试用户维度的灰度发布，不依赖于传统的接入层，简化了微服务的架构，减少了部署和运维的投入。同时实现了单个微服务及多个微服务组合的灰度发布，且有效防止了误操作，以及确保了所发布的beta版本的版本号是高于正式在线版本的版本号的，进一步实现了降低部署、运维、监控的难度和降低出错率的技术效果。
综上所述，本发明提供的一种灰度发布方法及系统，通过注册中心接收用户控制台发送的服务请求，其中，所述服务请求包括用户的用户标识以及所述用户所请求的微服务的标识。从而所述注册中心再根据所述微服务的标识判断所述微服务是否以灰度方式发布，在所述微服务以灰度方式发布时，则所述注册中心根据所述用户标识判断所述用户是否为测试用户。在所述用户为测试用户时，则所述注册中心将所述微服务的beta版本的服务地址返回给所述用户控制台，以使所述用户控制台根据所述服务地址调用所述beta版本。从而通过注册中心实现普通用户和测试用户维度的灰度发布，不依赖于传统的接入层，简化了微服务的架构，减少了部署和运维的投入。同时实现了单个微服务及多个微服务组合的灰度发布，且有效防止了误操作，进而克服了上述技术问题。进一步实现了降低部署、运维、监控的难度和出错率以及不需要在依赖接入系统的技术效果。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本发明的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
另外，在本发明各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。
所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read－onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。