CN111767060A - 多阶段灰度验证方法、装置、电子设备及介质 - Google Patents

Abstract

本说明书实施例公开了一种多阶段灰度验证方法，在无固定用户标识场景下，接收用户进行业务操作的操作请求；若检测到所述操作请求为所述业务操作的首次请求，获取所述业务操作对应的唯一操作标识，为所述业务操作生成一随机数，并将所述唯一操作标识和所述随机数对应后缓存；以及将所述业务操作的后续每次操作请求中写入所述随机数；针对所述业务操作的所有操作请求，根据所述随机数和灰度发布的分流规则，确定所述业务操作对应的目标版本，其中，所述目标版本为原始版本和灰度发布版本中的任意一个。

Description

多阶段灰度验证方法、装置、电子设备及介质

技术领域

本说明书实施例涉及区块链处理技术领域，尤其涉及一种多阶段灰度验证方法、装置、电子设备及介质。

背景技术

在互联网产品领域，灰度发布是指应用服务平台系统在新代码或新数据推送过程中使用的一种平滑过渡发布方式，即：将新版本先只预部署在少部分服务器上，然后引导一部分用户预先体验，而另一部分用户继续使用老版本，收集新版本用户的体验数据并分析这部分用户验证结果，若使用新版本的用户验证结果符合预期，则可以逐步扩大用户范围，即逐渐发布及放量至全量用户。通过灰度发布可以保证系统版本更新运行稳定，在初始灰度的时候就可以及时发现、调整系统问题，以保证其影响度。

现有技术中在有固定用户标识的场景下，在设定灰度分流规则时，通常选择用户userId末尾数字作为灰度规则入参，例如将末尾2个数字(取值范围为00-99)，灰度规则设置为选取尾号为00-01用户(比例2％)作为灰度验证流量。

发明内容

本说明书实施例提供了一种多阶段灰度验证方法、装置、电子设备及介质，能够在无固定userId且多阶段灰度发布的场景下，能够确保同一笔业务操作关联的多个操作请求的灰度状态一致。

本说明书实施例第一方面提供了一种多阶段灰度验证方法，包括：

在无固定用户标识场景下，接收用户进行业务操作的操作请求；

若检测到所述操作请求为所述业务操作的首次请求，获取所述业务操作对应的唯一操作标识，为所述业务操作生成一随机数，并将所述唯一操作标识和所述随机数对应后缓存；以及

将所述业务操作的后续每次操作请求中写入所述随机数；

针对所述业务操作的所有操作请求，根据所述随机数和灰度发布的分流规则，确定所述业务操作对应的目标版本，其中，所述目标版本为原始版本和灰度发布版本中的任意一个。

本说明书实施例第二方面提供了一种多阶段灰度验证装置，包括：

操作请求接收单元，用于在无固定用户标识场景下，接收用户进行业务操作的操作请求；

缓存单元，若检测到所述操作请求为所述业务操作的首次请求，用于获取所述业务操作对应的唯一操作标识，为所述业务操作生成一随机数，并将唯一操作标识和所述随机数对应后缓存；以及

随机数写入单元，用于将所述业务操作的后续每次操作请求中写入所述随机数；

灰度分流单元，用于针对所述业务操作的所有操作请求，根据所述随机数和灰度发布的分流规则，确定所述业务操作对应的目标版本，其中，所述目标版本为原始版本和灰度发布版本中的任意一个。

本说明书实施例第三方面还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述多阶段灰度验证方法的步骤。

本说明书实施例第四方面还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时上述多阶段灰度验证方法的步骤。

本说明书实施例的有益效果如下：

基于上述技术方案，上述技术方案应用在无固定用户标识(userId)且多阶段灰度发布的场景下，针对无固定userId的问题，采用生成随机数的方式解决；而对于多阶段灰度业务场景下多个请求灰度状态不一致的问题，每一笔业务操作对应一个唯一操作标识，从而可以从操作请求提取出业务操作的唯一操作标识，以及在检测到业务操作的操作请求为首次请求时，会生成一个随机数，然后将随机数和唯一操作标识对应后缓存；并确保业务操作的后续操作请求均会从缓存中获取到业务操作的随机数，从而确保业务操作关联的多个操作请求对应同一个随机数。如此，在进行灰度规则逻辑的判断时，由于同一笔业务操作关联的多个操作请求对应同一个随机数，从而能够确保同一笔业务操作关联的多个操作请求都会由同一个版本应用进行处理，解决了无固定userId且多阶段灰度发布的场景下，同一笔业务操作关联的多个操作请求由不同版本应用进行处理的问题，实现了无固定userId且多阶段灰度发布的场景下，同一笔业务操作关联的多个操作请求的灰度状态一致的效果。

附图说明

图1为本说明书实施例中多阶段灰度验证方法的方法流程图；

图2为本说明书实施例中多阶段灰度验证系统的结构示意图；

图3为本说明书实施例中多阶段灰度验证装置的结构示意图；

图4为本说明书实施例中电子设备的结构示意图。

具体实施方式

为了更好的理解上述技术方案，下面通过附图以及具体实施例对本说明书实施例的技术方案做详细的说明，应当理解本说明书实施例以及实施例中的具体特征是对本说明书实施例技术方案的详细的说明，而不是对本说明书技术方案的限定，在不冲突的情况下，本说明书实施例以及实施例中的技术特征可以相互组合。

本说明书实施例提供的多阶段灰度方法应用于无固定用户标识且多阶段灰度发布场景中，其中，灰度发布是指在应用的新版和旧版本间平滑过渡的一种发布方式；单阶段灰度指针对单次业务操作请求后台应用次数等于1的业务灰度，例如查询类的应用通常使用单阶段灰度发布；多阶段灰度指针对单次业务操作请求后台应用次数大于1的业务灰度，例如支付类的应用，电子商务类的应用和金融类的应用等通常使用多阶段灰度发布。

本说明书实施例中，灰度发布通常包括以下7个步骤，其中，第一个步骤，定义目标，其主要定义本次灰度验证要达成的目标，即设定灰度版本流量效果验证表征；第二个步骤，选定策略，其主要是选定灰度验证分流的规则，比如选取满足userId(一种用户或业务上唯一标识)末尾两位数字为00-09区间则为灰度流量；第三个步骤，筛选流量，主要选定灰度分流规则中动态入参，选择标准一般需要随机分布，比如有固定userId的，可以选择userId末尾两位；无固定userId的，可以通过随机生成器Random随机生成一个数字。

以及，在上述3个步骤完成之后，开始启动第四个步骤，部署发布，即前面选定的分流规则在应用集群上灰度发布更新；在发布更新之后，执行第五个步骤，发布总结，即针对灰度流量执行的结果进行总结，评估是否符合设定预期目标；接下来执行第六个步骤，产品完善，如果第5步灰度评估结果不符合预期的话，则会重新进行产品变更进行调整；接下来执行第7个步骤，新一轮灰度发布，重新执行第1步至第6步。

具体来讲，在第二步骤中选定策略时，需要选定灰度分流规则，通常的分流规则有两种，其中，第一种分流规则通常一般选择用户userId末尾数字作为灰度规则入参，例如将末尾2个数字(取值范围为00-99)，灰度规则设置为选取尾号为00-01用户(比例2％)作为灰度验证流量；第二种分流规则，使用Random随机数分流，然而在一些无固定userId的场景下，通常采用Random随机数分流，即每一次请求都随机生成一个数字N，然后根据N作为灰度规则的入参，根据分流规则和入参N，确定每次一次请求是由灰度版本应用还是原始版本应用进行响应。

但在实际使用过程中会遇到无固定userId且多阶段灰度场景，由于多阶段灰度场景通常要求一次业务操作关联的多个请求的灰度规则判断结果一致，即一次业务操作关联的多个请求由同一个版本应用进行处理，要么全由灰度版本应用进行响应，要么全由原始版本应用进行处理；此时，会使得现有的技术方案均不能确保一次业务操作关联的多个请求由同一个版本应用进行处理，进而急需一种解决无固定userId且需要保证多阶段灰度一致性要求的技术方案。

第一方面，如图1所示，本说明书实施例提供一种多阶段灰度验证方法，包括：

S102、在无固定用户标识场景下，接收用户进行业务操作的操作请求；

S104、若检测到操作请求为业务操作的首次请求，获取业务操作对应的唯一操作标识，为业务操作生成一随机数，并将唯一操作标识和随机数缓存；

S106、将业务操作的后续每次操作请求中写入随机数；

S108、针对业务操作的所有操作请求，根据随机数和灰度发布的分流规则，确定业务操作对应的目标版本，其中，目标版本为原始版本和灰度发布版本中的任意一个。

本说明书实施例提供的多阶段灰度验证方法应用在应用服务器集群中，应用服务器集群通常采用分布式架构，当然也可以采用集中式架构。

其中，在步骤S102中，在无固定用户标识的业务场景下，用户可以操作客户端发起业务操作的操作请求，然后操作请求由客户端发送给应用服务器集群，使得应用服务器集群接收到操作请求。

本说明书实施例中的业务操作为业务上一次完整操作流程，且业务操作关联有多个操作请求，以及每笔业务操作都会向服务端下发一个唯一操作标识,该笔业务操作关联的每次操作请求中都会携带该唯一操作标识。进一步的，无固定用户标识包括无固定用户标识和无固定业务标识，如此，在无固定用户标识的业务场景下，客户端会可以为每一笔业务操作生成一个唯一操作标识，并将唯一操作标识写入到每一步业务操作关联的多个操作请求中，客户端会将每一笔业务操作生成的唯一操作标识下发给服务端，能够确保业务操作关联的多个操作请求均由同一个版本应用进行处理；由于客户端会将每一笔业务操作生成的唯一操作标识下发给服务端，如此，使得本说明书实施例的方法能够应用在无固定用户标识且无固定业务标识的场景下。

本说明书实施例中，唯一操作标识也可以由服务端生成，此时，客户端在每一笔业务操作的首次请求发送给服务端之后，服务端接收到每一笔业务操作的首次请求之后，会为每一笔业务操作生成一个唯一操作标识并返回给客户端，使得客户端在每一笔业务操作的后续每次操作请求中均携带唯一操作标识，进而确保业务操作关联的多个操作请求均由同一个版本应用进行处理。例如，用户使用智能手机A进行支付操作而扫描支付二维码之后，向支付应用发送二维码识别请求，从而使得支付应用接收到二维码识别请求，此时，支付操作为业务操作，若从缓存中未查找到二维码识别请求对应的唯一操作标识。由此，服务端可以判定二维码识别请求为支付操作的首次请求，然后为支付操作生成唯一操作标识，并将生成的唯一操作标识返回给智能手机A，以促使智能手机A在该支付操作的后续每次操作请求中均携带唯一操作标识。

本说明书实施例中业务操作可以支付操作和交易操作等，支付操作通常会关联多个操作请求包括二维码识别请求，支付请求、密码验证请求和支付确认请求；具体地，用户在使用客户端进行支付时，会首先扫描二维码，客户端会将扫描到的二维码之后，生成二维码识别请求发送给支付应用；由支付应用识别二维码，并将识别结果返回给客户端；客户端上显示识别结果，在用户输入支付金额点击确认之后，客户端将支付请求发送给支付应用；支付应用接收到支付请求之后，还需进行密码验证，使得客户端还需将密码验证请求发送给支付应用，支付应用在接收到支付请求且密码验证成功之后，还会发送一个支付确认给客户端；客户端完成支付确认之后，会将支付确认请求发送给支付应用；支付应用接收到支付确认请求之后完成支付操作，由此可知，支付操作通常会关联的多个操作请求；而支付操作关联的多个操作请求均需由同一个版本的支付应用处理。

例如，用户使用智能手机A进行支付操作而扫描支付二维码之后，向支付应用发送二维码识别请求，从而使得支付应用接收到二维码识别请求，此时，支付操作为业务操作。

在获取到操作请求之后，首先从缓存中查找唯一操作标识；若未查找到唯一操作识别，则判定操作请求为业务操作的首次请求，进而执行步骤S104；若查找到唯一操作标识，则判定操作请求为业务操作的非首次请求，获取与唯一操作识别对应的随机数，并将获取的随机数写入该操作请求中，使得一次业务操作关联的多个操作请求均携带的随机数均相同，使得在分流规则在对一次业务操作关联的多个操作请求进行分流时，由于一次业务操作关联的多个操作请求均携带的随机数均相同，从而确保一次业务操作关联的多个请求由同一个版本应用进行处理，进而实现了在无固定userId且多阶段灰度场景下能够保证多阶段灰度一致性的效果。

本说明书实施例中为了解决多阶段灰度业务场景下，一个业务操作关联的多个操作请求灰度状态不一致的问题，每一笔业务操作服务端都会生成一个唯一操作标识可以用token表示，如此，在接收到业务操作的首次操作请求之后，直接为该业务操作生成唯一操作标识，并将唯一操作标识返回给客户端，使得客户端在每一笔业务操作的后续每次操作请求中均携带对应的唯一操作标识。如此，使得服务端可以直接从业务操作的非首次操作请求中提取唯一操作标识，以避免出现重复性标识导致一次业务操作关联的多个操作请求会分布给不同版本应用进行处理，即导致出现多阶段灰度分布不一致的问题。进一步的，分布式缓存例如可以是Redis和MemCache等。

本说明书实施例中，在检测到操作请求为业务操作的首次请求时，获取唯一操作标识，此时，若唯一操作标识由客户端生成，则直接从操作请求中提取唯一操作标识；若唯一操作标识由服务端生成，服务端可以为业务操作分配一个唯一操作标识，并将生成的唯一操作标识返回；如此，服务端通常上述两种方式均可以获取到唯一操作标识，均可以促使客户端在业务操作的后续每次操作中均携带唯一操作标识。

以及，在检测到操作请求为业务操作的首次请求时，获取唯一操作标识之后，还需为业务操作生成一随机数，再将唯一操作标识和随机数缓存。以及，在将唯一操作标识和随机数缓存时，可以将唯一操作标识和随机数对应后存储在分布式缓存中，由于分布式缓存能够高性能地读取数据，能够动态地扩展缓存节点，能够自动发现和切换故障节点，以及能够自动均衡数据分区；而通过分布式缓存来存储唯一操作标识和随机数，能够在动态应用中减少数据库负载并提升访问速度。即，能够高性能读取唯一操作标识和随机数，从而能够有效提高多阶段灰度验证的效率。

本说明书实施例中，在将唯一操作标识与随机数进行缓存时，需要将将唯一操作标识和随机数对应后进行存储，具体地，可以将唯一操作标识和随机数组成一个键值对，并将组成的键值对存储在分布式缓存中。当然，也可以建立一个索引表，然后将业务表和随机数对应写入索引表中。下面具体以唯一操作标识和随机数组成一个键值为例。

具体来讲，分布式缓存可以采用Redis集群,Redis集群中存储格式是KV键值对，其中，K:唯一操作标识V:随机数，由于本说明书实施例是应用无固定userId且多阶段灰度的场景下，分流规则入参则采用的Random随机数。先根据唯一操作标识作为关键词去Redis集群查找，若没找到则认为操作请求是业务操作的首次请求，通过Random生成一个随机数N作为分流规则入参，此时，将唯一操作标识用token标识，分流规则入参用N表示，从而将<token,N>键值对写入Redis集群中；若找到则返回分流规则入参N，将N写入到到操作请求中。

本说明书实施例中，在将唯一操作标识和随机数对应后存储在分布式缓存中之后，包括：为唯一操作标识和随机数设置过期时间；如此，针对每笔业务操作，在接收到该笔业务操作的首次请求且存储唯一操作标识和随机数之后，为该笔业务操作的唯一操作标识和随机数设置过期时间，及时进行缓存清理淘汰，提高分布式缓存的使用效率。即，分布式缓存采用过期淘汰机制，为每笔业务操作的唯一操作标识和随机数设置过期时间。

本说明书实施例中过期时间可以由人工或设备自行设定，也可以根据实际情况进行设定，例如可以根据分布式缓存中的缓存容量和业务操作的出现频率而设定，过期时间例如可以设置为10分钟，15分钟，20分钟和30分钟等。

在接收到业务操作的后续操作请求之后，将业务操作的后续每次操作请求中写入随机数。具体地，针对业务操作的后续每次操作请求，在接收到后续该次操作请求之后，根据后续该次操作请求携带的唯一操作标识，从缓存中获取随机数；根据随机数和灰度发布的分流规则，确定目标版本；将后续该次操作请求发送给目标版本对应的服务器，以使得目标版本对应的服务器处理操作请求，并将处理结果返回给客户端。

本说明书实施例中，若在从缓存中未查找到唯一操作标识，则从缓存中获取与唯一操作标识对应的随机数，并将获取的随机数写入操作请求中，从而利用一笔业务操作的唯一操作标识，能够将一笔业务操作关联的多个操作请求均对应同一个随机数。如此，在进行灰度规则逻辑的判断时，由于一笔业务操作关联的多个操作请求对应同一个随机数，从而能够确保同一笔业务操作关联的多个操作请求都会由同一个版本应用进行处理，解决了无固定userId且多阶段灰度发布的场景下，同一笔业务操作关联的多个操作请求由不同版本应用进行处理的问题，实现了无固定userId且多阶段灰度发布的场景下，同一笔业务操作关联的多个操作请求的灰度状态一致的效果。

接下来执行步骤S108,针对业务操作的所有操作请求，根据随机数和灰度发布的分流规则，确定业务操作对应的目标版本，其中，目标版本为原始版本和灰度发布版本中的任意一个。

具体来讲，在检测到业务操作的操作请求为首次请求之后，可以通过随机数生成器为业务操作生成一随机数，根据随机数和分流规则，确定业务操作对应的目标版本，以使得目标版本应用来处理业务操作的操作请求，并将处理结果返回给客户端。相应地，在接收到业务操作的后续每次操作请求之后，均会从缓存中获取与唯一操作标识对应的随机数据，并在后续每次操作请求中均会写入随机数，使得业务操作的所有操作请求均会写入同一个随机数，从而确保业务操作关联的多个操作请求对应同一个随机数，而分流规则针对同一个随机数会将业务操作关联的多个操作请求分配给同一个版本应用，从而实现了无固定userId且多阶段灰度发布的场景下，同一笔业务操作关联的多个操作请求的灰度状态一致的效果。

本说明书实施例中，分流规则可以由人工或设备设定，也可以根据实际情况设定，分流规则可以是一个逻辑表达式计算，输入一个随机数作为分流规则入参，输出一个0-100的整数，假如设置的灰度比例是50％，那么0-49走灰度逻辑，即，分流规则输出的数在0-49之间时，则由灰度版本应用处理对应的操作请求；以及50-99走非灰度逻辑，即，分流规则输出的数值在50-99之间时则由原始版本应用处理对应的操作请求。

例如，以用户使用智能手机A进行支付操作而扫描支付二维码之后，向支付应用发送二维码识别请求，从而使得支付应用接收到二维码识别请求，此时，从二维码识别请求获取到该业务操作的唯一操作标识例如为01010111，将01010111作为关键词在Redis中进行查找，若从Redis未查找到01010111，则使用Random生成一随机数54，根据01010111和54组成键值对得到K：01010111，V：54；然后将<01010111,54>键值对写入Redis中。以及，根据54和灰度发布的分流规则，确定目标版本，目标版本为灰度版本，则使用灰度版本应用对扫码支付二维码进行处理，将处理结果返回给智能手机A。

以及，可以根据唯一操作标识，接收到支付操作的后续每次操作请求，此时，针对支付操作的后续每次操作请求，根据唯一操作标识01010111从Redis获取54，并将54写入到支付操作的后续每次操作请求中；根据54和灰度发布的分流规则，确定目标版本，目标版本为灰度版本，则使用灰度版本应用对后续每次操作请求进行处理，将后续每次操作请求的处理结果返回给智能手机A。

本说明书实施例还提供了一种多阶段灰度验证系统，如图2所示，包括客户端20、应用集群21和分布式缓存22。其中，客户端20包括但不限于笔记本电脑、台式电脑、智能手机、平板电脑和智能音箱等；应用集群21包括路由分流模块210和逻辑执行模块，并根据灰度分流规则，应用集群21划分成正式版本机器集群V1和灰度版本机器集群V2；分布式缓存22例如可以是Redis和MemCache等。下面针对业务操作B进行完整性的叙述，具体如下：

步骤1.1、客户端20发起业务操作B的第一次请求，路由分流模块210接收到第一次请求之后，从第一次请求中获取业务操作B的唯一操作标识用token表示；即获取到token。

步骤1.2、更新分布式缓存22。路由分流模块210接收到业务操作B的第一次请求之后，将token作为关键词从分布式缓存22进行查找，由于是业务操作B的第一次请求，因此，从分布式缓存22为未查找到token，则使用Random生成器生成一随机数N；然后将<token,N>键值对写入分布式缓存22，从而更新分布式缓存22。

另外，在将token作为关键词从分布式缓存22进行查找时，如果找到则返回找到的结果。而且分布式缓存22采用过期淘汰机制，缓存时间可以设定最长30分钟，即一个键值对存储达到30分钟之后就会从分布式缓存22删除。

步骤1.3、根据步骤1.2中返回的分流规则入参N，逻辑执行模块执行分流规则，如果满足灰度规则，则逻辑执行模块将第一次请求发送给灰度版本机器集群V2进行处理，得到处理结果；否则，则将第一次请求发送给正式版本机器集群V1进行处理，得到处理结果。

具体地，灰度规则可以使用逻辑表达式计算，输入一个入参N，输出一个0-100的整数，其设置规则为灰度比例是50％，那么0-49走灰度逻辑，50-99走非灰度逻辑。此时，业务操作B的第一次请求对应的N输入到灰度规则中，输出的数字如果为68，则确定走非灰度逻辑，即，将第一次请求发送给正式版本机器集群V1进行处理，得到处理结果。

步骤1.4、将步骤1.3的结果返回给客户端20。

步骤2.1、将客户端发起业务操作B的第二次请求，路由分流模块210接收到第二次请求之后，从请求参数中获取唯一操作标识token。

步骤2.2、缓存查询，根据第二次请求中token,从分布式缓存22中获取分流规则入参N并返回。

具体来讲，根据第二次请求中的token，将token作为关键词从分布式缓存22进行查找，由于是业务操作B的第而次请求，因此，能够从分布式缓存22查找到token；然后根据分布式缓存22中存储的键值对，获取token对应的N并返回给客户端20，促使第二次请求中写入N。

步骤2.3、同步骤1.3根据分流规则入参N，逻辑执行模块执行分流规则，如果满足灰度规则，则逻辑执行模块将第一次请求发送给灰度版本机器集群V2进行处理，得到处理结果；否则，则将第一次请求发送给正式版本机器集群V1进行处理，得到处理结果。

其中，步骤2.3的具体实施过程中参见步骤1.3的陈述。

步骤2.4、将步骤2.3的处理结果返回给客户端20。

以及，针对业务操作B的后续N-2次请求将重复执行步骤2.1-2.4的逻辑，直至业务操作B结束。如此，针对每笔业务操作均执行上述操作，从而能够实现无固定userId且多阶段灰度发布的场景下，同一笔业务操作关联的多个操作请求的灰度状态一致的效果。

本说明书实施例采用的技术方案是：针对无固定userId的问题，采用生成随机数的方式解决；而对于多阶段灰度业务场景下多个请求灰度状态不一致的问题，每一笔业务操作对应一个唯一操作标识，从而可以从操作请求提取出业务操作的唯一操作标识，以及在检测到业务操作的操作请求为首次请求时，会生成一个随机数，然后将随机数和唯一操作标识对应后缓存；并确保业务操作的后续操作请求均会从缓存中获取到业务操作的随机数，从而确保业务操作关联的多个操作请求对应同一个随机数。如此，在进行灰度规则逻辑的判断时，由于同一笔业务操作关联的多个操作请求对应同一个随机数，从而能够确保同一笔业务操作关联的多个操作请求都会由同一个版本应用进行处理，解决了无固定userId且多阶段灰度发布的场景下，同一笔业务操作关联的多个操作请求由不同版本应用进行处理的问题，实现了无固定userId且多阶段灰度发布的场景下，同一笔业务操作关联的多个操作请求的灰度状态一致的效果。

第二方面，基于相同的技术构思，本说明书实施例提供一种多阶段灰度验证装置，如图3所示，包括：

操作请求接收单元301，用于在无固定用户标识场景下，接收用户进行业务操作的操作请求；

缓存单元302，若检测到所述操作请求为所述业务操作的首次请求，用于获取所述业务操作对应的唯一操作标识，为所述业务操作生成一随机数，并将唯一操作标识和所述随机数对应后缓存；以及

随机数写入单元303，用于将所述业务操作的后续每次操作请求中写入所述随机数；

灰度分流单元304，用于针对所述业务操作的所有操作请求，根据所述随机数和灰度发布的分流规则，确定所述业务操作对应的目标版本，其中，所述目标版本为原始版本和灰度发布版本中的任意一个。

在一种可选的实施方式中，随机数写入单元303，用于针对所述业务操作的后续每次操作请求，在接收到后续该次操作请求之后，根据后续该次操作请求携带的唯一操作标识，从所述缓存中获取所述随机数，将获取的所述随机数写入该次操作请求中。

在一种可选的实施方式中，缓存单元302，用于将所述唯一操作标识和所述随机数组成一个键值对，将组成的键值对存储在分布式缓存中。

在一种可选的实施方式中，灰度验证装置还包括：

过期时间设置单元，用于在将所述唯一操作标识和所述随机数对应后缓存之后，为所述唯一操作标识和所述随机数设置过期时间。

在一种可选的实施方式中，灰度验证装置还包括：

判断单元，用于在接收用户进行业务操作的操作请求之后，获取所述操作请求中携带的所述唯一操作标识，从所述缓存中查找与所述唯一操作标识对应的随机数；若未查找到与所述唯一操作标识对应的随机数，则判定所述操作请求为所述业务操作的首次请求；若查找到与所述唯一操作标识对应的随机数，则判定所述操作请求为所述业务操作的非首次请求。

第三方面，基于与前述实施例中多阶段灰度验证方法同样的发明构思，本说明书实施例还提供一种电子设备，如图4所示，包括存储器404、处理器402及存储在存储器404上并可在处理器402上运行的计算机程序，所述处理器402执行所述程序时实现前文所述多阶段灰度验证方法的任一方法的步骤。

其中，在图4中，总线架构(用总线400来代表)，总线400可以包括任意数量的互联的总线和桥，总线400将包括由处理器402代表的一个或多个处理器和存储器404代表的存储器的各种电路链接在一起。总线400还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口405在总线400和接收器401和发送器403之间提供接口。接收器401和发送器403可以是同一笔元件，即收发机，提供用于在传输介质上与各种其他装置通信的单元。处理器402负责管理总线400和通常的处理，而存储器404可以被用于存储处理器402在执行操作时所使用的数据。

第四方面，基于与前述实施例中多阶段灰度验证方法的发明构思，本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前文所述多阶段灰度验证方法的任一方法的步骤。

本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的设备。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令设备的制造品，该指令设备实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本说明书的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本说明书范围的所有变更和修改。

显然，本领域的技术人员可以对本说明书进行各种改动和变型而不脱离本说明书的精神和范围。这样，倘若本说明书的这些修改和变型属于本说明书权利要求及其等同技术的范围之内，则本说明书也意图包含这些改动和变型在内。

Claims (12)

1.一种多阶段灰度验证方法，包括：

在无固定用户标识场景下，接收用户进行业务操作的操作请求；

若检测到所述操作请求为所述业务操作的首次请求，获取所述业务操作对应的唯一操作标识，为所述业务操作生成一随机数，并将所述唯一操作标识和所述随机数对应后缓存；以及

将所述业务操作的后续每次操作请求中写入所述随机数；

针对所述业务操作的所有操作请求，根据所述随机数和灰度发布的分流规则，确定所述业务操作对应的目标版本，其中，所述目标版本为原始版本和灰度发布版本中的任意一个。

2.如权利要求1所述的方法，所述将所述业务操作的后续每次操作请求中写入所述随机数，包括：

针对所述业务操作的后续每次操作请求，在接收到后续该次操作请求之后，根据后续该次操作请求携带的唯一操作标识，从所述缓存中获取所述随机数，将获取的所述随机数写入该次操作请求中。

3.如权利要求1或2所述的方法，所述将所述唯一操作标识和所述随机数对应后缓存，包括：

将所述唯一操作标识和所述随机数组成一个键值对，将组成的键值对存储在分布式缓存中。

4.如权利要求3所述的方法，在将所述唯一操作标识和所述随机数对应后缓存之后，包括：

为所述唯一操作标识和所述随机数设置过期时间。

5.如权利要求4所述的方法，在接收用户进行业务操作的操作请求之后，所述方法还包括：

获取所述操作请求中携带的所述唯一操作标识，

从所述缓存中查找与所述唯一操作标识对应的随机数；

若未查找到与所述唯一操作标识对应的随机数，则判定所述操作请求为所述业务操作的首次请求；

若查找到与所述唯一操作标识对应的随机数，则判定所述操作请求为所述业务操作的非首次请求。

6.一种多阶段灰度验证装置，包括：

操作请求接收单元，用于在无固定用户标识场景下，接收用户进行业务操作的操作请求；

缓存单元，若检测到所述操作请求为所述业务操作的首次请求，用于获取所述业务操作对应的唯一操作标识，为所述业务操作生成一随机数，并将唯一操作标识和所述随机数对应后缓存；以及

随机数写入单元，用于将所述业务操作的后续每次操作请求中写入所述随机数；

灰度分流单元，用于针对所述业务操作的所有操作请求，根据所述随机数和灰度发布的分流规则，确定所述业务操作对应的目标版本，其中，所述目标版本为原始版本和灰度发布版本中的任意一个。

7.如权利要求6所述的装置，所述随机数写入单元，用于针对所述业务操作的后续每次操作请求，在接收到后续该次操作请求之后，根据后续该次操作请求携带的唯一操作标识，从所述缓存中获取所述随机数，将获取的所述随机数写入该次操作请求中。

8.如权利要求6或7所述的装置，所述缓存单元，用于将所述唯一操作标识和所述随机数组成一个键值对，将组成的键值对存储在分布式缓存中。

9.如权利要求8所述的装置，还包括：

过期时间设置单元，用于在将所述唯一操作标识和所述随机数对应后缓存之后，为所述唯一操作标识和所述随机数设置过期时间。

10.如权利要求9所述的装置，还包括：

判断单元，用于在接收用户进行业务操作的操作请求之后，获取所述操作请求中携带的所述唯一操作标识，从所述缓存中查找与所述唯一操作标识对应的随机数；若未查找到与所述唯一操作标识对应的随机数，则判定所述操作请求为所述业务操作的首次请求；若查找到与所述唯一操作标识对应的随机数，则判定所述操作请求为所述业务操作的非首次请求。

11.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现权利要求1-5任一项所述方法的步骤。

12.一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现权利要求1-5任一项所述方法的步骤。

Images