CN107463390A - 一种软件升级方法及升级服务器 - Google Patents

Abstract

一种软件升级方法及升级服务器，升级服务器获取用户提交的应用的版本；所述升级服务器对一个应用进行升级判决时，如确定需要将该应用的当前运行版本升级到该应用的最新版本，且该应用的升级依赖条件得到满足，则自动生成升级任务，所述升级任务包括对该应用升级。本申请实现了对软件升级合理、有效的管理，提高了软件升级的效率和成功率，减轻了用户的负担。

Description

一种软件升级方法及升级服务器

技术领域

本发明涉及计算机领域，更具体地，涉及一种软件升级方法及升级服务器。

背景技术

在大型的数据中心，服务器集群可以提供各种服务。文中，服务指提供一定功能的软件，例如，每个云产品都是一个服务。服务被部署到服务器集群上，提供相应的服务能力。服务可根据功能划分为一个或多个服务器角色(SR：Server Role)，每一个服务器角色是一个不可拆分的部署单元。服务器角色部署到服务器集群上的实例称为服务器角色实例，服务器角色实例是服务器上运行的服务中的某个功能组件。而应用(Application)是服务器角色中包含的每一个进程级服务组件，应用是软件升级的最小单位，每个应用独立工作，可以被部署到每一台服务器上。

软件升级是数据中心管理系统的重要任务之一，数据中心需要升级的应用很多，应用的版本更替也非常频繁，需要避免不必要的升级任务。而且。有些服务器角色中的应用工作时需要调用其他服务器角色的接口。因而即使一个应用自身完成升级，也可能因为调用失败而不能正常工作，这种调用关系变化时，升级的条件也会发生变化。目前，软件升级由用户触发，管理系统还缺乏对软件升级进行合理、有效管理的机制。对于其他软件升级的场景，也存在类似的问题。

发明内容

有鉴于此，本发明提供了以下方案。

一种软件升级方法，包括：

升级服务器获取用户提交的应用的版本；

所述升级服务器对一个应用进行升级判决时，如确定需要将该应用的当前运行版本升级到该应用的最新版本，且该应用的升级依赖条件得到满足，则自动生成升级任务，所述升级任务包括对该应用升级。

一种升级服务器，包括：

版本获取模块，用于获取用户提交的应用的版本；

升级判决模块，用于在对一个应用进行升级判决时，如确定需要将该应用的当前运行版本升级到该应用的最新版本，且该应用的升级依赖条件得到满足，则自动生成升级任务，所述升级任务包括对该应用升级。

上述方案能够根据应用的版本关系确定需要升级的应用，并根据应用的升级依赖条件自动生成升级任务，实现了对软件升级合理、有效的管理，提高了软件升级的效率和成功率，减轻了用户的负担。

附图说明

图1是本发明实施例一软件升级方法的流程图；

图2是本发明实施例一升级服务器的模块图；

图3是本发明示例性的数据中心的架构图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下文中将结合附图对本发明的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。

实施例一

在软件升级过程中，由于服务器角色之间的功能存在依赖，所以升级需要按照一定的顺序执行。

下面举例说明一下服务器角色之间的依赖关系及其对升级顺序的影响。假设存在服务器角色A和服务器角色B，服务器角色B中的应用要调用服务器角色A的接口。在某次升级过程中，如果新版本的服务器角色B的新功能需要调用新版本的服务器角色A新增加的接口(旧版本的服务器角色A尚不能提供这样的接口)，就要求先把服务器角色A成功升级到新版本后，才能进行服务器角色B的升级。在服务器角色A成功升级到新版本之后，服务器角色B成功升级到新版本之前，由于新版本的服务器角色A在提供新接口的同时会兼容旧版本的接口，因此旧版本的服务器角色B仍然能正确调用新版本的服务器角色A的接口。而如果先将服务器角色B成功升级到新版本，由于新版本的服务器角色B要调用新版本的服务器角色A的接口，而旧版本的服务器角色A没有提供该接口，会导致新版本的服务器角色B的调用失败而导致服务不正常。因而服务器角色A和服务器角色B均存在升级任务时，应当先升级服务器角色A，再升级服务器角色B。

当多个服务器角色升级的顺序确定之后，当且仅当前一个服务器角色升级成功后，才能进行下一个服务器角色的升级。如果前一个服务器角色升级失败，则升级过程将会被阻塞，不会启动对后续服务器角色的升级。即使因为软件修改等原因，依赖关系解除后，用户也需要重新启动对后续服务器角色的升级。当不同服务器角色之间相互依赖的关系越来越多时，会给运维带来很大的困难，并且效率也很低。

上文中，新版本的服务器角色A是指服务器角色A中部分或全部应用的版本是新的，服务器角色A的升级是指服务器角色A中的全部或部分应用升级，服务器角色A升级成功是指服务器角色A中参与升级的应用升级成功，服务器角色B也是如此。而服务器角色B调用服务器角色A的接口，也是服务器角色B中的应用具体执行的，也就是说，服务器角色B对服务器角色A的依赖，是服务器角色B中应用的升级依赖于服务器角色A。

此外，对某一个应用来说，用户提交的版本很多，一般来说，用户新提交的版本是用户想进行升级的版本。但是，用户新提交的版本可能会与之前升级过的版本相同，再次升级会给系统造成不必要的负担。因而需要提供一种校验的机制。

为此，本实施例提供一种软件升级方法，如图1所示，包括：

步骤110，升级服务器获取用户提交的应用的版本；

本实施例中，升级服务器是数据中心管理系统的组成部分，该管理系统还包括一个配置中心，用户可以通过该配置中心提供的接口向管理系统提交应用的版本，配置中心将接收的应用的版本保存后，升级服务器可以读取。但本发明不局限数据中心管理系统这一场景，如，用户也可以直接向升级服务器提交应用的版本。

用户一次可以提交一个或多个应用的版本，这些应用可以属于同一个服务器角色，也可以属于不同的服务器角色。管理系统可以为用户每次提交的一个或多个应用的版本生成一个唯一的提交版本号，提交版本号按照版本提交时间和编号规则顺序编号。该提交版本号可以用于应用的版本管理，如根据版本对应的提交版本号查找该版本的提交时间等信息。

步骤120，所述升级服务器对一个应用进行升级判决时，如确定需要将该应用的当前运行版本升级到该应用的最新版本，且该应用的升级依赖条件得到满足，则自动生成升级任务，所述升级任务包括对该应用升级。

文中，该应用的最新版本指用户最近一次提交的该应用的版本，这是在升级判决时进行版本的认定，因而这里所说的最近一次提交的该应用的版本是指本次升级判决之前用户最近一次提交的该应用的版本，本次升级判决之后，如果用户又提交了该应用的版本，则下次升级判决时认定的该应用的最新版本就不同于本次升级判决时认定的该应用的最新版本。

本实施例中，按照设定的判决周期启动升级判决，每次启动升级判决后，对最近一个判决周期内有版本提交的每一个应用进行升级判决。如果在最近一个判决周期内，一个应用有多个版本提交，则将最近一次提交的版本作为最新版本进行处理。升级判决也可以按其他方式进行，例如，在接收到用户提交的某一应用的版本之后即触发对该应用的升级判决。

本实施例中，如该应用的最新版本与该应用的当前运行版本及该应用最近一次升级的目标版本均不相同，则确定需要将该应用的当前运行版本升级到该应用的最新版本。一个应用的当前运行版本也即是该应用最近一次升级成功的版本，也可称为该应用的期望版本(expected_version)。如果最新版本与当前运行版本相同，自然无需对该应用升级。一个应用最近一次升级的目标版本是该应用最近一次升级时要升级到的版本，也可称为该应用的最后处理版本(last_processed_version)，如果升级成功，该应用最近一次升级的目标版本就是该应用的当前运行版本，如果升级失败，该应用最近一次升级的目标版本与当前运行版本不同。无论最近一次升级成功或失败，升级服务器都不需要再对相同的版本进行重复升级。因而通过对版本关系的上述校验，可以避免执行无用的升级。需要说明的是，软件存在从当前版本回滚到旧版本的场景，升级服务器将此种情况也视为一种升级，因而只将最新版本与最近一次升级的目标版本比较，如果最新版本与更早之前升级的目标版本相同，仍将其视为需要升级的版本。

本实施例中，如果以下两个条件之一得到满足，则确定该应用的升级依赖条件得到满足：

在配置的服务器角色SR的升级依赖关系中，该应用所属SR中应用的升级不依赖于其他SR；

在配置的SR的升级依赖关系中，该应用所属SR中应用的升级依赖于其他SR，且每一个被依赖的SR中的应用均满足以下版本关系：最新版本与当前运行版本相同，或者，最新版本与最近一次升级的目标版本不同。

如果该应用所属SR中应用的升级不依赖其他SR，可以直接生成该应用的升级任务。而如果依赖其他SR，则需要保证升级后可以正常调用其他SR的接口。升级服务器默认被依赖的SR中应用的最新版本可以提供该应用需要的接口，如果被依赖的SR中应用的最新版本已经在相应的SR实例上运行即为当前运行版本，则可以为该应用的最新版本提供调用的接口。如果被依赖的SR中应用的最新版本与其最近一次升级的目标版本不同，则要么需要参与本次升级，在升级成功后可以为该应用的最新版本提供调用的接口，要么与当前运行版本相同，也可以为该应用的最新版本提供调用的接口。因此只要每一个被依赖的SR中的应用均满足上述版本关系(一个被依赖的SR有多个应用时，该多个应用均满足上述版本关系)，即可以自动生成升级任务，所述升级任务包括对该应用升级。

某一应用的两个版本是否相同，可以通过比较两个版本自带的版本号而加以判断。如果一个应用之前没有升级也没有运行，则认为其最新版本与当前运行版本及最近一次升级的目标版本均不相同。

本实施例中，在该应用所属SR中应用的升级依赖其他SR时，自动生成的所述升级任务中，该应用的升级顺序排在所有被依赖的SR中的应用之后；自动生成所述升级任务后，如所有被依赖的SR中的应用均已升级成功，则启动对该应用的升级，否则取消对该应用的升级。而在启动对该应用的升级后，无论升级成功还是失败，该应用的最新版本均成为最近一次升级的目标版本。如果升级成功，则该应用的最新版本还成为该应用的当前运行版本。如果取消了对该应用的升级，则该应用的最新版本不会成为该应用最近一次升级的目标版本，因为没有进行过升级。

为了方便版本间的比较，本实施例为一个应用的版本打上两个标记。具体地，所述升级服务器启动对该应用的升级后，在该应用的版本列表中，为该应用的最新版本打上第一标记并删除该应用其他版本的第一标记；如果该应用升级成功，再为该应用的最新版本打上第二标记并删除该应用其他版本的第二标记；其中，所述第一标记表示所标记的版本是最近一次升级的目标版本，所述第二标记表示所标记的版本是当前运行版本。

本实施例还提供了一种升级服务器，如图2所示，包括：

版本获取模块10，用于获取用户提交的应用的版本；

升级判决模块20，用于在对一个应用进行升级判决时，如确定需要将该应用的当前运行版本升级到该应用的最新版本，且该应用的升级依赖条件得到满足，则自动生成升级任务，所述升级任务包括对该应用升级。

可选地，

所述升级判决模块确定需要将该应用的当前运行版本升级到该应用的最新版本，包括：如该应用的最新版本与该应用的当前运行版本及该应用最近一次升级的目标版本均不相同，则确定需要将该应用的当前运行版本升级到该应用的最新版本。

可选地，

所述升级判决模块确定该应用的升级依赖条件得到满足，包括：在以下两个条件中的一个得到满足时，确定该应用的升级依赖条件得到满足：

在配置的服务器角色SR的升级依赖关系中，该应用所属SR中应用的升级不依赖于其他SR；

在配置的SR的升级依赖关系中，该应用所属SR中应用的升级依赖于其他SR，且每一个被依赖的SR中的应用均满足以下版本关系：最新版本与当前运行版本相同，或者，最新版本与最近一次升级的目标版本不同。

可选地，

该应用所属SR中应用的升级依赖其他SR时，所述升级任务中，该应用的升级顺序排在所有被依赖的SR中的应用之后；

所述升级服务器还包括：升级执行模块，用于执行所述升级任务，如所有被依赖的SR中的应用均已升级成功，则启动对该应用的升级，否则取消对该应用的升级。

可选地，

所述升级执行模块启动对该应用的升级后，还在该应用的版本列表中，为该应用的最新版本打上第一标记并删除该应用其他版本的第一标记；如果该应用升级成功，再为该应用的最新版本打上第二标记并删除该应用其他版本的第二标记；其中，所述第一标记表示所标记的版本是最近一次升级的目标版本，所述第二标记表示所标记的版本是当前运行版本。

可选地，

所述升级判决模块对一个应用进行升级判决，包括：按照设定的判决周期启动升级判决，每次启动升级判决后，对最近一个判决周期内有版本提交的每一个应用进行升级判决。

本实施例方案能够根据应用的版本关系确定需要升级的应用，避免不必要的升级，并可根据应用的升级依赖条件自动生成升级任务，保证应用升级后可以正常使用，故实现了对软件升级合理、有效的管理，提高了软件升级的效率和成功率，减轻了用户的负担。

下面再用一个具体应用中的示例对本发明进行说明。

图3是一种自动化数据中心管理系统的架构图，包括控制集群和应用集群。控制集群中的配置中心用于提供接口让用户配置要部署的服务器角色和相应的应用版本。部署/升级服务器负责发现服务器角色实例的配置变化，产生升级任务，并且有节奏地升级应用集群中相应服务器上的服务器角色实例。其他模块和本发明没有直接关系，这里不再说明。

假定，应用集群提供两个服务：服务A和服务B。在配置中心里，服务A下定义了一个服务器角色A，它有一个应用A。服务B下定义了一个服务器角色B，服务器角色B下有一个应用B。配置的服务器角色的升级依赖关系如下：服务器角色A中应用的升级不依赖于其他服务器角色，而服务器角色B中应用的升级依赖于服务器角色A。配置依赖关系时，可以为服务器角色中各应用分别配置对其他服务器角色的依赖关系，也可以为服务器角色下的所有应用统一配置对其他服务器角色的依赖关系，此时，该服务器角色中每一个应用的升级依赖关系是相同的。

假设初始状态下，应用A的当前运行版本即应用A最近一次升级的目标版本，版本号为Version_1。该应用B的当前运行版本也是应用B最近一次升级的目标版本。之后，用户向配置中心提交了应用A的最新版本，版本号为Version_2，还提交了应用B的最新版本，版本号为Version_2。

升级服务器在用户提交应用A和应用B的最新版本后，进行升级判决，对应用A进行升级判决时，因为应用A的最新版本与其当前运行版本和最近一次升级的目标版本均不相同，而且应用A的升级不依赖于其他服务器角色，因而需要对应用A升级。对应用B进行升级判决时，因为应用B的最新版本与其当前运行版本和最近一次升级的目标版本均不相同，而应用B升级依赖的服务器角色A中的应用A也参与本次升级(应用A的最新版本不是最近一次升级的目标版本)。因此，升级服务器自动生成升级任务，包括对应用A升级和对应用B升级，且先对应用A进行升级。

假如应用A升级失败，这将导致应用B的升级被阻塞，即不再对应用B进行升级。如果用户(如运维人员)仍然希望对应用B升级(如用户确定原来配置的依赖关系有误或对应用B的版本进行了修改)，则只需要在配置中心把服务器角色B中应用的升级对服务器角色A的依赖关系解除，重新提交应用B的版本Version_2，就能够使被阻塞的升级继续进行，分析如下：

应用A升级失败后，应用A最近一次升级的目标版本为版本Version_2，而应用A的当前运行版本仍然是版本Version_1。应用B没有进行过升级，因而应用B的当前运行版本和最近一次升级的目标版本均是版本Version_1。

用户通过配置中心解除服务器角色B中应用的升级对服务器角色A的依赖关系后，提交应用B的版本Version_2，该版本是此时应用B的最新版本。假定用户也重新提交了应用A升级失败的版本Version_2，因为应用A的最新版本和其最近一次升级的目标版本均为版本Version_2，不满足升级条件，不对应用A升级。而对于应用B，其最新版本是版本Version_2，而其当前运行版本和最近一次升级的目标版本均为版本Version_1，是需要升级的版本，而且应用B的升级不再依赖于其他服务器角色，因而自动生成对应用B的升级任务。这相当于之前被阻塞的升级过程得以继续。

基于上述方案，当集群中存在多个服务，且相互间有一定的升级依赖关系时，可以自动生成合理的升级任务。而在升级过程被依赖关系阻塞以后，用户如果解除依赖关系，即可以继续被阻塞的升级，提高了运维效率。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (12)

1.一种软件升级方法，包括：

升级服务器获取用户提交的应用的版本；

所述升级服务器对一个应用进行升级判决时，如确定需要将该应用的当前运行版本升级到该应用的最新版本，且该应用的升级依赖条件得到满足，则自动生成升级任务，所述升级任务包括对该应用升级。

2.如权利要求1所述的软件升级方法，其特征在于：

所述升级服务器确定需要将该应用的当前运行版本升级到该应用的最新版本，包括：如该应用的最新版本与该应用的当前运行版本及该应用最近一次升级的目标版本均不相同，则确定需要将该应用的当前运行版本升级到该应用的最新版本。

3.如权利要求1或2所述的软件升级方法，其特征在于：

所述升级服务器确定该应用的升级依赖条件得到满足，包括：在以下两个条件中的一个得到满足时，确定该应用的升级依赖条件得到满足：

在配置的服务器角色SR的升级依赖关系中，该应用所属SR中应用的升级不依赖于其他SR；

在配置的SR的升级依赖关系中，该应用所属SR中应用的升级依赖于其他SR，且每一个被依赖的SR中的应用均满足以下版本关系：最新版本与当前运行版本相同，或者，最新版本与最近一次升级的目标版本不同。

4.如权利要求3所述的软件升级方法，其特征在于：

该应用所属SR中应用的升级依赖其他SR时，所述升级任务中，该应用的升级顺序排在所有被依赖的SR中的应用之后；

所述升级服务器自动生成所述升级任务后，还包括：如所有被依赖的SR中的应用均已升级成功，则启动对该应用的升级，否则取消对该应用的升级。

5.如权利要求4所述的软件升级方法，其特征在于：

所述升级服务器启动对该应用的升级后，还包括：在该应用的版本列表中，为该应用的最新版本打上第一标记并删除该应用其他版本的第一标记；如果该应用升级成功，再为该应用的最新版本打上第二标记并删除该应用其他版本的第二标记；其中，所述第一标记表示所标记的版本是最近一次升级的目标版本，所述第二标记表示所标记的版本是当前运行版本。

6.如权利要求1或2或4或5所述的软件升级方法，其特征在于：

所述升级服务器对一个应用进行升级判决，包括：按照设定的判决周期启动升级判决，每次启动升级判决后，对最近一个判决周期内有版本提交的每一个应用进行升级判决。

7.一种升级服务器，其特征在于，包括：

版本获取模块，用于获取用户提交的应用的版本；

升级判决模块，用于在对一个应用进行升级判决时，如确定需要将该应用的当前运行版本升级到该应用的最新版本，且该应用的升级依赖条件得到满足，则自动生成升级任务，所述升级任务包括对该应用升级。

8.如权利要求7所述的升级服务器，其特征在于：

所述升级判决模块确定需要将该应用的当前运行版本升级到该应用的最新版本，包括：如该应用的最新版本与该应用的当前运行版本及该应用最近一次升级的目标版本均不相同，则确定需要将该应用的当前运行版本升级到该应用的最新版本。

9.如权利要求7或8所述的升级服务器，其特征在于：

所述升级判决模块确定该应用的升级依赖条件得到满足，包括：在以下两个条件中的一个得到满足时，确定该应用的升级依赖条件得到满足：

在配置的服务器角色SR的升级依赖关系中，该应用所属SR中应用的升级不依赖于其他SR；

在配置的SR的升级依赖关系中，该应用所属SR中应用的升级依赖于其他SR，且每一个被依赖的SR中的应用均满足以下版本关系：最新版本与当前运行版本相同，或者，最新版本与最近一次升级的目标版本不同。

10.如权利要求9所述的升级服务器，其特征在于：

该应用所属SR中应用的升级依赖其他SR时，所述升级任务中，该应用的升级顺序排在所有被依赖的SR中的应用之后；

所述升级服务器还包括：升级执行模块，用于执行所述升级任务，如所有被依赖的SR中的应用均已升级成功，则启动对该应用的升级，否则取消对该应用的升级。

11.如权利要求10所述的升级服务器，其特征在于：

所述升级执行模块启动对该应用的升级后，还在该应用的版本列表中，为该应用的最新版本打上第一标记并删除该应用其他版本的第一标记；如果该应用升级成功，再为该应用的最新版本打上第二标记并删除该应用其他版本的第二标记；其中，所述第一标记表示所标记的版本是最近一次升级的目标版本，所述第二标记表示所标记的版本是当前运行版本。

12.如权利要求7或8或10或11所述的升级服务器，其特征在于：

所述升级判决模块对一个应用进行升级判决，包括：按照设定的判决周期启动升级判决，每次启动升级判决后，对最近一个判决周期内有版本提交的每一个应用进行升级判决。