一种灰度发布方法、装置、设备和存储介质与流程

本发明涉及自动程序设计技术领域，尤其是一种灰度发布方法、装置、设备和存储介质。

背景技术：

常见的系统管理架构包括面向服务的架构(service-orientedarchitecture，soa)以及日益流行的微服务架构。soa能够将应用程序以不同的功能单元(称为服务)进行拆分，每个服务均能独立自主地为其他服务工作，服务之间通过定义良好的接口和协议(依赖关系)联系起来。但对于soa来说，要替换掉系统中的某些部分而不对整个系统造成较大影响是个难题。因此，由soa转向微服务架构势在必行。微服务架构实质上可以认为是细粒度的soa，微服务架构可以实现系统各模块之间的低耦合，也就是说，微服务架构关注的是更轻量级的服务。

在从soa架构向微服务架构转型的过程中，现有技术往往仅关注于对某个应用服务的更新转型，而忽略了该服务对接口调用方式的更新，从而导致了存在生产安全问题。有鉴于此，本申请旨在提供一种灰度发布方法、装置、设备和存储介质。

技术实现要素：

针对现有技术的上述问题，本文的目的在于提供一种灰度发布方法，以解决现有技术在系统从soa架构向微服务架构转型的过程中，由于忽略接口的调用方式匹配问题导致的生产安全问题。

为了解决上述技术问题，本文的具体技术方案如下：

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

接收调用方发送的接口调用请求；

解析所述接口调用请求，获得接口身份信息；

根据所述接口身份信息，判断所述接口是否存在灰度调用；

若所述接口不存在灰度调用，则采用第一架构对应的第一调用代码调用所述接口；

若所述接口存在所述灰度调用，则采用第二架构对应的第二调用代码调用所述接口，所述第二架构为所述第一架构更新后的架构。

具体地，所述根据所述接口身份信息，判断所述接口是否存在灰度调用，进一步包括：

根据所述接口身份信息，查询所述接口是否配置有第二调用代码；

若所述接口未配置所述第二调用代码，则确定所述接口不存在灰度调用；

若所述接口有配置所述第二调用代码，则确定所述接口存在灰度调用。

进一步地，若所述接口有配置所述第二调用代码，则确定所述接口存在灰度调用进一步为：

若所述接口配置有所述第二调用代码，则根据所述接口身份信息，查询所述接口的调用方式切换开关是否开启；

若所述调用方式切换开关未开启，则确定所述接口不存在灰度调用；

若所述调用方式切换开关已开启，则确定所述接口存在灰度调用。

更进一步地，解析所述接口调用请求，还获得调用方身份信息，所述若所述调用方式切换开关已开启，则确定所述接口存在灰度调用进一步为：

若所述调用方式切换开关已开启，则根据所述调用方身份信息和所述接口身份信息，判断所述接口是否存在灰度调用。

具体地，所述获得调用方身份信息，包括：

根据第一获取函数或根据第二获取函数，获取所述调用方身份信息；所述第一获取函数用于整型和长整型身份信息；所述第二获取函数用于获取字符型身份信息。

进一步地，所述根据所述调用方身份信息和所述接口身份信息，判断所述接口是否存在灰度调用，进一步包括：

根据接口身份信息，查询所述接口的灰度调用条件；

根据调用方身份信息，判断所述调用方是否符合所述灰度调用条件；

若所述调用方符合所述灰度调用条件，则判断所述接口存在灰度调用；

若所述调用方不符合所述灰度调用条件，则判断所述接口不存在灰度调用。

优选地，所述灰度调用条件包括：预设身份数值、预设身份数值区间、预设灰度比例值、自定义调用条件中的一个或多个的组合。

优选地，所述方法还包括对所述灰度调用条件进行更新。

进一步地，所述对所述灰度调用条件进行更新，包括：

获得所述接口的第一灰度调用条件；

对所述第一灰度调用条件进行更新，得到第二灰度调用条件；

将第一灰度调用条件替换为第二灰度调用条件。

更进一步地，所述对所述第一灰度调用条件进行更新，得到第二灰度调用条件包括：

增加所述预设数值的数量，和/或增大所述预设数值区间，和/或增大所述预设灰度比例值中的一种或几种的组合。

优选地，所述方法还包括：将所述预设身份数值、预设数值身份区间和预设灰度比例值存储于第一存储模块中，将所述自定义调用条件存储于第二存储模块中。

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

接口调用请求接收模块，用于接收调用方发送的接口调用请求；

解析模块，用于根据所述接口调用请求，解析得到接口身份信息；

第一判断模块，用于根据所述接口身份信息，判断所述接口是否存在灰度调用；

第一调用执行模块，用于当所述接口存在灰度调用时，采用第一架构对应的第一调用代码调用所述接口；

第二调用执行模块，用于当所述接口存在灰度调用时，采用第二架构对应的第二调用代码调用所述接口，所述第二架构为所述第一架构更新后的架构。

第三方面，本文提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述技术方案提供的灰度发布方法。

第四方面，本文提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器质性时实现如上述技术方案提供的灰度发布方法。

采用上述技术方案，本文提供的一种灰度发布方法、装置、设备和存储介质，能够能虑到系统由soa架构向微服务架构转型时接口调用方式的匹配问题，从而能够克服接口调用方式不适配带来的安全性问题和调用失败问题，提高服务功能实现的安全性和成功率。

为让本文的上述和其他目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附图式，作详细说明如下。

附图说明

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

图1示出了本文实施例提供的一种灰度发布方法的步骤示意图；

图2示出了本文实施例中判断接口是否存在灰度调用方法的第一步骤示意图；

图3示出了本文实施例中判断接口是否存在灰度调用方法的第二步骤示意图；

图4示出了本文实施例中判断接口是否存在灰度调用方法的第三步骤示意图；

图5示出了本文实施例中对灰度调用条件进行更新的步骤示意图；

图6示出了本文实施例提供的一种灰度发布装置的结构示意图；

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

附图符号说明：

61、接口调用请求接收模块；

62、解析模块；

63、第一判断模块；

64、第一调用执行模块；

65、第二调用执行模块；

702、计算机设备；

704、处理器；

706、存储器；

708、驱动机构；

710、输入/输出模块；

712、输入设备；

714、输出设备；

716、呈现设备；

718、图形用户接口；

720、网络接口；

722、通信链路；

724、通信总线。

具体实施方式

下面将结合本文实施例中的附图，对本文实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本文一部分实施例，而不是全部的实施例。基于本文中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本文保护的范围。

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

常见的系统管理架构包括面向服务的架构(service-orientedarchitecture，soa)以及日益流行的微服务架构。soa是一种粗粒度、松耦合服务架构，它能够将应用程序的不同功能单元(称为服务)进行拆分，服务之间通过接口和协议联系起来。当在soa架构下要替换掉系统中的某些部分时，很难不对整个系统造成较大影响。而微服务架构可以看成是细粒度的soa，微服务架构可以实现系统各模块之间的低耦合，也就是说，微服务架构关注的是更轻量级。因此，微服务架构能够克服soa架构的上述缺陷从而也使得由soa转向微服务架构势在必行。

然而，再从soa架构向微服务架构转型的过程中，现有技术往往仅关注于对某个应用服务的更新转型，而忽略了该服务对接口调用方式的更新，从而导致了存在生产安全问题。

为了解决接口调用方式未及时更新带来的生产安全问题，本文实施例提供了一种灰度发布方法，图1是本文实施例提供的一种灰度发布方法的步骤示意图，本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或装置产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行。具体的如图1所示，所述方法可以包括：

s101：接收调用方发送的接口调用请求；

本说明书实施例中，所述调用方即为服务，服务发起对接口的调用请求以完成其功能实现，不同服务之间根据其实际功能需求所要求调用的接口可以相同也可以不同。本说明书实施例中，所述接口是指远程调用接口。

s102：解析所述接口调用请求，获得接口身份信息；

即根据所述接口调用请求，明确该服务所需调用的接口，所述接口身份信息可以包括：该接口的名称(id信息)，例如：接口的名称为“getuserbyid”，可以表征该接口可用于实现根据用户的id获取用户的功能。需要说明的是，不同的接口其名称(id信息)不同，即根据名称(id信息)可唯一确定一个所述接口。

s103：根据所述接口身份信息，判断所述接口是否存在灰度调用；

s104：若所述接口不存在灰度调用，则采用第一架构对应的第一调用代码调用所述接口；

s105：若所述接口存在所述灰度调用，则采用第二架构对应的第二调用代码调用所述接口，所述第二架构为所述第一架构更新后的架构。

本说明书实施例中，所述第一架构为soa架构，所述第二架构对应为微服务架构，微服务架构可以理解为是基于soa架构进行更新/升级得到的。当被调用接口不存在灰度调用时，则调用方仍以soa架构对应的调用代码(第一调用代码)调用该接口；否则，以微服务架构对应的调用代码(第二调用代码)调用该接口。从而无论该接口是否配置有灰度调用，都能满足调用方对其进行调用的需求，以使调用方的服务完成自身的功能实现，满足系统从soa架构向微服务架构的过渡转型。

综上，本说明书实施例提供的灰度发布方法，能够考虑到系统由soa架构向微服务架构转型时接口调用方式的匹配问题，从而能够克服接口调用方式不适配带来的安全性问题和调用失败问题，提高服务功能实现的安全性和成功率。

在一些可行的实施例中，如图2所示，步骤s103：根据所述接口身份信息，判断所述接口是否存在灰度调用，进一步包括：

s201：根据所述接口身份信息，查询所述接口是否配置有第二调用代码；

s202：若所述接口未配置所述第二调用代码，则确定所述接口不存在灰度调用；

s203：若所述接口有配置所述第二调用代码，则确定所述接口存在灰度调用。

本说明书实施例中，对满足服务对接口的调用需求前提下，使得一部分接口仍通过第一调用代码以满足soa架构对应的调用需求；另一部分接口配置有第二调用代码以满足微服务架构调用需求。并且本说明书实施例中，无需新增或更换接口，而是根据系统过渡转型需求，对涉及的接口写入新的调用代码，有利于降低开发成本。

如图3所示，进一步地，步骤s203：若所述接口有配置所述第二调用代码，则确定所述接口存在灰度调用进一步为：

s301：若所述接口有配置所述第二调用代码，则根据所述接口身份信息，查询所述接口的调用方式切换开关是否开启；

s302：若所述调用方式切换开关未开启，则确定所述接口不存在灰度调用；

s303：若所述调用方式切换开关已开启，则确定所述接口存在灰度调用。

本说明书实施例中，调用方并不直接将原有soa架构对应的第一调用代码删除，而是新增微服务架构对应的第二调用代码，并设置调用方式切换开关，控制切换以第一调用代码和第二调用代码中的一个来调用该接口。具体地，当所述调用方式切换开关开启时，可以将接口的调用方式从第一调用代码对应的方式切换成第二调用代码对应的方式；而当所述调用方式切换开关未开启时，则尽管该接口配置有第二调用代码，但该接口依旧只能采用第一调用代码对应的调用方式。

从而，本说明书实施例提供的灰度发布方法，可以对接口调用方式有选择的开启调用方式切换开关进行切换，不是以“一刀切”的方式使得所有配置有第二调用代码的接口均以第二调用代码被调用。通过调用方式切换开关的打开或闭合，可使得一部分接口仍以soa架构对应的第一调用代码被调用；另一部分接口以微服务对应的第二调用代码被调用并作用为调用测试，使得接口调用方式适配于soa架构向微服务架构的过渡、实现接口的灰度发布的同时，实现对灰度发布质量的测试，提高接口调用方式转型的成功率和效率。

对接口是否存在灰度调用、接口调用方式的切换可基于以下代码实现：

booleancallnewapi＝true；

if(！callnewapi){//若callnewapi非真，即当接口的调用方式切换开关未开启时；

//callsoainterface，以soa架构对应的第一调用代码调用接口；

}else{//否则

//callmicroserviceinterface，以微服务架构对应的第二调用代码调用接口；

}

在一些可行的实施例中，步骤s102在解析所述接口调用请求时，除获得接口身份信息外，还能够获得调用方身份信息，例如，调用方的名称(调用方id信息)。从而步骤s303：若所述调用方式切换开关已开启，则确定所述接口存在灰度调用进一步为：

若所述调用方式切换开关已开启，则根据所述调用方身份信息和所述接口身份信息，判断所述接口是否存在灰度调用。

本说明书实施例中，调用方身份信息可以是该接口的id信息(例如，为数字编号，则对应为整型或长整型)或是该接口的名称(对应为字符串)。则调用方身份信息可通过如下方法获得，方法包括：

根据第一获取函数或根据第二获取函数，获取所述调用方身份信息；所述第一获取函数用于整型和长整型身份信息；所述第二获取函数用于获取字符型身份信息。则本说明书实施例提供的灰度发布方法，可满足各种类型的调用方对接口进行灰度调用的需求，适用性广。

对于获取调用方身份信息可基于如下代码实现：

publicinterfaceidarkfeature{

booleanenabled()；//用于判定调用方式切换开关是否开启；

booleandark(longdarktarget)；//第一获取函数，用于获取整型或长整型的调用方身份信息；

booleandark(stringdarktarget)；//第二获取函数，用于获取为字符型的调用方身份信息；

}

不同调用方其身份信息类型可以是不同的，本说明书实施例中，采用上述代码中的两种获取函数，用于获取调用方身份信息，进而用于对调用方是否满足接口的灰度调用条件进行判断。例如，对于“getuserbyid”这个接口来说，对该接口发起调用请求的调用方的身份信息则用户id，是整型类型的参数。

本说明书实施例提供的灰度发布方法，能够综合接口身份信息和调用方身份信息来对是否存在灰度调用进行判断，有利于实现对接口灰度发布的灵活配置。

具体地，如图4所示，根据所述调用方身份信息和所述接口身份信息，判断所述接口是否存在灰度调用，进一步包括：

s401：根据接口身份信息，查询所述接口的灰度调用条件；

s402：根据调用方身份信息，判断所述调用方是否符合所述灰度调用条件；

s403：若所述调用方符合所述灰度调用条件，则判断所述接口存在灰度调用；

s404：若所述调用方不符合所述灰度调用条件，则判断所述接口不存在灰度调用。

本说明书实施例中，可对接口设置有灰度调用条件，以使满足该灰度调用条件的调用方才能够以微服务架构对应的第二调用代码调用该接口。对于配置有第二调用代码的接口来说，当其调用方式切换开关为打开状态时，也仍不是“一刀切”的使所有调用方均能以第二调用代码对应的调用方式调用该接口；而是，使满足该接口灰度调用条件的调用方能够以第二调用代码调用该接口，而另一部分不满足灰度调用条件的调用方仍以第一调用代码调用该接口。从而，在实现接口灰度发布的前提下，对调用方根据其身份信息进行筛选。

满足该接口灰度调用条件的一部分调用方能够以第二调用代码对该接口进行调用时，还可以作用为接口调用测试样本，以对该接口微服务架构的调用的成功率、效率等性能进行校验，提高接口适配于微服务调用的能力。在测试优化后，再逐渐扩大该接口灰度调用条件的适用范围，使得越来越多的调用方能够以第二调用代码调用该接口，实现接口的灰度发布。因此，在一些优选的实施例中，所述灰度发布方法，还包括：s405：对所述灰度调用条件进行更新。

需要说明的是，本文中，步骤s405：对所述灰度调用条件进行更新，并不是严格执行在步骤s404之后，而是可以执行在对接口配置第二调用代码之后的任意一个环节中。

在一些优选的实施例中，所述接口的灰度调用条件包括：预设调用身份数值、预设身份数值区间、预设灰度比例值以及自定义调用条件中的一个或多个，其中，自定义调用条件可以由业务方以spring的编程式进行编程实现。

本说明书实施例中，所述灰度调用条件能够支持不同格式(json、yaml、xml等格式)、不同数据源(本地文件配置或配置中心集中配置等)的配置；并且可扩展，支持复杂的灰度规则，例如与业务逻辑相关的规则。

本说明书实施例中，可按照既定的语法规则，对调用方身份适用于第二调用代码的灰度调用条件进行了配置，提供了具体数值、数值区间和比例值这三种规则之外，同时还支持业务扩展定义复杂的灰度调用条件，兼顾了对调用方灰度调用的便捷性和灵活性。

接口的灰度调用条件的配置可基于如下代码实现：

对于接口“getuserbyid”，其灰度调用条件为“893，342，1020-1120，30％”，其中，“893”和“342”为具体的调用方身份数值，“1020-1120”是身份数据区间，即当调用方的身份信息(调用方id信息)为“893”或“342”时，或当调用方的身份信息在[1020，1120]区间范围内时，该调用方能够以第二调用代码调用接口“getuserbyid”；灰度调用条件中“30％”为预设灰度比例值，即当所有要调用接口“getuserbyid”的调用方中，能够对该接口以第二调用代码进行调用的调用方占总调用方数量的30％。对接口“loan”其灰度调用条件仅设置有一区间值，此处不再赘述。

从上述示例可以看出，在灰度调用条件中，当设置有预设身份数值时，其数值可以设置有一个也可以设置有多个；并且，除此之外，当设置有预设身份区间时，其区间可以设置有一个也可以设置有多个。

如图5所示，在一些优选实施例中，步骤s405：所述对所述灰度调用条件进行更新，包括：

s501：获得所述接口的第一灰度调用条件；所述第一灰度调用条件即为所述接口当前配置的灰度调用条件。

s502：对所述第一灰度调用条件进行更新，得到第二灰度调用条件；

s503：将第一灰度调用条件替换为第二灰度调用条件。

即本说明书实施例中，在对接口的灰度调用条件进行更新时，并不是直接对接口当前的第一灰度调用条件直接进行更新，而是先保存该第一灰度调用条件并以预设的更新规则对第一灰度调用条件进行更新得到第二灰度调用条件，再用更新后的第二灰度调用条件替换替代原有的第一灰度调用条件，能够避免灰度调用条件的更新与判断调用方是否满足灰度调用条件的过程发生冲突。

需要说明的是，本说明书实施例中，优选地，对所述灰度调用条件采用热更新的方式，使得当修改了灰度调用条件后，系统无需重启即可实现对灰度调用条件的自动加载和更新，能够提高系统的可用性。

本说明书实施例中，通过更新灰度调用条件的方式，使得一部分调用方能够调用以微服务架构对应的调用代码调用接口，待调用测试通过后，再逐渐增加能以微服务架构对应的调用代码调用该接口的调用方的数量，使其比例越来越高，范围越来越大，实现接口的灰度发布；有利于减少接口调用的重复开发，缩短开发周期。

在一些可行的实施例中，在步骤s502：对所述第一灰度调用条件进行更新，得到第二灰度调用条件时，对第一灰度调用条件进行更新的更新规则可以包括：

增加所述预设数值的数量，和/或增大所述预设数值区间，和/或增大所述预设灰度比例值中的一种或几种的组合。

优选地，为了避免灰度调用条件热更新时，自定义调用条件被预设身份数值、预设身份区间和预设灰度比例值中的一个或多个覆盖，本说明书实施例中将所述预设身份数值、预设身份区间和预设灰度比例值存储于第一存储模块中，将所述自定义调用条件存储于第二存储模块中。

在一些可行的实施例中，步骤s502：根据调用方身份信息，判断所述调用方是否符合所述灰度调用条件，进一步包括：

判断所述调用方身份信息是否为整型或长整型；

若所述调用方身份信息为整型或长整型，则将调用方身份信息和所述灰度调用条件进行比较；

若所述调用方身份信息不为整型或长整型，则将所述调用方身份信息与所述灰度调用条件中的预设灰度比例值和/或自定义调用条件进行比较。

如图6所示，本说明书实施例中，还提供一种灰度发布装置，包括：

接口调用请求接收模块61，用于接收调用方发送的接口调用请求；

解析模块62，用于根据所述接口调用请求，解析得到接口身份信息；

第一判断模块63，用于根据所述接口身份信息，判断所述接口是否存在灰度调用；

第一调用执行模块64，用于当所述接口存在灰度调用时，采用第一架构对应的第一调用代码调用所述接口；

第二调用执行模块65，用于当所述接口存在灰度调用时，采用第二架构对应的第二调用代码调用所述接口，所述第二架构为所述第一架构更新后的架构。

所述装置还包括：

查询模块，用于根据所述接口身份信息，查询所述接口是否配置有第二调用代码；

第二判断模块，用于当所述接口未配置有所述第二调用代码时，判断所述接口不存在灰度调用；

第三判断模块，用于当所述接口有配置有所述第二调用代码时，判断所述接口存在灰度调用。

综上所述，本说明书实施例提供的一种灰度发布方法和装置，能够满足系统从soa架构向微服务架构转型过程中，接口调用方式的转变，实现接口灰度灰度，满足服务对接口的调用需求；且接口的灰度调用条件可以灵活扩展并支持复杂的灰度发布规则，兼顾了易用性和灵活性，可以缩短业务应用开发周期，降低维护成本。

本说明书实施例还提供一种灰度发布系统，包括规则配置单元、接口判定单元、规则加载单元和规则扩展单元，各单元的职责和功能如下：

规则配置单元，用于以统一的语法格式定义各接口的灰度调用条件。接口的灰度调用条件包括预设身份数值、预设身份数值区间和预设灰度比例值。

在灰度发布系统启动时，会将规则配置单元所做的配置解析并加载到内存对象中，从而能够直接使用灰度调用条件来判定某个调用方是否灰满足对接口以第二调用代码进行调用的条件。

接口判定单元，用于对业务调用方暴露对灰度判定接口，支持调用方灵活扩展，使用抽象接口来定义。

包括，返回调用方式切换开关的逻辑，用于判定调用方式切换开关是否开启，即是采用soa架构对应的第一调用代码还是采用微服务对应的第二调用代码；除此之外，还包括对调用方身份信息的获取，通过两个dark()获取函数，满足对不同类型的调用方的身份信息的获取。

规则加载单元，由于所述灰度发布系统需要集成到业务应用中使用，因此需尽可能做到低侵入松耦合。本说明书实施例提供的灰度发布系统，其中灰度调用规则的编写延续spring的配置方式，支持xml、yaml、properties等几种配置文件格式。同时，借鉴spring的约定优于配置设计原则，用户只需要将配置文件按照约定来命名，并且放置到约定的路径下，就能按照约定自动查找和加载配置文件。除了本地文件配置之外，还支持灵活的数据源配置，比如zookeeper或者企业级配置中心。

另外，在接口灰度发布的过程中，接口的灰度调用条件将会频繁修改，以实现逐渐增加满足对接口以第二调用代码进行调用的调用方的数量和范围。从运维的角度来说，如果每次修改灰度调用条件都要重启系统，则大大影响系统的可用性。所以，灰度规则需要支持热更新，具体来说，就是当修改了灰度规则之后，系统在不重启的情况下会自动加载、更新灰度规则。

规则扩展单元，本说明书实施例提供的灰度发布系统，其中灰度调用条件除提供了预设身份数值、预设身份数值区间和预设灰度比例值三种基本的灰度条件外，还支持业务方自行扩展定义复杂的业务规则。在接口灰度发布的场景中，三种基本的灰度条件已经能够满足绝大部分情况，对于极个别复杂的灰度条件，可借鉴spring的编程式配置，由业务方编程实现，兼顾易用性和灵活性。

如图7所示，为本文实施例提供的一种计算机设备，所述计算机设备702可以包括一个或多个处理器704，诸如一个或多个中央处理单元(cpu)，每个处理单元可以实现一个或多个硬件线程。计算机设备702还可以包括任何存储器706，其用于存储诸如代码、设置、数据等之类的任何种类的信息。非限制性的，比如，存储器706可以包括以下任一项或多种组合：任何类型的ram，任何类型的rom，闪存设备，硬盘，光盘等。更一般地，任何存储器都可以使用任何技术来存储信息。进一步地，任何存储器可以提供信息的易失性或非易失性保留。进一步地，任何存储器可以表示计算机设备702的固定或可移除部件。在一种情况下，当处理器704执行被存储在任何存储器或存储器的组合中的相关联的指令时，计算机设备702可以执行相关联指令的任一操作。计算机设备702还包括用于与任何存储器交互的一个或多个驱动机构708，诸如硬盘驱动机构、光盘驱动机构等。

计算机设备702还可以包括输入/输出模块710(i/o)，其用于接收各种输入(经由输入设备712)和用于提供各种输出(经由输出设备714))。一个具体输出机构可以包括呈现设备716和相关联的图形用户接口718(gui)。在其他实施例中，还可以不包括输入/输出模块710(i/o)、输入设备712以及输出设备714，仅作为网络中的一台计算机设备。计算机设备702还可以包括一个或多个网络接口720，其用于经由一个或多个通信链路722与其他设备交换数据。一个或多个通信总线724将上文所描述的部件耦合在一起。

通信链路722可以以任何方式实现，例如，通过局域网、广域网(例如，因特网)、点对点连接等、或其任何组合。通信链路722可以包括由任何协议或协议组合支配的硬连线链路、无线链路、路由器、网关功能、名称服务器等的任何组合。

对应于图1-图5中的方法，本文实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法的步骤。

本文实施例还提供一种计算机可读指令，其中当处理器执行所述指令时，其中的程序使得处理器执行如图1至图5所示的方法。

应理解，在本文的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本文实施例的实施过程构成任何限定。

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

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本文的范围。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

另外，在本文各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本文的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本文各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

本文中应用了具体实施例对本文的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本文的方法及其核心思想；同时，对于本领域的一般技术人员，依据本文的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本文的限制。