CN117874745A - 灰度验证方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请提供一种灰度验证方法、装置、电子设备及存储介质，涉及计算机技术领域。该方法包括：在处理第一业务逻辑过程中，若触发对第一业务逻辑对应的变更业务代码的灰度验证，则读取用于验证变更业务代码对应的流量拦截规则；流量拦截规则包括拦截点区间；拦截点区间用于表征第一业务逻辑中需要验证的接口范围；变更业务代码位于拦截点区间；获取拦截点区间的首个接口的流量作为灰度流量；利用灰度流量对变更业务代码进行灰度验证。本申请实施例通过利用灰度流量对发生变更的业务代码进行灰度验证，能够及时地发现灰度发布过程中，变更业务带来的问题，从而提高灰度发布版本的准确性。

Description

灰度验证方法、装置、电子设备及存储介质

技术领域

本申请涉及计算机技术领域，具体而言，涉及一种灰度验证方法、装置、电子设备及存储介质。

背景技术

随着公司业务的快速发展，产品更新迭代加快，客户量也迅速增长，传统的发布方式已经不能满足快速、稳定、低风险的需求。在此背景下，灰度发布应运而生。并且，灰度发布已经成为一种重要的发布策略。

但现有的灰度发布策略都是以服务为对象进行灰度，由于服务的运行状态正常并不能表明该服务对应的变更业务是正常的，因此，不能及时的发现灰度过程中业务功能变更出现的问题。

发明内容

本申请实施例的目的在于提供一种灰度验证方法、装置、电子设备及存储介质，用以通过利用灰度流量对发生变更的业务代码进行灰度验证，能够及时地发现灰度发布过程中，变更业务带来的问题，从而提高灰度发布版本的准确性。

第一方面，本申请实施例提供一种灰度验证方法，该方法包括：在处理第一业务逻辑过程中，若触发对第一业务逻辑对应的变更业务代码的灰度验证，则读取用于验证变更业务代码对应的流量拦截规则；流量拦截规则包括拦截点区间；拦截点区间用于表征第一业务逻辑中需要验证的接口范围；变更业务代码位于拦截点区间；获取拦截点区间的首个接口的流量作为灰度流量；利用灰度流量对变更业务代码进行灰度验证。

本申请实施例在触发了对第一业务逻辑对应的变更业务代码的灰度验证时，读取验证变更业务代码对应的流量拦截规则，基于流量拦截规则中的拦截点区间确定首个接口，获取首个接口的流量作为灰度流量对变更业务代码进行灰度验证。在这个过程中，设置拦截点区间提高了灰度验证范围的针对性和灵活性。并且，变更的业务代码位于拦截点区间，因此，获取拦截点区间首个接口的流量作为灰度流量除了能够验证变更的业务代码的正确性，还能验证位于拦截点区间其他未发生更变的业务代码的正确性，进而验证变更的业务代码不会影响未发生变更的业务代码。因此，利用灰度流量对拦截点区间中的业务功能进行验证能够及时地发现灰度发布过程中，变更业务带来的影响和问题，从而提高灰度发布版本的准确性。

在一些实施例中，流量拦截规则还包括拦截的流量类型，流量类型包括历史流量类型和/或实时流量类型；获取拦截点区间的首个接口的流量作为灰度流量，包括：针对流量类型为历史流量类型的情况，获取拦截点区间的首个接口的历史流量作为灰度流量；历史流量为第二业务逻辑中在历史时间段内经过首个接口的流量；第一业务逻辑为在第二业务逻辑的基础上，对第二业务逻辑中的部分业务代码进行变更后获得；针对流量类型为实时流量类型的情况，获取拦截点区间的首个接口的实时流量作为灰度流量。

本申请实施例中，考虑到在一段时间内用户可能不会使用目标系统，用户不使用目标系统则不会产生实时流量。因此，在本申请实施例中，灰度流量可以是历史流量和/或实时流量。使用历史流量可立马对存在变更的业务代码的业务逻辑进行灰度验证，使用实时流量可直接验证存在变更业务代码的第一业务逻辑的正确性。并且，由于历史流量是第二业务逻辑中在历史时间段内经过首个接口的流量，而第一业务逻辑为在第二业务逻辑的基础上，对第二业务逻辑中的部分业务代码进行变更后获得，因此，使用历史流量对变更的业务代码进行灰度验证，除了能及时地执行验证过程外，还能反映存在变更业务代码的第一业务逻辑的整体鲁棒性。

在一些实施例中，利用灰度流量对变更业务代码进行灰度验证，包括：从拦截点区间的首个接口放行灰度流量，使灰度流量在拦截点区间内按接口的先后调用顺序进行流转，以利用灰度流量对变更业务代码进行灰度验证。

本申请实施例通过在拦截点区间的首个接口放行灰度流量，使得灰度流量在拦截点区间内按接口顺序进行流转，以对拦截点区间包括的接口进行验证，提高灰度验证的灵活性。

在一些实施例中，该方法还包括：在拦截点区间的最后一个接口对灰度流量进行销毁。

本申请实施例在拦截点区间的最后一个接口对灰度流量进行销毁，使得灰度流量不再向下流转，降低灰度流量对拦截点区间的下游微服务的影响。

在一些实施例中，在获取拦截点区间的首个接口的历史流量作为灰度流量之前，该方法还包括：

基于预先配置的代码标识深拷贝与代码标识匹配的第二业务逻辑中历史时间经过首个接口的流量作为历史流量。

本申请实施例通过代码标识深拷贝与代码标识匹配的第二业务逻辑中，历史时间经过首个接口的流量作为历史流量，使得进行灰度验证的灰度流量是变更的业务代码所需的灰度流量，从而针对性地使用历史流量及时地对存在变更的业务代码的业务逻辑进行灰度验证。

在一些实施例中，在利用灰度流量对变更业务代码进行灰度验证之后，该方法还包括：对灰度验证过程中产生的灰度数据进行删除。

本申请实施例通过对灰度过程中产生的灰度数据进行删除，避免数据泄露造成的数据滥用和数据安全问题。同时，也减少了存储负担，优化存储资源，提高系统处理效率。

在一些实施例中，该方法还包括：生成灰度验证过程中的灰度日志信息；基于灰度日志信息对变更业务代码的正确性进行评估。

本申请实施例通过灰度日志信息记录灰度验证过程的情况，以对灰度验证的情况进行评估，帮助开发人员能快速定位和解决问题。

第二方面，本申请实施例提供一种灰度验证装置，该装置包括：读取模块，用于在处理第一业务逻辑过程中，若触发对第一业务逻辑对应的变更业务代码的灰度验证，则读取用于验证变更业务代码对应的流量拦截规则；流量拦截规则包括拦截点区间；拦截点区间用于表征第一业务逻辑中需要验证的接口范围；变更业务代码位于拦截点区间；获取模块，用于获取拦截点区间的首个接口的流量作为灰度流量；验证模块，用于利用灰度流量对变更业务代码进行灰度验证。

第三方面，本申请实施例提供一种电子设备，包括：处理器、存储器、存储介质和总线，其中，所述处理器和所述存储器通过所述总线完成相互间的通信；所述存储器存储有可被所述处理器执行的程序指令，所述处理器调用所述程序指令能够执行第一方面的方法步骤。

第四方面，本申请实施例提供一种非暂态计算机可读存储介质，包括：所述计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行第一方面的方法步骤。

本申请的其他特征和优点将在随后的说明书阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请实施例了解。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种灰度验证方法的流程示意图；

图2为本申请实施例提供的一种灰度验证装置的结构示意图；

图3为本申请实施例提供的电子设备结构示意图。

具体实施方式

下面将结合附图对本申请技术方案的实施例进行详细的描述。以下实施例仅用于更加清楚地说明本申请的技术方案，因此只作为示例，而不能以此来限制本申请的保护范围。

需要说明的是，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同；本文中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请；本申请的说明书和权利要求书及上述附图说明中的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。

在本申请实施例的描述中，技术术语“第一”“第二”等仅用于区别不同对象，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量、特定顺序或主次关系。在本申请实施例的描述中，“多个”的含义是两个以上，除非另有明确具体的限定。

在本申请实施例的描述中，术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

随着公司业务的快速发展，产品更新迭代加快，客户量也迅速增长，传统的发布方式已经不能满足快速、稳定、低风险的需求。在此背景下，灰度发布应运而生。并且，灰度发布已经成为一种重要的发布策略。

现有的灰度发布的方法有：

灰度发布(又名金丝雀发布)：将新版本服务和旧版本服务混合部署，通过增加新版本服务的流量来观察其表现，使变更业务能够平滑过渡；可以保证整体系统的稳定，在初始灰度的时候就可以发现、处理问题。

蓝绿部署：可以将用户流量从先前版本的应用或微服务逐渐转移到几乎相同的新版本中，旧版本成为蓝色环境，新版本称之为绿色环境。一旦生产流量从蓝色转移到绿色，蓝色就可以在回滚或退出生产的情况下保持待机。

流量分离：将请求流量，有控制的分别路由到新版本和旧版本的服务，通过设置权重来控制每个版本的流量比例。

滚动发布：在灰度发布基础上进一步优化改进，是一种自动化程度较高的发布方式；逐个更新微服务实例，在每次更新后检查服务健康状态，确保新版本可以正常工作。

但上述灰度发布方法都是以服务为对象进行发布，其主要关注服务的可用性，不会深入检查业务功能的正确性。而在实际的生产环境中，发布服务通常意味着新增、修改或删除某些代码以实现特定的业务功能，因此，服务的运行状态正常并不能保证该服务对应的变更业务是正常的，使得不能及时的发现灰度发布过程中业务功能变更出现的问题。

示例性的，将登录功能部署在一个微服务中，原始版本的登录功能包括输入正确的账号和密码即可正常登录。新版本的登录功能新增动态验证码的校验部分，此时需要输入正确的账号、密码以及动态验证码才能正常登录。在进行灰度发布时，可正常调用登录的微服务，使得用户可输入账号、密码和动态验证码进行登录，但是由于开发人员在开发实现动态验证码校验的代码时，存在代码逻辑的问题或者数据依赖不清楚的问题或者配置参数不正确的问题等，使得即使输入了正确的账号、密码和动态验证码也不能保证一定能登录成功。因此，服务的运行状态正常并不能保证该服务对应的变更业务是正常的。

为解决上述问题，本申请实施例提供一种灰度验证方法，用于在触发灰度验证逻辑后，基于灰度流量对变更后的业务功能进行灰度验证。

图1为本申请实施例提供的一种灰度验证方法的流程示意图，可以理解的是，本申请实施例提供的灰度验证方法可以应用于终端设备(也可以称为电子设备)以及服务器；其中终端设备具体可以为智能手机、平板电脑、计算机、个人数字助理(PersonalDigitalAssistant，PDA)等；服务器具体可以为应用服务器，也可以为Web服务器。为便于理解本申请实施例提供的技术方案，下面以服务器作为执行主体为例，对本申请实施例提供的灰度验证方法的应用场景进行介绍。如图1所示，该方法包括：

步骤S101，服务器在处理第一业务逻辑过程中，若触发对第一业务逻辑对应的变更业务代码的灰度验证，则读取用于验证变更业务代码对应的流量拦截规则；流量拦截规则包括拦截点区间；拦截点区间用于表征第一业务逻辑中需要验证的接口范围；变更业务代码位于拦截点区间。

在具体实施过程中，开发人员基于变更业务需求开发该需求对应的变更业务代码，并将该变更业务代码发布到生产环境中，以与生产环境中已有的业务代码构成第一业务逻辑。其中，一个业务流程对应一个业务逻辑。

需要说明的是，技术人员在开发变更业务代码时，在变更业务代码的入口处，增加是否对该变更业务代码进行灰度验证的判断条件，以使服务器在处理第一业务逻辑的过程中，执行到变更的业务代码的位置时，若该变更业务代码满足灰度验证的条件，则执行读取用于验证变更业务代码对应的流量拦截规则的过程。

示例性的，对变更业务代码进行灰度验证的判断条件如下：

ifis_grayscale＝“1”:

do_something()

其中，“is_grayscale”表征是否进行灰度验证的判断条件，“do_something()”表征变更业务代码的入口，当“is_grayscale”的值为1时，表明需要对“do_something()”中的变更业务代码进行灰度验证，否则不需要对“do_something()”中的变更业务代码进行灰度验证。

流量拦截规则为开发人员预先基于变更业务需求的特征进行个性化配置生成。流量拦截规则用于表征如何对变更的业务需求进行灰度验证，即如何对变更的业务需求对应的变更业务代码进行灰度验证。因此，针对不同的变更业务需求，其配置的流量拦截规则可能是不相同的。

流量拦截规则包括拦截点区间，拦截点区间用于表征第一业务逻辑中需要验证的接口范围，拦截点区间中每一个拦截点对应一个接口。

由于接口部署在微服务上，因此，拦截点包括两个要素，分别为微服务名称以及该微服务上的接口名称。示例性的，拦截点的信息如下：

其中，“service_name”表示微服务名称，“interface_name”表示接口名称。一个微服务可以创建的拦截点的个数小于等于该微服务所拥有的接口的个数。

应当知道的是，由于流量拦截规则为开发人员预先基于变更业务需求的特征进行个性化配置生成，因此，针对不同的变更业务需求，其拦截点区间的设置也是个性化的。

具体的，针对明确知道变更业务可能涉及哪些微服务上哪些接口时，可明确指出起始拦截点和终止拦截点，从而最小化灰度验证时涉及的微服务及接口，以此减少系统资源的消耗。针对变更业务涉及微服务范围不清晰的场景，在确定起始拦截点后，将第一业务逻辑的最后一个接口作为终止拦截点，虽然该拦截点区间较大，但是基于该拦截点区间进行的灰度验证过程覆盖的微服务更全、能够更全面的反映变更业务对下游服务的影响。

需要说明的是，开发人员在预先配置流量拦截规则时，可通过配置文件的形式对流量拦截规则进行配置。当服务器读取用于验证变更业务代码对应的流量拦截规则时，可加载对应的配置文件，以获得对应的流量拦截规则。也可将生成的流量拦截规则存储在数据库中，当服务器读取用于验证变更业务代码对应的流量拦截规则时，可直接读取数据库表，以从数据库中获得对应的流量拦截规则。

还需要说明的是，流量拦截规则的内容除了包括拦截点区间外，还可以包括变更业务需求的名称、进行灰度验证的时间、灰度流量的类型、灰度流量的比例、灰度数据的清理方式、清理灰度数据的SQL语句等内容。

示例性的，流量拦截规则配置如下：

(1)变更需求名称：客户授信时新增查询客户公积金；

(2)拦截点区间包括起始拦截点和结束拦截点：针对授信业务流程，包括微服务1-微服务4。此时，选择微服务1的某个接口作为起始拦截点A；选择微服务3的某个接口作为结束拦截点E；

(3)灰度验证的时间：选择每天下午16:00-18:00进行灰度验证；在每天下午17:00-17:30不进行灰度验证；

(4)灰度流量的类型：

将起始拦截点A的历史流量作为灰度流量，灰度流量的比例：将流经起始拦截点A的50％的历史流量作为灰度流量；

将起始拦截点A的实时流量作为灰度流量，灰度流量的比例：将流经起始拦截点A的10％的实时流量作为灰度流量；

(5)灰度数据的清理方式：实时清理；

(6)清理灰度数据的SQL语句：选择服务1、服务2、服务3的清理SQL语句。

需要说明的是，在本申请实施例中，开发人员基于变更需求开发对应的变更业务代码。即，若变更业务需求为查询客户公积金，则变更业务代码为查询客户公积金的业务代码。

再有，通过在流量拦截规则中配置灰度验证的时间，使得服务器在处理第一业务逻辑的过程中，只有触发灰度验证的时间在预先配置的灰度验证的时间内，才会执行读取用于验证变更业务代码对应的流量拦截规则，以利用灰度流量对第一业务逻辑对应的变更业务代码进行灰度验证，避免在流量高峰期或关键业务时段灰度验证过程对正常的业务流程的影响。

步骤S102，服务器获取拦截点区间的首个接口的流量作为灰度流量。

在具体实施过程中，流量是指访问某个接口的请求数据。灰度流量是指被标记有灰度标签，且用于对变更业务代码进行灰度验证的请求数据。

服务器读取用于验证变更业务代码对应的流量拦截规则后，便可基于流量拦截规则中设置的拦截点区间确定拦截点区间的首个接口。

由于业务流程由微服务的各个接口提供的功能组成，用户的请求数据会按照接口的先后顺序依次通过这些接口，请求数据在各个接口之间流转，因此，在确定拦截点区间后，只需要获取拦截点区间的首个接口的流量作为灰度流量。

步骤103，服务器利用灰度流量对变更业务代码进行灰度验证。

服务器在获取到灰度流量后，便可利用灰度流量对变更业务代码进行灰度验证。具体的，服务器从拦截点区间的首个接口放行灰度流量，使灰度流量在拦截点区间内按接口的先后调用顺序进行流转，以利用灰度流量对变更业务代码进行灰度验证。

本申请实施例在触发了对第一业务逻辑对应的变更业务代码的灰度验证时，读取验证变更业务代码对应的流量拦截规则，基于流量拦截规则中的拦截点区间确定首个接口，获取首个接口的流量作为灰度流量对变更业务代码进行灰度验证。在这个过程中，设置拦截点区间提高了灰度验证范围的针对性和灵活性。并且，变更的业务代码位于拦截点区间，因此，获取拦截点区间首个接口的流量作为灰度流量除了能够验证变更的业务代码的正确性，还能验证位于拦截点区间其他未发生更变的业务代码的正确性，进而验证变更的业务代码不会影响未发生变更的业务代码。因此，利用灰度流量对拦截点区间中的业务功能进行验证能够及时地发现灰度发布过程中，变更业务带来的影响和问题，从而提高灰度发布版本的准确性。

在一些实施例中，流量拦截规则还包括拦截的流量类型，流量类型包括历史流量类型和/或实时流量类型；获取拦截点区间的首个接口的流量作为灰度流量，包括：针对流量类型为历史流量类型的情况，获取拦截点区间的首个接口的历史流量作为灰度流量；历史流量为第二业务逻辑中在历史时间段内经过首个接口的流量；第一业务逻辑为在第二业务逻辑的基础上，对第二业务逻辑中的部分业务代码进行变更后获得；针对流量类型为实时流量类型的情况，获取拦截点区间的首个接口的实时流量作为灰度流量。

在具体实施过程中，考虑到在发布了变更业务代码后，用户可能不会频繁地发起请求数据，因此，为了能够及时地对变更业务代码进行灰度验证，可获取拦截点区间的首个接口的历史流量作为灰度流量对变更业务代码进行灰度验证。

除此之外，由于历史流量是第二业务逻辑中在历史时间段内经过首个接口的流量。而第一业务逻辑为在第二业务逻辑的基础上，对第二业务逻辑中的部分业务代码进行变更后获得的。因此，将历史流量作为灰度流量进行灰度验证，可观察包括变更业务代码的第一业务逻辑是否能对历史流量进行正确处理，从而验证第一业务逻辑的整体鲁棒性。

在发布了变更业务代码后，若用户实时地发起请求数据，由于实时流量反应了用户当前的真实访问行为，因此可获取拦截点区间的首个接口的实时流量作为灰度流量对变更业务代码进行灰度验证。实时流量是指此时此刻，经过首个接口的流量。

应当知道的是，在存在实时流量时，也可同时利用拦截点区间的首个接口的实时流量和历史流量对变更业务代码进行灰度验证。

需要说明的是，在获取拦截点区间的首个接口的历史流量之前，还需通过深拷贝的方式拷贝第二业务逻辑中在历史时间段内经过首个接口的流量，并将深拷贝后的历史流量存储在目标位置，使得在需要利用历史流量进行灰度验证时，直接获取即可。其中，目标位置可以是拦截点对应的缓存、也可以是redis数据库等。

需要说明的是，在设置拦截点时，还可以配置拦截点对应的存储数量阈值，使得按照配置的存储数量阈值记录历史流量。在记录的历史流量超过存储数量阈值时，按时间先后顺序依次丢弃先存储的历史流量，记录新的历史流量。

深拷贝是指复制对象的第二层结构，即对象的引用、属性值和子对象都会被复制；如果对象内部有指针类型的属性，则该指针也会被复制，并且指向新复制的对象；深拷贝适用于复制复杂的对象，如树形结构、链表等。因此，通过深拷贝的方式获得历史流量可获得完全独立的副本，不受原对象变化的影响。

还需说明的是，在进行灰度验证时，并不需要将所有流量都作为灰度流量进行灰度验证。因此，在配置流量拦截规则时，可配置灰度流量的比例。在获取拦截点区间的首个接口的历史流量和/或实时流量时，可按照预先配置的灰度流量的比例进行获取，以利用少量的流量进行灰度验证，从而降低灰度验证对系统运行的影响以及节约系统资源。

本申请实施例中，考虑到在一段时间内用户可能不会使用目标系统，用户不使用目标系统则不会产生实时流量。因此，在本申请实施例中，灰度流量可以是历史流量和/或实时流量。使用历史流量可立马对存在变更的业务代码的业务逻辑进行灰度验证，使用实时流量可直接验证存在变更业务代码的第一业务逻辑的正确性。并且，由于历史流量是第二业务逻辑中在历史时间段内经过首个接口的流量，而第一业务逻辑为在第二业务逻辑的基础上，对第二业务逻辑中的部分业务代码进行变更后获得，因此，使用历史流量对变更的业务代码进行灰度验证，除了能及时地执行验证过程外，还能反映存在变更业务代码的第一业务逻辑的整体鲁棒性。

在一些实施例中，服务器利用灰度流量对变更业务代码进行灰度验证，包括：服务器从拦截点区间的首个接口放行灰度流量，使灰度流量在拦截点区间内按接口的先后调用顺序进行流转，以利用灰度流量对变更业务代码进行灰度验证。

在具体实施过程中，服务器从拦截点区间的首个接口放行获取的灰度流量，使得灰度流量在拦截点区间中按接口的先后调用顺序进行流转，以对变更业务代码进行灰度验证。

本申请实施例通过在拦截点区间的首个接口放行灰度流量，使得灰度流量在拦截点区间内按接口顺序进行流转，以对拦截点区间包括的接口进行验证，提高灰度验证的灵活性。

在一些实施例中，该方法还包括：服务器在拦截点区间的最后一个接口对灰度流量进行销毁。

在具体实施过程中，由于在流量拦截规则中设置了拦截点区间来确定灰度验证的范围，因此，在灰度流量到达拦截点区间的最后一个接口时，服务器对流转到最后一个接口的灰度流量进行销毁。以降低灰度流量对拦截点区间的下游微服务的影响。

本申请实施例在拦截点区间的最后一个接口对灰度流量进行销毁，使得灰度流量不再向下流转，降低灰度流量对拦截点区间的下游微服务的影响。

在一些实施例中，在获取拦截点区间的首个接口的历史流量作为灰度流量之前，该方法还包括：基于预先配置的代码标识深拷贝与所述代码标识匹配的所述第二业务逻辑中历史时间经过所述首个接口的流量作为历史流量。

在具体实施过程中，某个业务功能只有被用户选择，才会触发系统执行。因此，在获取拦截点区间的首个接口的历史流量作为灰度流量之前，需要基于变更业务需求所需的流量种类对历史流量进行拷贝存储。其中，将变更业务需求所需的流量称为指定流量。

示例性的，客户授信的业务流程中新增查询用户公积金的功能，只有用户授权查询公积金才会触发查询公积金的操作。其中，用户授权查询公积金的查询请求是指定流量。而不同意查询公积金的请求不会触发公积金查询操作，则不为指定流量。因此，开发人员需要预先指定拷贝哪些历史流量用作灰度流量进行存储，即，开发人员需要预先配置代码标识用于标识哪些流量是指定流量。

因此，在设置拦截点区间时，还可在拦截点区间的首个接口处设置预先配置的代码标识，以使系统基于预先配置的代码标识深拷贝与代码标识匹配的第二业务逻辑中历史时间经过首个接口的流量作为历史流量。

由于服务与服务之间进行交互时，请求报文的格式通常是固定的，此时可通过精准匹配或模糊匹配请求报文中的某一个key的某一个值，来判断该请求报文是否是指定流量。

为便于理解如何获得指定流量，给出如下示例：

假设变更业务需求为新增查询用户公积金，只有在用户同意查询时，才会触发查询用户公积金。假设到达拦截点区间的首个接口的请求报文如下：

开发人员在拦截点区间的首个接口处配置代码标识为[.user_info.is_allow＝1]，当到达该接口的报文中user_info层级下的is_allow字段为1时，认为该流量为指定流量。

本申请实施例通过代码标识深拷贝与代码标识匹配的第二业务逻辑中，历史时间经过首个接口的流量作为历史流量，使得进行灰度验证的灰度流量是变更的业务代码所需的灰度流量，从而针对性地使用历史流量及时地对存在变更的业务代码的业务逻辑进行灰度验证。

在一些实施例中，服务器在利用灰度流量对变更业务代码进行灰度验证之后，该方法还包括：服务器对灰度验证过程中产生的灰度数据进行删除。

在具体实施过程中，灰度数据是指在利用灰度流量在灰度验证过程中产生的各种类型的数据。示例性的，针对客户授信时新增查询客户公积金的功能，在利用灰度流量进行灰度验证过程中产生的灰度数据有：

查询请求数据：包括由第一业务逻辑发出的公积金查询请求，如请求的IP地址、请求时间、请求类型(如查询、修改等)、查询的具体公积金信息等。

查询结果数据：指查询返回的结果数据，包括客户的公积金余额、缴纳记录等。这些数据用于验证查询结果的正确性和完整性。

错误和异常数据：如果在灰度验证过程中出现错误或异常，如查询失败、系统超时等，这些数据也是灰度数据的一部分。有助于识别和解决系统中的问题。

响应时间数据：指查询请求从发出到收到响应所花费的时间。通过监测响应时间，可以评估新功能在真实环境中的性能表现。

用户行为数据：例如，用户是否正常查看了自己的公积金信息，是否有进行其他相关操作等。这些数据可以帮助了解用户对新功能的接受程度和使用习惯。

应当知道的是，针对不同类型的新增业务功能，其对应的灰度数据是不相同的。

由于灰度数据可能涉及用户隐私以及灰度数据占用系统部分的存储空间，使得系统性能下降等问题，因此，开发人员在配置流量拦截规则时，还可以配置清理灰度数据的SQL语句。服务器在利用灰度流量对变更业务代码进行灰度验证之后，调用流量拦截规则中的清理灰度数据的SQL语句对灰度验证过程中产生的灰度数据进行删除。

示例性的，SQL语句的形式如下：

其中，is_grayscale表示灰度标签，condition中必定包含每个流量的唯一标识，一个服务存在一个或多个清除灰度数据的SQL语句。

需要说明的是，由于是在拦截点区间内执行灰度验证，因此，可能在多个微服务中都产生了灰度数据，在利用SQL语句对灰度验证过程中产生的灰度数据进行删除时，是利用不同微服务对应的SQL语句删除对应微服务上的灰度数据。

除此之外，流量拦截规则还配置了灰度数据的清理方式，清理方式包括实时清理和定时清理。其中，实时清理是在第一业务逻辑处理结束后，立刻调用SQL语句删除涉及服务的灰度数据。定时清理是在每天的流量低峰期定时清理灰度过程中产生的灰度数据。

本申请实施例通过对灰度过程中产生的灰度数据进行删除，避免数据泄露造成的数据滥用和数据安全问题。同时，也减少了存储负担，优化存储资源，提高系统处理效率。

在一些实施例中，该方法还包括：服务器生成灰度验证过程中的灰度日志信息；服务器基于灰度日志信息对变更业务代码的正确性进行评估。

在具体实施过程中，服务器在利用灰度流量对变更业务代码进行灰度验证时，生成每次灰度验证的灰度日志信息，以记录灰度验证过程中，灰度流量在拦截点区间中的行为和结果。

服务器基于这些灰度日志信息对变更业务代码的正确性进行评估。通过分析日志中的数据，判断变更业务代码是否如预期的方式工作。例如，可以检查请求是否成功处理、返回的结果是否正确、是否有异常错误发生等。

应当知道的是，开发人员也可通过观察灰度日志信息对变更业务代码的正确性进行评估，若确认无误，则可将包括变更业务代码的第一业务逻辑进行正式推广。

本申请实施例通过灰度日志信息记录灰度验证过程的情况，以对灰度验证的情况进行评估，帮助开发人员能快速定位和解决问题。

图2为本申请实施例提供的一种灰度验证装置的结构示意图，如图2所示，该装置包括：读取模块201、获取模块202和验证模块203；其中，

读取模块201，用于在处理第一业务逻辑过程中，若触发对第一业务逻辑对应的变更业务代码的灰度验证，则读取用于验证变更业务代码对应的流量拦截规则；流量拦截规则包括拦截点区间；拦截点区间用于表征第一业务逻辑中需要验证的接口范围；变更业务代码位于拦截点区间；获取模块202，用于获取拦截点区间的首个接口的流量作为灰度流量；验证模块203，用于利用灰度流量对变更业务代码进行灰度验证。

在上述实施例的基础上，流量拦截规则还包括拦截的流量类型，流量类型包括历史流量类型和/或实时流量类型；获取模块202具体用于：针对流量类型为历史流量类型的情况，获取拦截点区间的首个接口的历史流量作为灰度流量；历史流量为第二业务逻辑中在历史时间段内经过首个接口的流量；第一业务逻辑为在第二业务逻辑的基础上，对第二业务逻辑中的部分业务代码进行变更后获得；针对流量类型为实时流量类型的情况，获取拦截点区间的首个接口的实时流量作为灰度流量。

在上述实施例的基础上，验证模块203具体用于：从拦截点区间的首个接口放行灰度流量，使灰度流量在拦截点区间内按接口的先后调用顺序进行流转，以利用灰度流量对变更业务代码进行灰度验证。

在上述实施例的基础上，该装置还包括销毁模块，用于在拦截点区间的最后一个接口对灰度流量进行销毁。

在一些实施例中，获取模块202具体用于：基于预先配置的代码标识深拷贝与代码标识匹配的第二业务逻辑中历史时间经过首个接口的流量作为历史流量。

在上述实施例的基础上，该装置还包括删除模块，用于对灰度验证过程中产生的灰度数据进行删除。

在上述实施例的基础上，该装置还包括评估模块，用于生成灰度验证过程中的灰度日志信息；基于灰度日志信息对变更业务代码的正确性进行评估。

应理解的是，该装置与上述的灰度验证方法实施例对应，能够执行上述方法实施例涉及的各个步骤，该装置具体的功能可以参见上文中的描述，为避免重复，此处适当省略详细描述。该装置包括至少一个能以软件或固件(firmware)的形式存储于存储器中或固化在装置的操作系统(operatingsystem，OS)中的软件功能模块。

图3为本申请实施例提供的电子设备结构示意图，如图3所示，所述电子设备，包括处理器(processor)301、存储器(memory)302和总线303；其中，所述处理器301和存储器302通过所述总线303完成相互间的通信。所述处理器301用于调用所述存储器302中的程序指令，以执行上述各方法实施例所提供的方法。

处理器301可以是一种集成电路芯片，具有信号处理能力。上述处理器301可以是通用处理器，包括中央处理器(CentralProcessingUnit，CPU)、网络处理器(NetworkProcessor，NP)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。其可以实现或者执行本申请实施例中公开的各种方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器302可以包括但不限于随机存取存储器(RandomAccessMemory，RAM)，只读存储器(ReadOnlyMemory，ROM)，可编程只读存储器(ProgrammableRead-OnlyMemory，PROM)，可擦除只读存储器(ErasableProgrammableRead-OnlyMemory，EPROM)，电可擦除只读存储器(ElectricallyErasableProgrammableRead-OnlyMemory，EEPROM)等。

本实施例公开一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述各方法实施例所提供的方法。

本实施例提供一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行上述各方法实施例所提供的方法。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

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

Claims (10)

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

在处理第一业务逻辑过程中，若触发对所述第一业务逻辑对应的变更业务代码的灰度验证，则读取用于验证所述变更业务代码对应的流量拦截规则；所述流量拦截规则包括拦截点区间；所述拦截点区间用于表征所述第一业务逻辑中需要验证的接口范围；所述变更业务代码位于所述拦截点区间；

获取所述拦截点区间的首个接口的流量作为灰度流量；

利用所述灰度流量对所述变更业务代码进行灰度验证。

2.根据权利要求1所述的方法，其特征在于，所述流量拦截规则还包括拦截的流量类型，所述流量类型包括历史流量类型和/或实时流量类型；所述获取所述拦截点区间的首个接口的流量作为灰度流量，包括：

针对所述流量类型为所述历史流量类型的情况，获取所述拦截点区间的首个接口的历史流量作为灰度流量；所述历史流量为第二业务逻辑中在历史时间段内经过所述首个接口的流量；所述第一业务逻辑为在所述第二业务逻辑的基础上，对所述第二业务逻辑中的部分业务代码进行变更后获得；

针对所述流量类型为所述实时流量类型的情况，获取所述拦截点区间的首个接口的实时流量作为灰度流量。

3.根据权利要求1所述的方法，其特征在于，所述利用所述灰度流量对所述变更业务代码进行灰度验证，包括：

从所述拦截点区间的首个接口放行所述灰度流量，使所述灰度流量在所述拦截点区间内按接口的先后调用顺序进行流转，以利用所述灰度流量对所述变更业务代码进行灰度验证。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

在所述拦截点区间的最后一个接口对所述灰度流量进行销毁。

5.根据权利要求2所述的方法，其特征在于，所述在获取所述拦截点区间的首个接口的历史流量作为灰度流量之前，所述方法还包括：

基于预先配置的代码标识深拷贝与所述代码标识匹配的所述第二业务逻辑中历史时间经过所述首个接口的流量作为历史流量。

6.根据权利要求1所述的方法，其特征在于，在所述利用所述灰度流量对所述变更业务代码进行灰度验证之后，所述方法还包括：

对灰度验证过程中产生的灰度数据进行删除。

7.根据权利要求1-6任一所述的方法，其特征在于，所述方法还包括：

生成灰度验证过程中的灰度日志信息；

基于所述灰度日志信息对所述变更业务代码的正确性进行评估。

8.一种灰度验证装置，其特征在于，所述装置包括：

读取模块，用于在处理第一业务逻辑过程中，若触发对所述第一业务逻辑对应的变更业务代码的灰度验证，则读取用于验证所述变更业务代码对应的流量拦截规则；所述流量拦截规则包括拦截点区间；所述拦截点区间用于表征所述第一业务逻辑中需要验证的接口范围；所述变更业务代码位于所述拦截点区间；

获取模块，用于获取所述拦截点区间的首个接口的流量作为灰度流量；

验证模块，用于利用所述灰度流量对所述变更业务代码进行灰度验证。

9.一种电子设备，其特征在于，包括：处理器和存储器，所述存储器存储有所述处理器可执行的机器可读指令，所述机器可读指令被所述处理器执行时执行如权利要求1至7任一所述的方法。

10.一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如权利要求1至7任一所述的方法。