一种软件升级的灰度发布方法及系统与流程

本发明涉及一种计算机领域，更具体地，涉及一种软件升级的灰度发布方法及相应的灰度发布系统。

背景技术：

灰度发布是在黑与白之间，能够平滑过渡的一种发布方式。ab测试(test)就是一种灰度发布方式，先让一部分用户继续用a，一部分用户开始用b，如果用户对b没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到b上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题。

灰度发布可用于将软件从旧版本逐步升级到新版本的过程。软件升级的灰度发布过程分为多个阶段依次升级，前一阶段升级成功后，再对下一组服务器升级，如果某一阶段升级失败，会停止灰度发布过程，将服务器上的服务回滚到升级前的版本。目前，在灰度发布过程的各个阶段，对软件实例升级是否成功的观察方式是相同的，对有功能缺陷的版本的影响范围尚不能做到有效控制。

技术实现要素：

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

一种软件升级的灰度发布方法，应用于灰度发布系统，包括：

为灰度发布过程的多个阶段配置对应的观察时间的参数，其中，第一个阶段对应的观察时间最长；

依次进行所述灰度发布过程的多个阶段，在每一阶段对部分待升级的软件实例进行升级，并基于该阶段对应的观察时间对新版本的软件实例的运行状态进行观察，以确定所述软件实例是否升级成功。

一种灰度发布系统，包括参数配置模块和灰度发布模块，其中：

所述参数配置模块，用于为灰度发布过程的多个阶段配置对应的观察时间的参数，其中，第一个阶段对应的观察时间最长；

所述灰度发布模块，用于依次进行所述灰度发布过程的多个阶段，在每一阶段对部分待升级的软件实例进行升级，并基于该阶段对应的观察时间对新版本的软件实例的运行状态进行观察，以确定所述软件实例是否升级成功。

上述软件升级的灰度发布方法和系统实现了“慢启动”模式的灰度发布，在灰度发布的第一个阶段使用更长的观察时间，使发布更加稳健，而在后续阶段加快观察时间，可以使正确的版本尽快完成发布。

附图说明

图1是本发明实施例一灰度发布方法的流程图；

图2是本发明实施例一灰度发布系统的模块图；

图3是本发明应用示例的系统架构图(只列出与灰度发布相关部分)；

图4是本发明应用示例软件实例状态跳转的示意图；

图5a、图5b和图5c是软件实例状态变化的几种情况的示意图；

图6是本发明应用示例慢启动模式的灰度发布过程的示意图。

具体实施方式

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

实施例一

软件部署到机器上的实例称为软件实例，软件升级具体是对部署在机器(如服务器)上的软件实例的升级。本实施例的灰度发布系统以服务器集群的管理系统为例，但本发明不局限于此。

在灰度发布过程的各个阶段，管理系统需要对服务器上新版本的软件实例的运行状态进行观察，以确定软件实例是否升级成功。现有技术中，各阶段都是使用相同的配置参数，观察的时间都是一样的。而灰度发布是为了保证系统的稳定性，如果在灰度发布的第一个阶段就可以发现新版本的问题而进行调整，就可以减少问题的影响范围。因而如果灰度发布的第一个阶段观察时间更长，可以让潜在的问题得以显露，有效控制有功能缺陷的版本的影响范围。而当足够多的服务器上的软件实例在第一个阶段完成升级并工作正常后，可以恢复正常的升级速度来完成其他服务器上软件实例的升级，将正确的版本部署到服务器集群上。文中将其称为“慢启动”模式的灰度发布。

为了支持“慢启动”模式，本实施例提供了一种自动化的“慢启动”模式的灰度发布方法，如图1所示，包括：

步骤110，为灰度发布过程的多个阶段配置对应的观察时间的参数，其中，第一个阶段对应的观察时间最长；

本实施例中，所述灰度发布过程包括两个阶段，其中第一个阶段为慢启动阶段，第二个阶段为正常阶段。但在其他实施例中，灰度发布过程也可以包括三个以上的阶段，各阶段对应的观察时间可以不同，也可以有部分阶段对应的观察时间相同。

本实施例中，所述观察时间的参数包括:观察超时时间tout和状态正常时间窗口twin。

本实施例中，服务器集群的管理系统进行灰度发布时，可以根据配置信息确定每一阶段需要进行软件实例升级的服务器，并对所述服务器上待升级的软件实例进行升级。其中，所述配置信息包括以下一种或多种信息：

每一阶段需要进行软件实例升级的服务器的数量；

每一阶段需要进行软件实例升级的服务器占所有需要进行软件实例升级的服务器的比例；

每一阶段需要进行软件实例升级的服务器的标识信息；

每一阶段需要进行软件实例升级的服务器集合的标识信息。

例如，在配置了第一个阶段需要进行软件实例升级的服务器的数量时，管理系统可以随机从服务器集群中选择相应数量的服务器，在第一个阶段对这些选择的服务器上的软件实例进行升级。又如，配置了第一个阶段需要进行软件实例升级的服务器集合的标识信息时(例如采用某个机架的标识，代表该机架上的所有服务器)，管理系统则在第一个阶段对所述服务器集合中服务器上的软件实例进行升级。以上配置信息也可以组合使用，例如，对不同的阶段使用不同的配置信息，或者在同一阶段，除配置相应的标识信息外，还可以按照配置的数量或比例随机选择部分服务器等。另外，灰度发布过程的多个阶段中有一个阶段的配置信息可以由其他阶段推定，即隐含在其他阶段的配置信息中。

步骤120，依次进行所述灰度发布过程的多个阶段，在每一阶段对部分待升级的软件实例进行升级，并基于该阶段对应的观察时间对新版本的软件实例的运行状态进行观察，以确定所述软件实例是否升级成功。

本实施例中，基于该阶段对应的观察时间对新版本的软件实例的运行状态进行观察，以确定所述软件实例是否升级成功，包括：

在一软件实例更新为新版本并运行后，启动定时时长为tout的第一定时器和定时时长为twin的第二定时器，twin≤tout；

在所述第二定时器每次超时前，观察是否收到对该软件实例的报错，如果没有收到，则判定该软件实例升级成功，结束；如果收到，在对该软件实例的报错停止后重新启动所述第二定时器并继续观察；

如果所述第一定时器超时前该软件实例没有升级成功，则判定该软件实例升级失败。

本实施例中，所述第一个阶段对应的观察时间最长，是指第一个阶段和所述多个阶段中的其他阶段相比，对应的twin较大。twin较大意味着在更大的时间窗口观察是否收到对软件实例的报错，在该更大的时间窗口没有收到报错时才会判定为软件实例升级成功，这使得软件实例必须有更长的时间不报错才能升级成功。观察时间最长意味着软件实例启动后不出错的时间更长才能升级成功，在有多个这使得第一个阶段的发布更加稳健，可以及时发现升级版本的缺陷，减少有缺陷的版本的影响范围。

应当说明的是，上述tout和twin可以有其他等同的配置方式，例如，配置twin和使用twin进行观察的次数n，这相当于将tout配置为n×twin。又如，只使用一个时间参数t，如果在t超时前收到对软件实例的报错，则判定该软件实例升级成功，否则判决该软件实例升级失败。这相当于将tout和twin配置为相等的情况。此外，还可以采用其他的配置方式如为观察过程配置多个不同的twin等，对于观察时间的具体参数本发明并不局限。

本实施例中，依次进行所述灰度发布过程的多个阶段，包括：在所述灰度发布过程的前一阶段升级成功后，再进行后一阶段的升级；其中，一个阶段升级成功可以是指：在该阶段升级的所有软件实例中有预定比例的软件实例升级成功，或者指有预定数量的软件实例在该阶段升级成功。

本实施例还提供了一种灰度发布系统，如图2所示，包括参数配置模块10和灰度发布模块20，其中：

所述参数配置模块10，用于为灰度发布过程的多个阶段配置对应的观察时间的参数，其中，第一个阶段对应的观察时间最长；

所述灰度发布模块20，用于依次进行所述灰度发布过程的多个阶段，在每一阶段对部分待升级的软件实例进行升级，并基于该阶段对应的观察时间对新版本的软件实例的运行状态进行观察，以确定所述软件实例是否升级成功。

可选地，

所述参数配置模块配置的观察时间的参数包括:观察超时时间tout和状态正常时间窗口twin；

所述灰度发布模块基于该阶段对应的观察时间对新版本的软件实例的运行状态进行观察，以确定所述软件实例是否升级成功，包括：在一软件实例更新为新版本并运行后，启动定时时长为tout的第一定时器和定时时长为twin的第二定时器，twin≤tout；在所述第二定时器每次超时前，观察是否收到对该软件实例的报错，如果没有收到，则判定该软件实例升级成功，结束；如果收到，在对该软件实例的报错停止后重新启动所述第二定时器并继续观察；如果所述第一定时器超时前该软件实例没有升级成功，则判定该软件实例升级失败。

可选地，

所述参数配置模块为第一个阶段配置的观察时间最长，是指第一个阶段和所述多个阶段中的其他阶段相比，对应的twin最大。

可选地，

所述灰度发布模块依次进行所述灰度发布过程的多个阶段，包括：在所述灰度发布过程的前一阶段升级成功后，再进行后一阶段的升级；其中，一个阶段升级成功指在该阶段升级的所有软件实例中有预定比例的软件实例升级成功，或者指有预定数量的软件实例在该阶段升级成功。

可选地，

所述灰度发布过程包括两个阶段，其中第一个阶段为慢启动阶段，第二个阶段为正常阶段。

可选地，

所述灰度发布系统是服务器集群的管理系统；

所述灰度发布模块在每一阶段对部分待升级的软件实例进行升级，包括：根据配置信息，确定每一阶段需要进行软件实例升级的服务器，对所述服务器上待升级的软件实例进行升级，其中，所述配置信息包括以下一种或多种信息：每一阶段需要进行软件实例升级的服务器的数量；每一阶段需要进行软件实例升级的服务器占所有需要进行软件实例升级的服务器的比例；每一阶段需要进行软件实例升级的服务器的标识信息；及，每一阶段需要进行软件实例升级的服务器集合的标识信息。

本实施例的灰度发布方法和系统，在第一个阶段使用更长的时间进行观察，使发布更加稳健。第一个阶段升级成功后，再使用较短的观察时间，以恢复正常的升级速度，使正确的版本能及时发布到服务器上。此外，通过配置各阶段参与升级的服务器的数量、比例等，也可以在稳健和速度之间进行调整，以达到所需要的效果。而且，这种配置方式使得对同一服务器上不同的软件实例升级时，该服务器可以被分配到不同的阶段，从而对其上不同的软件实例使用不同的观察时间，增加了升级的灵活性。

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

图3示出了本示例的系统架构，包括服务器集群和相应的管理系统，本示例中的服务器集群属于数据中心，因而该管理系统也可以称为数据中心的管理系统。图中示出了管理系统中与本发明相关的配置中心(包含参数配置模块)和升级管理系统(包含灰度发布系统)，服务器集群的多台服务器以及相应的应用监控模块。

这里先对一台服务器上软件实例的升级过程做一下描述。用户通过配置中心提供的接口修改软件的版本后，升级管理系统会为新版本的软件完成构建，并将相应的执行文件和配置下发到该服务器，该服务器完成相应软件实例的版本更新。之后，升级管理系统停止旧版本的软件实例，在该服务器上运行新版本的软件实例，进入观察阶段。

软件实例的运行状态的跳转如图4所示，包括观察状态(probation)、正常状态(good)和故障状态(error)三种状态。以下只对新版本的软件实例从观察状态到正常状态或故障状态的跳转进行描述。当该服务器上新版本的软件实例启动后，管理系统会把该软件实例的运行状态置为观察状态，管理系统根据配置信息，确定该服务器上软件实例升级的阶段，并根据该阶段对应的观察时间的参数来确定应当使用的观察时间，例如，当该服务器上软件实例在第一个阶段升级时，将采用最长的观察时间进行观察。

本示例中，观察时间的参数包括观察超时时间(probatiomtimeout)和状态正常时间窗口(slicewindow)。一软件实例由观察状态变成正常状态的条件是：从观察开始时间起，在状态正常时间窗口内，应用监控模块没有报错，如图5a所示。如果在状态正常时间窗口内，应用监控模块报错，则在停止报错后重置观察开始时间为当前时间，重新观察，如图5b所示。当从第一次开始观察开始到观察超时时间的时间段里，一直不满足由观察状态变成正常状态的条件，则判定该软件实例的工作不正常，将观察状态变成故障状态，如图5c所示。在升级场景下，从观察状态变成正常状态表示软件实例升级成功，从观察状态变成故障状态表示软件实例升级失败。

就软件升级的整个灰度发布过程而言，为了支持在不同阶段升级的软件实例使用不同的观察时间，本示例将灰度发布过程分为两个阶段：慢启动阶段和正常阶段，为这两个阶段分别配置对应的观察时间的参数，其中慢启动阶段对应的观察时间更长。慢启动阶段和正常阶段需要进行升级的软件实例，可以通过用户(如管理系统的运维人员)为阶段配置的相应服务器的信息来确定，如根据配置的慢启动阶段需要进行软件实例升级的服务器数量，在慢启动阶段选择该数量的服务器，对这些服务器上的软件实例进行升级。用户还可以配置慢启动阶段和正常阶段升级成功的条件，如软件实例升级成功的服务器达到预定数目即判定该阶段升级成功，或者有预定比例的服务器上的软件实例升级成功即判定该阶段升级成功，否则认为该阶段升级失败。慢启动阶段升级失败后，将根据用户的配置，决定是否回滚到旧版本。

下面详细描述一下本示例慢启动模式的灰度发布过程，可以同时参照图6。

步骤一，用户通过配置页面上修改某个服务器集群上软件实例的软件版本，选择慢启动模式，并配置在慢启动阶段升级的服务器数目n和观察时间的参数，提交给管理系统的配置中心，升级管理系统开始对所述软件实例进行灰度发布。

本步骤中，用户可以将慢启动阶段观察时间配置为相对于正常阶段观察时间的比值t，t大于1。

步骤二，升级管理系统发现升级任务，完成构建和文件下发过程，提交对服务器上软件实例的升级申请，让可用性服务(如服务器集群的应用监控模块)审批；

步骤三，升级管理系统从审批通过的服务器里先选出n台服务器，这n台服务器上的软件实例将进行慢启动阶段的升级，升级时，按照设置的比值，采用相对正常阶段更长的观察时间对软件实例的运行状态进行观察；而其他审批通过但是没有被选中的服务器处于待升级状态，直到慢启动阶段成功后才进行正常阶段的软件实例升级；

步骤四，当在慢启动阶段升级的服务器上的软件实例都升级成功了，升级管理系统会开始正常阶段的升级，采用相对慢启动阶段较短的观察时间对服务器上软件实例的运行状态进行观察；如果在慢启动阶段有部分服务器上的软件实例升级失败，假设数目为n，则可以从待升级状态的服务器里再选中n台服务器作为补充，继续慢启动阶段的升级；直到一共有n台服务器都升级成功，慢启动阶段结束，进入正常升级阶段。这相当于慢启动阶段升级成功所要求的软件实例升级成功的服务器数目设置为n，在其他示例中，也可以设置为小于n的值，或者满足一定比例的服务器上的软件实例升级成功，即认为慢启动阶段升级成功

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

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