本申请涉及计算机技术领域，并且更具体地，涉及一种微服务的升级方法与升级装置。
背景技术：
微服务(Microservice)系统是当前互联网非常流行的云化分布式系统。微服务是指功能上高内聚、低耦合，可独立开发、编译、测试、发布、部署、升级、运维的最小软件单元。
零中断业务升级是微服务系统的一个很重要的功能。零中断业务升级功能指的是，在一个微服务升级的整个过程中，该微服务可以对外提供连续不间断的业务响应能力。微服务系统具备了零中断业务升级功能后，可以在微服务升级过程中也能实现业务零中断。
实现业务零中断的根本在于，同一个微服务必须做到多服务实例部署，并且在升级该微服务时，对该微服务的多个服务实例按照时间先后顺序至少做两次升级，保证在每次升级时都有“活着”的微服务实例可以向用户提供业务响应服务。应理解，同一微服务的不同微服务实例提供完全一致的功能。
在微服务系统中，部署微服务实例的载体可以称为节点，具体地，该节点可以是操作系统或虚拟机。例如，分别在节点1、节点2和节点3上部署微服务1的服务实例，即实现了微服务1的多服务实例部署。
当前技术中，在升级一个微服务时，对该微服务部署的节点按照时间先后顺序一个接一个依次进行升级。例如，微服务1分别在节点1、节点2和节点3上部署了微服务实例，在升级该微服务1时，首先升级节点1上的微服务实例，与此同时，利用节点2和/或节点3上的微服务实例向用户提供业务响应；完成节点1上微服务实例的升级后，升级节点2上的微服务实例，与此同时，利用节点1和/或节点3上的微服务实例向用户提供业务响应；完成节点2上微服务实例的升级后，升级节点3上的微服务实例，与此同时，利用节点1和/或节点2上的微服务实例向用户提供业务响应。
上述可知，现有的微服务升级方案缺乏对微服务升级的有效管理，例如，面对大批量需要升级的微服务时，不便于升级管理。
技术实现要素：
本申请提出一种微服务的升级方法与升级装置，能够较好地实现微服务的升级管理，从而可以提高微服务升级的整体效率。
第一方面，提供一种微服务的升级方法，其特征在于，包括：确定待升级的至少一个微服务；确定所述至少一个微服务部署的至少两个节点；根据升级策略，将所述至少两个节点划分为具有不同优先级的多个组，其中，每个组包括按照所述升级策略确定的至少一个节点，所述至少一个微服务中同一个微服务部署的节点至少属于所述多个组中的两个组；按照所述多个组的优先级，对所述至少一个微服务进行升级。
在本方案中，根据升级策略，将待升级的微服务部署的节点划分为具有不同优先级的多个组，换句话说，根据该升级策略确定该多个组的组数(即升级的次数)，根据该升级策略确定每一组的节点(即每次升级的节点以及节点数)，相对于现有技术只是逐节点地升级微服务，本申请提供的方案能够较好地实现微服务的升级管理，从而可以提高微服务升级的整体效率。
结合第一方面，在第一方面的一种可能的实现方式中，该升级策略可以为下列策略中的任一种：业务性能优先策略，升级效率优先策略与最小升级批次策略。
具体地，该业务性能优先策略的宗旨是，在微服务升级过程中以保障业务性能为前提，将微服务升级对业务性能的影响降低到最小。该升级效率优先策略的宗旨是，在微服务升级过程中首要考虑升级效率。该最小升级批次策略的宗旨是，在微服务升级过程中尽量减小升级的次数。
结合第一方面，在第一方面的一种可能的实现方式中，所述升级策略为业务性能优先策略，所述根据升级策略，将所述至少两个节点划分为具有不同优先级的多个组，包括：根据所述业务性能优先策略，将所述至少两个节点划分为所述多个组，其中，第一组的优先级高于第二组的优先级，所述第一组的节点的活跃度低于所述第二组的节点的活跃度，所述活跃度用于指示节点的业务繁忙程度。
在本方案中，将活跃度较高的节点划分到优先级较高的组中，将活跃度较低的节点划分到优先级较低的组中，换句话说，微服务升级时，先升级活跃度较低的节点，后升级活跃度较高的节点，从而可以在一定程度上降低微服务升级对业务性能的影响。
可选地，在一种可能的实现方式中，所述升级策略为业务性能优先策略，该多个组中的每个组只包括一个节点。
在本方案中，所述升级策略为业务性能优先策略，每次升级只升级一个节点，并且先升级活跃度较低的节点，后升级活跃度较高的节点，这样可以实现将微服务升级对业务性能的影响降低到最小。
结合第一方面，在第一方面的一种可能的实现方式中，所述升级策略为升级效率优先策略，所述根据升级策略，将所述至少两个节点划分为具有不同优先级的多个组，包括：根据所述升级效率优先策略，将所述至少两个节点划分为所述多个组，其中，所述至少两个节点中升级时长大于第一阈值的节点被划分到所述多个组中的同一组。
在本方案中，根据升级效率优先策略将待升级的微服务部署的节点划分为多个组，然后按照该多个组的优先级，对待升级的微服务进行升级，可以有效提高微服务升级的升级效率。
结合第一方面，在第一方面的一种可能的实现方式中，所述升级策略为最小升级批次策略，所述根据升级策略，将所述至少两个节点划分为具有不同优先级的多个组，包括：根据所述最小升级批次策略，将所述至少两个节点划分为所述多个组，其中，所述多个组的组数小于第二阈值。
作为一种可能的实现方式中，所述第二阈值等于2。
在本方案中，根据最小升级批次策略将待升级的微服务部署的节点划分为多个组，然后按照该多个组的优先级，对待升级的微服务进行升级，相比于现有技术，能够减少微服务升级的次数。
结合第一方面，在第一方面的一种可能的实现方式中，在业务繁忙的情况下，所述升级策略被确定为所述业务性能优先策略；或在业务空闲的情况下，所述升级策略被确定为所述升级效率优先策略；或在不关心业务性能或升级效率的情况下，所述升级策略被确定为所述最小升级批次策略。
在本方案中，通过在不同应用场景下采用不同的升级策略升级微服务，从而可以实现对微服务升级的合理管理。
结合第一方面，在第一方面的一种可能的实现方式中，所述升级方法还包括：在用户界面上呈现第一区域，所述第一区域包括用于用户选择的备选升级策略，所述备选升级策略包括业务性能优先策略，升级效率优先策略与最小升级批次策略；根据用户对所述备选升级策略的选择结果，确定所述升级策略。
在本方案中，通过在用户界面呈现升级策略，使得用户可以根据需求选择合适的升级策略，然后根据用户选择的升级策略执行微服务的升级，能够提供微服务升级的用户满意度。
结合第一方面，在第一方面的一种可能的实现方式中，所述至少两个节点包括三个或三个以上的节点，所述多个组中的至少一个组包括两个或两个以上的节点。
相对于现有技术中逐节点地升级微服务，本方案能够提高微服务升级的效率。
结合第一方面，在第一方面的一种可能的实现方式中，所述确定待升级的至少一个微服务，包括：在用户界面上呈现第二区域，所述第二区域用于用户输入需要升级的微服务；根据用户在所述第二区域的输入信息，确定所述至少一个微服务。
优选地，所述第二区域包括用于用户选择需要升级的微服务的备选微服务。
在本方案，通过用户界面实现与用户交互，根据用户输入信息来确定待升级的微服务，并且在用户界面呈现待升级的微服务，使得管理人员可直观地看到待升级的微服务，可以提高微服务升级的用户满意度。
结合第一方面，在第一方面的一种可能的实现方式中，所述升级方法还包括：在用户界面呈现第三区域，并在所述第三区域内呈现所述多个组。
结合第一方面，在第一方面的一种可能的实现方式中，所述第三区域设置有用户编辑模式，所述升级方法还包括：检测所述第三区域进入所述用户编辑模式；在所述用户编辑模式下，获取用户对所述多个组的编辑结果；所述按照所述多个组的优先级对所述至少一个微服务进行升级，包括：根据用户对所述多个组的编辑结果，对所述至少一个微服务进行升级。
在本方案中，在用户界面呈现待升级的多个组(即升级批次)，使得用户直观地看到微服务升级时各个节点的升级顺序与分组，同时允许用户对该升级顺序与分组进行编辑，从而可以有效提高微服务升级的用户满意度。
第二方面，提供一种微服务的升级装置，该升级装置用于执行上述第一方面或第一方面的任一可能的实现方式中的方法。具体地，该升级装置可以包括用于执行第一方面或第一方面的任一可能的实现方式中的方法的模块。
第三方面，提供一种微服务的升级装置，该升级装置包括存储器和处理器，该存储器用于存储指令，该处理器用于执行该存储器存储的指令，并且对该存储器中存储的指令的执行使得该处理器执行第一方面或第一方面的任一方面的可能实现方式中的方法。
第四方面，提供一种微服务升级管理系统，该微服务升级管理系统包括通信接口与第二方面或第三方面提供的微服务的升级装置，该升级装置通过该通信接口与外部调用模块通信，以及与微服务部署的节点进行通信。
综上所述，在本方案中，根据升级策略，将待升级的微服务部署的节点划分为具有不同优先级的多个组，换句话说，根据该升级策略确定该多个组的组数(即升级的次数)，根据该升级策略确定每一组的节点(即每次升级的节点以及节点数)，相对于现有技术只是逐节点地升级微服务，本申请提供的方案能够较好地实现微服务的升级管理，从而可以提高微服务升级的整体效率。
附图说明
图1是微服务系统的架构示意图。
图2是现有技术中微服务升级的示意图。
图3是本发明实施例提供的微服务的升级方法的示意性流程图。
图4是本发明实施例提供的用户界面的示意图。
图5是本发明实施例提供的微服务的升级装置的示意性框图。
图6是本发明实施例提供的微服务的升级装置的另一示意性框图。
图7是本发明实施例提供的微服务升级管理系统的示意性框图。
图8是本发明实施例提供的微服务升级管理系统的另一示意性框图。
具体实施方式
下面将结合附图，对本发明实施例中的技术方案进行描述。
为了便于理解与描述本发明实施例，下文首先结合图1描述微服务系统的架构。
图1为微服务系统的架构示意图。微服务系统可以包括多个微服务，在图1中，以微服务系统包括微服务1、微服务2与微服务3为例进行说明。同一个微服务可以在多个节点上部署微服务实例。如图1所示，微服务1分别在节点1与节点2上部署服务实例1，微服务2分别在节点1与节点2上部署服务实例2，微服务3分别在节点1与节点2上部署服务实例3。
微服务部署的节点可以是服务器，也可以是虚拟机，或者是其他运行有操作系统的主机。
同一个微服务部署在多个节点上的微服务实例可以独立对外提供服务。同一个微服务的多个微服务实例可以做负载均衡，以提高业务性能和可靠性。例如，在高峰期可以启动同一微服务的更多的微服务实例为用户提供服务，以此提高业务响应速度，从而提高系统性能。再例如，当一个微服务的某个实例发生故障后，该微服务的其他实例可以接替其工作，对外表现为某个设备故障后业务不中断，从而提高系统可靠性。
如图1所示，微服务系统还包括Nginx，Nginx是一款轻量级的Web服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器。在微服务系统中，Nginx作为一个统一的系统入口。当一个新的微服务上线时，该新的微服务可以动态地注册到Nginx上，用户每次访问微服务系统时，可以从Nginx上获取微服务系统内所有微服务的访问地址。应理解，Nginx也可以看作是处理外部请求的路由模块。
零中断业务升级是微服务系统的重要功能，零中断业务升级功能指的是，在一个微服务升级的整个过程中，该微服务可以对外提供连续不间断的业务响应能力。
具体地，图2示出微服务升级的示意性流程图。以微服务1升级为例，零中断业务升级的步骤如下：
211，节点1上的微服务实例1向节点1的路由管理模块申请注销路由信息。
具体地，节点1上的路由管理模块用于管理节点1上微服务实例的注册或注销。
应理解，微服务系统中的每个节点上都包括该路由管理模块。
212，节点1的路由管理模块删除节点1上微服务实例1的路由信息，并通知Nginx清除节点1上微服务实例1的路由信息。
步骤211与步骤212可以称为节点1上微服务实例1的摘机过程。
213，节点1上的微服务实例1升级到微服务实例1’。
应理解，步骤213中的升级过程包括节点1上用于处理微服务1的进程的重启操作。
214，微服务实例1’向节点1的路由管理模块申请注册路由信息。
具体地，系统调用该路由管理模块的注册路由接口，申请注册节点1上服务实例1’的路由信息。
215，节点1上的路由管理模块增加节点1上微服务实例1’的路由信息，并通知Nginx增加节点1上微服务实例1’的路由信息。
步骤214与步骤215可以称为节点1上微服务实例1的挂机过程。
完成节点1上的微服务实例1的升级之后，继续按照上述步骤211至步骤215执行节点2上的微服务实例1的升级。如果微服务1仅在节点1与节点2上部署了微服务实例1，则完成节点2上的微服务实例1的升级后，即完成微服务1的升级。如果微服务1除了节点1与节点2，还在其他节点上部署了微服务实例1，则在完成节点2上的微服务实例1的升级之后，继续按照上述步骤211至步骤215执行其他节点上的微服务实例1的升级，直至完成微服务1部署的所有节点上的微服务实例1之后，才算完成微服务1的升级。
在节点1上的微服务实例1的升级过程中，微服务系统针对系统外部调用请求的响应流程为：
221，Nginx获取系统外部调用模块发送的业务请求，在图2中，以该业务请求针对微服务1为例进行说明。
222，Nginx将该业务请求转发到节点2上的微服务实例1。
应理解，由于在节点1上的微服务实例1升级之前，Nginx已经清除了节点1上微服务实例1的路由信息，因此，当Nginx接收到该业务请求后，不会向节点1上的微服务实例1转发该业务请求，而是向微服务1部署在节点2上的微服务实例1转发该业务请求。应理解，如果微服务1除了节点1与节点2之外，还在其他节点上部署了微服务实例1，则Nginx还可以向其他节点转发该业务请求。
223，节点2上的微服务实例1响应该业务请求，并将响应内容发送给Nginx。
224，Nginx将节点2上的微服务实例1的响应内容转发给系统外部调用模块。
从上述步骤可知，在微服务1的升级过程中，总有“活的”实例可以提供业务响应，从而实现了零中断业务升级。
当前技术中，微服务的零中断业务升级方案均是逐个节点进行升级。假设微服务1在节点1、节点2与节点3上分别部署了微服务实例1，在现有的零中断业务升级方案中，首先对节点1上的微服务实例1进行升级(例如按照图2中所示的步骤211至步骤215进行升级)，完成节点1上的微服务实例1的升级后，再对节点2上的微服务实例1进行升级，完成节点2上的微服务实例1的升级后，再对节点3上的微服务实例1进行升级，完成节点3上的微服务实例1的升级后，即完成微服务1的升级。
上述可知，现有的零中断业务升级方案，只是逐一节点地进行微服务升级，对微服务升级没有合理的管理。例如，当用户要求降低微服务升级对业务性能的影响时，或者用户要求提高微服务升级的升级效率时，现有的零中断业务升级方案均不能很好地满足。再例如，当大量微服务需要升级时，或者一个微服务在大量节点上部署了微服务实例，现有的零中断升级方案严重降低了微服务的升级效率。
针对上述技术问题，本发明实施例提出一种微服务的升级方法与升级装置，能够实现对微服务升级的有效管理。
图3为本发明实施例的微服务的升级方法300的示意性流程图。该升级方法300例如可以由微服务系统中的控制节点执行，该控制节点可以为物理节点，也可以为虚拟节点。如图3所示，该升级方法300包括：
310，确定待升级的至少一个微服务。
具体地，接收外部模块发送的业务请求，通过该业务请求确定待升级的至少一个微服务。应理解，外部模块是相对于微服务系统来说的，指的是微服务系统之外的模块。例如，用户可以通过该外部模块向微服务系统发送业务请求。
在本发明实施例中，待升级的至少一个微服务可以是一个微服务，也可以是多个微服务。
320，确定该至少一个微服务部署的至少两个节点。
该至少两个节点指的是部署有该至少一个微服务的微服务实例的节点。例如，微服务1分别在节点1、节点2与节点3上部署微服务实例1，微服务2分别在节点2、节点3、节点4与节点5上部署微服务实例2，微服务3分别在节点1、节点3与节点6上部署微服务实例3。假设待升级的该至少一个微服务包括微服务1、微服务2与微服务3，则该至少两个节点包括节点1、节点2、节点3、节点4、节点5与节点6。
330，根据升级策略，将该至少两个节点划分为具有不同优先级的多个组，其中，每个组包括按照该升级策略确定的至少一个节点，该至少一个微服务中同一个微服务部署的节点至少属于该多个组中的两个组。
具体地，将该至少两个节点划分为多个组，该多个组具有不同的优先级，这里的优先级指的是升级的先后顺序，即优先级高的组先升级，优先级低的组在优先级高的组完成升级之后再升级。需要说明的是，同一组的节点并行升级。例如，该多个组中的某个组包括节点1，节点2与节点3，轮到升级该某个组时，节点1，节点2与节点3并行升级。
需要说明的是，与现有技术中每次只对一个节点进行升级不同，本发明实施例中的每个组包括根据该升级策略确定的至少一个节点，并不绝对限定一个组只包括一个节点，只要符合升级策略，可以包括一个节点或多个节点。
具体地，该升级策略可以为下列策略中的任一种：业务性能优先策略，升级效率优先策略与最小升级批次策略。
具体地，该业务性能优先策略的宗旨是，在微服务升级过程中以保障业务性能为前提，将微服务升级对业务性能的影响降低到最小。该升级效率优先策略的宗旨是，在微服务升级过程中首要考虑升级效率。该最小升级批次策略的宗旨是，在微服务升级过程中尽量减小升级的次数。应理解，为了保证业务零中断，升级的次数至少为两次，如果选择最小升级批次策略作为升级策略，可以将升级次数确定为2，即将该至少两个节点划分为两个组。
在本发明实施例中，在将该至少两个节点划分为具有不同优先级的多个组时，需要保证该至少一个微服务中同一个微服务部署的节点至少属于该多个组中的两个组，换句话说，待升级的同一个微服务部署的所有节点不能分到同一组中。应理解，只有这样才能保证微服务升级的业务零中断。
为了便于描述，下文中采用“业务零中断条件”的描述来表达该至少一个微服务中同一个微服务部署的节点至少属于该多个组中的两个组。
340，按照该多个组的优先级，对该至少一个微服务进行升级。
具体地，按照该多个组的优先级从高到低的顺序，依次对每个组的节点进行升级，其中，同一组的节点并行升级。
应理解，本文中提及的对节点进行升级，均指的是对待升级的微服务在该节点上部署的微服务实例进行升级。
具体地，对微服务实例的升级过程可以参考上文结合图2描述的步骤211至步骤215，为了简洁，这里不再赘述。
需要说明的是，将待升级的至少一个微服务部署的至少两个节点划分为具有不同优先级的多个组，也可以表述为，生成该至少一个微服务的升级批次，这里的升级批次指的是具有不同优先级的多个组。例如，当该多个组为两个组时，表示微服务升级分两个批次完成；当该多组为三个或三个以上的组时，表示微服务升级分三个或三个以上的批次完成。
因此，在本发明实施例中，根据升级策略，将待升级的微服务部署的节点划分为具有不同优先级的多个组，换句话说，根据该升级策略确定该多个组的组数(即升级的次数)，根据该升级策略确定每一组的节点(即每次升级的节点以及节点数)，相对于现有技术只是逐节点地升级微服务，本发明实施例能够较好地实现微服务的升级管理，从而可以提高微服务升级的整体效率。
可选地，在一些实施例中，该至少两个节点包括三个或三个以上的节点，该多个组中的至少一个组包括两个或两个以上的节点。
相对于现有技术中逐节点地升级微服务，本发明实施例能够提高微服务升级的效率。
可选地，在一些实施例中，该升级策略为业务性能优先策略，330根据升级策略，将该至少两个节点划分为具有不同优先级的多个组，包括：根据该业务性能优先策略，将该至少两个节点划分为该多个组，其中，第一组的优先级高于第二组的优先级，该第一组的节点的活跃度低于该第二组的节点的活跃度，该活跃度用于指示节点的业务繁忙程度。
具体地，业务性能优先策略的宗旨在于，在满足业务零中断条件下，将微服务升级对业务性能的影响降到最小。
在本发明实施例中，将活跃度较高的节点划分到优先级较高的组中，将活跃度较低的节点划分到优先级较低的组中，换句话说，微服务升级时，先升级活跃度较低的节点，后升级活跃度较高的节点，从而可以在一定程度上降低微服务升级对业务性能的影响。
例如，待升级的该至少一个微服务包括微服务1、微服务2与微服务3。微服务1分别在节点1、节点2与节点3上部署微服务实例1，微服务2分别在节点2、节点3、节点4与节点5上部署微服务实例2，微服务3分别在节点1、节点3与节点6上部署微服务实例3。即该至少一个微服务部署的该至少两个节点包括节点1、节点2、节点3、节点4、节点5与节点6。假设节点1、节点2、节点3、节点4、节点5与节点6按照活跃度从高到低的排序为，节点1>节点2>节点3>节点5>节点4>节点6。可以将节点1、节点2、节点3、节点4、节点5与节点6划分为以下三组：
第一组，节点4，节点5，节点6。
第二组，节点3，节点2。
第三组，节点1。
其中，第一组的优先级高于第二组的优先级，第二组的优先级高于第三组的优先级。则在执行微服务升级时，先并行升级节点4、节点5与节点6，然后并行升级节点2与节点3，最后升级节点1。
还应理解，一个组包括的节点的数量越多，说明在对这个组升级时，并行升级的节点越多，意味着对业务性能的影响程度越大。反之，如果一个组包括的节点的数量越少，说明在对这个组升级时，并行升级的节点越少，意味着对业务性能的影响程度越小。因此，当该至少两个节点中活跃度超过系统阈值的节点占大多数，或者，该至少两个节点中所有节点的活跃度均超过该系统阈值，说明当前业务非常繁忙，这种情况下，可以进一步减少每个组中节点的个数，优选地，每个组只包括一个节点，即每次升级只升级一个节点，而且，是先升级活跃度较低的节点，后升级活跃度较高的节点，这样可以实现将微服务升级对业务性能的影响降低到最小。
应理解，本发明实施例中提及的系统阈值指的是能够表征业务繁忙程度高的活跃度的值，可以系统预定义。
假设上述例子中的节点1、节点2、节点3、节点4、节点5与节点6的活跃度均超过系统阈值，则将节点1、节点2、节点3、节点4、节点5与节点6划分为以下6组：
第一组，节点6；第二组，节点4；第三组，节点5；第四组，节点3；第五组，节点2；第六组，节点1。从第一组到第六组，优先级逐个降低。
因此，在本发明实施例中，根据业务性能优先策略将待升级的微服务部署的节点划分为多个组，然后按照该多个组的优先级，对待升级的微服务进行升级，可以有效降低微服务升级对业务性能的影响。
在升级策略为业务性能优先策略的实施例中，也可以认为是根据该至少两个节点的活跃度，将该至少两个节点划分为该多个组。
具体地，一个节点的活跃度可以根据该节点的下列指标中的任一个指标的量化值或多个指标的加权值确定：处理器使用率(下文简称为cpu使用率)、内存使用率(下文简称为mem使用率)、输入/输出(Input/Output，IO)接口使用率(下文简称为IO使用率)、以及外部访问量。
需要说明的是，上述cpu使用率、mem使用率、IO使用率以及外部访问量都是时间相关的物理量。具体地，该cpu使用率可以是预设时间段内的cpu使用率，该mem使用率可以是预设时间内的mem使用率，该IO使用率可以是预设时间内的IO使用率，该外部访问量可以是单位时间内的外部访问量。
应理解，一个节点的活跃度与该节点的cpu使用率、mem使用率、IO使用率以及外部访问量均是正相关的。
可选地，在该升级策略为业务性能优先策略的实施例中，330根据升级策略，将该至少两个节点划分为具有不同优先级的多个组，包括：根据该业务性能优先策略对应的升级效用函数，得到该多个组的划分信息；根据该多个组的划分信息，将该至少两个节点划分为具有不同优先级的多个组。
具体地，通过求解该业务性能优先策略对应的升级效用函数的最优解，得到该多个组的划分信息。该业务性能优先策略对应的升级效用函数的最优解指的是，使得该多个组的升级对业务性能的影响最小时，该多个组的划分信息。
作为示例而非限定，该升级效用函数为如下公式(1)所示：
其中，policy表示升级策略，在本实施例中为业务性能优先策略。x表示该至少两个节点。表示评估节点活跃度的函数，Rcpu表示节点的cpu使用率，Rmem表示节点的内存使用率，Rio表示节点的IO使用率，Rreq表示节点的外部访问量，t表示Rcpu、Rmem、Rio与Rreq的时间，应理解，是时间相关的函数。
应理解，升级策略policy为业务性能优先策略时的升级效用函数在量化效用时侧重的是业务性能。
还应理解，当升级策略policy不同时，公式(1)表示的升级效用函数在量化效用时的侧重点不同。例如，当升级策略policy为升级效率优先策略时的升级效用函数在量化效用时侧重的是升级时长。
在实际应用中，可以对公式(1)作具体地完善与细化，本发明实施例对此不作限定。
可选地，作为一种实现方式，可以通过下文提供的代码上实现根据业务性能优先策略，将该至少两个节点划分为该多个组，具体请参见注释“#批次生成算子一：业务性能优先策略”对应的代码。
可选地，在一些实施例中，该升级策略为升级效率优先策略，330根据升级策略，将该至少两个节点划分为具有不同优先级的多个组，包括：根据该升级效率优先策略，将该至少两个节点划分为该多个组，其中，该至少两个节点中升级时长大于第一阈值的节点被划分到该多个组中的同一组。
具体地，该第一阈值可以系统预定义，可以认为升级时长大于该第一阈值的节点为升级时长较长的节点，升级时长小于该第一阈值的节点为升级时长较短的节点。
具体地，该升级效率优先策略的宗旨是，在满足业务零中断条件下，使得微服务升级的升级时长最短。
应理解，由于同一组的节点并行升级，因此一个组的升级时长以该组中升级时长最长的节点为准。可知，将升级时长较长的节点划分到同一组进行并行升级，可以有效地减少微服务升级总时长。
具体地，在本发明实施例中，根据该升级效率优先策略，将该至少两个节点划分为该多个组的具体步骤如下：
首先，计算该至少两个节点的升级时长。
具体地，可以根据节点的活跃度估算该节点的升级时长，获得节点的活跃度的方法详见上文相关描述，这里不再赘述。
然后，从该至少两个节点中，找到升级时长最长的节点(记其升级时长为t1)，再从剩余节点中找到升级时长最长的节点，以此类推，直到找到无法满足业务零中断条件的第一个升级时长最长的节点(记其升级时长为t2)。将在无法满足业务零中断条件的第一个升级时长最长的节点之前找到的节点划分为第一组，将无法满足业务零中断条件的第一个升级时长最长的节点划分到第二组，该至少两个节点中的剩余节点可以都划分到第二组中。
按照上述方式，将该至少两个节点划分为该第一组与第二组，微服务升级的升级总时长为t1与t2之和。应理解，上述这种分组方式是所有分组方式中使得升级总时长最短的方式。
需要说明的是，在上述实施例中，如果将该至少两个节点中的剩余节点都划分到第二组中，出现无法满足业务零中断条件的情形，则继续增加新的划分组，以此类推。
优选地，在该升级策略为升级效率优先策略的实施例中，在满足业务零中断条件的前提下，将该至少两个节点中升级时长较长的节点划分到同一组，并将该多个组的组数降到最小(大于或等于2)。
例如，待升级的该至少一个微服务包括微服务1、微服务2与微服务3。微服务1分别在节点1、节点2与节点3上部署微服务实例1，微服务2分别在节点2、节点3、节点4与节点5上部署微服务实例2，微服务3分别在节点1、节点3与节点6上部署微服务实例3。即该至少一个微服务部署的该至少两个节点包括节点1、节点2、节点3、节点4、节点5与节点6。分别确定节点1、节点2、节点3、节点4、节点5与节点6的升级时长。假设节点1、节点2、节点3、节点4、节点5与节点6按照升级时长从长到短的排序为：节点1>节点3>节点6>节点2>节点4>节点5，其中，节点6的升级时长大于第一阈值，节点2的升级时长小于第一阈值。则可以将节点1、节点2、节点3、节点4、节点5与节点6划分为以下两组：
第一组，节点1，节点3，节点6。
第二组，节点2，节点4，节点5。
因此，在本发明实施例中，根据升级效率优先策略将待升级的微服务部署的节点划分为多个组，然后按照该多个组的优先级，对待升级的微服务进行升级，可以有效提高微服务升级的升级效率。
可选地，在该升级策略为升级效率优先策略的实施例中，330根据升级策略，将该至少两个节点划分为具有不同优先级的多个组，包括：根据该升级效率优先策略对应的升级效用函数，得到该多个组的划分信息；根据该多个组的划分信息，将该至少两个节点划分为具有不同优先级的多个组。
具体地，通过求解该升级效率优先策略对应的升级效用函数的最优解，得到该多个组的划分信息。该升级效率优先策略对应的升级效用函数的最优解指的是，使得该多个组的升级总时长最短的该多个组的划分信息。
作为示例而非限定，该升级效用函数如上述公式(1)所示，在本实施例中，policy表示升级效率优先策略。升级策略policy为升级效率优先策略时的升级效用函数在量化效用时侧重的是升级时长，且该多个组的升级总时长最短对应该升级效用函数的最优解。
在实际应用中，可以对公式(1)作具体地完善与细化，本发明实施例对此不作限定。
可选地，作为一种实现方式，可以通过下文提供的代码上实现根据升级效率优先策略，将该至少两个节点划分为该多个组，具体请参见注释“#批次生成算子二：升级效率优先策略”对应的代码。
可选地，在一些实施例中，该升级策略为最小升级批次策略，330根据升级策略，将该至少两个节点划分为具有不同优先级的多个组，包括：根据该最小升级批次策略，将该至少两个节点划分为该多个组，其中，该多个组的组数小于第二阈值。
具体地，该最小批次升级的宗旨是，在满足业务零中断条件下，使得升级的次数最少，即使得该多个组的组数最少。应理解，该最小批次升级并不保证业务性能或升级效率。
优选地，在本发明实施例中，该第二阈值等于2。
具体地，从该至少一个微服务中的每个微服务部署的节点中分别抽取一个节点放入第一组，该至少两个节点中的剩余节点的放入第二组，即在本实施例中，该多个组包括两组：第一组与第二组。
例如，待升级的该至少一个微服务包括微服务1、微服务2与微服务3。微服务1分别在节点1、节点2与节点3上部署微服务实例1，微服务2分别在节点2、节点3、节点4与节点5上部署微服务实例2，微服务3分别在节点1、节点3与节点6上部署微服务实例3。即该至少一个微服务部署的该至少两个节点包括节点1、节点2、节点3、节点4、节点5与节点6。将节点1、节点2、节点3、节点4、节点5与节点6划分为以下两组：
第一组，节点1，节点4，节点6。
第二组，节点2，节点3，节点5。
因此，在本发明实施例中，根据最小升级批次策略将待升级的微服务部署的节点划分为多个组，然后按照该多个组的优先级，对待升级的微服务进行升级，相比于现有技术，能够减少微服务升级的次数。
可选地，作为一种实现方式，可以通过下文提供的代码上实现根据最小升级批次策略，将该至少两个节点划分为该多个组，具体请参见注释“#批次生成算子三：最小升级批次策略”对应的代码。
通过上文对三种升级策略(业务性能优先策略，升级效率优先策略与最小升级批次策略)的描述可知，实际应用中，可以根据具体的应用场景或者应用需求，选择合适的升级策略来实现微服务的升级。
具体地，可以在业务繁忙的情况下，选择业务性能优先策略作为该升级策略；在业务空闲的情况下，选择升级效率优先策略作为该升级策略；在不必关心升级效率与业务性能的情况下，选择最小升级批次策略作为该升级策略。
在本发明实施例中，通过在不同应用场景下采用不同的升级策略升级微服务，从而可以实现对微服务升级的合理管理。
在本发明实施例中，根据升级策略将待升级的微服务部署的节点划分为多个组，按照该多个组的优先级，对待升级的微服务进行升级。相对于现有技术中逐个节点实现微服务的升级，本发明实施例能够在保障零中断业务升级的前提下实现较为高效、合理的微服务系统的升级。
可选地，在一些实施例中，该升级方法300还包括：在用户界面上呈现第一区域，该第一区域包括用于用户选择的备选升级策略，该备选升级策略包括业务性能优先策略，升级效率优先策略与最小升级批次策略；根据用户对该备选升级策略的选择结果，确定该升级策略。
具体地，如图4所示的用户界面，该第一区域如图4中所示的升级策略选择区。该升级策略选择区中呈现有备选升级策略，该备选升级策略包括业务性能优先策略、升级效率优先策略与最少升级批次策略。用户可以在想要选择的升级策略的右上角打对号，以表示其为最终选中的升级策略。
应理解，图4仅为示例而非限定，在升级策略选择区内，还可以将用户选中的升级策略的图标设置为高亮或者颜色发生变化，或其他标识形式。
可选地，在升级策略选择区中还可以设置创建新升级策略的图标，当创建新升级策略的图标被用户触发(如点击)时，用户界面弹出允许输入新的升级策略的对话框。
在本发明实施例中，通过在用户界面呈现升级策略，使得用户可以根据需求选择合适的升级策略，然后根据用户选择的升级策略执行微服务的升级，能够提供微服务升级的用户满意度。
可选地，在一些实施例中，310确定待升级的至少一个微服务，包括：在用户界面上呈现第二区域，该第二区域用于用户输入需要升级的微服务；根据用户在该第二区域的输入信息，确定该至少一个微服务。
优选地，该第二区域包括用于用户选择需要升级的微服务的备选微服务。
具体地，该第二区域例如为图4中所示的待升级微服务展示区。该待升级微服务展示区可以允许用户编辑待升级的微服务。该待升级微服务展示区包括用于呈现用户编辑后保存的待升级的微服务的区域，例如图4中所示的待升级微服务展示区内用于呈现待升级微服务1、待升级微服务2与待升级微服务3的区域。该待升级微服务展示区还允许用户删除已经在待升级微服务展示区呈现的微服务。具体地，如图4所示，当用户点击待升级微服务展示区内的待升级微服务1右上角的叉号图标时，该待升级微服务1从待升级微服务展示区中删除。
优选地，在该待升级微服务展示区内，还可以设置下拉菜单，该下拉菜单当被用户触发(例如单击或者双击)时，弹出微服务列表，该微服务列表中可以呈现微服务系统中的所有微服务，也可以呈现优先级满足阈值的部分微服务。具体地，该下拉菜单例如为图4中所示的待升级微服务展示区中的添加待升级微服务的图标。
具体地，将检测到用户保存了在待升级微服务展示区内的输入信息后，可以根据待升级微服务展示区内呈现的信息，确定待升级的该至少一个微服务。
在本发明实施例中，通过用户界面实现与用户交互，根据用户输入信息来确定待升级的微服务，并且在用户界面呈现待升级的微服务，使得管理人员可直观地看到待升级的微服务，可以提高微服务升级的用户满意度。
可选地，在一些实施例中，在340按照该多个组的优先级对该至少一个微服务进行升级之前，该升级方法300还包括：在用户界面呈现第三区域，并在该第三区域内呈现该多个组。
具体地，该第三区域如图4中所示的升级批次确认区，该升级批次确认区中呈现有与步骤330中确定的该多个组对应的升级批次。例如，在步骤330中的该多个组为两个组，且优先级较高的第一组包括节点1、节点2与节点4，优先级较低的第二组包括节点3与节点5，则在该升级批次确认区包括批次一与批次二的子区域，在批次1的子区域中呈现节点1、节点2与节点4，在批次1的子区域中呈现节点3与节点5。
可选地，在一些实施例中，该第三区域设置有用户编辑模式，该升级方法300还包括：检测该第三区域进入该用户编辑模式；在该用户编辑模式下，获取用户对该多个组的编辑结果；340按照该多个组的优先级对该至少一个微服务进行升级，包括：根据用户对该多个组的编辑结果，对该至少一个微服务进行升级。
具体地，升级管理员可以在第三区域内直观看到待升级的节点的升级批次，可以将该第三区域切换到用户编辑模式，编辑该升级批次。用户编辑完成后，可以用户保存编辑结果。在第三区域发生用户编辑的情况下，系统按照经过用户编辑更新后的升级批次，升级对应的节点。
在本发明实施例中，在用户界面呈现待升级的多个组(即升级批次)，使得用户直观地看到微服务升级时各个节点的升级顺序与分组，同时允许用户对该升级顺序与分组进行编辑，从而可以有效提高微服务升级的用户满意度。
因此，在本发明实施例中，通过图4所示的用户界面与用户交互，实现微服务升级，同时可以让用户或者管理人员可以直观地看到待升级的微服务、升级策略以及升级批次，能够提高微服务升级的用户体验满意度，从而可以在保障在零中断业务升级前提下做到更科学合理的微服务升级。
图5为本发明实施例提供的微服务的升级装置500的示意性框图。如图5所示，该升级装置500包括：
确定模块510，用于确定待升级的至少一个微服务；
该确定模块510还用于，确定该至少一个微服务部署的至少两个节点；
分组模块520，用于根据升级策略，将该至少两个节点划分为具有不同优先级的多个组，其中，每个组包括按照该升级策略确定的至少一个节点，该至少一个微服务中同一个微服务部署的节点至少属于该多个组中的两个组；
升级模块530，用于按照该多个组的优先级，对该至少一个微服务进行升级。
因此，在本发明实施例中，根据升级策略，将待升级的微服务部署的节点划分为具有不同优先级的多个组，换句话说，根据该升级策略确定该多个组的组数(即升级的次数)，根据该升级策略确定每一组的节点(即每次升级的节点以及节点数)，相对于现有技术只是逐节点地升级微服务，本发明实施例能够较好地实现微服务的升级管理，从而可以提高微服务升级的整体效率。
可选地，作为一个实施例，该升级策略为业务性能优先策略，该分组模块520具体用于，根据该业务性能优先策略，将该至少两个节点划分为该多个组，其中，第一组的优先级高于第二组的优先级，该第一组的节点的活跃度低于该第二组的节点的活跃度，该活跃度用于指示节点的业务繁忙程度。
可选地，作为一个实施例，该升级策略为升级效率优先策略，该分组模块520具体用于，根据该升级效率优先策略，将该至少两个节点划分为该多个组，其中，该至少两个节点中升级时长大于第一阈值的节点被划分到该多个组中的同一组。
可选地，作为一个实施例，该升级策略为最小升级批次策略，该分组模块520具体用于，根据该最小升级批次策略，将该至少两个节点划分为该多个组，其中，该多个组的组数小于第二阈值。
可选地，在该升级策略为最小升级批次策略的实施例中，该第二阈值等于2。
可选地，作为一个实施例，在业务繁忙的情况下，该升级策略被确定为该业务性能优先策略；或在业务空闲的情况下，该升级策略被确定为该升级效率优先策略；或在不关心业务性能或升级效率的情况下，该升级策略被确定为该最小升级批次策略。
可选地，作为一个实施例，该升级装置500还包括：
第一呈现模块，用于在用户界面上呈现第一区域，该第一区域包括用于用户选择的备选升级策略，该备选升级策略包括业务性能优先策略，升级效率优先策略与最小升级批次策略；
该确定模块还用于，根据用户对该备选升级策略的选择结果，确定该升级策略。
可选地，作为一个实施例，该至少两个节点包括三个或三个以上的节点，该多个组中的至少一个组包括两个或两个以上的节点。
可选地，作为一个实施例，该升级装置还包括：
第二呈现模块，用于在用户界面上呈现第二区域，该第二区域用于用户输入需要升级的微服务；
该确定模块具体用于，根据用户在该第二区域的输入信息，确定该至少一个微服务。
可选地，作为一个实施例，该第二区域包括用于用户选择需要升级的微服务的备选微服务。
可选地，作为一个实施例，该升级装置还包括：
第三呈现模块，用于在用户界面呈现第三区域，并在该第三区域内呈现该多个组。
可选地，作为一个实施例，该第三区域设置有用户编辑模式，该升级装置还包括：
检测模块，用于检测该第三区域进入该用户编辑模式；
获取模块，用于在该用户编辑模式下，获取用户对该多个组的编辑结果；
该升级模块具体用于，根据用户对该多个组的编辑结果，对该至少一个微服务进行升级。
具体地，本发明实施例提供的升级装置500可以为微服务系统中的控制节点，该控制节点可以为物理节点，也可以为虚拟节点。
还应理解，该升级装置500中的确定模块510、分组模块520，与升级模块530，具体地可以由处理器或处理器相关电路组件实现。
如图6所示，本发明实施例还提供了一种微服务的升级装置600，该升级装置600包括：处理器610与存储器620。处理器610与存储器620通过内部连接通路互相通信，传递控制和/或数据信号。存储器620用于存储指令，该处理器610用于执行该存储器620存储的指令。当存储器620中存储的指令被执行时，处理器610用于，确定待升级的至少一个微服务；确定该至少一个微服务部署的至少两个节点；根据升级策略，将该至少两个节点划分为具有不同优先级的多个组，其中，每个组包括按照该升级策略确定的至少一个节点，该至少一个微服务中同一个微服务部署的节点至少属于该多个组中的两个组；按照该多个组的优先级，对该至少一个微服务进行升级。
因此，在本发明实施例中，根据升级策略，将待升级的微服务部署的节点划分为具有不同优先级的多个组，换句话说，根据该升级策略确定该多个组的组数(即升级的次数)，根据该升级策略确定每一组的节点(即每次升级的节点以及节点数)，相对于现有技术只是逐节点地升级微服务，本发明实施例能够较好地实现微服务的升级管理，从而可以提高微服务升级的整体效率。
可选地，在一些实施例中，该升级策略为业务性能优先策略，处理器610具体用于，根据该业务性能优先策略，将该至少两个节点划分为该多个组，其中，第一组的优先级高于第二组的优先级，该第一组的节点的活跃度低于该第二组的节点的活跃度，该活跃度用于指示节点的业务繁忙程度。
可选地，在一些实施例中，该升级策略为升级效率优先策略，处理器610具体用于，根据该升级效率优先策略，将该至少两个节点划分为该多个组，其中，该至少两个节点中升级时长大于第一阈值的节点被划分到该多个组中的同一组。
可选地，在一些实施例中，该升级策略为最小升级批次策略，处理器610具体用于，根据该最小升级批次策略，将该至少两个节点划分为该多个组，其中，该多个组的组数小于第二阈值。
优选地，该第二阈值等于2。
可选地，在一些实施例中，在业务繁忙的情况下，该升级策略被确定为该业务性能优先策略；或在业务空闲的情况下，该升级策略被确定为该升级效率优先策略；或在不关心业务性能或升级效率的情况下，该升级策略被确定为该最小升级批次策略。
可选地，在一些实施例中，处理器610还用于，在用户界面上呈现第一区域，该第一区域包括用于用户选择的备选升级策略，该备选升级策略包括业务性能优先策略，升级效率优先策略与最小升级批次策略；根据用户对该备选升级策略的选择结果，确定该升级策略。
可选地，在一些实施例中，该至少两个节点包括三个或三个以上的节点，该多个组中的至少一个组包括两个或两个以上的节点。
可选地，在一些实施例中，处理器610还用于，在用户界面上呈现第二区域，该第二区域用于用户输入需要升级的微服务；处理器610具体用于，根据用户在该第二区域的输入信息，确定该至少一个微服务。
优选地，该第二区域包括用于用户选择需要升级的微服务的备选微服务。
可选地，在一些实施例中，处理器610还用于，在用户界面呈现第三区域，并在该第三区域内呈现该多个组。
优选地，该第三区域设置有用户编辑模式，处理器610还用于，检测该第三区域进入该用户编辑模式；在该用户编辑模式下，获取用户对该多个组的编辑结果；处理器610具体用于，根据用户对该多个组的编辑结果，对该至少一个微服务进行升级。
应理解，本发明实施例提供的微服务的升级装置600可以对应于本发明实施例提供的升级装置500，并且升级装置600中的各个模块的上述和其它操作和/或功能分别为了实现上述方法实施例中的相应流程，为了简洁，在此不再赘述。
应理解，本发明实施例中的处理器可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
还应理解，本发明实施例中的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data Rate SDRAM，DDRSDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(Synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DR RAM)。
需要说明的是，当处理器为通用处理器、DSP、ASIC、FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件时，存储器(存储模块)集成在处理器中。
如图7所示，本发明实施例还提出一种微服务升级管理系统700，该微服务升级管理系统700包括控制节点710与通信接口720。该控制节点710对应于本发明实施例提供的升级装置500或升级装置600。该通信接口720用于接收外部请求，并将该外部请求转发给该控制节点710，以便于该控制节根据该外部请求确定待升级的微服务，或者还可以根据该外部请求确定升级策略。该控制节点710通过该通信接口720通知对应的节点执行微服务升级。
具体地，该微服务升级系统700可以是客户机/服务器(Client/Server，C/S)结构或浏览器/服务器(Browser/Server，B/S)结构。
优选地，该微服务升级系统700可以提供如图4所示的用户界面，以便运维人员可以参与微服务的升级操作。
如图8所示，本发明实施例还提供了一种微服务升级管理系统800，该微服务升级管理系统800包括：
外部请求处理模块810，用于获取外部模块发送的请求，还用于向外部模块发送该请求的响应。该请求为微服务升级请求，该请求中指示了待升级的微服务，还可以携带用于指示升级策略的信息。
具体地，当该微服务升级管理系统800为C/S结构时，该外部模块可以是客户端。当该微服务升级管理系统800为B/S结构时，该外部模块可以是浏览器。
外部请求处理模块810还用于向升级批次生成算子模块840转发外部模块发送的请求。
微服务升级管理模块820，用于管理微服务系统的升级，还用于控制具体的升级流程。
具体地，微服务升级管理模块820，用于根据升级批次生成算子模块840生成的升级批次，该升级批次指的是将待升级的微服务部署的节点划分为多个组的分组信息。微服务升级管理模块820，还用于根据升级批次创建升级任务以及管理当前的升级任务进程等。
微服务状态缓存模块830，用于缓存微服务系统中各个微服务的部署状态。
具体地，微服务状态缓存模块830，用于定时采集或通过其他微服务查询各节点上部署的微服务实例的运行状态。
升级批次生成算子模块840，用于从外部请求处理模块810获取，待升级的微服务的信息，以及升级策略的信息，然后根据该升级策略生成对应的升级批次，即将待升级的微服务部署的节点划分为具有不同优先级的多个组。
具体地，该升级批次生成算子模块840根据微服务状态缓存模块830缓存的各个微服务的部署状态，确定待升级的微服务部署的至少两个节点；在满足业务零中断升级的前提下，根据升级策略将该至少两个节点划分为具有不同优先级的多个组，该多个组的信息即为升级批次。
该升级批次生成算子模块840可以存储有多个用于适配不同的升级策略的升级算子：例如，对应于业务性能优先策略的升级算子一、对应于升级效率优先策略的升级算子二、以及对应于最小升级批次策略的升级算子三。
为了便于更好地理解本发明实施例，下文提供了采用Python语言对本发明实施例提供的微服务升级管理系统800的一个简单实现，旨在展示该微服务升级管理系统800中的各功能模块以及各个功能模块之间的调用关系。由于重点在于实现微服务升级管理系统800，部分细节未给出详细代码(例如如何采集节点的活跃度指标等)。
还应理解，本文中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本发明实施例的范围。
应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
应理解，上述实施例中，各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的保护范围。
还应理解，在本申请提供的实施例中，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
以上所述，仅为本申请的具体实施方式，本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。