应用服务更新方法及装置与流程

本发明涉及互联网领域，具体而言，涉及一种应用服务更新方法及装置。

背景技术：

随着互联网的迅速发展，用户需求越来越复杂，对公司技术架构设计要求就越来越高了，应用数量也随之倍增，这个时候传统运维手工发布模式就很难应对这一变化了。

单个应用发布过程是比较简单的，大致可以分为三个步骤：停止服务、替换应用包、启动服务。在应用数量比较小的场景下，每次发布都由运维人员手工完成，工作量相对较小。例如，传化物流初期应用数量只有几十个，但一年之后应用数量直接上升至400多个，而且每个发布日80％的应用都会发布更新，如此大的更新发布频率和发布量，对运维人员来说，如果还是采用传统的手工更新发布模式，只能是人肉战术，而且效率极低。此时，作为运维人员就迫切希望将这些工作自动化，解放双手。

技术实现要素：

有鉴于此，本发明实施例的目的在于提供一种应用服务更新方法，以改善上述的问题。

本发明实施例的另一目的还在于提供一种应用服务更新装置，以改善上述问题。

本发明实施例提供了一种应用更新方法，应用于服务器集群，所述服务器集群包括前端服务器及至少一个后端服务器，所述方法包括：接收应用服务更新指令；依据所述更新指令，对未标记已更新标识的后端服务器添加待更新标识；更新存储在标记有所述待更新标识的后端服务器的应用服务程序；对存储有更新后的应用服务程序的后端服务器添加已更新标识。

进一步地，所述更新存储在标记有所述待更新标识的后端服务器的应用服务程序的步骤包括：下线存储在标记有所述待更新标识的后端服务器的应用服务程序；获取存储在版本管理服务器的待更新应用服务程序代码包；替换所述应用服务程序代码包为待更新应用服务程序代码包。

进一步地，所述替换应所述用服务程序代码包为待更新应用服务程序代码包之前，还包括：验证发布信息，所述验证发布信息包括：验证发布者的身份；验证发布次数；验证所述代码包的正确性；当验证所述发布者的身份、所述发布次数以及所述代码包的正确性均通过后替换应所述用服务程序代码包为待更新应用服务程序代码包。

进一步地，所述验证所述代码包的正确性通过后，在所述更新存储在标记有所述待更新标识的后端服务器的应用服务程序之前，还包括：获取所述待更新应用服务程序的配置包；替换所述应用服务程序的配置包为所述待更新应用服务程序的配置包。

进一步地，所述方法在所述替换应所述用服务程序代码包为待更新应用服务程序代码包之后，还包括：加载上线所述更新后的应用服务程序。

本发明实施例提供了一种应用更新装置，应用于服务器集群，所述服务器集群包括前端服务器及至少一个后端服务器，所述装置包括：指令接收单元，用于接收应用服务更新指令；待更新标识添加单元，用于依据所述更新指令，对未标记已更新标识的后端服务器添加待更新标识；更新单元，用于更新存储在标记有所述待更新标识的后端服务器的应用服务程序；已更新标识添加单元，用于对存储有更新后的应用服务程序的后端服务器添加已更新标识。

进一步地，所述更新单元包括：服务下线子单元，用于下线存储在标记有所述待更新标识的后端服务器的应用服务程序；代码获取子单元，用于获取存储在版本管理服务器的待更新应用服务程序代码包；代码替换子单元，用于替换应用服务程序代码包。

进一步地，所述装置还包括验证单元，所述验证单元包括：身份验证子单元，验证发布者的身份；发布次数验证子单元，用于验证发布次数；代码包验证子单元，用于验证所述代码包的完整性、正确性。

进一步地，所述更新单元还包括：配置获取子单元，用于获取所述待更新应用服务程序的配置包；配置替换子单元，用于替换所述应用服务程序的配置包为所述待更新应用服务程序的配置包。

进一步地，所述装置还包括服务加载单元，用于加载上线所述更新后的应用服务程序。

相对现有技术，本发明具有以下有益效果：

本发明公开的一种应用服务更新发布方法及装置，应用于一服务器集群，所述服务器集群包括前端服务器以及后端服务器，在其更新发布的过程中，各个后端服务器的更新串行进行，逐一进行应用服务程序的更新，各后端服务器之间互不干扰，不会中断提供的服务，用户不会感知到更新发布的过程，提升了用户体验，确保了信息的安全，并且适用于大规模的应用更新上线场景。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1示出了本发明所提供的一种应用服务更新装置适用场景示意图。

图2示出了本发明提供的应用服务更新装置适用的前端服务器示意图。

图3示出了本发明提供的应用服务更新装置框图。

图4示出了验证单元示意框图。

图5示出了更新单元示意框图。

图6示出了本发明提供的应用服务更新方法流程图。

图7所示出了本发明提供的步骤s103的子步骤图。

图8示出了本发明提供的步骤s104的子步骤图。

图标：10-应用服务线上服务系统；100-前端服务器；120-存储器；130-存储控制器；140-处理器；150-外设接口；200-应用服务更新装置；201-指令接收单元；202-验证单元；2011-身份验证子单元；2012-发布日验证子单元；2013-发布次数验证子单元；2014-代码包验证子单元；203-待更新标识添加单元；204-更新单元；2041-服务下线子单元；2042-代码获取子单元；2043-配置获取子单元；2044-配置替换子单元；2045-代码替换子单元；205-已更新标识添加单元；206-服务加载单元；207-报警单元；300-后端服务器；400-用户端。

具体实施方式

下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

在本发明的描述中，需要说明的是，术语“上”、“下”、“左”、“右”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，或者是该发明产品使用时惯常摆放的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。

在本发明的描述中，还需要说明的是，除非另有明确的规定和限定，术语“设置”、“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。

在本发明的描述中，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。术语“水平”、“竖直”、“悬垂”等术语并不表示要求部件绝对水平或悬垂，而是可以稍微倾斜。如“水平”仅仅是指其方向相对“竖直”而言更加水平，并不是表示该结构一定要完全水平，而是可以稍微倾斜。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

下面结合附图，对本发明的一些实施方式作详细说明。在不冲突的情况下，下述的实施例及实施例中的特征可以相互组合。

请参阅图1，图1示出了作为本实施例提供的应用服务更新装置200的应用场景的应用服务线上服务系统10。如图1所示，应用服务线上服务系统10包括用户端400、服务器集群(图未标)，服务器集群包括前端服务器100以及多台后端服务器300，所述后端服务器300存储有用于提供服务的应用服务程序，用户端400、前端服务器100及后端服务器300通过网络连接，通过该网络，用户端400与所述服务器集群进行数据交互。于本发明实施例中，用户端400中安装有至少一个应用程序(application，app)，与前端服务器100相对应，为用户提供服务。该前端服务器100可以是，但不限于，网络服务器、数据库服务器、云端服务器等等。该用户端400可以是，但不限于智能手机、个人电脑(personalcomputer，pc)、平板电脑、个人数字助理(personaldigitalassistant，pda)、移动上网设备(mobileinternetdevice，mid)等。所述用户端400的操作系统可以是，但不限于，安卓(android)系统、ios(iphoneoperatingsystem)系统、windowsphone系统、windows系统等。

图2示出了一种可应用本发明实施例中的前端服务器100的结构框图，所述前端服务器100包括应用服务更新装置200、处理器140、存储器120、存储控制器130及外设接口150。

所述存储器120、存储控制器130及处理器140，各元件相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。所述应用服务更新装置200包括至少一个可以软件或固件(firmware)的形式存储于所述存储器120中或固化在所述前端服务器100的操作系统(operatingsystem，os)中的软件功能模块。所述处理器140用于执行存储器120中存储的可执行模块，例如，所述应用服务更新装置200包括的软件功能模块或计算机程序。

其中，存储器120可以是，但不限于，随机存取存储器(randomaccessmemory，ram)，只读存储器(readonlymemory，rom)，可编程只读存储器(programmableread-onlymemory，prom)，可擦除只读存储器(erasableprogrammableread-onlymemory，eprom)，电可擦除只读存储器(electricerasableprogrammableread-onlymemory，eeprom)等。其中，存储器120用于存储程序，所述处理器140在接收到执行指令后，执行所述程序，前述本发明实施例任一实施例揭示的流过程定义的服务端所执行的方法可以应用于处理器140中，或者由处理器140实现。

处理器140可能是一种集成电路芯片，具有信号的处理能力。上述的处理器140可以是通用处理器，包括中央处理器(centralprocessingunit，简称cpu)、网络处理器(networkprocessor，简称np)等；还可以是数字信号处理器(dsp)、专用集成电路(asic)、现成可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器140也可以是任何常规的处理器140等。

外设接口150将各种输入/输出装置耦合至处理器140以及存储器120。在一些实施例中，外设接口150、处理器140以及存储控制器130可以在单个芯片中实现。在其他一些实例中，他们可以分别由独立的芯片实现。

可以理解，图2所示的结构仅为示意，前端服务器100还可包括比图2中所示更多或者更少的组件，或者具有与图2所示不同的配置。图2中所示的各组件可以采用硬件、软件或其组合实现。

第一实施例

请参阅图3，图3显示了本实施例提供的一种应用服务更新装置200的结构框图。应用服务更新装置200包括指令接收单元201、验证单元202、待更新标识添加单元203、更新单元204、已更新标识添加单元205以及服务加载单元206。

指令接收单元201用于接收管理员下达的更新应用服务程序的指令，所述更新应用服务程序的指令可以是用户直接向所述前端服务器100下达的指令，也可以是管理员通过用户端400向服务器下达的更新应用服务程序的指令。所述指令可以包括：待更新应用服务程序的存储路径信息，版本信息，以及待更新应用服务程序的代码包的地址信息等。

验证单元202用于进行管理员身份信息、应用程序代码包等信息的验证。验证单元202包括身份验证子单元2011、发布日验证子单元2012、发布次数验证子单元2013以及代码包验证子单元2014等。

请参阅图4，身份验证子单元2011用于验证发布者的管理员身份，例如，可以通过账号、密码等方式对发布者进行身份的验证，当发布者无法通过身份验证时，无法进行后续的发布操作。

发布日验证子单元2012、发布次数验证子单元2013分别用于验证应用服务程序的更新发布日以及发布次数，发布日验证子单元2012可预设可以发布更新应用服务程序的日期，在管理员发布更新的时候通过读取系统时间或获取网络时间来获取当前的发布日期，并将获取到的发布如期与预设的发布更新应用服务程序的日期进行比对，匹配则允许继续的发布操作。通过固定的更新发布日期从而提高用户体验。发布次数验证单元202用于验证在更新发布日的发布更新次数，在发布日的发布更新的次数不能超过预设的次数(例如3次)，否则不允许继续后续的更新发布操作。

代码包验证子单元2014用于验证所述代码包的完整性、正确性，代码包验证子单元2014可以通过验证代码包的名称、大小、编号、md5码等来验证所述代码包是否为正确、完整的代码包。

上述的验证单元202适用于常规发布应用服务程序更新，在本发明的其余实施例中，所述验证单元202还包括紧急发布验证子单元(图未示)，紧急发布验证子单元用于验证紧急发布，例如当所述应用服务程序出现重大运行故障时需要立马更新时，需要进行紧急发布。紧急发布验证子单元验证通过时，验证单元202可跳过发布日验证单元202、发布次数验证单元202，不再进行发布日、发布次数等的验证，以简化应用服务程序更新发布流程。

待更新标识添加单元203用于依据所述应用服务更新指令，对未标记已更新标识的后端服务器300添加待更新标识。例如，在tengine中，通过操作修改nginx的upstream配置文件来为后端服务器300添加待更新标识，在tengine中，后端服务器300可以称作member，tengine的健康检查机制是会按照一定的时间间隔像各个member发起健康检查的请求，并会记录member返回的状态。整个发布过程是串行的，在发布每一台member之前，通过发布脚本修改upstream.conf文件，将web-appname-1标记为down，此即为本实施例中的待更标识。

更新单元204用于根据更新存储在有待更新标识的后端服务器300的应用服务程序。在本实施例中，更新单元204用于更新web-appname-1被标记为down的member中的应用服务程序。更新单元204包括服务下线子单元2041，代码获取子单元2042、配置获取子单元2043、配置替换子单元2044以及代码替换子单元2045。

请参阅图5，服务下线子单元2041用于下线被标记为down的member中的应用服务程序，具体地，每隔一段时间，nginx会进行reload，nginx检测到该member标记为down时，会在当前连接处理完成之后，不再接收新的请求，即该member完成当前的处理操作之后即会处于离线状态。

代码获取子单元2042用于获取存储在版本管理服务器的待更新应用服务程序代码包。在本实施例中，借助jenkins，实现代码编译打包，不再由开发人员本地打包，只需提供最新代码的svn路径，由测试人员直接在jenkins管理平台上点击构建即可完成应用的打包，只需提供代码包的路径，即可获取到待更新应用服务程序的代码包，这个过程减轻了开发人员的压力，也避免了因为手动打包过程中的失误而造成应用包不可用，使得应用上线流程更加顺利。

配置获取子单元2043，在本实施例中，配置分为系统配置和业务配置。其中系统配置为数据库、缓存相关配置，业务配置即为非数据库相关配置。配置中心采用的是key-value一一对应的关系展示，并存入数据库中。具体实现是在发布生产之前管理员登录配置中心，将应用的所有测试环境配置项上传至配置中心，然后修改相应配置项为生产配置(内部应用调用的配置测试和生产一致，无须修改)，数据库相关配置是由数据库管理员修改，并且修改完之后的配置value对于开发是不可见的，保证了数据库读写账号密码的安全。当发布脚本调用配置获取子单元2043，配置获取子单元2043将去指定目录获取相应的配置包。

配置替换子单元2044，用于替换所述应用服务程序的配置包为配置获取子单元2043获取的所述待更新应用服务程序的配置包。

代码替换子单元2045用于将后端服务器300中存储的应用服务程序代码包替换为代码获取子单元2042获取到的待更新应用服务程序的代码包。具体地，代码替换子单元2045拷贝代码获取子单元2042获取的代码包，并将其存放至指定路径，覆盖原有的代码包，即完成了待更新应用服务程序的代码包替换。

已更新标识添加单元205用于为已经替换了应用服务程序代码包的后台服务器添加已更新标识，在本实施例中，操作nginx配置文件，将down标记去掉，并添加一个已更新标记。

服务加载单元206用于加载上线更新后的应用服务程序，在本实施例中，nginx重新加载(即reload)配置，nginx接收到该信号后判断member可以上线提供服务，该member可以继续接受用户请求。以此类推，直至完成整个服务器集群的应用服务程序发布更新。

所述应用服务更新装置200还包括报警单元207。报警单元207在应用服务程序下线之前关闭报警，并且在应用服务程序上线之后开启报警。开启报警后，报警单元207可在应用服务程序运行出现故障时发出警报，例如可以通过网络发送短信或邮件通知管理员等。

报警单元207还用于在上述任何一个功能单元出现运行故障时或验证错误时(例如，所述发布者没有通过身份验证单元202的身份验证)，通过网络发送短信或邮件通知管理员进行警示提醒。

第二实施例，请参阅图6，图6显示了本实施例提供的一种应用服务更新方法的流程图。

步骤s101：接收应用服务更新指令。所述更新应用服务程序的指令可以是用户直接向所述前端服务器100下达的指令，也可以是管理员通过用户端400向服务器下达的更新应用服务程序的指令。所述指令可以包括：待更新应用服务程序的存储路径信息，版本信息，待更新应用服务程序的配置信息以及待更新应用服务程序的代码包的地址信息等。此步骤可以由指令接收单元201执行。

步骤s102：依据所述更新指令，对未标记已更新标识的后端服务器300添加待更新标识。在本实施例中，服务器集群使用的是tengine，在tengine中，通过操作修改nginx的upstream配置文件来为后端服务器300添加待更新标识，在tengine中，后端服务器300可以称作member，tengine的健康检查机制是会按照一定的时间间隔像各个member发起健康检查的请求，并会记录member返回的状态。整个发布过程是串行的，在发布每一台member之前，通过发布脚本修改upstream.conf文件，将web-appname-1标记为down，此即为本实施例中的待更标识。此步骤可以由待更新标识添加单元203执行。

步骤s103：验证发布信息，请参阅图7，步骤s103包括子步骤s1031-s1032：

子步骤s1031：验证发布者的身份；通过账号、密码等方式对发布者进行身份的验证，当发布者无法通过身份验证时，无法进行后续的发布操作。此步骤可以由身份验证子单元2011执行。

子步骤s1032：验证发布次数，验证当前的应用服务程序在更新发布日的发布更新次数，在发布日的发布更新的次数不能超过预设的次数(例如3次)，否则不允许继续后续的更新发布操作。此步骤可以由发布次数验证单元202执行

当所述验证发布者身份及验证发布次数均通过后方进行步骤s104。

步骤s104：更新存储在标记有所述待更新标识的后端服务器300的应用服务程序。请参阅图8，步骤s104分为子步骤s1041-s1045。

子步骤s1041：下线存储在所述有待更新标识的后端服务器300的应用服务程序。在本实施例中，nginx每隔一段时间会进行重新加载(reload)，nginx检测到该member标记为down时，会在当前连接处理完成之后，不再接收新的请求，即该member完成当前的处理操作之后即会处于离线状态。此步骤可以由服务下线子单元2041执行。

子步骤s1042：获取存储在版本管理服务器的待更新应用服务程序代码包。在本实施例中，借助jenkins，实现代码编译打包，不再由开发人员本地打包，只需提供最新代码的svn路径，由测试人员直接在jenkins管理平台上点击构建即可完成应用的打包，只需提供代码包的路径，即可获取到待更新应用服务程序的代码包，这个过程减轻了开发人员的压力，也避免了因为手动打包过程中的失误而造成应用包不可用，使得应用上线流程更加顺利。此步骤可以由代码获取子单元2042执行。

子步骤s1043：获取所述待更新应用服务程序的配置包。此步骤可以由配置获取子单元2043执行，当调用配置获取子单元2043时，配置获取子单元2043将去指定目录获取相应的配置包。

子步骤s1044：替换所述应用服务程序的配置包为所述待更新应用服务程序的配置包。此步骤可以由配置替换子单元2044执行，配置替换子单元2044替换所述应用服务程序的配置包为配置获取子单元2043获取的所述待更新应用服务程序的配置包。

子步骤s1045：替换应所述用服务程序代码包为待更新应用服务程序代码包。具体地，首先拷贝获取的代码包，并将其存放至指定路径，覆盖原有的代码包，即完成了待更新应用服务程序的代码包替换。此步骤可以有代码替换子单元2045执行。

在步骤s1045之前，还包括步骤s1033：验证所述代码包的正确性。通过验证代码包的名称、大小、编号、md5码等来验证所述代码包是否为正确、完整的代码包，该步骤可以由代码包验证子单元2014执行。

步骤s105：对存储有更新后的应用服务程序的后端服务器300添加已更新标识。在本实施例中，操作nginx配置文件，将down标记去掉，并添加一个已更新标记。该步骤可以由已更新标识添加单元205执行。

步骤s105：加载上线所述更新后的应用服务程序。在本实施例中，nginx重新加载(即reload)配置，nginx接收到该信号后判断member可以上线提供服务，该member可以继续接受用户请求。该步骤可以由服务加载单元206执行。

综上所述，本发明公开的一种应用服务更新发布方法及装置，应用于一服务器集群，所述服务器集群包括前端服务器以及后端服务器，在其更新发布的过程中，各个后端服务器的更新串行进行，各后端服务器之间互不干扰，不会中断提供的服务，用户不会感知到更新发布的过程，提升了用户体验，所述更新发布的过程均线上进行，避免了由于人工打包、修改配置等因素容易产生的不安全因素，确保了信息的安全，并且适用于大规模的应用更新上线场景。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本发明的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本发明各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

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

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

以上所述仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。