CN111338824A - 灰度发布方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请提供一种灰度发布方法、装置、电子设备及存储介质。本申请提供的灰度发布方法根据业务规则以及场景灰度策略进行规则检验，得到检验结果，其中，场景灰度策略包括业务规则的灰度发布范围，当在预设时长内检验结果符合预设结果，则将场景灰度策略的限定取消，将业务规则进行无限制的全场景发布。而当检验结果不符合预设结果，则进行规则回滚。从而，针对业务规则以及规则引擎提供了一套灰度发布的解决方案，当业务规则的内容和/或规则运行过程中发生异常，能够被及时获知以及规避发布风险，提高业务处理***的稳定性以及用户体验。

Description

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

技术领域

本申请涉及通信技术领域，尤其涉及一种灰度发布方法、装置、电子设备及存储介质。

背景技术

随着通信技术的飞速发展，移动通信运营商的业务规模也随之逐步扩大，业务规则成为了移动通信运营商的重要资产，业务规则制定的好坏直接决定运营商的市场占有率以及用户体验。

目前，运营商采用开源的规则引擎对业务规则进行规则检验，不但降低了业务逻辑组件的复杂性，还提高了业务规则检验的效率。其中，针对业务规则不同的类型，采用了不同的运行方式进行检验，例如，针对SQL脚本的业务规则，通过运行SQL脚本进行规则检验，针对规则文件脚本，通过运行规则文件脚本进行规则检验。

然而，不论是通过哪种运行方式进行规则检验，当业务规则的内容以及运行过程出现异常，均会造成业务处理***的不稳定，尤其当业务规则迭代速率较快时，一旦出现异常，则会发生未知的风险，给运营商以及用户带来不可估量的损失。

发明内容

本申请提供一种灰度发布方法、装置、电子设备及存储介质，用以解决当业务规则内容以及运行过程出现异常时，现有的规则引擎无法及时规避风险对业务处理***以及用户造成损失的技术问题。

第一方面，本申请提供一种灰度发布方法，包括：

根据业务规则以及场景灰度策略进行规则检验，得到检验结果，所述场景灰度策略包括所述业务规则的灰度发布范围；

若在预设时长内所述检验结果符合预设结果，取消所述场景灰度策略的限定，对所述业务规则进行全场景发布；

若所述检验结果不符合所述预设结果，进行规则回滚。

在一种可能的设计中，在所述根据业务规则以及场景灰度策略进行规则检验，得到检验结果之前，包括：

确定所述灰度发布范围，所述灰度发布范围内具有处理所述业务规则所属业务的权限；

根据每个业务规则的特性确定对应的所述灰度发布范围；

根据所述业务规则以及对应的所述灰度发布范围确定灰度发布规则表，所述灰度发布规则表包括灰度规则。

在一种可能的设计中，所述根据所述业务规则以及场景灰度策略进行规则检验，得到检验结果，包括：

获取待处理业务，所述待处理业务包括待处理业务规则；

判断所述待处理业务规则是否为所述灰度规则；

若判断结果为是，通过所述待处理业务规则对应的规则引擎以及所述灰度发布范围进行规则检验，得到所述检验结果。

若判断结果为否，通过所述待处理业务规则对应的规则引擎在所述全场景进行业务处理。

在一种可能的设计中，当所述待处理业务规则的类型为规则文件脚本，所述通过所述待处理业务规则对应的规则引擎以及所述灰度发布范围进行规则检验，得到所述检验结果，还包括：

根据所述灰度发布范围对所述待处理业务规则对应的规则引擎进行筛选；

通过筛选后的规则引擎在对应的所述灰度发布范围内进行规则检验以得到所述检验结果。

在一种可能的设计中，所述规则回滚，包括：

当所述灰度规则的类型为SQL脚本，则失效所述灰度规则在所述灰度发布范围的权限；

当所述灰度规则的类型为所述规则文件脚本，则通知所述灰度规则对应的规则引擎删除所述灰度规则的规则编号。

可选地，通过消息队列中间件进行所述灰度规则的发布。

第二方面，本申请提供一种灰度发布装置，包括：

第一处理模块，用于根据业务规则以及场景灰度策略进行规则检验，得到检验结果，所述场景灰度策略包括所述业务规则的灰度发布范围；

第二处理模块，用于若在预设时长内所述检验结果符合预设结果，取消所述场景灰度策略的限定，对所述业务规则进行全场景发布；

第三处理模块，用于若所述检验结果不符合所述预设结果，进行规则回滚。

在一种可能的设计中，所述灰度发布装置，还包括：

第四处理模块，用于：

确定所述灰度发布范围，所述灰度发布范围内具有处理所述业务规则所属业务的权限；

根据每个业务规则的特性确定对应的所述灰度发布范围；

根据所述业务规则以及对应的所述灰度发布范围确定灰度发布规则表，所述灰度发布规则表包括灰度规则。

在一种可能的设计中，所述第一处理模块，具体用于：

获取待处理业务，所述待处理业务包括待处理业务规则；

判断所述待处理业务规则是否为所述灰度规则；

若判断结果为是，通过所述待处理业务规则对应的规则引擎以及所述灰度发布范围进行规则检验，得到所述检验结果。

若判断结果为否，通过所述待处理业务规则对应的规则引擎在所述全场景进行业务处理。

在一种可能的设计中，当所述待处理业务规则的类型为规则文件脚本，所述第一处理模块，还用于：

根据所述灰度发布范围对所述待处理业务规则对应的规则引擎进行筛选；

通过筛选后的规则引擎在对应的所述灰度发布范围内进行规则检验以得到所述检验结果。

在一种可能的设计中，所述第三处理模块，具体用于：

当所述灰度规则的类型为SQL脚本，则失效所述灰度规则在所述灰度发布范围的权限；

当所述灰度规则的类型为所述规则文件脚本，则通知所述灰度规则对应的规则引擎删除所述灰度规则的规则编号。

可选地，所述第四处理模块，还用于：

通过消息队列中间件进行所述灰度规则的发布。

第三方面，本申请提供一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行第一方面及可选的方案涉及的灰度发布方法。

第四方面，本申请提供一种存储有计算机指令的非瞬时计算机可读存储介质，所述计算机指令用于使所述计算机执行第一方面及可选的方案涉及的灰度发布方法。

本申请提供的灰度发布方法、装置、电子设备及存储介质，根据业务规则以及场景灰度策略进行规则检验，得到检验结果，其中，场景灰度策略包括业务规则的灰度发布范围，当在预设时长内检验结果符合预设结果，则将场景灰度策略的限定取消，将业务规则进行无限制的全场景发布。而当检验结果不符合预设结果，则进行规则回滚。从而，针对本申请中的业务规则提供了一套灰度发布的解决方案，当业务规则的内容和/或规则运行过程中发生异常，都能够被及时获知，进而规避发布风险，提高业务处理***的稳定性以及用户体验。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种灰度发布方法的应用场景图；

图2为本申请实施例提供的一种灰度发布方法的流程示意图；

图3为本申请实施例提供的另一种灰度发布方法的流程示意图；

图4为本申请实施例提供的再一种灰度发布方法的流程示意图；

图5为本申请实施例提供的一种灰度发布装置的结构示意图；

图6为本申请实施例提供的另一种灰度发布装置的结构示意图；

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

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的方法和装置的例子。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

随着通信技术的飞速发展，移动通信运营商的业务规模也随之逐步扩大，业务规则成为了移动通信运营商的重要资产，业务规则制定的好坏直接决定运营商的市场占有率以及用户体验。目前，运营商采用开源的规则引擎对业务规则进行规则检验，不但降低了业务逻辑组件的复杂性，还提高了检验效率。而具体地，针对业务规则类型的不同，规则引擎可以采用不同的运行方式进行检验，例如，针对SQL脚本的业务规则，相应的规则引擎通过运行SQL脚本进行规则检验，针对规则文件脚本，相应的规则引擎通过运行规则文本脚本进行规则检验。然而，不论采用何种运行方式进行规则检验，当业务规则的内容和/或运行过程出现异常，均会造成业务处理***的不稳定，尤其对于目前运营商业务规则迭代速率较快、业务规则逻辑复杂的情况下，一旦发生异常，都会导致未知风险的发生，则会给运营商以及用户带来不可估量的损失。

可见，亟需一种解决方案，以能够在业务规则的内容和/或运行过程中出现异常时，及时获知异常，规避业务规则的发布风险，进而减少对运营商以及用户带来的损失。

灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。目前，灰度发布常用的发布策略可以分为两种，一种是在程序代码层面，通过一套线上环境得以实现，于程序代码处设置控制开关，对于不同的用户设置不同的逻辑；另一种是在接入层面，通过多套相互隔离的线上环境实现，于接入层对于不同的用户对应不同的转发环境。然而，由于运营商所涉及的业务规则不是普通的程序代码，则无法通过在程序代码层面设置控制开关以控制业务逻辑，再者，业务规则的迭代更新速率较快，业务规则逻辑复杂，控制开关难以实现。另一方面，对于规则文件运行的这类业务规则，其运行方式是通过一次性加载至规则引擎进行，若采用多套线上环境则需要较大的运维成本。可见，现有的灰度发布策略均不完全适用于运营商所涉及的业务规则的发布。

针对现有技术中的上述问题，本申请实施例提供一种灰度发布方法、装置、电子设备及存储介质。其中，本申请实施例提供的灰度发布方法，首先根据业务规则以及场景灰度策略进行规则检验，得到检验结果，其中，场景灰度策略包括业务规则的灰度发布范围，当在预设时长内检验结果符合预设结果，则将场景灰度策略的限定取消，将业务规则进行无限制的全场景发布。而当检验结果不符合预设结果，则进行规则回滚。从而，在进行规则检验步骤中引入了场景灰度策略，有效控制了业务规则的发布范围，规避了业务规则的发布风险，降低了业务规则迭代升级带来的影响，提高业务处理***的稳定性以及用户体验。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图1为本申请实施例提供的一种灰度发布方法的应用场景图。如图1所示，本申请实施例提供的灰度发布方法可以由电子设备执行，其中，电子设备可以是服务器或服务器集群，图1中以服务器100为例示出。本申请实施例提供的灰度发布方法中所涉及的业务规则，是处理移动通信运营商为用户终端提供的业务服务时所依据的规则。例如，业务服务是用户识别卡开户业务，处理该开户业务时则需要执行开户业务所包括的各种业务规则。其中，用户终端可以是手机、智能手表等，对于用户终端的类型本申请实施例不作限定，图1中以手机200为例示出。

本申请实施例提供的灰度发布方法，服务器100根据业务规则以及场景灰度策略进行规则检验，得到检验结果，其中，场景灰度策略包括业务规则的灰度发布范围，若在预设时长内检验结果符合预设结果，则取消场景灰度策略的限定，对业务规则进行场景不限制的发布；若检验结果不符合预设结果，则进行规则回滚。从而，通过在进行规则检验中引入场景灰度策略，有效控制了业务规则的发布范围，规避了业务规则的发布风险，降低了业务规则迭代升级带来的影响，提高业务处理***的稳定性以及用户体验。如前所描述，业务规则是处理运营商为用户终端提供的业务服务时所依据的规则，用户终端例如手机200。

图2为本申请实施例提供的一种灰度发布方法的流程示意图。如图2所示，本实施例提供的灰度发布方法，包括：

S101：根据业务规则以及场景灰度策略进行规则检验，得到检验结果。

其中，场景灰度策略包括业务规则的灰度发布范围。

针对运营商提供的每项业务，均需要依据每项业务所包括的业务规则才能使得业务得以处理。规则引擎是一种接收数据输入、解释业务规则，并根据业务规则做出相应业务决策的技术手段。

根据业务规则以及场景灰度策略进行规则检验，其中，规则检验是指依据业务规则通过规则引擎处理业务规则所属业务。而本步骤中根据业务规则进行规则检验时，设置了场景灰度策略，其中，场景灰度策略包括业务规则的灰度发布范围，例如，运营商提供业务服务的某个特定的物理区域。换言之，在进行规则检验时，对灰度发布范围内的业务规则进行规则检验，以能够有效控制业务规则所面向的发布对象，发布对象可以理解为属于灰度发布范围内，运营商开放的业务所面向的用户人群。

进行规则检验，则可以根据业务规则得到相应的业务决策，所得到的业务决策即为检验结果。

S102：若在预设时长内检验结果符合预设结果，取消场景灰度策略的限定，对业务规则进行全场景发布。

在进行规则检验得到检验结果之后，判断检验结果与预设结果是否相符，其中，预设结果为规则引擎依据业务规则针对某项业务应该作出的业务决策，换言之，预设结果为依据业务规则针对某向业务所输出的正确的业务决策。可以理解的是，当检验结果符合预设结果，则表明该项业务所包括的业务规在处理业务过程中未出现异常。而当在预设时长内其检验结果均符合预设结果，则表明依据该业务规则处理对应的业务达到了预期效果，则取消场景灰度策略的限定，对业务规则进行场景不限制的发布，即全场景发布。其中，预设时长可根据所涉及的业务以及业务规则进行设置，对此，本实施例不作限定。

S103：若检验结果不符合预设结果，进行规则回滚。

当业务规则的内容和/或业务处理过程中发生异常，则检验结果会不符合预设结果，此时，表明该业务规则不应当被发布，若发布则会造成未知的风险，因而，进行规则回滚。在本技术领域中，回滚是指程序或数据处理发生错误时，将程序或数据恢复到上一次正确状态的行为。可以理解的是，检验结果与预设结果一旦出现不符合，均进行规则回滚。

本实施例提供的灰度发布方法，首先根据业务规则以及场景灰度策略进行规则检验，得到检验结果，其中，场景灰度策略包括业务规则的灰度发布范围，当在预设时长内检验结果符合预设结果，则取消场景灰度策略的限定，将业务规则进行无限制的全场景发布，而当检验结果不符合预设结果，则进行规则回滚。可见，在进行规则检验步骤中引入了场景灰度策略，有效控制了业务规则的发布范围，能够及时获知业务规则出现的异常，当出现异常时，进行规则回滚，及时规避了业务规则的发布风险，降低了业务规则迭代升级带来的影响，提高业务处理***的稳定性以及用户体验。

在根据业务规则以及场景灰度策略进行规则检验，得到检验结果之前，本申请实施例提供的灰度发布方法还可以包括确定业务规则与对应的灰度发布范围，基于此，在一种可能的实施方式中，图3为本申请实施例提供的另一种灰度发布方法的流程示意图，如图3所示，本实施例提供的灰度发布方法，还可以包括：

S301：确定灰度发布范围。

其中，灰度发布范围内具有处理业务规则所属业务的权限。

场景灰度策略包括灰度发布范围，在灰度发布范围内具有处理业务规则所属业务的权限。确定灰度发布范围，可以理解为，确定业务规则灰度发布的场景范围，对于运营商所涉及的业务，确定的灰度发布范围可以是地市灰度发布范围即一个或多个特定的地市、营业厅灰度发布范围即一个或多个特定的业务受理营业厅、人员灰度发布范围即一位或多位特定的业务受理人员。其中，当确定了一个或多个特定的地市为灰度发布范围，则表示某项业务仅可以在该一个或多个特定的地市进行处理，除此之外的地市则没有权限处理该项业务。类似地，一个或多个特定的业务受理营业厅被确定为灰度发布范围，则某项业务仅可以在该一个或多个特定的业务受理营业厅进行处理，除此之外的业务受理营业厅没有权限处理该项业务；当一位或多位特定的业务受理人员被确定为灰度发布范围，则某项业务仅可以由该一位或多位业务受理人员进行处理，除此之外的业务受理人员则没有权限处理该项业务。可以理解的是，每个地市、每个业务受理营业厅以及每位业务受理人员均分配有对应的编码或工号，可以根据编码或工号进行灰度发布范围的确定。

S302：根据每个业务规则的特性确定对应的灰度发布范围。

在确定了灰度发布范围之后，根据每个业务规则的特性，选择每个业务规则对应的灰度发布范围。当确定了该业务规则对应的灰度发布范围，则该业务规则仅可以作用于对应的灰度发布范围，除此之外的物理区域或业务受理人员在处理业务时，则该项业务规则对其无作用。例如，当确定了某项业务包括的某个业务规则对应的灰度发布范围为地市灰度发布范围，则表明该业务规则仅可以在该地市被处理业务时依据，除此之外的其他地市不可以依据该业务规则处理对应的业务。

S303：根据业务规则以及对应的灰度发布范围确定灰度发布规则表。

其中，灰度发布规则表包括灰度规则。

在确定了灰度发布范围，以及根据业务规则的特性确定了对应的灰度发布范围之后，将每个业务规则以及对应的灰度发布范围确定为灰度发布规则表，可以理解的是，灰度发布规则表中的业务规则即为灰度规则。

本实施例提供的灰度发布方法，在根据业务规则以及场景灰度策略进行规则检验，得到检验结果之前，还确定业务规则以及对应的灰度发布范围。首先确定灰度发布范围，即选择进行灰度发布所面向的对象，然后根据每个业务规则的特性确定对应的灰度发布范围，即控制每个业务规则所面向的对象，再将业务规则以及对应的灰度发布范围确定为灰度发布规则表，其中，灰度发布规则表中所包括的业务规则即为灰度规则。本实施例提供的灰度发布方法，有效控制业务规则进行灰度发布的发布范围，以能够及时获知发布风险。

可选地，灰度发布规则表包括的灰度规则通过消息队列(Message Queue，简称MQ)中间件进行发布，例如，将灰度规则发送至MQ指定的主题(Topic)，规则引擎实时获取该主题下的灰度规则，对其进行增加或删除，当业务规则被确定为灰度规则时，则进行增加，当进行规则回滚时，则进行删除。从而实现灰度规则的动态实时发布，提高了灰度规则的发布效率。

一种可能的设计中，步骤S101可以通过如图4所示的方式实现，图4为本申请实施例提供的再一种灰度发布方法的流程示意图，如图4所示，该方法包括：

S1010：获取待处理业务。

待处理业务包括待处理业务规则。

获取待处理业务是指获取用户需要受理的业务，其中，每项业务都是依据业务规则得以处理，因而，所获取的待处理业务包括了待处理业务规则。值得被理解的，每项业务可能会包括一个或多个业务规则，待处理业务则也可能包括一个或多个待处理业务规则，具体地由所涉及的业务决定，对此，本实施例不作限定。

S1011：判断待处理业务规则是否为灰度规则。

在获得待处理业务包括的待处理业务规则之后，查询灰度发布规则表中的灰度规则是否包含了待处理业务规则。

S1012：若判断结果为是，通过待处理业务规则对应的规则引擎以及灰度发布范围进行规则检验，得到检验结果。

当待处理业务规则为灰度规则，即判断结果为是，则通过待处理业务规则对应的规则引擎在对应的灰度发布范围内进行规则检验，得到检验结果。如前所描述，规则引擎根据业务规则类型的不同其运行方式不同，即待处理业务规则类型为结构化查询语言(Structured Query Language简称SQL)脚本时，对应的规则引擎通过运行SQL脚本进行业务处理，为了描述方便，将该规则引擎称之为SQL规则引擎。类似地，当待处理业务规则的类型为规则文件脚本时，对应的规则引擎通过运行规则文件脚本进行业务处理，将该规则引擎称之为规则文件的规则引擎。因而，当判断结果为是，则通过待处理业务规则对应的规则引擎在该待处理业务规则对应的灰度发布范围内进行规则检验，即依据待处理业务规则处理该待处理业务规则所属的业务，得到检验结果。

S1013：若判断结果为否，通过待处理业务规则对应的规则引擎在全场景进行业务处理。

当待处理业务规则不属于灰度规则表中所包括的业务规则，即待处理业务规则不是灰度规则，则通过待处理业务规则对应的规则引擎在全场景进行业务处理，其中的全场景可以理解为，不受灰度发布范围的限定，依据业务规则进行正常的业务处理。

本实施例提供的灰度发布方法，通过获取待处理业务，判断待处理业务包括的待处理业务规则是否为灰度规则，当其为灰度规则时，通过待处理业务规则对应的规则引擎以及灰度发布范围进行规则检验，得到检验结构；当其不为灰度规则时，则通过待处理业务规则对应的规则引擎在全场景进行业务处理。从而，通过灰度发布规则表对待处理业务规则进行筛选，对属于灰色规则的待处理业务规则进行规则检验，实现了规则引擎的灰度发布。

进一步的，当判断待处理业务规则为灰度规则，并且待处理业务规则的类型为规则文件脚本时，通过待处理业务规则对应的规则引擎以及灰度发布范围进行规则检验，得到检验结果，还包括：

根据灰度发布范围对待处理业务规则对应的规则引擎进行筛选；

通过筛选后的规则引擎在对应的灰度发布范围内进行规则检验以得到检验结果。

待处理业务规则为灰度规则，并且，该待处理业务规则的类型为规则文件脚本时，则对待处理业务规则对应的规则引擎根据灰度发布范围进行筛选。

对于规则文件脚本而言，其是被一次性加载至规则文件的规则引擎对应的内存中，换言之，所有的规则文件脚本会被一次性加载至规则文件的规则引擎中。而在这些同属于规则文件脚本类型的待处理业务规则中，有些待处理业务规则为灰度规则，而有些可能不是灰度规则，但因为都被一次性加载至规则文件的规则引擎中，因而，需要对规则文件的规则引擎也根据灰度发布范围进行筛选，得到筛选后的规则引擎。

通过筛选后的规则引擎在对应的灰度发布范围内进行规则检验，得到对应的检验结果。具体地，仅运行属于灰度规则的待处理业务规则所对应的规则引擎，而其他不属于灰度规则的待处理业务规则对应的规则引擎则不运行，换言之，此时，对于同属于规则文件脚本类型的待处理业务规则，在处理待处理业务时，不属于灰度规则的待处理业务规则对应的规则引擎不运行。

本实施例提供的灰度发布方法，对于规则文件脚本的待处理业务规则，进一步对其对应的规则引擎根据灰度发布范围进行筛选，通过筛选后的规则引擎在对应的灰度发布范围内进行规则检验，得到规则检验结果。对于该类型的灰度规则，规则引擎进行了二次封装，保证了业务处理***的稳定性。

在上述实施例的基础上，当检验结果与预设结果不符，则进行规则回滚。可选地，规则回滚一种可能的实现方式包括：

当灰度规则的类型为SQL脚本，则失效灰度规则在灰度发布范围的权限。

当灰度规则的类型为规则文件脚本，则通知灰度规则对应的规则引擎以删除灰度规则的规则编号。

检验结果与预设结果不符合，则表明对应的业务规则内容和/或运行过程出现异常，此时，若该灰度规则的类型为SQL脚本，则失效其对应的灰度发布范围内的所有灰度规则。而当该灰度规则的类型为规则文件脚本，因为以规则文件脚本运行的灰度规则是被一次性加载至对应的规则引擎的内存，则需要通知对应的规则引擎删除灰度规则的规则编号，可以理解的是，规则文件脚本的灰度规则都对应配置有规则编号，删除规则编号即删除其对应的灰度规则。

本实施例提供的灰度发布方法，当检验结果与预设结果不符合时，进行规则回滚，其中对于不类型的灰度规则，采用不同的规则回滚，例如，对于SQL脚本的灰度规则，失效该灰度规则在对应的灰度发布范围的权限，而对于规则文件脚本的灰度规则，则与对应的规则引擎内存中删除该灰度规则的规则编码，从而，及时又全面地进行规则回滚，减少业务规则出现异常对业务处理***以及用户带来的影响。

下述为本申请装置实施例，可以用于执行上述任一方法实施例提供的灰度发布方法的步骤。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图5为本申请实施例提供的一种灰度发布装置的结构示意图。如图5所示，本实施提供的灰度发布装置500可以包括：

第一处理模块501，用于根据业务规则以及场景灰度策略进行规则检验，得到检验结果，其中，场景灰度策略包括业务规则的灰度发布范围。

第二处理模块502，用于若在预设时长内检验结果符合预设结果，取消场景灰度策略的限定，对业务规则进行全场景发布。

第三处理模块503，用于若检验结果不符合预设结果，进行规则回滚。

在图5所示实施例的基础上，图6为本申请实施例提供的另一种灰度发布装置的结构示意图。如图6所示，本实施例提供的灰度发布装置500，还包括：

第四处理模块504，用于：

确定灰度发布范围，灰度发布范围内具有处理业务规则所属业务的权限；

根据每个业务规则的特性确定对应的灰度发布范围；

根据业务规则以及对应的灰度发布范围确定灰度发布规则表，灰度发布规则表包括灰度规则。

可选地，第四处理模块504，还用于：

通过消息队列中间件进行灰度规则的发布。

一种可能的设计中，第一处理模块501，具体用于：

获取待处理业务，待处理业务包括待处理业务规则；

判断待处理业务规则是否为灰度规则；

若判断结果为是，通过待处理业务规则对应的规则引擎以及灰度发布范围进行规则检验，得到检验结果。

若判断结果为否，通过待处理业务规则对应的规则引擎在全场景进行业务处理。

当待处理业务规则的类型为规则文件脚本，可选地，第一处理模块501，还用于：

根据灰度发布范围对待处理业务规则对应的规则引擎进行筛选；

通过筛选后的规则引擎在对应的灰度发布范围内进行规则检验以得到检验结果。

一种可能的设计中，第三处理模块503，具体用于：

当灰度规则的类型为SQL脚本，则失效灰度规则在灰度发布范围的权限；

当灰度规则的类型为规则文件脚本，则通知灰度规则对应的规则引擎删除灰度规则的规则编号。

值得说明的是，本申请所提供的装置实施例仅仅是示意性的，上述装置实施例中模块划分仅仅是一种逻辑功能划分，实际实现时可以有另外的划分方式。例如多个模块可以结合或者可以集成到另一个***。各个模块相互之间的耦合可以是通过一些接口实现，这些接口通常是电性通信接口，但是也不排除可能是机械接口或其它的形式接口。因此，作为分离部件说明的模块可以是或者也可以不是物理上分开的，既可以位于一个地方，也可以分布到同一个或不同设备的不同位置上。

图7为本申请实施例提供的一种电子设备的结构示意图。如图7所示，本实施例提供的电子设备700，包括：

至少一个处理器701；以及

与至少一个处理器701通信连接的存储器702；其中，

存储器702存储有可被至少一个处理器701执行的指令，指令被至少一个处理器701执行，以使至少一个处理器701能够执行上述方法实施例中的灰度发布方法的各个步骤，具体可以参考前述方法实施例中的相关描述。

可选地，存储器702既可以是独立的，也可以跟处理器701集成在一起。

当存储器702是独立于处理器701之外的器件时，电子设备700，还可以包括：

总线703，用于连接处理器701以及存储器702。

此外，本申请实施例还提供一种存储有计算机指令的非瞬时计算机可读存储介质，计算机指令用于使计算机执行上述各实施例中的灰度发布方法的各个步骤。例如，可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由权利要求书指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。

Claims (10)

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

根据业务规则以及场景灰度策略进行规则检验，得到检验结果，所述场景灰度策略包括所述业务规则的灰度发布范围；

若在预设时长内所述检验结果符合预设结果，取消所述场景灰度策略的限定，对所述业务规则进行全场景发布；

若所述检验结果不符合所述预设结果，进行规则回滚。

2.根据权利要求1所述的灰度发布方法，其特征在于，在所述根据业务规则以及场景灰度策略进行规则检验，得到检验结果之前，包括：

确定所述灰度发布范围，所述灰度发布范围内具有处理所述业务规则所属业务的权限；

根据每个业务规则的特性确定对应的所述灰度发布范围；

根据所述业务规则以及对应的所述灰度发布范围确定灰度发布规则表，所述灰度发布规则表包括灰度规则。

3.根据权利要求2所述的灰度发布方法，其特征在于，所述根据所述业务规则以及场景灰度策略进行规则检验，得到检验结果，包括：

获取待处理业务，所述待处理业务包括待处理业务规则；

判断所述待处理业务规则是否为所述灰度规则；

若判断结果为是，通过所述待处理业务规则对应的规则引擎以及所述灰度发布范围进行规则检验，得到所述检验结果；

若判断结果为否，通过所述待处理业务规则对应的规则引擎在所述全场景进行业务处理。

4.根据权利要求3所述的灰度发布方法，其特征在于，当所述待处理业务规则的类型为规则文件脚本，所述通过所述待处理业务规则对应的规则引擎以及所述灰度发布范围进行规则检验，得到所述检验结果，还包括：

根据所述灰度发布范围对所述待处理业务规则对应的规则引擎进行筛选；

通过筛选后的规则引擎在对应的所述灰度发布范围内进行规则检验以得到所述检验结果。

5.根据权利要求1-4中任一项所述的灰度发布方法，其特征在于，所述规则回滚，包括：

当所述灰度规则的类型为SQL脚本，则失效所述灰度规则在所述灰度发布范围的权限；

当所述灰度规则的类型为所述规则文件脚本，则通知所述灰度规则对应的规则引擎删除所述灰度规则的规则编号。

6.根据权利要求5所述的灰度发布方法，其特征在于，通过消息队列中间件进行所述灰度规则的发布。

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

第一处理模块，用于根据业务规则以及场景灰度策略进行规则检验，得到检验结果，所述场景灰度策略包括所述业务规则的灰度发布范围；

第二处理模块，用于若在预设时长内所述检验结果符合预设结果，取消所述场景灰度策略的限定，对所述业务规则进行全场景发布；

第三处理模块，用于若所述检验结果不符合所述预设结果，进行规则回滚。

8.根据权利要求7所述的灰度发布装置，其特征在于，所述灰度发布装置，还包括：

第四处理模块，用于：

确定所述灰度发布范围，所述灰度发布范围内具有处理所述业务规则所属业务的权限；

根据每个业务规则的特性确定对应的所述灰度发布范围；

根据所述业务规则以及对应的所述灰度发布范围确定灰度发布规则表，所述灰度发布规则表包括灰度规则。

9.一种电子设备，其特征在于，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-6中任一项所述的灰度发布方法。

10.一种存储有计算机指令的非瞬时计算机可读存储介质，其特征在于，所述计算机指令用于使所述计算机执行权利要求1-6中任一项所述的灰度发布方法。

Images