灰度发布控制方法、装置、系统、电子设备及存储介质与流程

本发明涉及互联网领域，尤其涉及一种灰度发布控制方法、装置、系统、电子设备及存储介质。

背景技术：

对于网站应用来说，通常要求提供7*24小时无间断服务，即使服务升级也要不影响到用户正常访问网站。一般情况下会通过灰度发布，即将新版本先发布其中一台服务器，看服务器有没有报异常，访问网站看服务是否正常，确认没问题后，再发布一半服务器，最后确认没问题再全量发布。

目前的灰度发布一般通过自动部署系统完成，灰度发布一般只能支持到按照少量几种信息进行灰度，对于较复杂的灰度逻辑支持不好，影响灰度发布的灵活应用。

技术实现要素：

本发明实施例要解决的技术问题是为了克服现有技术中灰度发布只能支持到按照少量几种信息进行灰度，对于较复杂的灰度逻辑支持不好，影响灰度发布的灵活应用的缺陷，提供一种灰度发布控制方法、装置、系统、电子设备及存储介质。

本发明实施例是通过以下技术方案解决上述技术问题的：

本发明实施例提供一种web(全球广域网)服务灰度发布控制方法，web服务具有原始版本和至少一备选版本，所述方法包括：

接收客户端的访问请求，所述访问请求用于请求访问所述web服务；

获取所述web服务匹配的灰度策略，所述灰度策略包括灰度控制逻辑，所述灰度控制逻辑用于配置所述web服务按照预设信息区分的指定访问的至少一备选版本；

根据所述灰度控制逻辑，判断是否存在所述客户端在所述预设信息上的值所对应的备选版本；

若存在，则将所述访问请求转发至所述对应的备选版本；

若不存在，则将所述访问请求转发至所述原始版本。

较佳地，所述访问请求包括请求url(统一资源定位符)，所述灰度控制逻辑配置有所述web服务指定访问的备选版本的url以及所述原始版本的url；

将所述访问请求转发至所述对应的备选版本的步骤包括：将所述访问请求转发至所述对应的备选版本的url；

将所述访问请求转发至所述原始版本的步骤包括：将所述访问请求转发至所述原始版本的url。

较佳地，所述预设信息包括ip(互联网协议地址)、uid(用户身份证明)、user-agent(用户代理)和第三方服务调用者中的至少一种。

较佳地，所述灰度控制逻辑配置有所述web服务指定访问的至少一备选版本以及每个备选版本的控制逻辑；

根据所述灰度控制逻辑，判断是否存在所述客户端在所述预设信息上的值所对应的备选版本的步骤，包括：

判断所述灰度控制逻辑配置的备选版本是否为空；

若为空，则将所述访问请求转发至所述原始版本；

若不为空，则：

逐一执行所述备选版本的控制逻辑，直至找到所述客户端在所述预设信息上的值所命中的备选版本，并将命中的备选版本作为所述对应的备选版本，将所述访问请求转发至所述对应的备选版本；

若所述客户端在所述预设信息上的值未命中任何备选版本，则将所述访问请求转发至所述原始版本；

和/或，所述灰度控制逻辑还配置有每个备选版本的请求分发策略；

所述方法在将所述访问请求转发至所述对应的备选版本时，按照所述请求分发策略进行请求分发；

和/或，所述灰度控制逻辑还配置有每个备选版本是否后台执行；

所述方法在将所述访问请求转发至所述对应的备选版本时，若所述对应的备选版本配置为后台执行，则后台转发所述访问请求至所述对应的备选版本。

较佳地，所述灰度控制逻辑还配置有每个备选版本的异常处理规则，所述异常处理规则用于配置至少一种异常逻辑以及在出现所述异常逻辑时相应的解决方案；

所述方法还包括在将所述访问请求转发至所述对应的备选版本后，判断是否出现任意一种所述异常逻辑，若是，则执行相应的解决方案；

其中，所述异常逻辑优选包括以下状况中的至少一种：

产生错误的响应状态码；

访问超时；

访问限流；

所述解决方案优选包括：将所述访问请求转发至所述原始版本。

较佳地，所述灰度策略还包括验证逻辑，所述验证逻辑用于验证所述备选版本的内容是否正确；

所述方法还包括：在将所述访问请求转发至所述对应的备选版本后，按照所述验证逻辑验证所述备选版本的响应结果是否正确；

若错误，则将所述访问请求转发至所述原始版本。

本发明实施例提供一种灰度控制方法，所述方法包括：

配置灰度策略，所述灰度策略包括灰度控制逻辑，所述灰度控制逻辑用于配置web服务按照预设信息区分的指定访问的至少一备选版本。

较佳地，所述预设信息包括ip、uid、user-agent和第三方服务调用者中的至少一种。

较佳地，所述灰度控制逻辑配置有所述web服务指定访问的至少一备选版本，以及以下内容中的至少一种：

所述web服务的原始版本的url；

每个备选版本的url；

每个备选版本的控制逻辑；

每个备选版本的请求分发策略；

每个备选版本是否后台执行；

每个备选版本的异常处理规则，所述异常处理规则用于配置至少一异常逻辑以及在出现所述异常逻辑时相应的解决方案，其中，所述异常逻辑中优选包括以下状况中的至少一种：

产生错误的响应状态码；

访问超时；

访问限流；

所述解决方案优选包括：将所述访问请求转发至所述原始版本。

较佳地，所述灰度策略还包括验证逻辑，所述验证逻辑用于验证所述备选版本的内容是否正确。

本发明实施例提供一种web服务灰度发布控制装置，所述web服务具有原始版本和至少一备选版本，所述装置包括：接收模块、获取模块、判断模块和转发模块；

所述接收模块用于接收客户端的访问请求，所述访问请求用于请求访问所述web服务；

所述获取模块用于获取所述web服务匹配的灰度策略，所述灰度策略包括灰度控制逻辑，所述灰度控制逻辑用于配置所述web服务按照预设信息区分的指定访问的至少一备选版本；

所述判断模块用于根据所述灰度控制逻辑，判断是否存在所述客户端在所述预设信息上的值所对应的备选版本，若存在则调用所述转发模块将所述访问请求转发至所述对应的备选版本，若不存在则调用所述转发模块将所述访问请求转发至所述原始版本。

较佳地，所述访问请求包括请求url，所述灰度控制逻辑配置有所述web服务指定访问的备选版本的url以及所述原始版本的url；

将所述访问请求转发至所述对应的备选版本包括：将所述访问请求转发至所述对应的备选版本的url；

将所述访问请求转发至所述原始版本包括：将所述访问请求转发至所述原始版本的url。

较佳地，所述预设信息包括ip、uid、user-agent和第三方服务调用者中的至少一种。

较佳地，所述灰度控制逻辑配置有所述web服务指定访问的至少一备选版本以及每个备选版本的控制逻辑；

所述判断模块用于判断所述灰度控制逻辑配置的备选版本是否为空，若为空则调用所述转发模块将所述访问请求转发至所述原始版本，若不为空则逐一执行每个备选版本的控制逻辑，直至找到所述客户端在所述预设信息上的值所命中的备选版本，然后将命中的备选版本作为所述对应的备选版本，调用所述转发模块将所述访问请求转发至所述对应的备选版本，若所述客户端在所述预设信息上的值未命中任何备选版本则调用所述转发模块将所述访问请求转发至所述原始版本；

和/或，所述灰度控制逻辑还配置有每个备选版本的请求分发策略；

所述转发模块在将所述访问请求转发至所述对应的备选版本时，按照所述请求分发策略进行请求分发；

和/或，所述灰度控制逻辑还配置有每个备选版本是否后台执行；

所述转发模块在将所述访问请求转发至所述对应的备选版本时，若所述对应的备选版本配置为后台执行，则后台转发所述访问请求至所述对应的备选版本。

较佳地，所述灰度控制逻辑还配置有每个备选版本的异常处理规则，所述异常处理规则用于配置至少一种异常逻辑以及在出现所述异常逻辑时相应的解决方案；

所述装置还包括：

异常处理模块，用于在将所述访问请求转发至所述对应的备选版本后，判断是否出现任意一种所述异常逻辑，若是，则执行相应的解决方案；

其中，所述异常逻辑优选包括以下状况中的至少一种：

产生错误的响应状态码；

访问超时；

访问限流；

所述解决方案优选包括：调用所述转发模块将所述访问请求转发至所述原始版本。

较佳地，所述灰度策略还包括验证逻辑，所述验证逻辑用于验证所述备选版本的内容是否正确；

所述装置还包括：

验证模块，用于在将所述访问请求转发至所述对应的备选版本后，按照所述验证逻辑验证所述备选版本的响应结果是否正确，若验证错误则调用所述转发模块将所述访问请求转发至所述原始版本。

本发明实施例提供一种灰度控制系统，所述系统包括：

配置模块，用于配置灰度策略，所述灰度策略包括灰度控制逻辑，所述灰度控制逻辑用于配置web服务按照预设信息区分的指定访问的至少一备选版本。

较佳地，所述预设信息包括ip、uid、user-agent和第三方服务调用者中的至少一种。

较佳地，所述灰度控制逻辑配置有所述web服务指定访问的至少一备选版本，以及以下内容中的至少一种：

所述web服务的原始版本的url；

每个备选版本的url；

每个备选版本的控制逻辑；

每个备选版本的请求分发策略；

每个备选版本是否后台执行；

每个备选版本的异常处理规则，所述异常处理规则用于配置至少一异常逻辑以及在出现所述异常逻辑时相应的解决方案，其中，所述异常逻辑优选包括以下状况中的至少一种：

产生错误的响应状态码；

访问超时；

访问限流；

所述解决方案优选包括：将所述访问请求转发至所述原始版本。

较佳地，所述灰度策略还包括验证逻辑，所述验证逻辑用于验证所述备选版本的内容是否正确。

本发明实施例提供一种web服务系统，所述web服务系统包括权利要求11-16中任意一项所述的web服务灰度发布控制装置以及权利要求17-20中任意一项所述的灰度控制系统；

所述web服务灰度发布控制装置在接收到所述客户端的访问请求后调用所述灰度控制系统，所述灰度控制系统返回所述web服务匹配的灰度策略给所述web服务灰度发布控制装置。

本发明实施例提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上所述的web服务灰度发布控制方法。

本发明实施例提供一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如上所述的web服务灰度发布控制方法的步骤。

本发明实施例提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如上所述的灰度控制方法。

本发明实施例提供一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如上所述的灰度控制方法的步骤。

在符合本领域常识的基础上，上述各优选条件，可任意组合，即得本发明各较佳实施例。

本发明实施例的积极进步效果在于：通过按照预设信息区分web服务指定访问的备选版本，实现了支持多种信息、多备选版本的灰度发布；通过灰度策略的配置，尤其是灰度控制逻辑和验证逻辑，使得支持复杂的灰度逻辑，能够更灵活地进行灰度发布；通过在异常状况下的自适应处理，保证服务的正常可用以及良好的用户体验。

附图说明

图1为本发明实施例1的一种web服务灰度发布控制方法的流程图。

图2为本发明实施例2的一种web服务灰度发布控制方法的流程图。

图3为本发明实施例3的一种灰度控制方法的流程图。

图4为本发明实施例4的一种web服务灰度发布控制装置的示意框图。

图5为本发明实施例5的一种web服务灰度发布控制装置的示意框图。

图6为本发明实施例6的一种灰度控制系统的示意框图。

图7为本发明实施例6的一种web服务系统的示意框图。

图8为本发明实施例7的一种电子设备的结构示意图。

具体实施方式

下面通过实施例的方式进一步说明本发明，但并不因此将本发明限制在所述的实施例范围之中。

实施例1

图1示出了本实施例的一种web服务灰度发布控制方法。所述web服务具有原始版本和至少一备选版本。所述web服务灰度发布控制方法包括以下步骤：

步骤11：接收客户端的访问请求。所述访问请求用于请求访问所述web服务。

步骤12：获取所述web服务匹配的灰度策略。所述灰度策略包括灰度控制逻辑。所述灰度控制逻辑用于配置所述web服务按照预设信息区分的指定访问的至少一备选版本。

步骤13：根据所述灰度控制逻辑，判断是否存在所述客户端在所述预设信息上的值所对应的备选版本，若存在，则执行步骤14，若不存在，则执行步骤15。

步骤14：将所述访问请求转发至所述对应的备选版本。

步骤15：将所述访问请求转发至所述原始版本。

本实施例的web服务灰度发布控制方法可以应用但不限于应用于web服务版本的更新，不同版本的测试等场景。所述原始版本可以是web服务原先的、功能稳定的老版本，所述备选版本可以是web服务新开发的、功能需要进一步测试或者不确定功能是否稳定的新版本。对于一个web服务所能具有的备选版本的数量，可以根据实际开发情况、发布情况等多种因素而定，本实施例不作具体限定。

本实施例的灰度控制逻辑表示客户端在预设信息上的值不同，指定访问的web服务的备选版本就可能不同。本实施例中，所述预设信息可以包括ip、uid、user-agent和第三方服务调用者中的至少一种，相比于传统的灰度发布可支持灰度的信息更多，使得整个灰度发布更为灵活。通过所述灰度控制逻辑的配置，本实施例的方法可以实现在不同用户访问同一web服务时，使用的版本会有所不同，支持多版本的灰度发布。

实施例2

本实施例提供的web服务灰度发布控制方法是在实施例1的基础上的进一步细化，主要体现于：

本实施例的灰度策略包括灰度控制逻辑和验证逻辑。所述灰度策略具体可以配置多个配置项，有利于实现更复杂的灰度控制和版本验证。其中，用于实现所述灰度控制逻辑的配置项可以包括但不限于配置：

键值(key，如key＝请求url)，用于灰度策略的匹配；

所述原始版本的url(old_version_url)；

所述web服务指定访问的至少一备选版本(version，如version＝versionn，n为正整数)；

每个备选版本的url(versionn_url，可以是相对路径如/tem/v1，也可以时绝对路径如服务器内部转发地址http://a.local/item/v1、重定向地址http://a.com/item/v1)；

每个备选版本的控制逻辑(versionn_control_logic，如versionn_control_logic＝lua代码)；

每个备选版本的请求分发策略(versionn_dispatch，如versionn_dispatch＝redirect/forward)，所述请求分发策略用于表示在分发请求时是服务器内部转发到versionn的url还是重定向到versionn的url；

每个备选版本是否后台执行(versionn_background，如versionn_background＝0/1)，如果是后台执行，则表示将流量复制到versionn，而不执行灰度逻辑；

每个备选版本的异常处理规则，所述异常处理规则用于配置至少一种异常逻辑以及在出现所述异常逻辑时相应的解决方案，其中，所述异常逻辑优选包括但不限于以下状况中的至少一种：

产生错误的响应状态码(versionn_error_status，如versionn_error_status＝404,500,502,503)；

访问超时(versionn_timeout，如versionn_timeout＝5s)；

访问限流(versionn_limit，如versionn_limit＝100/s)；

上述状况相应的解决方案可以相同或不同，本实施例的所述解决方案优选包括但不限于：将所述访问请求转发至所述原始版本。

所述验证逻辑用于验证所述备选版本的内容是否正确。用于实现所述验证逻辑的配置项可以包括但不限于配置：

验证规则(versionn_validation_rule，如versionn_validation_rule＝lua代码)，用于验证versionn内容是否正确，若返回0则表示验证失败。

每个备选版本的配置项可以根据实际需求相同或不同。各配置项的具体配置也可以根据实际需求相同或不同。

图2示出了本实施例的一种web服务灰度发布控制方法。针对本实施例的灰度控制逻辑，所述web服务灰度发布控制方法包括以下步骤：

步骤21：接收客户端的访问请求，所述访问请求包括请求url、源ip、请求参数和请求头，其中请求url用以表示请求访问的web服务。

步骤22：使用所述请求url，获取key为所述请求url的灰度策略。

步骤23：判断所述灰度策略的灰度控制逻辑配置的备选版本是否为空，若为空，则执行步骤24，若不为空，则执行步骤25。

步骤24：将所述访问请求转发至所述原始版本的url。

步骤25：逐一执行所述备选版本的控制逻辑，直至找到所述客户端在所述预设信息上的值所命中的备选版本，并将命中的备选版本作为所述对应的备选版本，然后执行步骤27。例如，假设web服务指定访问的备选版本为version1和version2，则先执行version1的控制逻辑，此处利用lua(一种脚本语言)脚本语言能通过loadstring(一个函数类型)动态解析脚本实现动态配置，将请求url、源ip、请求参数和请求头传入lua函数并执行，假设预设信息为uid且预设uid尾号为1、3、5的访问请求转发至version1，如果执行的返回值为1则表示命中version1，否则表示未命中version1，然后执行version2的控制逻辑，同样判断返回值是否为1，若返回1则表示命中version2，否则表示未命中version2。

步骤26：若所述客户端在所述预设信息上的值未命中任何备选版本，则执行步骤24。

步骤27：将所述访问请求转发至所述对应的备选版本的url。在将所述访问请求转发至所述对应的备选版本时，需要按照所述请求分发策略进行请求分发，如果是forward则表示服务器内部转发至所述对应的备选版本的url，如果是redirect则表示重定向到所述对应的备选版本的url；若所述对应的备选版本配置为后台执行，则后台转发所述访问请求至所述对应的备选版本，在不上线的情况下通过观察日志来判断所述对应的备选版本是否正确。

步骤28：判断是否出现任意一种所述异常逻辑，包括转发返回响应后响应状态代码是否正确、是否超时、是否限流，若出现任意一种所述异常逻辑，则执行步骤24，若未出现任意一种所述异常逻辑，则执行步骤29。

步骤29：按照所述验证逻辑验证所述备选版本的响应结果是否正确，若错误，则执行步骤24。

在本实施例中，灰度发布的控制非常灵活，能支持多版本灰度，能支持灰度的可配置，能支持复杂的灰度控制和验证逻辑，能复制流量来灰度验证功能，能柔性自适应处理异常逻辑，在遇到问题时快速自动降级到原始版本处理，不用担心影响到用户体验，从而实现柔性多版本灰度。

实施例1和实施例2的web灰度服务发布控制方法均可以使用nginx(一个高性能的http和反向代理服务，也是一个imap/pop3/smtp服务)接入层(或是用其他类似nginx的技术，比如用go语言写一个接入层)+lua实现。

实施例3

图3示出了本实施例的一种灰度控制方法。所述灰度控制方法包括：

步骤31：配置灰度策略。

本实施例中，所述灰度策略包括灰度控制逻辑。所述灰度控制逻辑用于配置web服务按照预设信息区分的指定访问的至少一备选版本。本实施例的灰度控制逻辑表示客户端在预设信息上的值不同，指定访问的web服务的备选版本就不同。

本实施例中，所述预设信息包括ip、uid、user-agent和第三方服务调用者中的至少一种，相比于传统的灰度发布可支持灰度的信息更多，使得整个灰度发布更为灵活。

所述灰度策略具体可以配置多个配置项，有利于实现更复杂的灰度控制。其中，用于实现所述灰度控制逻辑的配置项可以包括但不限于配置：

键值(key，如key＝请求url)，用于灰度策略的匹配；

所述原始版本的url(old_version_url)；

所述web服务指定访问的至少一备选版本(version，如version＝versionn，n为正整数)；

每个备选版本的url(versionn_url，可以是相对路径如/tem/v1，也可以时绝对路径如服务器内部转发地址http://a.local/item/v1、重定向地址http://a.com/item/v1)；

每个备选版本的控制逻辑(versionn_control_logic，如versionn_control_logic＝lua代码)；

每个备选版本的请求分发策略(versionn_dispatch，如versionn_dispatch＝redirect/forward)，所述请求分发策略用于表示在分发请求时是服务器内部转发到versionn的url还是重定向到versionn的url；

每个备选版本是否后台执行(versionn_background，如versionn_background＝0/1)，如果是后台执行，则表示将流量复制到versionn，而不执行灰度逻辑；

每个备选版本的异常处理规则，所述异常处理规则用于配置至少一种异常逻辑以及在出现所述异常逻辑时相应的解决方案，其中，所述异常逻辑优选包括但不限于以下状况中的至少一种：

产生错误的响应状态码(versionn_error_status，如versionn_error_status＝404,500,502,503)；

访问超时(versionn_timeout，如versionn_timeout＝5s)；

访问限流(versionn_limit，如versionn_limit＝100/s)；

上述状况相应的解决方案可以相同或不同，本实施例的所述解决方案优选包括但不限于：将所述访问请求转发至所述原始版本。

本实施例中，所述灰度策略还可以包括验证逻辑。所述验证逻辑用于验证所述备选版本的内容是否正确。用于实现所述验证逻辑的配置项可以包括但不限于配置：

验证规则(versionn_validation_rule，如versionn_validation_rule＝lua代码)，用于验证versionn内容是否正确，若返回0则表示验证失败。

每个备选版本的配置项可以根据实际需求相同或不同。各配置项的具体配置也可以根据实际需求相同或不同。

本实施例的灰度控制方法可以单独使用，以实现复杂灰度策略的配置，也可以配合实施例1或实施例2中的web服务灰度发布控制方法使用，例如为web服务灰度发布控制方法提供配置好的灰度策略，以保证灰度控制的进行。

实施例4

图4示出了本实施例的一种web服务灰度发布控制装置。所述web服务具有原始版本和至少一备选版本。所述web服务灰度发布控制装置40包括：接收模块41、获取模块42、判断模块43和转发模块44。

所述接收模块41用于接收客户端的访问请求。所述访问请求用于请求访问所述web服务。

所述获取模块42用于获取所述web服务匹配的灰度策略。所述灰度策略包括灰度控制逻辑。所述灰度控制逻辑用于配置所述web服务按照预设信息区分的指定访问的至少一备选版本。

所述判断模块43用于根据所述灰度控制逻辑，判断是否存在所述客户端在所述预设信息上的值所对应的备选版本，若存在则调用所述转发模块44将所述访问请求转发至所述对应的备选版本，若不存在则调用所述转发模块44将所述访问请求转发至所述原始版本。

本实施例的web服务灰度发布控制装置40可以应用但不限于应用于web服务版本的更新，不同版本的测试等场景。所述原始版本可以是web服务原先的、功能稳定的老版本，所述备选版本可以是web服务新开发的、功能需要进一步测试或者不确定功能是否稳定的新版本。对于一个web服务所能具有的备选版本的数量，可以根据实际开发情况、发布情况等多种因素而定，本实施例不作具体限定。

本实施例的灰度控制逻辑表示客户端在预设信息上的值不同，指定访问的web服务的备选版本就可能不同。本实施例中，所述预设信息可以包括ip、uid、user-agent和第三方服务调用者中的至少一种，相比于传统的灰度发布可支持灰度的信息更多，使得整个灰度发布更为灵活。通过所述灰度控制逻辑的配置，本实施例的装置可以实现在不同用户访问同一web服务时，使用的版本会有所不同，支持多版本的灰度发布。

实施例5

本实施例提供的web服务灰度发布控制装置是在实施例4的基础上的进一步细化，主要体现于：

本实施例的灰度策略包括灰度控制逻辑和验证逻辑。所述灰度策略具体可以配置多个配置项，有利于实现更复杂的灰度控制和版本验证。其中，用于实现所述灰度控制逻辑的配置项可以包括但不限于配置：

键值(key，如key＝请求url)，用于灰度策略的匹配；

所述原始版本的url(old_version_url)；

所述web服务指定访问的至少一备选版本(version，如version＝versionn，n为正整数)；

每个备选版本的url(versionn_url，可以是相对路径如/tem/v1，也可以时绝对路径如服务器内部转发地址http://a.local/item/v1、重定向地址http://a.com/item/v1)；

每个备选版本的控制逻辑(versionn_control_logic，如versionn_control_logic＝lua代码)；

每个备选版本的请求分发策略(versionn_dispatch，如versionn_dispatch＝redirect/forward)，所述请求分发策略用于表示在分发请求时是服务器内部转发到versionn的url还是重定向到versionn的url；

每个备选版本是否后台执行(versionn_background，如versionn_background＝0/1)，如果是后台执行，则表示将流量复制到versionn，而不执行灰度逻辑；

每个备选版本的异常处理规则，所述异常处理规则用于配置至少一种异常逻辑以及在出现所述异常逻辑时相应的解决方案，其中，所述异常逻辑优选包括但不限于以下状况中的至少一种：

产生错误的响应状态码(versionn_error_status，如versionn_error_status＝404,500,502,503)；

访问超时(versionn_timeout，如versionn_timeout＝5s)；

访问限流(versionn_limit，如versionn_limit＝100/s)；

上述状况相应的解决方案可以相同或不同，本实施例的所述解决方案优选包括但不限于：将所述访问请求转发至所述原始版本。

所述验证逻辑用于验证所述备选版本的内容是否正确。用于实现所述验证逻辑的配置项可以包括但不限于配置：

验证规则(versionn_validation_rule，如versionn_validation_rule＝lua代码)，用于验证versionn内容是否正确，若返回0则表示验证失败。

每个备选版本的配置项可以根据实际需求相同或不同。各配置项的具体配置也可以根据实际需求相同或不同。

图5示出了本实施例的web服务灰度发布控制装置。针对本实施例的灰度控制逻辑，所述web服务灰度发布控制装置50包括接收模块51、获取模块52、判断模块53、转发模块54、异常处理模块55和验证模块56。

所述接收模块51用于接收客户端的访问请求，所述访问请求包括请求url、源ip、请求参数和请求头，其中请求url用以表示请求访问的web服务。

所述获取模块52用于使用所述请求url，获取key为所述请求url的灰度策略。

所述判断模块53用于判断所述灰度控制逻辑配置的备选版本是否为空，若为空则调用所述转发模块54将所述访问请求转发至所述原始版本的url，若不为空则逐一执行每个备选版本的控制逻辑，直至找到所述客户端在所述预设信息上的值所命中的备选版本，然后将命中的备选版本作为所述对应的备选版本，调用所述转发模块54将所述访问请求转发至所述对应的备选版本的url，若所述客户端在所述预设信息上的值未命中任何备选版本则调用所述转发模块54将所述访问请求转发至所述原始版本的url。

所述转发模块54在将所述访问请求转发至所述对应的备选版本的url时，需要按照所述请求分发策略进行请求分发，如果是forward则表示服务器内部转发至所述对应的备选版本的url，如果是redirect则表示重定向到所述对应的备选版本的url；若所述对应的备选版本配置为后台执行，则后台转发所述访问请求至所述对应的备选版本，在不上线的情况下通过观察日志来判断所述对应的备选版本是否正确。

所述异常处理模块55用于在将所述访问请求转发至所述对应的备选版本的url后，判断是否出现任意一种所述异常逻辑，包括转发返回响应后响应状态代码是否正确、是否超时、是否限流，若出现任意一种所述异常逻辑则调用所述转发模块54将所述访问请求转发至所述原始版本的url。

所述验证模块56用于在将所述访问请求转发至所述对应的备选版本的url后，按照所述验证逻辑验证所述备选版本的响应结果是否正确，若验证错误则调用所述转发模块54将所述访问请求转发至所述原始版本的url。

在本实施例中，灰度发布的控制非常灵活，能支持多版本灰度，能支持灰度的可配置，能支持复杂的灰度控制和验证逻辑，能复制流量来灰度验证功能，能柔性自适应处理异常逻辑，在遇到问题时快速自动降级到原始版本处理，不用担心影响到用户体验，从而实现柔性多版本灰度。

实施例4和实施例5中的web灰度服务发布控制装置40、50均可以使用nginx接入层(或是用其他类似nginx的技术，比如用go语言写一个接入层)+lua实现。

实施例6

图6示出了本实施例的一种灰度控制系统。所述灰度控制系统60包括：配置模块61。所述配置模块61用于配置灰度策略。

本实施例中，所述灰度策略包括灰度控制逻辑。所述灰度控制逻辑用于配置web服务按照预设信息区分的指定访问的至少一备选版本。本实施例的灰度控制逻辑表示客户端在预设信息上的值不同，指定访问的web服务的备选版本就不同。

本实施例中，所述预设信息包括ip、uid、user-agent和第三方服务调用者中的至少一种，相比于传统的灰度发布可支持灰度的信息更多，使得整个灰度发布更为灵活。

所述灰度策略具体可以配置多个配置项，有利于实现更复杂的灰度控制。其中，用于实现所述灰度控制逻辑的配置项可以包括但不限于配置：

键值(key，如key＝请求url)，用于灰度策略的匹配；

所述原始版本的url(old_version_url)；

所述web服务指定访问的至少一备选版本(version，如version＝versionn，n为正整数)；

每个备选版本的url(versionn_url，可以是相对路径如/tem/v1，也可以时绝对路径如服务器内部转发地址http://a.local/item/v1、重定向地址http://a.com/item/v1)；

每个备选版本的控制逻辑(versionn_control_logic，如versionn_control_logic＝lua代码)；

每个备选版本的请求分发策略(versionn_dispatch，如versionn_dispatch＝redirect/forward)，所述请求分发策略用于表示在分发请求时是服务器内部转发到versionn的url还是重定向到versionn的url；

每个备选版本是否后台执行(versionn_background，如versionn_background＝0/1)，如果是后台执行，则表示将流量复制到versionn，而不执行灰度逻辑；

每个备选版本的异常处理规则，所述异常处理规则用于配置至少一种异常逻辑以及在出现所述异常逻辑时相应的解决方案，其中，所述异常逻辑优选包括但不限于以下状况中的至少一种：

产生错误的响应状态码(versionn_error_status，如versionn_error_status＝404,500,502,503)；

访问超时(versionn_timeout，如versionn_timeout＝5s)；

访问限流(versionn_limit，如versionn_limit＝100/s)；

上述状况相应的解决方案可以相同或不同，本实施例的所述解决方案优选包括但不限于：将所述访问请求转发至所述原始版本。

本实施例中，所述灰度策略还可以包括验证逻辑。所述验证逻辑用于验证所述备选版本的内容是否正确。用于实现所述验证逻辑的配置项可以包括但不限于配置：

验证规则(versionn_validation_rule，如versionn_validation_rule＝lua代码)，用于验证versionn内容是否正确，若返回0则表示验证失败。

每个备选版本的配置项可以根据实际需求相同或不同。各配置项的具体配置也可以根据实际需求相同或不同。

本实施例的灰度控制系统60可以单独使用，以实现复杂灰度策略的配置，也可以配合实施例4或实施例5中的web服务灰度发布控制装置40或50使用，例如：

如图7所示的一种web服务系统，所述web服务系统包括web服务灰度发布控制装置40或50以及灰度控制系统60。所述web服务灰度发布控制装置40或50在接收到所述客户端的访问请求后调用所述灰度控制系统60，所述灰度控制系统60返回所述web服务匹配的灰度策略给所述web服务灰度发布控制装置40或50，以保证灰度控制的进行。所述web服务系统还可以进一步包括发布所述原始版本的web服务器70和发布所述备选版本的web服务器80。

实施例7

图8为本发明实施例7提供的一种电子设备的结构示意图。所述电子设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现实施例1-3中任意一种方法。图8显示的电子设备90仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图8所示，电子设备90可以以通用计算设备的形式表现，例如其可以为服务器设备。电子设备90的组件可以包括但不限于：上述至少一个处理器91、上述至少一个存储器92、连接不同系统组件(包括存储器92和处理器91)的总线93。

总线93包括数据总线、地址总线和控制总线。

存储器92可以包括易失性存储器，例如随机存取存储器(ram)921和/或高速缓存存储器922，还可以进一步包括只读存储器(rom)923。

存储器92还可以包括具有一组(至少一个)程序模块924的程序/实用工具925，这样的程序模块924包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

处理器91通过运行存储在存储器92中的计算机程序，从而执行各种功能应用以及数据处理，例如本发明实施例1-3所提供的任意一种方法。

电子设备90也可以与一个或多个外部设备94(例如键盘、指向设备等)通信。这种通信可以通过输入/输出(i/o)接口95进行。并且，模型生成的设备90还可以通过网络适配器96与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器96通过总线93与模型生成的设备90的其它模块通信。应当明白，尽管图中未示出，可以结合模型生成的设备90使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、raid(磁盘阵列)系统、磁带驱动器以及数据备份存储系统等。

应当注意，尽管在上文详细描述中提及了电子设备的若干单元/模块或子单元/模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。

实施例9

本实施例提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现实施例1-3所提供的任意一种方法的步骤。

其中，可读存储介质可以采用的更具体可以包括但不限于：便携式盘、硬盘、随机存取存储器、只读存储器、可擦拭可编程只读存储器、光存储器件、磁存储器件或上述的任意合适的组合。

在可能的实施方式中，本发明还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行实现实施例1-3所述的任意一种方法中的步骤。

其中，可以以一种或多种程序设计语言的任意组合来编写用于执行本发明的程序代码，所述程序代码可以完全地在用户设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户设备上部分在远程设备上执行或完全在远程设备上执行。

虽然以上描述了本发明的具体实施方式，但是本领域的技术人员应当理解，这些仅是举例说明，本发明的保护范围是由所附权利要求书限定的。本领域的技术人员在不背离本发明的原理和实质的前提下，可以对这些实施方式做出多种变更或修改，但这些变更和修改均落入本发明的保护范围。