CN103164202B - 一种灰度发布方法和装置 - Google Patents

Abstract

本发明提出一种灰度发布方法和系统，其中方法包括：A、预先保存灰度发布顺序表，所述灰度发布顺序表包括不同类型请求消息的灰度发布顺序以及允许发布新版本软件的请求消息类型；B、接收用户对软件的请求消息，根据该请求消息的类型查找所述灰度发布顺序表，当所述请求消息的类型为允许发布新版本软件的请求消息类型时，控制该请求消息访问所述软件的新版本；否则，控制该请求消息访问所述软件的旧版本。本发明能够降低灰度发布过程中的风险。

Description

一种灰度发布方法和装置

技术领域

本发明涉及灰度发布技术领域，尤其涉及一种灰度发布方法和装置。

背景技术

灰度发布是指在软件版本发布过程中，能够平滑过渡的一种发布方式。假设当前软件版本是A，新的软件版本是B，当用户通过客户端向服务器发送针对该软件的请求消息时，服务器控制一部分用户继续使用版本A，另一部分用户开始使用版本B；如果用户在使用版本B的过程中没有出现异常，则逐步将所有用户都迁移到版本B。

灰度发布可以保证整体系统的稳定。用户对软件的请求往往会有多种类型，如查询、更新、删除、上传、下载等，现有的灰度发布方法对用户的请求消息不加区分，导致灰度发布的风险较大。

发明内容

本发明提供了一种灰度发布方法和装置，能够降低灰度发布的风险。

本发明的技术方案是这样实现的：

一种灰度发布方法，包括：

A、预先保存灰度发布顺序表，所述灰度发布顺序表包括不同类型请求消息的灰度发布顺序以及允许发布新版本软件的请求消息类型；

B、接收用户对软件的请求消息，根据该请求消息的类型查找所述灰度发布顺序表，当所述请求消息的类型为允许发布新版本软件的请求消息类型时，控制该请求消息访问所述软件的新版本；否则，控制该请求消息访问所述软件的旧版本。

一种灰度发布装置，包括：

存储模块，用于保存灰度发布顺序表，所述灰度发布顺序表包括不同类型请求消息的灰度发布顺序以及允许发布新版本软件的请求消息类型；

灰度发布控制模块，用于接收用户对软件的请求消息，根据该请求消息的类型查找所述灰度发布顺序表，当所述请求消息的类型为允许发布新版本软件的请求消息类型时，控制该请求消息访问所述软件的新版本；否则，控制该请求消息访问所述软件的旧版本。

可见，本发明提出的灰度发布方法和装置，在灰度发布过程中对用户不同类型的请求消息加以区分，先对部分允许发布软件新版本的请求消息进行灰度发布，从而降低灰度发布过程中的风险。

附图说明

图1为本发明提出的灰度发布方法流程图；

图2为本发明第一种灰度发布实现方式的流程图；

图3为本发明第二种灰度发布实现方式的流程图。

具体实施方式

本发明提出一种灰度发布方法，如图1为本发明提出的灰度发布方法流程图，包括：

步骤101：预先保存灰度发布顺序表，所述灰度发布顺序表包括不同类型请求消息的灰度发布顺序以及允许发布新版本软件的请求消息类型；

步骤102：接收用户对软件的请求消息，根据该请求消息的类型查找所述灰度发布顺序表，当所述请求消息的类型为允许发布新版本软件的请求消息类型时，控制该请求消息访问所述软件的新版本；否则，控制该请求消息访问所述软件的旧版本。

步骤102之后，可以进一步包括：

步骤103：针对一种请求消息类型，当该类型的请求消息访问软件新版本的数量大于预先设定的门限值、并且访问过程没有出现异常时，按照所述灰度发布顺序表中不同类型请求消息的灰度发布顺序，将所述类型之后的类型设置为允许发布新版本软件的请求消息类型；继续执行步骤102。

通过上述过程，可以对来自用户的不同类型的请求消息加以区分，首先针对部分类型的请求消息发布软件的新版本，之后逐步扩大到对所有类型的请求消息发布软件的新版本。

此外，本发明还可以与现有技术中以用户号码为标准的灰度发布控制策略相结合。当用户的号码为允许发布新版本的号码、并且该用户的请求消息类型为允许发布新版本的类型时，控制该请求消息访问软件的新版本；否则，控制该请求消息访问软件的旧版本。

具体实现方式可以为：

上述步骤102中，当请求消息的类型为允许发布新版本软件的请求消息类型时，在控制请求消息访问软件的新版本之前，进一步包括：判断所述用户是否为允许发布新版本软件的用户，如果是，则继续执行所述控制请求消息访问软件的新版本的步骤；否则，控制该请求消息访问所述软件的旧版本。如图2为本发明第一种灰度发布实现方式的流程图。

或者，上述步骤102中，在接收用户对软件的请求消息之后，并在根据该请求消息的类型查找灰度发布顺序表之前，进一步包括：判断所述用户是否为允许发布新版本软件的用户，如果是，则继续执行所述根据请求消息类型查找灰度发布顺序表的步骤；否则，控制该请求消息访问所述软件的旧版本。如图3为本发明第二种灰度发布实现方式的流程图。

此外，上述过程中，判断用户是否为允许发布新版本软件的用户的方式可以为：

判断用户的号码是否属于允许发布新版本软件的用户号码段；

或者，判断用户的号码是否为允许发布新版本软件的测试用户号码。这种方式可以将灰度发布的控制粒度减小到单个用户，从而进一步降低灰度发布的风险。

以下举具体的实施例对本发明做详细介绍。在以下的实施例中，需要进行新版本软件发布的服务器称为实际服务器，由中间层的代理转发服务器实现该软件的灰度发布。

实施例一：

本实施例依据用户请求消息的类型进行灰度发布。在本实施例中，代理转发服务器预先保存灰度发布顺序表，灰度发布顺序表中包括不同类型请求消息的灰度发布顺序、以及允许发布新版本软件的请求消息类型。如下表1为本实施例中的灰度发布顺序表示例，在该表中，按照灰度发布顺序，请求消息的类型从前到后依次为：查询、下载、更新、删除和上传；在初始状态下，允许发布新版本软件的请求消息为查询请求消息。

请求消息类型	是否允许发布新版本软件
		查询	是
下载	否
		更新	否
删除	否
		上传	否

表1

以下为实施例一的实现流程。

步骤401：代理转发服务器接收来自用户A的查询请求消息，查找表1，发现查询请求消息为允许发布新版本软件的请求消息，则控制用户A的查询请求消息访问实际服务器中的新版本软件。

步骤402：代理转发服务器接收来自用户B的下载请求消息，查找表1，发现下载请求消息为不允许发布新版本软件的请求消息，则控制用户B的下载请求消息访问实际服务器中的旧版本软件。

步骤403：经过对多个用户请求消息的处理之后，代理转发服务器统计出采用查询请求消息访问新版本软件的用户数量大于预先设定的门限值(假定门限值为1000)、并且访问过程没有出现异常，这种情况下，代理转发服务器可以扩大请求消息的灰度发布范围，将“查询”类型之后的一种、多种或全部类型设置为允许发布新版本软件的类型。例如，将表1修改为下表2，在表2中，允许发布新版本软件的请求消息类型范围扩大至“查询”、“下载”和“更新”。

请求消息类型	是否允许发布新版本软件
		查询	是
下载	是
		更新	是
删除	否
		上传	否

表2

步骤404：代理转发服务器接收来自用户C的下载请求消息，查找表2，发现下载请求消息为允许发布新版本软件的请求消息，则控制用户C的下载请求消息访问实际服务器中的新版本软件。

步骤405：代理转发服务器接收来自用户D的删除请求消息，查找表2，发现删除请求消息为不允许发布新版本软件的请求消息，则控制用户D的删除请求消息访问实际服务器中的旧版本软件。

代理转发服务器继续对来自不同用户的请求消息进行处理，直至将允许发布新版本软件的请求消息类型扩展到所有类型。

实施例二：

本实施例依据用户请求消息的类型和用户号码进行灰度发布，在本实施例中，首先根据用户请求消息的类型判断是否发布新版本软件，之后根据用户号码判断是否发布新版本软件。在本实施例中，代理转发服务器预先保存的灰度发布顺序表与实施例一中的表1相同；本实施例首先对部分测试号码(如“101”、“111”、“121”、“131”、“141”、“151”、“161”、“171”、“181”、“191”)进行灰度发布，之后扩大到号码段(如“100”～“199”)，最终扩大到所有用户。

以下为实施例二的实现流程。

步骤501：代理转发服务器接收来自用户A的查询请求消息，用户A的号码为“111”。首先查找表1，发现查询请求消息为允许发布新版本软件的请求消息；之后判断出用户A的号码为预先设定的测试号码，则控制用户A的查询请求消息访问实际服务器中的新版本软件。

步骤502：代理转发服务器接收来自用户B的查询请求消息，用户B的号码为“188”。首先查找表1，发现查询请求消息为允许发布新版本软件的请求消息；之后判断出用户B的号码不是预先设定的测试号码，则控制用户B的查询请求消息访问实际服务器中的旧版本软件。

步骤503：经过对多个用户请求消息的处理之后，代理转发服务器统计出所有测试号码均已采用查询请求消息访问过新版本软件，并且访问过程没有出现异常。这种情况下，代理转发服务器将允许采用查询请求消息访问新版本软件的用户号码扩大至号码段“100”～“199”。

步骤504：代理服务器继续接收用户的请求消息，当统计出采用查询请求消息访问过新版本软件的用户超过预先设定的门限值，并且访问过程没有出现异常时，将允许采用查询请求消息访问新版本软件的用户号码扩大至所有号码。

之后，针对其他类型的请求消息，代理服务器采用同样的流程进行灰度发布，直至将新版本软件的发布扩大至所有请求消息类型和所有用户号码。

实施例三：

本实施例依据用户请求消息的类型和用户号码进行灰度发布，在本实施例中，首先根据用户号码判断是否发布新版本软件，之后根据用户请求消息的类型判断是否发布新版本软件。本实施例与实施例二类似，二者的不同点仅在于判断的顺序，在此不赘。

综上可见，本发明提出的灰度发布方法和系统，通过采用请求消息类型、单个用户、用户号码段等多层次细粒度的灰度发布控制策略，能够降低服务器端软件新版本的灰度发布风险。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims (10)

1.一种灰度发布方法，其特征在于，所述方法包括：

A、预先保存灰度发布顺序表，所述灰度发布顺序表包括不同类型请求消息的灰度发布顺序以及允许发布新版本软件的请求消息类型；

B、接收用户对软件的请求消息，根据该请求消息的类型查找所述灰度发布顺序表，当所述请求消息的类型为允许发布新版本软件的请求消息类型时，控制该请求消息访问所述软件的新版本；否则，控制该请求消息访问所述软件的旧版本。

2.根据权利要求1所述的方法，其特征在于，进一步包括：

C、针对一种允许发布新版本软件的请求消息类型，当采用该类型的请求消息访问软件新版本的用户数量大于预先设定的门限值、并且访问过程没有出现异常时，按照所述灰度发布顺序表中不同类型请求消息的灰度发布顺序，将所述允许发布新版本软件的请求消息类型之后的类型设置为允许发布新版本软件的请求消息类型。

3.根据权利要求1所述的方法，其特征在于，当请求消息的类型为允许发布新版本软件的请求消息类型时，在所述控制请求消息访问软件的新版本之前，进一步包括：

判断所述用户是否为允许发布新版本软件的用户，如果是，则继续执行所述控制请求消息访问软件的新版本的步骤；否则，控制该请求消息访问所述软件的旧版本。

4.根据权利要求1所述的方法，其特征在于，在所述接收用户对软件的请求消息之后，并在根据该请求消息的类型查找灰度发布顺序表之前，进一步包括：

判断所述用户是否为允许发布新版本软件的用户，如果是，则继续执行所述根据请求消息的类型查找灰度发布顺序表的步骤；否则，控制该请求消息访问所述软件的旧版本。

5.根据权利要求3或4所述的方法，其特征在于，所述判断用户是否为允许发布新版本软件的用户的方式为：

判断所述用户的号码是否为允许发布新版本软件的用户号码，或者，判断所述用户的号码是否属于允许发布新版本软件的用户号码段。

6.一种灰度发布装置，其特征在于，所述装置包括：

存储模块，用于保存灰度发布顺序表，所述灰度发布顺序表包括不同类型请求消息的灰度发布顺序以及允许发布新版本软件的请求消息类型；

灰度发布控制模块，用于接收用户对软件的请求消息，根据该请求消息的类型查找所述灰度发布顺序表，当所述请求消息的类型为允许发布新版本软件的请求消息类型时，控制该请求消息访问所述软件的新版本；否则，控制该请求消息访问所述软件的旧版本。

7.根据权利要求6所述的装置，其特征在于，所述灰度发布控制模块还用于，针对一种允许发布新版本软件的请求消息类型，当采用该类型的请求消息访问软件新版本的用户数量大于预先设定的门限值、并且访问过程没有出现异常时，对存储模块保存的灰度发布顺序表进行如下修改：按照所述灰度发布顺序表中不同类型请求消息的灰度发布顺序，将所述允许发布新版本软件的请求消息类型之后的类型设置为允许发布新版本软件的请求消息类型。

8.根据权利要求6所述的装置，其特征在于，所述灰度发布控制模块还用于，当请求消息的类型为允许发布新版本软件的请求消息类型时，在控制请求消息访问软件的新版本之前进一步判断所述用户是否为允许发布新版本软件的用户，如果是，则控制请求消息访问软件的新版本；否则，控制该请求消息访问所述软件的旧版本。

9.根据权利要求6所述的装置，其特征在于，所述灰度发布控制模块还用于，在接收用户对软件的请求消息之后，判断所述用户是否为允许发布新版本软件的用户，如果是，则根据该请求消息类型查找灰度发布顺序表；否则，控制该请求消息访问所述软件的旧版本。

10.根据权利要求8或9所述的装置，其特征在于，所述灰度发布控制模块判断用户是否为允许发布新版本软件的用户的方式为：

判断所述用户的号码是否为允许发布新版本软件的用户号码，或者，判断所述用户的号码是否属于允许发布新版本软件的用户号码段。