一种灰度升级的方法、装置、设备和存储介质与流程

1.本技术涉及计算机技术领域，尤其涉及一种灰度升级的方法、装置、设备和存储介质。


背景技术：

2.在物联网领域中，灰度升级(又称灰度发布、灰度更新)是一种在产品升级过程中平滑过渡的发布方式。例如，在对产品进行升级时，可先让一部分用户继续用当前版本，一部分用户开始验证新版本(即进行灰度验证)，若用户对新版本没有反对意见，则逐步扩大范围，直至把所有用户都迁移到新版本中。灰度升级有利于保证系统的整体稳定性。
3.目前的灰度升级方案中，灰度环境相对固定，例如，通常使用一个专门的灰度环境进行灰度验证，为了避免资源浪费，该灰度环境的硬件配置一般低于常规生产环境，从而导致部分场景无法验证。此外，由于灰度验证受到特定环境的限制，导致灰度资源不能充分利用。


技术实现要素：

4.有鉴于此，本技术至少提供一种灰度升级的方法、装置、设备和存储介质。
5.本技术的技术方案是这样实现的：
6.第一方面，本技术提供了一种灰度升级的方法，该方法包括：将产品版本相同的多个业务集群中的任一业务集群确定为灰度集群，将多个业务集群中除灰度集群之外的业务集群确定为生产集群；将灰度集群对应的产品版本升级为目标版本；在对目标版本进行验证通过的情况下，将生产集群对应的产品版本升级为目标版本。
7.第二方面，本技术提供了一种灰度升级的装置，该装置包括第一确定模块、第一升级模块和第二升级模块；其中，第一确定模块，用于将产品版本相同的多个业务集群中的任一业务集群确定为灰度集群，将多个业务集群中除灰度集群之外的业务集群确定为生产集群；第一升级模块，用于将灰度集群对应的产品版本升级为目标版本；第二升级模块，用于在对目标版本进行验证通过的情况下，将生产集群对应的产品版本升级为目标版本。
8.第三方面，本技术提供了一种计算机设备，该计算机设备包括存储器和处理器；其中，存储器，用于存储计算机可执行指令；处理器，与该存储器连接，用于通过执行该计算机可执行指令，实现如第一方面所述的方法。
9.第四方面，本技术提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，计算机程序被至少一个处理器执行时实现如第一方面所述的方法。
10.本技术所提供的一种灰度升级的方法、装置、设备和计算机可读存储介质，可将产品版本相同的多个业务集群中的任一业务集群确定为灰度集群，将多个业务集群中除灰度集群之外的业务集群确定为生产集群；从而，可将灰度集群对应的产品版本升级为目标版本；进一步地，在对目标版本进行验证通过的情况下，可将生产集群对应的产品版本升级为目标版本。该方法通过从多个备选的业务集群中确定一个业务集群作为灰度集群，从而可
使得灰度环境不固定，因而有利于增加灰度环境的丰富性。
11.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，而非限制本技术的技术方案。
附图说明
12.此处的附图被并入说明书中并构成本说明书的一部分，这些附图示出了符合本技术的实施例，并与说明书一起用于说明本技术的技术方案。
13.图1为本技术实施例提供的一种灰度升级的方法的示意图；
14.图2为适用于本技术实施例的物联网商城的一种系统架构的示意图；
15.图3为本技术实施例提供的灰度升级方法的一种可能的实现流程的示意图；
16.图4为本技术实施例对灰度集群进行版本升级前业务集群的状态示意图；
17.图5为本技术实施例对灰度集群进行版本升级的过程中业务集群的状态示意图；
18.图6为本技术实施例灰度验证过程中业务集群的状态示意图；
19.图7为本技术实施例对目标版本进行修复的过程中业务集群的状态示意图；
20.图8为本技术实施例对目标版本进行修复完成后业务集群的状态示意图；
21.图9为本技术实施例对业务集群#1进行版本升级时业务集群的状态示意图；
22.图10为本技术实施例对业务集群#2进行版本升级时业务集群的状态示意图；
23.图11为本技术实施例版本回退后业务集群的状态示意图；
24.图12为本技术实施例提供的一种灰度升级的装置的组成结构示意图；
25.图13为本技术实施例中计算机设备的一种硬件实体示意图。
具体实施方式
26.为了能够更加详尽地了解本技术实施例的特点与技术内容，下面结合附图对本技术实施例的实现进行详细阐述，所附附图仅供参考说明之用，并非用来限定本技术实施例。
27.除非另有定义，本技术实施例所使用的所有的技术和科学术语与属于本技术的技术领域的技术人员通常理解的含义相同。本技术实施例中所使用的术语只是为了描述本技术实施例的目的，不是旨在限制本技术。
28.在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。还需要指出，本技术实施例所涉及的术语“第一\第二\第三”仅是用于区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本技术实施例能够以除了在这里图示或描述的以外的顺序实施。
29.在现有的灰度升级方案中，灰度环境相对固定，例如，通常使用一个专门的灰度环境进行灰度验证，为了避免资源浪费，该灰度环境的硬件配置一般低于常规生产环境，从而导致部分场景无法验证。此外，由于灰度验证受到特定环境的限制，导致灰度资源不能充分利用。
30.为此，本技术实施例提供一种灰度升级的方法、装置、设备和存储介质。该方法可以由计算机设备的处理器执行。其中，计算机设备指的可以是服务器、笔记本电脑、平板电
脑、台式计算机等具备数据处理能力的设备。该方法通过从多个备选的业务集群中确定一个业务集群作为灰度集群，从而可使得灰度环境不固定，因而有利于增加灰度环境的丰富性。
31.下面将结合附图对本技术各实施例进行详细说明。图1示出了本技术实施例提供的一种灰度升级的方法，该方法可以包括：
32.s101，将产品版本相同的多个业务集群中的任一业务集群确定为灰度集群，将多个业务集群中除灰度集群之外的业务集群确定为生产集群。
33.在本技术实施例中，首先可从多个备选的产品版本相同的业务集群中，确定一个业务集群作为灰度集群，并将除该灰度集群之外的业务集群确定为生产集群。其中，灰度集群可作为灰度环境，进而可在该灰度环境中进行后续的灰度验证；生产集群可用于承载业务，以便于在灰度集群进行版本升级的过程中对外提供服务。
34.作为一种实现方式，可通过预先配置的规则，从产品版本相同的多个业务集群中确定一个业务集群作为灰度集群，例如，该规则可配置为：若多个业务集群中有一个业务集群当前未承载业务，或承载的业务流量相对较少，那么，可优先将该业务集群确定为灰度集群。
35.应理解，上述多个业务集群，可以理解为两个或两个以上业务集群，本技术对于业务集群的具体数量不做限制。还应理解，在一些实施例中，还可将产品版本相同的多个业务集群中的两个或两个以上业务集群确定为灰度集群。
36.s102，将灰度集群对应的产品版本升级为目标版本。
37.在确定灰度集群后，可将该灰度集群对应的产品版本升级为目标版本。示例性地，该目标版本提供的业务可具备新业务特性。其中，新业务特性例如可包括：相比于升级之前的版本，该目标版本所提供的新功能和/或新配置参数。举例来说，在物联网系统中，该新业务特性例如可以为某个新的订单流程，或者，某个新推出的产品或商品。
38.示例性地，将灰度集群对应的产品版本升级为目标版本，可通过如下步骤实现：将灰度集群的业务流量切换至生产集群；关停灰度集群对外提供业务的功能；在关停灰度集群对外提供业务的功能的情况下，将灰度集群对应的产品版本升级为目标版本。
39.根据本实施例的方法，在灰度升级前，可先将灰度集群原本承载的业务流量切换至生产集群，或者说，引流至生产集群，从而灰度集群可不承载业务流量。此时，可对灰度集群停服，或者说，可关停灰度集群对外提供业务的功能。在对灰度集群停服后，可对灰度集群进行版本升级，进而将灰度集群对应的产品版本升级为目标版本。
40.在对灰度集群进行版本升级的过程中，由于始终有一个或多个生产集群可对外提供业务(服务)，因此用户仍可通过生产集群正常使用业务，从而保障了系统的可靠性。
41.s103，在对目标版本进行验证通过的情况下，将生产集群对应的产品版本升级为目标版本。
42.灰度集群升级为目标版本后，可对目标版本进行验证，也即，进行灰度验证。若验证通过，则可将生产集群对应的产品版本升级为目标版本。
43.在一种实现方式中，可根据目标版本的新业务特性(也即目标版本的新功能和/或新配置参数)确定一个用户集合(例如记为第二用户集合)作为目标版本的体验用户，并通过该用户集合对目标版本进行验证。该实现方式可通过如下步骤实现：步骤1031：根据新业
务特性，确定第二用户集合；步骤1032：通过第二用户集合，对目标版本进行验证。下面分别介绍上述步骤。
44.步骤1031：根据新业务特性，确定第二用户集合。
45.其中，第二用户集合可以由一个或多个目标用户组成。示例性地，可获取第一用户集合中第一用户的属性信息，并根据与新业务特性相关的灰度规则和第一用户的属性信息，确定第一用户是否为目标用户，进而可得到包括目标用户的第二用户集合。
46.应理解，第一用户可以为第一用户集合中的任一用户，当该用户被确定为目标用户后，可被划分至第二用户集合中，从而可参与后续的灰度验证。
47.在一种实现方式中，可通过如下方式获取第一用户集合中第一用户的属性信息：接收来自第一用户集合中第一用户的访问请求；通过解析访问请求，得到第一用户的标识；根据第一用户的标识，得到第一用户的属性信息。
48.举例来说，当第一用户发起访问请求时(例如，当第一用户登陆系统时)，该访问请求中例如可携带第一用户的标识(如账号、登陆名等)，从而，可通过调用服务查询得到该标识对应的用户属性信息，也即，第一用户的属性信息。示例性地，第一用户的属性信息例如可以是该第一用户注册时提供的属性信息，或者还可以是通过分析该第一用户的行为习惯得到的属性信息。
49.在一种实现方式中，灰度规则可包括灰度标识，该灰度标识例如可根据目标版本的新业务特性确定。一示例，假设新业务特性适用于某省份范围内的用户群体，则可将灰度标识确定为该省份，或者，确定为该省份对应的省编码；另一示例，假设新业务特性适用于与智能家居相关的用户群体，则可将灰度标识确定为智能家居，或者，确定为与智能家居对应的标签或编码。需要说明的是，该灰度标识还可以包括两个或两个以上标识，例如，灰度标识可同时包括上述省编码和智能家居对应的标签或编码。
50.在该实现方式中，可通过如下方式确定第一用户是否为目标用户：将第一用户的属性信息和灰度标识进行匹配；在第一用户的属性信息和灰度标识相匹配的情况下，确定第一用户为目标用户。
51.一示例，灰度标签例如为a省份对应的省编码，在该情况下，可通过查询第一用户的属性信息得到该第一用户所属省份的省编码，进而可将该第一用户所属省份的省编码和a省份对应的省编码进行匹配，若该第一用户所属省份的省编码与a省份对应的省编码一致，则可将该第一用户确定为目标用户。另一示例，灰度标签例如为智能家居，在该情况下，可通过查询第一用户的属性信息获知该第一用户经常访问的商品类型，若该第一用户经常访问的商品类型与智能家居相匹配，则可将该第一用户确定为目标用户。
52.步骤1032：通过第二用户集合，对目标版本进行验证。
53.示例性地，在灰度验证阶段，可将步骤1031中确定的第二用户集合的业务流量引导至灰度集群，从而，第二用户集合中的用户可体验新业务特性，进而对目标版本进行验证。在一种实现方式中，第二用户集合中的目标用户在发起访问请求时(如登陆系统时)，可为该目标用户的访问请求添加灰度标签，从而，可将拥有该灰度标签的用户的访问请求路由至灰度集群中，相应地，该目标用户的业务流量可被引导至灰度集群。对于该目标用户而言，可依照其原有的操作习惯进行操作，而无需关注当前的环境是否为灰度环境，且无需更换访问地址，换句话说，用户在前台的体验过程中无需感知灰度环境的切换，也无需进行特
殊操作，因此提高了用户的访问体验。
54.需要说明的是，对于不属于第二用户集合的用户，例如非目标用户，那么，该非目标用户在发起访问请求时(如登陆系统时)，该非目标用户的访问请求可被路由至生产集群中，相应地，该非目标用户的业务流量可被引导至生产集群，从而，非目标用户可继续通过升级之前的版本进行业务办理。作为一种实现方式，在将非目标用户的业务流量引导至生产集群的过程中，可基于当前各生产集群的负载，将该非目标用户的业务流量引导至负载较小的生产集群，以避免某个生产集群发生过载而导致系统故障。
55.根据本实施例的方法，可获取第一用户集合中第一用户的属性信息，并根据与新业务特性相关的灰度规则和第一用户的属性信息，确定第一用户是否为目标用户，得到包括目标用户的第二用户集合，进而通过第二用户集合对目标版本进行验证。这样，在进行灰度验证时，可有针对性地选取目标用户对目标版本进行验证，以提高验证的准确性。此外，随着新业务特性的变更，第二用户集合可发生变化，也即，验证目标版本的用户集合不固定，从而有利于提高灰度验证的覆盖率。
56.在s103中，在对目标版本进行验证通过的情况下，可将生产集群对应的产品版本升级为目标版本。
57.在一些实施例中，生产集群例如可包括第一生产集群和第二生产集群，此时，在对目标版本进行验证通过的情况下，可通过滚动升级的方式，将第一生产集群和第二生产集群对应的产品版本逐个升级为目标版本。例如，可先对第一生产集群进行升级，再对第二生产集群进行升级；又例如，还可以先对第二生产集群进行升级，再对第一生产集群进行升级，本技术对此不予限定。
58.应理解，第一生产集群，或者第二生产集群，可以包括一个生产集群，也可以包括两个或两个以上生产集群。举例来说，第一生产集群例如可以包括2个生产集群，第二生产集群例如可以包括3个生产集群，那么在该情况下，可先将第一生产集群中的2个生产集群对应的产品版本同时升级为目标版本，再先第二生产集群中的3个生产集群对应的产品版本同时升级为目标版本，或者，还可以先将第二生产集群中的3个生产集群对应的产品版本同时升级为目标版本，再将第一生产集群中的2个生产集群对应的产品版本同时升级为目标版本，本技术对此不予限定。
59.示例性地，在对第一生产集群对应的产品版本进行升级时，可先将第一生产集群的业务流量切换至第二生产集群和/或灰度集群，以确保在第一生产集群进行版本升级的过程中用户仍能够正常使用业务。业务流量切换完成后，可将第一生产集群对应的产品版本升级为目标版本，从而可使得第一生产集群提供的业务具备目标版本的新业务特性。
60.示例性地，在对第二生产集群对应的产品版本进行升级时，可先将第二生产集群的业务流量切换至第一生产集群和/或灰度集群，以确保在第二生产集群进行版本升级的过程中用户仍能够正常使用业务。业务流量切换完成后，可将第二生产集群对应的产品版本升级为目标版本，从而可使得第二生产集群提供的业务具备目标版本的新业务特性。
61.根据本实施例的方法，在对生产集群对应的产品版本进行升级时，可始终保持一个或多个业务集群能够正常提供服务，从而保障了系统的可靠性。
62.上文介绍了在对目标版本进行验证通过的情况下，该方法的相应流程。下面介绍在对目标版本进行验证未通过的情况下，该方法的相应流程。
63.在第一种实现方式中，在对目标版本进行验证未通过的情况下，例如，在验证过程中发现目标版本存在缺陷的情况下，可对该目标版本进行修复，例如，可对目标版本更新补丁或进行升级操作，以实现对目标版本的修复。
64.示例性地，在对目标版本进行修复时，可先将第二用户集合的业务流量从灰度集群切换至生产集群，以确保在对目标版本进行修复时，参与灰度验证的用户(即第二用户集合中的用户)仍能够正常使用业务。业务流量切换完成后，可对目标版本进行修复，之后，再将第二用户集合的业务流量从生产集群切换至灰度集群，并通过第二用户集合继续对修复之后的目标版本进行验证。在一些实施例中，在修复不成功的情况下，可将灰度集群对应的产品版本回退为升级之前的版本，从而结束灰度发布。
65.在第二种实现方式中，在对目标版本进行验证未通过的情况下，例如，在灰度验证过程中发现目标版本存在重大质量缺陷的情况下，可通过如下步骤结束灰度发布：1)删除或更改灰度规则，以使得用户无法访问灰度集群；2)将第二用户集合的业务流量从灰度集群切换至生产集群；3)将灰度集群对应的产品版本回退为升级之前的版本。
66.对于上述步骤1)，作为一种实现方式，可通过删除灰度规则的方式，使得用户无法访问灰度集群。例如，删除灰度规则后，发起访问请求的用户均可被确定为非目标用户，从而该用户的访问请求可被路由至生产集群中；作为另一种实现方式，可通过更改灰度规则的方式，使得用户无法访问灰度集群。例如，可删除灰度规则中的灰度标识，以使得发起访问请求的用户无法与灰度标识进行匹配，从而被确定为非目标用户，进而，该用户的访问请求可被路由至生产集群中。
67.根据本实施例的方法，在将灰度集群对应的产品版本回退为升级之前的版本的过程中，灰度集群的业务流量可切换至生产集群，因此参与灰度验证的用户(即第二用户集合中的用户)仍能够正常使用业务，从而保障了系统的可靠性。
68.上文结合图1介绍了本技术实施例提供的一种灰度升级的方法。为便于理解本技术的实施例，下面以该方法由流量管控引擎执行为例，结合图2至图11介绍本技术实施例提供的灰度升级方法的一种可能的实现流程。该实现流程例如可应用于物联网商城，物联网商城例如可提供电脑端(pc端)和/或移动端入口。
69.图2示出了适用于本技术实施例的物联网商城的一种系统架构。该系统架构可包括流量管控引擎(如图2中的流量管控引擎200)，该流量管控引擎200可包括集群管理模块201、路由管理模块202、负载均衡模块203和灰度规则管理模块204。其中，流量管控引擎200可接收来自商城的业务请求，进而，可根据流量管控引擎的路由规则将业务请求路由至对应的业务集群。
70.该系统架构还可以包括多个产品版本相同的业务集群(如图2中的业务集群#1、业务集群#2和业务集群#3)。作为示例，业务集群可为客户、客户经理提供物联网产品和商品展示、订购、查询、管理、物流跟踪、发票开具等功能。在没有灰度发布任务时，该业务集群#1、业务集群#2和业务集群#3可共同承载业务，业务流量可通过流量管控引擎200接入，并通过负载均衡模块203引流至各个业务集群。灰度发布时，业务集群#1、业务集群#2和业务集群#3可转换为2+1集群架构，其中，2+1集群架构可以理解为，由2个生产集群和1个灰度集群组成的集群架构。
71.下面分别介绍流量管控引擎200中的各个模块。
72.集群管理模块201：负责管理业务集群#1、业务集群#2和业务集群#3。在有灰度发布验证任务时，可选择该三个业务集群中的一个业务集群作为本次灰度发布的灰度集群，并可根据灰度验证情况对除灰度集群之外的业务集群进行滚动升级或版本回退。
73.路由管理模块202：负责解析用户的业务请求，并可根据路由规则确定该业务请求需路由至哪个业务集群。
74.负载均衡模块203：负责根据当前各个业务集群的负载情况，将业务流量引导至相应的业务集群。
75.灰度规则管理模块204：负责配置灰度规则及灰度规则的管理。
76.随着业务的不断发展，且由于产品发布速度的不断提升，新版本上线的验证评估时间不断压缩，新版本中部分新业务及新特性的问题缺陷在测试阶段未完全暴露，导致新版本发布后引发客户不满。
77.为保障新业务在大规模推广之前能够进行充分验证，可引入灰度升级技术。然而，目前的灰度升级方案中，灰度环境相对固定，用户需使用独立接入统一资源定位系统(uniform resource locator，url)的方式访问业务。在灰度发布时，用户需自主选择是否体验新版本，或直接提示用户将切换至灰度环境，这样会导致灰度的资源不能充分利用。此外，目前的灰度升级方案中，通常通过固定的用户群体进行灰度验证，因此可能存在业务覆盖不全的情况。
78.鉴于此，本技术实施例提供一种灰度升级的方法。在该方法中，可由流量管控引擎200的集群管理模块201从多个业务集群中确定一个业务集群作为进行灰度验证的灰度集群，同时，可动态分析用户的行为习惯，并根据新业务特性确定参与灰度验证的用户范围。用户发起访问请求后，可由流量管控引擎200的路由管理模块202查询用户资料，判断将该访问请求路由至业务集群还是灰度集群，该过程用户在入口处无感知，且不需要进行特殊操作，从而，可在用户无感知的情况下，将友好用户路由至灰度集群体验新版本应用。
79.如图3所示，本技术实施例提供的灰度升级方法的实现流程可包括：
80.s301，确定灰度集群和生产集群。
81.该步骤可对应于前述实施例中的s101。
82.在本实施例中，商城系统的业务流量可由业务集群#1、业务集群#2和业务集群#3共同承载。在将业务集群的产品版本升级为目标版本(即新版本)前，可对目标版本的新功能和/或需求范围进行可灰评估，也即，确定哪些功能可在灰度集群进行灰度验证，或者，确定哪些功能适合在哪些用户群体中进行灰度验证。
83.在一些实施例中，可依据可灰评估的结果，在进行版本升级前，可由集群管理模块201在业务集群#1、业务集群#2和业务集群#3中确定一个业务集群作为本次版本升级的灰度集群，用以进行灰度验证；在一些实施例中，还可通过预先配置的规则，由集群管理模块201在业务集群#1、业务集群#2和业务集群#3中确定一个业务集群作为本次版本升级的灰度集群，例如，该规则可配置为，若某个业务集群当前未承载业务，或承载的业务流量相对较少，那么，可优先将该业务集群确定为灰度集群。同时，集群管理模块201可将除灰度集群之外的业务集群确定为生产集群，用以在灰度集群进行版本升级的过程中对外提供服务。
84.举例来说，集群管理模块201例如可将业务集群#3确定为灰度集群，并可将除业务集群#3之外的业务集群(业务集群#1和业务集群#2)确定为生产集群。为便于描述本实施
例，下文中以灰度集群为业务集群#3、生产集群为业务集群#1和业务集群#2为例，进行示例性说明。
85.s302，将灰度集群对应的产品版本升级为目标版本。
86.该步骤可对应于前述实施例中的s102。
87.其中，目标版本提供的业务可具备新业务特性。作为示例，新业务特性例如可包括：相比于升级之前的版本，该目标版本所提供的新功能和/或新配置参数。
88.示例性地，s302可分为升级前、升级中、和升级后三个阶段。下面分别对该三个阶段进行阐述。
89.1)升级前：负载均衡模块203可将灰度集群(业务集群#3)承载的业务流量(或者说生产业务流量)引流至生产集群(业务集群#1和业务集群#2)，此时，业务流量可由生产集群承载，灰度集群未承载业务流量，因此可对灰度集群进行版本升级。升级前三个业务集群的状态如图4所示，其中，三个业务集群的版本一致(均为v1)；配置表数据源一致(均为pub/prod/order)；业务运行状态为双业务集群运行，也即，两个生产集群(业务集群#1和业务集群#2)承载业务，灰度集群(业务集群#3)不承载业务。其中，业务集群#1和业务集群#2承载的业务流量可以相同，也可以不同，本技术不予限定。例如，业务集群#1和业务集群#2可分别承载50％的业务流量，以避免某个业务集群的流量过载而导致出现故障；又例如，当业务集群#1的网络状态较差时，可令业务集群#2承载相对较多的业务流量，以提高用户体验。
90.应理解，本技术实施例中的版本编号和配置表数据源仅是示例性的，不应对本技术实施例的实施过程构成任何限定。
91.2)升级中：灰度集群原有承载的业务流量引流至另外两个生产集群后，此时灰度环境没有任何业务承载，因此，可对灰度集群停服。在对灰度集群停服的情况下，可将灰度集群对应的产品版本升级为目标版本，其中，可包括灰度应用的升级和/或灰度配置的升级。升级过程中三个业务集群的状态如图5所示，其中，两个生产集群的版本一致(均为v1)，灰度集群的版本由v1升级为v2；两个生产集群的配置表数据源一致(均为pub/prod/order)，灰度集群的配置表数据源变更为pubconf/prodconf/orderconf；业务运行状态为双业务集群运行，也即，两个生产集群承载业务，灰度集群不承载业务。其中，业务集群#1和业务集群#2承载的业务流量可以相同，也可以不同，本技术不予限定。作为一个示例，业务集群#1和业务集群#2可分别承载50％的业务流量。
92.根据本实施例的方法，在对灰度集群进行版本升级的过程中，仍有两个业务集群可提供服务，因此保障了业务的高可靠性。
93.3)升级后：灰度集群升级完成后，灰度集群的产品版本变更为v2，同时配置信息可切到灰度配置中，例如可表现为，升级后资源池(如pod)中的应用配置与升级前不同，升级后数据库中的业务配置与升级前不同。
94.s303，对目标版本进行验证。
95.将灰度集群对应的产品版本升级为目标版本后，可在灰度规则管理模块204中配置灰度规则。示例性地，灰度规则管理模块204可基于目标版本的新业务特性配置灰度规则。例如，本次上线的新业务特性为推出的新的范式商品，那么，可对该新的范式商品的商品信息进行分析，进而根据分析结果选取某个区域的用户作为参与本次灰度验证的体验用户，并通过配置相应的灰度规则，将所有该区域的用户引流至灰度集群；又例如，新业务特
性为新推出的智能门锁，那么，可选取与智能家居相关的用户群体作为参与本次灰度验证的体验用户。
96.在一种实现方式中，在对目标版本进行验证时，在保障用户体验的前提下，可通过更新灰度规则不断扩大可访问灰度集群的用户群体。举例来说，根据灰度规则，例如可支持a城市的用户访问灰度集群，那么，随着灰度验证进程的发展，可通过更新该灰度规则的方式，使得可访问灰度集群的用户范围扩大至a城市所属的整个省份。
97.在本实施例中，用户请求接入流量管控引擎200后，首先可由路由管理模块202解析用户请求中携带的用户信息(如用户的标识)，并调用服务查询该用户的属性信息，进而，可根据灰度规则和该用户的属性信息，判断该用户是否为目标用户。在该用户为目标用户的情况下，可将该用户的访问请求路由至灰度集群；相应地，在该用户为非目标用户的情况下，可由负载均衡模块203根据当前生产集群的负载情况，将该用户的访问请求引导至相应的生产集群中。
98.示例性地，当用户登录商城时，流量管控引擎200的路由管理模块202可根据灰度规则管理模块204的灰度规则和该用户的属性信息判断该用户是否为目标用户。作为一个示例，灰度规则中可包括灰度标识，从而路由管理模块202可将灰度标识和该用户的属性信息进行匹配，在灰度标识和该用户的属性信息相匹配的情况下，可将该用户确定为目标用户。进一步地，路由管理模块202可为该目标用户的访问请求(会话请求)添加灰度标签，从而，负载均衡模块203可将所有拥有该标签的访问请求对应的业务流量引导至灰度集群，以进行灰度验证。相应地，可将非目标用户的访问请求对应的业务流量引导至生产集群继续进行业务办理。
99.灰度验证过程中，三个业务集群的状态如图6所示，其中，两个生产集群的版本一致(均为v1)，灰度集群的版本为v2；两个生产集群的配置表数据源一致(均为pub/prod/order)，灰度集群的配置表数据源为pubconf/prodconf/orderconf；业务运行状态为双业务集群、灰度集群运行，也即，两个生产集群和灰度集群共同承载业务。作为一种实现方式，灰度集群承载的业务流量可少于生产集群承载的业务流量，其中，业务集群#1和业务集群#2承载的业务流量可以相同，也可以不同，本技术不予限定。作为一个示例，业务集群#1和业务集群#2可分别承载45％的业务流量，灰度集群可承载10％的业务流量。灰度验证完成后，集群管理模块201可将灰度集群转换为具备新业务特性的普通业务集群对外提供服务，此时，业务集群#1、业务集群#2和业务集群#3都有业务流量请求接入。
100.根据本实施例的方法，灰度升级完成后对外提供服务，无新增灰度地址，用户仍可使用原来的地址访问商城，同时，可依照用户原有习惯进行操作，无需关注是否当前环境是否为灰度环境，换句话说，用户在前台的体验过程中无需感知灰度环境的切换，也无需进行特殊操作，因此提高了用户的访问体验。
101.在一些实施例中，若在灰度验证过程中发现目标版本存在缺陷，则可对目标版本进行修正，例如，可对目标版本更新补丁或进行升级操作。此时，可先删除或修改灰度规则，使得灰度集群暂停对外提供服务，进一步地，可将体验用户(参与灰度验证的用户)的业务流量动态切换至生产集群，以使得这部分用户在版本修复过程中仍然能够正常使用业务。
102.示例性地，对目标版本进行修复的过程中，三个业务集群的状态如图7所示。其中，两个生产集群的版本一致(均为v1)，灰度集群的版本由v2更新为v3；业务运行状态为双业
务集群运行，也即，两个生产集群承载业务，灰度集群不承载业务。其中，业务集群#1和业务集群#2承载的业务流量可以相同，也可以不同，本技术不予限定。作为一个示例，业务集群#1和业务集群#2可分别承载50％的业务流量。目标版本修复完成后，可恢复灰度规则，并将体验用户的业务流量切换至灰度集群，以便于继续对修复之后的目标版本进行验证，如图8所示。此时，业务运行状态变更为三个业务集群共同运行。
103.s304，在对目标版本进行验证通过的情况下，将生产集群对应的产品版本升级为目标版本。
104.该步骤可对应于前述实施例中的s103。
105.在一些实施例中，可通过滚动升级的方式，将业务集群#1和业务集群#2对应的产品版本逐个升级为目标版本。其中，对业务集群#1和业务集群#2进行滚动升级时，可以没有升级的优先级次序之分。
106.作为示例，下面以先对生产集群#1进行版本升级，再对生产集群#2进行版本升级为例进行示例性说明。
107.在对业务集群#1进行版本升级时，首先将业务集群#1的业务流量切换至业务集群#2和/或业务集群#3中，由业务集群#3(对应的产品版本为目标版本)和/或业务集群#2(对应的产品版本为升级之前的版本)承载全部业务流量，此时业务集群#1不再承载业务流量，故可将业务集群#1对应的产品版本升级为目标版本。在一些实施例中，若s303中对目标版本进行了修复，则在该步骤中可将生产集群#1对应的产品版本升级为修复之后的目标版本，即v3版本，相应地，生产集群#1的配置表数据源可变更为pubconf/prodconf/orderconf，如图9所示。在图9所示的实施例中，业务集群#1的业务流量例如可全部切换至业务集群#3中，此时，业务集群#2可承载45％的业务流量，业务集群#3可承载55％的业务流量，业务集群#1不承载业务流量。在一些实施例中，若s303中未对目标版本进行修复，则在该步骤中可将生产集群#1对应的产品版本升级为v2版本。
108.在对业务集群#2进行版本升级时，首先将业务集群#2的业务流量切换至业务集群1和/或业务集群#3中，由业务集群#1(对应的产品版本为目标版本)和业务集群#3(对应的产品版本为目标版本)承载全部业务流量，此时业务集群#2不再承载业务流量，故可将业务集群#2对应的产品版本升级为目标版本。在一些实施例中，若s303中对目标版本进行了修复，则在该步骤中可将生产集群#2对应的产品版本升级为修复之后的目标版本，即v3版本，相应地，生产集群#1的配置表数据源可变更为pubconf/prodconf/orderconf，如图10所示。在图10所示的实施例中，业务集群#2的业务流量例如可全部切换至业务集群#1中，此时，业务集群#1可承载45％的业务流量，业务集群#3可承载55％的业务流量，业务集群#2不承载业务流量。在一些实施例中，若s303中未对目标版本进行修复，则可将生产集群#2对应的产品版本升级为v2版本。
109.至此，灰度发布+滚动升级的过程即可结束。升级完成后，可恢复原来的三个业务集群共同承载业务流量对外提供服务的状态，并可撤销部署在灰度规则管理模块204的灰度规则。在整个灰度验证和滚动升级过程中，始终有两个业务集群可对外提供服务，从而保障了系统的高可靠性。
110.需要说明的是，在本技术实施例中，集群管理模块201还可依据本次升级的可灰评估结果确定多个业务集群作为灰度集群，相应地，将对灰度集群进行版本升级时也可对多
个业务集群同时进行升级，类似地，滚动升级时也可对多个业务集群同时进行升级。对多个业务集群同时升级的实现流程和对单个业务集群升级的实现流程类似，这里不再赘述。
111.s305，在对目标版本进行验证未通过的情况下，将灰度集群对应的产品版回退为升级之前的版本。
112.目标用户登录到灰度集群后，若验证发现目标版本存在重大质量缺陷，则可将灰度集群对应的产品版回退为升级之前的版本。
113.首先，应立即撤销部署在灰度规则管理模块204的灰度规则，包括全球广域网(world wide web，web)访问和应用程序接口(application program interface，api)请求的规则。之后，可将灰度集群(业务集群#3)承载的业务流量切回至生产集群(业务集群#1和业务集群2)，由双业务集群承载业务流量，再将灰度集群的版本回退为升级之前的版本(即v1版本)。回退操作完成后，可恢复原来的三个业务集群承载业务流量的状态，并结束灰度发布。版本回退前三个业务集群的状态可以参考图7。版本回退后三个业务集群的状态如图11所示。
114.根据上述实现流程，本技术实施例提供的灰度升级的方法可实现以下功能：
115.1)商城灰度集群动态管理，建设三个对等集群，灰度发布(灰度升级)时由流量管控引擎的集群管理模块选择一个业务集群作为灰度发布的验证集群，灰度发布完成后，灰度集群转换为业务集群，保障资源的充分使用，并且无论是灰度发布期间还是滚动升级时，商城应用至少有两个完整独立业务集群共同分担流量，承载生产业务并提供服务，保障系统的可靠性。
116.2)商城用户访问灰度集群时，由流量管控引擎的路由管理模块根据灰度规则管理的灰度规则进行动态路由控制，用户访问商城的登录请求、业务流程按照灰度规则由路由管理模块智能控制是否路由至灰度集群，，用户前台无感知，同时提高了灰度验证的覆盖率。
117.如前文所述，传统的灰度发布(灰度升级)方案中，灰度环境有独立登录门户(或升级体验版本客户端)，与生产环境不同，体验灰度需要用户操作，由用户选择切换至灰度环境体验新功能，如果选择切换至灰度环境的用户较少，则会导致灰度验证不足。本技术实施例可针对用户请求，由流量管控引擎的路由管理模块判断用户的请求是否路由至灰度集群，无需用户操作，用户在前台的体验过程中无感知。另一方面，由于传统的灰度发布方案中灰度环境是固定的，有一个专门的灰度环境体验新特性和应用，为避免资源浪费，灰度集群硬件配置低于生产环境，导致部分场景无法验证，本技术实施例采取的方案中，使用三个对等的业务集群，灰度集群可由流量管控引擎的从业务集群中选择一个作为灰度发布的验证集群，提高系统的灵活性。灰度发布验证完成后，转为生产环境，避免资源浪费，保持三个业务集群全部对外提供服务。同时商城系统灰度发布和滚动升级过程中都有一个或多个业务集群承载生产业务流量对外提供服务，时刻保证系统的高可靠性，以便于更好地应对突发业务的流量激增。
118.基于前述的实施例，本技术实施例提供一种灰度升级的装置，该装置包括所包括的各模块，可以通过计算机设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(central processing unit，cpu)、微处理器(microprocessor unit，mpu)、数字信号处理器(digital signal processor，dsp)或现场
可编程门阵列(field programmable gate array，fpga)等。
119.图12示出了本技术实施例提供的一种灰度升级的装置1200的组成结构。如图12所示，装置1200可以包括：第一确定模块1201、第一升级模块1202和第二升级模块1203；其中，
120.第一确定模块1201，用于将产品版本相同的多个业务集群中的任一业务集群确定为灰度集群，将多个业务集群中除灰度集群之外的业务集群确定为生产集群；第一升级模块1202，用于将灰度集群对应的产品版本升级为目标版本；第二升级模块1203，用于在对目标版本进行验证通过的情况下，将生产集群对应的产品版本升级为目标版本。
121.在一些实施例中，装置1200还包括获取模块、第二确定模块和第一验证模块；获取模块，用于获取第一用户集合中第一用户的属性信息；第二确定模块，用于根据与目标版本的新功能和/或新配置参数相关的灰度规则，和第一用户的属性信息，确定第一用户是否为目标用户，得到包括目标用户的第二用户集合；第一验证模块，用于通过第二用户集合，对目标版本进行验证。
122.在一些实施例中，灰度规则包括灰度标识；第二确定模块包括匹配单元、和确定单元；匹配单元，用于将第一用户的属性信息和灰度标识进行匹配；确定单元，用于在第一用户的属性信息和灰度标识相匹配的情况下，确定第一用户为目标用户。
123.在一些实施例中，第一升级模块1202包括第一切换单元、关停单元和第一升级单元；第一切换单元，用于将灰度集群的业务流量切换至生产集群；关停单元，用于关停灰度集群对外提供业务的功能；第一升级单元，用于在关停灰度集群对外提供业务的功能的情况下，将灰度集群对应的产品版本升级为目标版本。
124.在一些实施例中，生产集群包括第一生产集群和第二生产集群；第二升级模块1203包括第二切换单元和第二升级单元；第二切换单元，用于将第一生产集群的业务流量切换至第二生产集群和/或灰度集群；第二升级单元，用于将第一生产集群对应的产品版本升级为目标版本；第二切换单元，还用于将第二生产集群的业务流量切换至第一生产集群和/或灰度集群；第二升级单元，还用于将第二生产集群对应的产品版本升级为目标版本。
125.在一些实施例中，装置1200还包括第一切换模块、修复模块、第二切换模块和第二验证模块；第一切换模块，用于在对目标版本进行验证未通过的情况下，将第二用户集合的业务流量从灰度集群切换至生产集群；修复模块，用于对目标版本进行修复；第二切换模块，用于在修复完成之后，将第二用户集合的业务流量从生产集群切换至灰度集群；第二验证模块，用于通过第二用户集合，对修复之后的目标版本进行验证。
126.在一些实施例中，装置1200还包括删改模块、第三切换模块和回退模块；删改模块，用于在对目标版本进行验证未通过的情况下，删除或更改灰度规则，以使得用户无法访问灰度集群；第三切换模块，用于将第二用户集合的业务流量从灰度集群切换至生产集群；回退模块，用于将灰度集群对应的产品版本回退为升级之前的版本。
127.以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。在一些实施例中，本技术实施例提供的装置具有的功能或包含的模块可以用于执行上述方法实施例描述的方法，对于本技术装置实施例中未披露的技术细节，请参照本技术方法实施例的描述而理解。
128.需要说明的是，本技术实施例中，如果以软件功能模块的形式实现上述的方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的
理解，本技术实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本技术各个实施例所述方法的全部或部分。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read only memory，rom)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本技术实施例不限制于任何特定的硬件、软件或固件，或者硬件、软件、固件三者之间的任意结合。
129.本技术实施例还提供一种计算机设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法中的部分或全部步骤。
130.本技术实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述方法中的部分或全部步骤。所述计算机可读存储介质可以是瞬时性的，也可以是非瞬时性的。
131.本技术实施例还提供一种计算机程序，包括计算机可读代码，在所述计算机可读代码在计算机设备中运行的情况下，所述计算机设备中的处理器执行用于实现上述方法中的部分或全部步骤。
132.本技术实施例还提供一种计算机程序产品，所述计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，所述计算机程序被计算机读取并执行时，实现上述方法中的部分或全部步骤。该计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一些实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一些实施例中，计算机程序产品具体体现为软件产品，例如软件开发包(software development kit，sdk)等等。
133.这里需要指出的是：上文对各个实施例的描述倾向于强调各个实施例之间的不同之处，其相同或相似之处可以互相参考。以上设备、存储介质、计算机程序及计算机程序产品实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本技术设备、存储介质、计算机程序及计算机程序产品实施例中未披露的技术细节，请参照本技术方法实施例的描述而理解。
134.需要说明的是，图13为本技术实施例中计算机设备的一种硬件实体示意图，如图13所示，该计算机设备1300的硬件实体包括：处理器1301、通信接口1302和存储器1303，其中：
135.处理器1301通常控制计算机设备1300的总体操作。
136.通信接口1302可以使计算机设备通过网络与其他终端或服务器通信。
137.存储器1303配置为存储由处理器1301可执行的指令和应用，还可以缓存待处理器1301以及计算机设备1300中各模块待处理或已经处理的数据(例如，图像数据、音频数据、语音通信数据和视频通信数据)，可以通过闪存(flash)或随机访问存储器(random access memory，ram)实现。处理器1301、通信接口1302和存储器1303之间可以通过总线1304进行数据传输。
138.应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本技术的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结
构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本技术的各种实施例中，上述各步骤/过程的序号的大小并不意味着执行顺序的先后，各步骤/过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术实施例的实施过程构成任何限定。上述本技术实施例序号仅仅为了描述，不代表实施例的优劣。
139.需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
140.在本技术所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。
141.上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。
142.另外，在本技术各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
143.本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(read only memory，rom)、磁碟或者光盘等各种可以存储程序代码的介质。
144.或者，本技术上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本技术各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、rom、磁碟或者光盘等各种可以存储程序代码的介质。
145.以上所述，仅为本技术的实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。

技术特征：
1.一种灰度升级的方法，其特征在于，所述方法包括：将产品版本相同的多个业务集群中的任一业务集群确定为灰度集群，将所述多个业务集群中除所述灰度集群之外的业务集群确定为生产集群；将所述灰度集群对应的产品版本升级为目标版本；在对所述目标版本进行验证通过的情况下，将所述生产集群对应的产品版本升级为所述目标版本。2.根据权利要求1所述的方法，其特征在于，所述方法还包括：获取第一用户集合中第一用户的属性信息；根据与所述目标版本的新功能和/或新配置参数相关的灰度规则，和所述第一用户的属性信息，确定所述第一用户是否为目标用户，得到包括所述目标用户的第二用户集合；通过所述第二用户集合，对所述目标版本进行验证。3.根据权利要求2所述的方法，其特征在于，所述灰度规则包括灰度标识；所述根据与所述目标版本的新功能和/或新配置参数相关的灰度规则，和所述第一用户的属性信息，确定所述第一用户是否为目标用户，包括：将所述第一用户的属性信息和所述灰度标识进行匹配；在所述第一用户的属性信息和所述灰度标识相匹配的情况下，确定所述第一用户为所述目标用户。4.根据权利要求1至3中任一项所述的方法，其特征在于，所述将所述灰度集群对应的产品版本升级为目标版本，包括：将所述灰度集群的业务流量切换至所述生产集群；关停所述灰度集群对外提供业务的功能；在关停所述灰度集群对外提供业务的功能的情况下，将所述灰度集群对应的产品版本升级为目标版本。5.根据权利要求1至3中任一项所述的方法，其特征在于，所述生产集群包括第一生产集群和第二生产集群；所述将所述生产集群对应的产品版本升级为所述目标版本，包括：将所述第一生产集群的业务流量切换至所述第二生产集群和/或所述灰度集群；将所述第一生产集群对应的产品版本升级为所述目标版本；将所述第二生产集群的业务流量切换至所述第一生产集群和/或所述灰度集群；将所述第二生产集群对应的产品版本升级为所述目标版本。6.根据权利要求2或3所述的方法，其特征在于，所述方法还包括：在对所述目标版本进行验证未通过的情况下，将所述第二用户集合的业务流量从所述灰度集群切换至所述生产集群；对所述目标版本进行修复；在所述修复完成之后，将所述第二用户集合的业务流量从所述生产集群切换至所述灰度集群；通过所述第二用户集合，对修复之后的目标版本进行验证。7.根据权利要求2或3所述的方法，其特征在于，所述方法还包括：在对所述目标版本进行验证未通过的情况下，删除或更改所述灰度规则，以使得用户
无法访问所述灰度集群；将所述第二用户集合的业务流量从所述灰度集群切换至所述生产集群；将所述灰度集群对应的产品版本回退为升级之前的版本。8.一种灰度升级的装置，其特征在于，所述装置包括第一确定模块、第一升级模块和第二升级模块；其中，所述第一确定模块，用于将产品版本相同的多个业务集群中的任一业务集群确定为灰度集群，将所述多个业务集群中除所述灰度集群之外的业务集群确定为生产集群；所述第一升级模块，用于将所述灰度集群对应的产品版本升级为目标版本；所述第二升级模块，用于在对所述目标版本进行验证通过的情况下，将所述生产集群对应的产品版本升级为所述目标版本。9.一种计算机设备，其特征在于，所述计算机设备包括：存储器，用于存储计算机可执行指令；处理器，与所述存储器连接，用于通过执行所述计算机可执行指令，实现权利要求1至7任一项所述的方法。10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序被至少一个处理器执行时实现如权利要求1至7任一项所述的方法。

技术总结
本申请实施例公开了一种灰度升级的方法、装置、设备和存储介质，该方法包括：将产品版本相同的多个业务集群中的任一业务集群确定为灰度集群，将多个业务集群中除灰度集群之外的业务集群确定为生产集群；将灰度集群对应的产品版本升级为目标版本，目标版本提供的业务具备新业务特性；在对目标版本进行验证通过的情况下，将生产集群对应的产品版本升级为目标版本。该方法通过从多个备选的业务集群中确定一个业务集群作为灰度集群，从而可使得灰度环境不固定，因而有利于增加灰度环境的丰富性。因而有利于增加灰度环境的丰富性。因而有利于增加灰度环境的丰富性。


技术研发人员：李万鹏 杨朋 赖思霞 张卓 蒋圆圆 马莉 李莉 梁恩磊 李飞龙 汪帆
受保护的技术使用者：中国移动通信集团有限公司
技术研发日：2022.10.28
技术公布日：2023/9/7