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

Abstract

本申请提出一种灰度发布方法、装置、设备及存储介质，其中，方法包括：监测软件的灰度版本的运行状态是否为可用状态；如果灰度版本的运行状态为可用状态，则启用预设的灰度规则；根据灰度规则，将接收到的请求中的第一用户请求采用灰度版本响应，以向发送第一用户请求的客户端提供灰度服务，以及将接收到的请求中的第二用户请求采用软件的正式版本响应，以向发送第二用户请求的客户端提供正式服务。该方法能够实现自动监测灰度版本的运行状态是否为可用状态，无需人工去检查灰度版本的运行状态，可以提升监测结果的准确性。此外，在监测到灰度版本为可用状态时，才将请求引入至灰度版本，可以避免运行灰度版本期间访问中断的情况发生。

Description

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

技术领域

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

背景技术

当一个软件或应用程序(Application，简称APP)需要在生产环境发布一个待上线的新版本时，可以先选择添加一个灰度版本，并配置相应的灰度规则(比如流量权重、http请求中的header字段等)，将原有的生产环境的默认版本的访问流量引流一部分至灰度版本。经过测试稳定后，可以将此灰度版本，切换成默认版本，从而由灰度版本接管原有的生产环境的默认版本上的访问流量。

目前，配置灰度规则时，需要人工等待灰度版本启动正常后，才去配置灰度规则。如果过早的配置灰度规则，比如灰度版本未正常启动，就有访问流量引入到了灰度版本，那么灰度版本就无法访问，造成部分用户无法访问系统的情况。而且，如果灰度版本在运行过程中出现了异常，比如灰度版本发生重启或者异常故障核心转储(core dump)的情况，都会导致引入灰度版本的用户流量无法访问该APP，从而造成运行灰度版本期间有访问流量中断的情况发生。

发明内容

本申请提出一种灰度发布方法、装置、设备及存储介质，以实现自动监测灰度版本的运行状态是否为可用状态，无需人工去检查灰度版本的运行状态，避免人工引起的主观误差，可以提升监测结果的准确性，同时还可以降低人力成本。此外，在监测到灰度版本的运行状态为可用状态时，才启用灰度规则，将请求引入至灰度版本，从而可以避免运行灰度版本期间访问中断的情况发生，用于解决现有技术中由人工等待灰度版本启动正常后，配置灰度规则可能造成运行灰度版本期间有访问流量中断的情况发生的技术问题。

本申请第一方面实施例提出了一种灰度发布方法，包括：

监测软件灰度版本的运行状态是否为可用状态；

如果所述灰度版本的运行状态为可用状态，则启用预设的灰度规则；

根据所述灰度规则，将接收到的请求中的第一用户请求采用所述灰度版本响应，以向发送所述第一用户请求的客户端提供灰度服务，以及将所述接收到的请求中的第二用户请求采用所述软件的正式版本响应，以向发送所述第二用户请求的客户端提供正式服务。

本申请实施例的灰度发布方法，通过监测软件的灰度版本的运行状态是否为可用状态，若是，则启用预设的灰度规则，根据灰度规则，将接收到的请求中的第一用户请求采用灰度版本响应，以向发送第一用户请求的客户端提供灰度服务，以及将接收到的请求中的第二用户请求采用软件的正式版本响应，以向发送第二用户请求的客户端提供正式服务。由此，通过自动监测灰度版本的运行状态是否为可用状态，无需人工去检查灰度版本的运行状态，避免人工引起的主观误差，可以提升监测结果的准确性，同时还可以降低人力成本。此外，在监测到灰度版本的运行状态为可用状态时，才启用灰度规则，将请求引入至灰度版本，从而可以避免运行灰度版本期间访问中断的情况发生。

本申请第二方面实施例提出了一种灰度发布装置，包括：

灰度检测模块，用于监测软件灰度版本的运行状态是否为可用状态；

规则获取模块，用于如果所述灰度版本的运行状态为可用状态，则启用预设的灰度规则；

第一响应模块，用于根据所述灰度规则，将接收到的请求中的第一用户请求采用所述灰度版本响应，以向发送所述第一用户请求的客户端提供灰度服务，以及将所述接收到的请求中的第二用户请求采用所述软件的正式版本响应，以向发送所述第二用户请求的客户端提供正式服务。

本申请实施例的灰度发布装置，通过监测软件的灰度版本的运行状态是否为可用状态，若是，则启用预设的灰度规则，根据灰度规则，将接收到的请求中的第一用户请求采用灰度版本响应，以向发送第一用户请求的客户端提供灰度服务，以及将接收到的请求中的第二用户请求采用软件的正式版本响应，以向发送第二用户请求的客户端提供正式服务。由此，通过自动监测灰度版本的运行状态是否为可用状态，无需人工去检查灰度版本的运行状态，避免人工引起的主观误差，可以提升监测结果的准确性，同时还可以降低人力成本。此外，在监测到灰度版本的运行状态为可用状态时，才启用灰度规则，将请求引入至灰度版本，从而可以避免运行灰度版本期间访问中断的情况发生。

本申请第三方面实施例提出了一种计算机设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时，执行如本申请第一方面实施例提出的灰度发布方法。

本申请第四方面实施例提出了一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如本申请第一方面实施例提出的灰度发布方法。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为灰度发布示意图；

图2为灰度版本的添加过程示意图；

图3为灰度规则的配置过程示意图；

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

图5为本申请实施例中灰度发布示意图；

图6为本申请实施例二所提供的灰度发布方法的流程示意图；

图7为本申请实施例三所提供的灰度发布方法的流程示意图；

图8为本申请实施例四所提供的灰度发布方法的流程示意图；

图9为本申请实施例五所提供的灰度发布方法的流程示意图；

图10为本申请实施例六所提供的灰度发布装置的结构示意图；

图11为本申请实施例七所提供的灰度发布装置的结构示意图。

具体实施方式

下面详细描述本申请的实施例，实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。

目前，当一个APP需要在生产环境发布一个待上线的新版本时，可以先选择添加一个灰度版本，并配置相应的灰度规则(比如流量权重)，将原有的生产环境的默认版本的访问流量引流一部分至灰度版本。经过测试稳定后，可以将此灰度版本，切换成默认版本，从而由切换后的默认版本接管原有的生产环境中默认版本上的访问流量。

作为一种示例，灰度发布示意图可以如图1所示。其中，对业务系统进行灰度发布时，会先引入一个灰度版本。首先，将5％的访问流量引入至该灰度版本，待测试灰度版本功能正常后，逐步扩大引入至灰度版本的访问流量，同时增加灰度版本的运行实例数，最终将所有访问流量引入至灰度版本。

作为另一种示例，参见图2，在demo1-test应用添加一个灰度版本v2，灰度版本v2启动具有一个过程，等灰度版本v2启动正常后，再配置灰度规则，将访问流量引入灰度版本v2。例如，参见图3，灰度规则：引入至灰度版本v2的访问流量和引入至当前版本v1的访问流量比为5:95。此时，访问demo1-test这个应用的5％流量就引入至灰度版本v2中。待验证完成后，确认灰度版本v2没有问题后，就可以将所有访问流量引入至灰度版本v2，整个灰度发布过程结束。

然而，上述配置灰度规则时，需要人工等待灰度版本启动正常后，才去配置灰度规则。如果过早的配置灰度规则，比如灰度版本未正常启动，就有访问流量引入到了灰度版本，那么灰度版本就无法访问，造成部分流量用户无法访问系统。而且，如果灰度版本在运行过程中出现了异常，比如灰度版本发生重启或者核心转储(core dump)等情况，都会导致引入灰度版本的用户流量无法访问该APP，从而造成运行灰度版本期间有访问流量中断的情况发生。

本申请主要针对现有技术中由人工等待灰度版本启动正常后，配置灰度规则可能造成运行灰度版本期间有访问流量中断的情况发生的技术问题，提出一种灰度发布方法。

本申请实施例的灰度发布方法，通过监测软件的灰度版本的运行状态是否为可用状态，若是，则启用预设的灰度规则，根据灰度规则，将接收到的请求中的第一用户请求采用灰度版本响应，以向发送第一用户请求的客户端提供灰度服务，以及将接收到的请求中的第二用户请求采用软件的正式版本响应，以向发送第二用户请求的客户端提供正式服务。由此，通过自动监测灰度版本的运行状态是否为可用状态，无需人工去检查灰度版本的运行状态，避免人工引起的主观误差，可以提升监测结果的准确性，同时还可以降低人力成本。此外，在监测到灰度版本的运行状态为可用状态时，才启用灰度规则，将请求引入至灰度版本，从而可以避免运行灰度版本期间访问中断的情况发生。

下面参考附图描述本申请实施例的灰度发布方法、装置、设备及存储介质。在具体描述本申请实施例之前，为了便于理解，首先对常用技术词进行介绍：

core dump，它是当程序运行过程中发生异常时，由操作系统把程序当前的内存状况存储在一个core文件中。

灰度发布：APP迭代更新较快，并且，每一次APP升级都伴随着各种各样的风险，比如新旧版本兼容的风险、用户使用习惯突然改变而造成用户流失的风险、系统宕机的风险等等。为了避免上述提及的风险，很多APP都采用了灰度发布的策略，其主要思想就是把影响集中到一个点，然后再发散到一个面，当出现意外情况时，很容易回退，避免造成大范围的影响。

具体地，当APP增加新功能或采用改进技术的APP上线发布前，如果新的发布影响面较大时，会考虑先切分部分用户流量进来，让这部分用户先体验新的APP，开发人员可以根据这部分用户产生的数据对新的APP进行不断优化，最终正式上线发布，然后再让所有用户使用。这种灰度发布方法降低了发布新功能的风险，实现了平滑的发布。

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

本申请实施例以灰度发布方法被配置于灰度发布装置中来举例说明，该灰度发布装置可以应用于任一计算机设备中，以使该计算机设备可以执行灰度发布功能。

其中，计算机设备可以为个人电脑(Personal Computer，简称PC)、云端设备、移动设备、服务器等，移动设备例如可以为手机、平板电脑、个人数字助理、穿戴式设备、车载设备等具有各种操作系统、触摸屏和/或显示屏的硬件设备。

如图4所示，该灰度发布方法可以包括以下步骤：

步骤101，监测软件的灰度版本的运行状态是否为可用状态。

本申请实施例中，灰度版本为软件待上线的新版本。

本申请实施例中，在软件的灰度版本发布过程中，可以通过监听方式，监测灰度版本的运行状态是否为可用状态。

作为一种示例，在软件的灰度版本发布过程中，可以通过新增一个灰度检测模块，实时监测灰度版本的运行状态。

步骤102，如果灰度版本的运行状态为可用状态，则启用预设的灰度规则。

本申请实施例中，可以根据每个软件的需求，预先设置对应的灰度规则。

作为一种可能的实现方式，灰度规则可以包括访问流量引入至灰度版本和引入至软件的正式版本的比例，其中，正式版本可以为软件的旧版本、当前版本或者默认版本。

作为另一种可能的实现方式，灰度规则可以包括将包含特定IP地址的请求，引入至灰度版本，比如可以设置预设条件，该预设条件可以为将包含特定IP地址的请求，引入至灰度版本。

作为又一种可能的实现方式，灰度规则可以包括将包含特定用户名的请求，引入至灰度版本，比如可以设置预设条件，该预设条件可以为将包含特定用户名的请求，引入至灰度版本。

作为再一种可能的实现方式，灰度规则可以包括将包含特定cookie的请求，引入至灰度版本，比如可以设置预设条件，该预设条件可以为将包含特定cookie的请求，引入至灰度版本。

应当理解的是，灰度规则不是特定的，也不局限于本申请所描述的方式，实际应用时，可以根据每个软件的实际需要，以各种不同的方式，预先设定灰度规则，本申请对此并不作限制。

本申请实施例中，在监测到软件的灰度版本的运行状态为可用状态时，可以启用预设的灰度规则。

步骤103，根据灰度规则，将接收到的请求中的第一用户请求采用灰度版本响应，以向发送第一用户请求的客户端提供灰度服务，以及将接收到的请求中的第二用户请求采用软件的正式版本响应，以向发送第二用户请求的客户端提供正式服务。

本申请实施例中，在启用灰度规则后，可以根据灰度规则，对接收到的请求进行筛选，确定引入至灰度版本的第一用户请求，从而可以采用灰度版本响应该第一用户请求，并向发送第一用户请求的客户端提供灰度服务，以及确定引入至正式版本的第二用户请求，从而采用正式版本响应该第二用户请求，并向发送第二用户请求的客户端提供正式服务。

作为一种示例，当灰度规则包括访问流量引入至灰度版本和引入至软件的正式版本的比例时，可以根据上述比例，从接收到的请求中，确定第一用户请求，以及第二用户请求。

作为另一种示例，当灰度规则包括将包含特定IP地址的请求，引入至灰度版本时，可以根据灰度规则中的预设条件，对接收到的请求中的IP地址进行筛选，将包含特定IP地址的请求作为第一用户请求，其余请求作为第二用户请求。

作为又一种示例，当灰度规则包括将包含特定用户名的请求，引入至灰度版本时，可以根据灰度规则中的预设条件，对接收到的请求中的用户名进行筛选，将包含特定用户名的请求作为第一用户请求，其余请求作为第二用户请求。

作为再一种示例，当灰度规则包括将包含特定cookie的请求，引入至灰度版本时，可以根据灰度规则中的预设条件，对接收到的请求中的cookie进行筛选，将包含特定cookie的请求作为第一用户请求，其余请求作为第二用户请求。

作为一种应用场景，以灰度规则包括访问流量引入至灰度版本和引入至软件的正式版本的比例进行示例，参见图5，假设上述比例为5:95，可以通过灰度检测模块实时检测灰度版本的运行状态是否为可用状态，若灰度版本的运行状态为可用状态，则将5％的访问流量对应的请求引入至灰度版本，由灰度版本响应5％的访问流量对应的请求，以及将95％的访问流量对应的请求引入至正式版本，由正式版本响应95％的访问流量对应的请求。由此，在监测到灰度版本的运行状态为可用状态时，才启用灰度规则，将访问流量引入至灰度版本，从而可以避免访问流量中断的情况发生。

本申请实施例的灰度发布方法，通过监测软件的灰度版本的运行状态是否为可用状态，若是，则启用预设的灰度规则，根据灰度规则，将接收到的请求中的第一用户请求采用灰度版本响应，以向发送第一用户请求的客户端提供灰度服务，以及将接收到的请求中的第二用户请求采用软件的正式版本响应，以向发送第二用户请求的客户端提供正式服务。由此，通过自动监测灰度版本的运行状态是否为可用状态，无需人工去检查灰度版本的运行状态，避免人工引起的主观误差，可以提升监测结果的准确性，同时还可以降低人力成本。此外，在监测到灰度版本的运行状态为可用状态时，才启用灰度规则，将请求引入至灰度版本，从而可以避免运行灰度版本期间访问中断的情况发生。

需要说明的是，在采用灰度规则，分配访问请求或者访问流量的过程中，比如将50％的访问流量引入至灰度版本，此时，可能发生同一个用户发送的不同请求，被引入至不同版本的情况，比如用户发送的第一个请求被分配至灰度版本，第二个请求被分配至正式版本，则将造成用户看到的页面，一会是正式版本的页面，一会是灰度版本的页面。如果两本版本的页面差异较大，则严重降低了用户的使用体验。

因此，为了避免同一个用户发送的请求，被分配至不同版本的情况，本申请实施例中，可以增加会话保持功能，使得同一个用户发送的请求，由同一个版本进行响应。

具体地，如果发送请求的客户端在历史使用软件的过程中，发送的历史请求是由灰度版本进行响应并提供灰度服务的，则可以建立该历史请求的目标标识与响应历史请求的灰度版本之间的对应关系，其中，目标标识信息包括发送历史请求的客户端的IP地址或端口号、http请求中的header字段、user-agent字段、cookie中的至少一个。从而在本次接收到该客户端发送的请求时，可以根据发送请求的客户端的IP地址或端口号、http请求中的header字段、user-agent字段、cookie，查询上述对应关系，确定为该客户端提供过服务的为灰度版本，之后，可以利用灰度版本为该客户端继续提供灰度服务。

同理，如果发送请求的客户端在历史使用软件的过程中，发送的历史请求是由正式版本进行响应并提供正式服务的，则可以建立该历史请求的目标标识与响应历史请求的正式版本之间的对应关系。从而在本次接收到该客户端发送的请求时，可以根据发送请求的客户端的IP地址或端口号、http请求中的header字段、user-agent字段、cookie，查询上述对应关系，确定为该客户端提供过服务的为正式版本，之后，可以利用正式版本为该客户端继续提供正式服务。

也就是说，在灰度版本或正式版本响应历史请求后，可以建立映射关系，该映射关系，用于指示历史请求的目标标识，与响应历史请求的灰度版本或正式版本之间的对应关系，从而，本申请中，可以根据映射关系，对接收到的请求进行筛选，以确定第一用户请求，以及第二用户请求。由此，可以保证同一用户或者同一个客户端发送的所有请求，均有由同一个版本进行响应，避免用户发送的请求在正式版本和灰度版本中进行切换，改善用户的使用体验。

而如果发送请求的客户端为第一次发送请求，则在灰度版本或者正式版本为其提供服务后，可以建立该请求中的目标标识与响应该请求的灰度版本或正式版本之间的映射关系，并对上述映射关系进行存储。从而在该客户端下一次发送请求时，可以由上述映射关系中的灰度版本或正式版本，直接向该客户端提供灰度服务或者正式服务。

进一步地，还可以通过定时器，对上述映射关系的存储时长进行计时，当计时时长到达设定存储时长时，可以删除上述映射关系，从而可以降低存储资源的占用。

进一步地，若发送请求的客户端在预设时长内未发送下一请求，也可以删除上述映射关系，从而可以降低存储资源的占用。

需要说明的是，在灰度版本发布过程中，还可以增加会话保持的选项，可以由用户选择是否会话保持，以提升该方法的灵活性和适用性，满足不同用户的个性化需求。如果用户开启会话保持，那么该用户发送的所有请求，均由同一个版本进行响应，避免用户发送的请求在正式版本和灰度版本中进行来回切换的情况，改善用户的使用体验。

作为一种可能的实现方式，可以配置灰度版本的访问地址，通过访问该灰度版本的访问地址，来判断灰度版本的运行状态是否为可用状态。下面结合实施例二，对上述过程进行详细说明。

图6为本申请实施例二所提供的灰度发布方法的流程示意图。

如图6所示，该灰度方法可以包括以下步骤：

步骤201，访问软件的灰度版本的访问地址。

本申请实施例中，可以预先配置软件的灰度版本的访问地址，之后，可以实时或者周期性地访问该灰度版本的访问地址。

作为一种示例，参见图5，可以由灰度检测模块实时或者周期性地访问灰度版本的访问地址。

步骤202，判断是否访问成功，若是，执行步骤205，若否，执行步骤203。

步骤203，确定灰度版本的运行状态为不可用状态。

本申请实施例中，当访问不成功时，表明灰度版本的运行状态为不可用状态。

步骤204，将接收到的请求采用软件的正式版本响应。

本申请实施例中，当灰度版本的运行状态为不可用状态时，比如，灰度版本发生重启或者异常故障core dump等情况，此时，可以将接收到的请求采用软件的正式版本响应，以避免运行灰度版本期间访问中断的情况发生。

进一步地，在灰度版本的运行状态为不可用状态时，还可以发出告警提示，由人工进行干预。

步骤205，确定灰度版本的运行状态为可用状态。

本申请实施例中，当访问成功时，表明灰度版本的运行状态为可用状态，此时，可以执行后续步骤。

步骤206，启用预设的灰度规则，根据灰度规则，将接收到的请求中的第一用户请求采用灰度版本响应，以向发送第一用户请求的客户端提供灰度服务，以及将接收到的请求中的第二用户请求采用软件的正式版本响应，以向发送第二用户请求的客户端提供正式服务。

步骤206的执行过程可以参见上述实施例中步骤102至103的执行过程，在此不做赘述。

本申请实施例的灰度发布方法，通过访问软件的灰度版本的访问地址，来监测灰度版本的运行状态，由此，可以实现自动监测灰度版本的运行状态是否为可用状态，无需人工去检查灰度版本的运行状态，避免人工引起的主观误差，可以提升监测结果的准确性，同时还可以降低人力成本。

作为一种可能的实现方式，如果未配置软件的灰度版本的访问地址，则可以通过监测运行灰度版本实例的宿主机或者容器的运行状态，根据宿主机或者容器的运行状态，来判断灰度版本的运行状态是否为可用状态。下面结合实施例三，对上述过程进行详细说明。

图7为本申请实施例三所提供的灰度发布方法的流程示意图。

如图7所示，该灰度方法可以包括以下步骤：

步骤301，监测运行灰度版本实例的宿主机或者容器的运行状态。

本申请实施例中，灰度版本中的实例个数为至少一个，例如可以为一个，或者也可以为多个。举例而言，为了提升软件的高可靠性，灰度版本可以运行多个副本，每个副本称为一个实例。

本申请实施例中，可以实时或者周期性地监测运行灰度版本实例的宿主机或者容器的运行状态。

作为一种示例，参见图5，可以由灰度检测模块实时或者周期性地监测运行灰度版本实例的宿主机或者容器的运行状态。

步骤302，判断宿主机或者容器的运行状态是否为可用状态，若是，执行步骤305，若否，执行步骤303。

步骤303，确定灰度版本的运行状态为不可用状态。

本申请实施例中，当宿主机或者容器的运行状态为不可用状态时，表明灰度版本的运行状态为不可用状态，或者，当宿主机或者容器的可用状态的持续时长未达到预设时长时，表明灰度版本的运行状态为不可用状态。

步骤304，将接收到的请求采用软件的正式版本响应。

步骤304的执行过程可以参见上述实施例中步骤204的执行过程，在此不做赘述。

步骤305，判断可用状态的持续时长是否达到预设时长，若是，执行步骤306，若否，执行步骤303。

本申请实施例中，预设时长为预先设置的，例如预设时长可以为计算机设备的内置程序预先设置的，或者为了提升该方法的灵活性和适用性，预设时长还可以由用户进行设置，比如为10个监测周期，对此不作限制。

本申请实施例中，当宿主机或者容器的运行状态为可用状态时，考虑到灰度版本启动需要一定的时长，比如10个监测周期，因此，可以判断宿主机或者容器的可用状态的持续时长是否达到预设时长，若是，执行步骤306，若否，执行步骤303。

步骤306，确定灰度版本的运行状态为可用状态。

本申请实施例中，当宿主机或者容器的可用状态的持续时长达到预设时长时，表明灰度版本的运行状态为可用状态，此时，可以执行后续步骤。

步骤307，启用预设的灰度规则，根据灰度规则，将接收到的请求中的第一用户请求采用灰度版本响应，以向发送第一用户请求的客户端提供灰度服务，以及将接收到的请求中的第二用户请求采用软件的正式版本响应，以向发送第二用户请求的客户端提供正式服务。

步骤307的执行过程可以参见上述实施例中步骤102至103的执行过程，在此不做赘述。

本申请实施例的灰度发布方法，通过监测运行灰度版本实例的宿主机或者容器的运行状态，根据宿主机或者容器的运行状态，来确定灰度版本的运行状态，由此，可以实现自动监测灰度版本的运行状态是否为可用状态，无需人工去检查灰度版本的运行状态，避免人工引起的主观误差，可以提升监测结果的准确性，同时还可以降低人力成本。

作为一种可能的实现方式，可以配置灰度版本中实例的访问地址，通过访问该灰度版本中实例的访问地址，来判断灰度版本的运行状态是否为可用状态。下面结合实施例四，对上述过程进行详细说明。

图8为本申请实施例四所提供的灰度发布方法的流程示意图。

如图8所示，该灰度方法可以包括以下步骤：

步骤401，根据灰度版本中实例的访问地址，访问实例。

本申请实施例中，灰度版本中的实例的个数为至少一个，可以预先配置灰度版本中每个实例的访问地址，之后，可以实时或者周期性地访问各实例。

作为一种示例，参见图5，可以由灰度检测模块实时或者周期性地访问灰度版本中实例的访问地址。

步骤402，判断是否存在可用状态的实例，若是，执行步骤405，若否，执行步骤403。

本申请实施例中，如果某个实例访问成功，则表明存在可用状态的实例，此时，可以执行步骤405，如果所有的实例均访问不成功，则表明不存在可用状态的实例，此时，可以执行步骤403。

步骤403，确定灰度版本的运行状态为不可用状态。

本申请实施例中，当灰度版本中不存在可用状态的实例时，则表明灰度版本的运行状态为不可用状态。

步骤404，将接收到的请求采用软件的正式版本响应。

步骤404的执行过程可以参见上述实施例中步骤204的执行过程，在此不做赘述。

步骤405，确定灰度版本的运行状态为可用状态。

本申请实施例中，当灰度版本中存在可用状态的实例时，则表明灰度版本的运行状态为可用状态。

步骤406，启用预设的灰度规则，根据灰度规则，将接收到的请求中的第一用户请求采用灰度版本响应，以向发送第一用户请求的客户端提供灰度服务，以及将接收到的请求中的第二用户请求采用软件的正式版本响应，以向发送第二用户请求的客户端提供正式服务。

步骤406的执行过程可以参见上述实施例中步骤102至103的执行过程，在此不做赘述。

本申请实施例的灰度发布方法，通过访问灰度版本中实例的访问地址，来确定灰度版本的运行状态，由此，可以实现自动监测灰度版本的运行状态是否为可用状态，无需人工去检查灰度版本的运行状态，避免人工引起的主观误差，可以提升监测结果的准确性，同时还可以降低人力成本。

作为一种可能的实现方式，还可以通过监测灰度版本的运行日志，来判断灰度版本的运行状态是否为可用状态。下面结合实施例五，对上述过程进行详细说明。

图9为本申请实施例五所提供的灰度发布方法的流程示意图。

如图9所示，该灰度方法可以包括以下步骤：

步骤501，查询软件的灰度版本的运行日志。

本申请实施例中，可以预先配置灰度版本的运行日志对应的路径，根据上述路径查询灰度版本的运行日志。

作为一种示例，参见图5，在灰度版本发布过程中，可以由灰度检测模块实时或者周期性地查询灰度版本的运行日志。

步骤502，判断运行日志是否存在访问异常或者是否存在访问丢包，若是，执行步骤505，若否，执行步骤503。

实际应用时，若灰度版本的访问流量较大，则可能出现访问忙而丢包的情况，此时，为了避免运行灰度版本期间访问中断的情况发生，灰度版本不可用。因此，本申请实施例中，可以判断运行日志是否存在访问异常或者是否存在访问丢包，若是，执行步骤505，若否，执行步骤503。

作为一种可能的实现方式，可以提供解析运行日志的插件，通过上述插件，对运行日志进行解析，以确定运行日志是否存在访问异常或者是否存在访问丢包。

步骤503，确定灰度版本的运行状态为不可用状态。

本申请实施例中，当运行日志存在访问异常，或者运行日志存在访问丢包时，可以确定灰度版本的运行状态为不可用状态。

步骤504，将接收到的请求采用软件的正式版本响应。

步骤504的执行过程可以参见上述实施例中步骤204的执行过程，在此不做赘述。

步骤505，确定灰度版本的运行状态为可用状态。

本申请实施例中，当运行日志未存在访问异常且未存在访问丢包时，表明灰度版本的运行状态为可用状态。

步骤506，启用预设的灰度规则，根据灰度规则，将接收到的请求中的第一用户请求采用灰度版本响应，以向发送第一用户请求的客户端提供灰度服务，以及将接收到的请求中的第二用户请求采用软件的正式版本响应，以向发送第二用户请求的客户端提供正式服务。

步骤506的执行过程可以参见上述实施例中步骤102至103的执行过程，在此不做赘述。

本申请实施例的灰度发布方法，通过监测灰度版本的运行日志，来监测灰度版本的运行状态，由此，可以实现自动监测灰度版本的运行状态是否为可用状态，无需人工去检查灰度版本的运行状态，避免人工引起的主观误差，可以提升监测结果的准确性，同时还可以降低人力成本。

作为一种可能的实现方式，在上述实施例中的基础上，在灰度版本的运行状态为不可用状态之后，还可以继续监测灰度版本的运行状态，以在灰度版本的运行状态恢复为可用状态时，执行根据灰度规则，将接收到的请求中的第一用户请求采用灰度版本响应，以向发送第一用户请求的客户端提供灰度服务，以及将接收到的请求中的第二用户请求采用软件的正式版本响应，以向发送第二用户请求的客户端提供正式服务的步骤。具体执行过程可以参见上述实施例中步骤103的执行过程，在此不做赘述。

需要说明的是，如果监测到灰度版本多次发生异常，例如灰度版本多次发生重启或者异常故障core dump等情况，此时，为了避免请求在正式版本和灰度版本中来回切换，降低用户体验的情况发生，本申请中，可以统计灰度版本的运行状态发生变化的次数，如果次数大于预设阈值，则将接收到的请求采用软件的正式版本响应。

其中，预设阈值为预先设置的，比如为3次。

进一步地，在灰度版本的运行状态发生变化的次数大于预设阈值时，还可以发出告警提示，由人工进行干预。

为了实现上述实施例，本申请还提出一种灰度发布装置。

图10为本申请实施例六所提供的灰度发布装置的结构示意图。

如图10，该灰度发布装置可以包括：灰度检测模块101、规则启用模块102以及第一响应模块103。

其中，灰度检测模块101，用于监测软件灰度版本的运行状态是否为可用状态。

作为一种可能的实现方式，灰度检测模块101，具体用于：访问灰度版本的访问地址；如果访问成功，则确定灰度版本的运行状态为可用状态；如果访问不成功，则确定灰度版本的运行状态为不可用状态。

作为另一种可能的实现方式，灰度检测模块101，具体用于：根据灰度版本中实例的访问地址，访问实例；如果存在可用状态的实例，则确定灰度版本的运行状态为可用状态；如果不存在可用状态的实例，则确定灰度版本的运行状态为不可用状态。

作为又一种可能的实现方式，灰度检测模块101，具体用于：监测运行灰度版本实例的宿主机或者容器的运行状态；如果宿主机或者容器的运行状态为不可用状态，则确定灰度版本的运行状态为不可用状态；如果宿主机或者容器的运行状态为可用状态，则判断可用状态的持续时长是否达到预设时长；如果达到预设时长，则确定灰度版本的运行状态为可用状态；如果未达到预设时长，则确定灰度版本的运行状态为不可用状态。

作为再一种可能的实现方式，灰度检测模块101，具体用于：查询灰度版本的运行日志；如果运行日志未存在访问异常且未存在访问丢包，则确定灰度版本的运行状态为可用状态；如果运行日志存在访问异常或者存在访问丢包，则确定灰度版本的运行状态为不可用状态。

规则启用模块102，用于如果灰度版本的运行状态为可用状态，则获取预设的灰度规则。

第一响应模块103，用于根据灰度规则，将接收到的请求中的第一用户请求采用灰度版本响应，以向发送第一用户请求的客户端提供灰度服务，以及将接收到的请求中的第二用户请求采用软件的正式版本响应，以向发送第二用户请求的客户端提供正式服务。

进一步地，在本申请实施例的一种可能的实现方式中，参见图11，在图10所示实施例的基础上，该灰度发布装置还可以包括：第二响应模块104、统计模块105和确定模块106。

第二响应模块104，用于在监测软件灰度版本的运行状态是否为可用状态之后，如果灰度版本的运行状态为不可用状态，则将接收到的请求采用软件的正式版本响应。

灰度检测模块101，还用于继续监测灰度版本的运行状态。

第一响应模块103，还用于当灰度版本的运行状态恢复为可用状态时，执行根据灰度规则，将接收到的请求中的第一用户请求采用灰度版本响应，以向发送第一用户请求的客户端提供灰度服务，以及将接收到的请求中的第二用户请求采用软件的正式版本响应，以向发送第二用户请求的客户端提供正式服务的步骤。

统计模块105，用于在监测软件灰度版本的运行状态是否为可用状态之后，统计灰度版本的运行状态发生变化的次数。

第二响应模块104，还用于如果次数大于预设阈值，则将接收到的请求采用软件的正式版本响应。

确定模块106，用于在根据灰度规则，将接收到的请求中的第一用户请求采用灰度版本响应，以向发送第一用户请求的客户端提供灰度服务，以及将接收到的请求中的第二用户请求采用软件的正式版本响应，以向发送第二用户请求的客户端提供正式服务之前，根据灰度规则，确定访问流量引入至灰度版本和引入至正式版本的比例；根据比例，从接收到的请求中，确定第一用户请求，以及第二用户请求；或者，按照灰度规则中的预设条件，对接收到的请求中的IP地址进行筛选，确定第一用户请求，以及第二用户请求；或者，根据映射关系，对接收到的请求进行筛选，以确定第一用户请求，以及第二用户请求；其中，映射关系，用于指示历史请求的目标标识，与响应历史请求的灰度版本或正式版本之间的对应关系，其中，目标标识信息包括发送历史请求的客户端的IP地址或端口号、http请求中的header字段、user-agent字段、cookie中的至少一个。

需要说明的是，前述对灰度发布方法实施例的解释说明也适用于该实施例的灰度发布装置，此处不再赘述。

本申请实施例的灰度发布装置，通过监测软件的灰度版本的运行状态是否为可用状态，若是，则启用预设的灰度规则，根据灰度规则，将接收到的请求中的第一用户请求采用灰度版本响应，以向发送第一用户请求的客户端提供灰度服务，以及将接收到的请求中的第二用户请求采用软件的正式版本响应，以向发送第二用户请求的客户端提供正式服务。由此，通过自动监测灰度版本的运行状态是否为可用状态，无需人工去检查灰度版本的运行状态，避免人工引起的主观误差，可以提升监测结果的准确性，同时还可以降低人力成本。此外，在监测到灰度版本的运行状态为可用状态时，才启用灰度规则，将请求引入至灰度版本，从而可以避免运行灰度版本期间访问中断的情况发生。

为了实现上述实施例，本申请还提出一种计算机设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时，执行如本申请前述实施例提出的灰度发布方法。

为了实现上述实施例，本申请还提出一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本申请前述实施例提出的灰度发布方法。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。如，如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (16)

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

在软件的灰度版本发布过程中，通过灰度检测模块实时监测软件的灰度版本的运行状态是否为可用状态；

如果所述灰度版本的运行状态为可用状态，则启用预设的灰度规则；

根据所述灰度规则，将接收到的请求中的第一用户请求采用所述灰度版本响应，以向发送所述第一用户请求的客户端提供灰度服务，以及将所述接收到的请求中的第二用户请求采用所述软件的正式版本响应，以向发送所述第二用户请求的客户端提供正式服务；

在采用所述灰度版本响应或所述正式版本响应后，建立映射关系，所述映射关系用于指示历史请求的目标标识，与响应历史请求的灰度版本或正式版本之间的对应关系；

当再次接收到请求时，根据所述映射关系，将所述请求中与所述第一用户请求属于同一个客户端发送的所有请求均由所述灰度版本响应，将所述请求中与所述第二用户请求属于同一个客户端发送的所有请求均由所述正式版本响应；

通过定时器对所述映射关系的存储时长进行计时，在所述计时时长达到设定存储时长时，删除所述映射关系；

所述监测软件灰度版本的运行状态是否为可用状态之后，所述方法还包括：

如果所述灰度版本的运行状态为不可用状态，则将所述接收到的请求采用所述软件的正式版本响应；

继续监测所述灰度版本的运行状态；

当所述灰度版本的运行状态恢复为可用状态时，执行所述灰度规则，将接收到的请求中的第一用户请求采用所述灰度版本响应，以向发送所述第一用户请求的客户端提供灰度服务，以及将所述接收到的请求中的第二用户请求采用所述软件的正式版本响应，以向发送所述第二用户请求的客户端提供正式服务的步骤。

2.如权利要求1所述的方法，其特征在于，所述监测软件灰度版本的运行状态是否为可用状态，包括：

访问所述灰度版本的访问地址；

如果访问成功，则确定所述灰度版本的运行状态为可用状态；

如果访问不成功，则确定所述灰度版本的运行状态为不可用状态。

3.如权利要求1所述的方法，其特征在于，所述监测软件灰度版本的运行状态是否为可用状态，包括：

根据所述灰度版本中实例的访问地址，访问所述实例；

如果存在可用状态的实例，则确定所述灰度版本的运行状态为可用状态；

如果不存在可用状态的实例，则确定所述灰度版本的运行状态为不可用状态。

4.如权利要求1所述的方法，其特征在于，所述监测软件灰度版本的运行状态是否为可用状态，包括：

监测运行所述灰度版本实例的宿主机或者容器的运行状态；

如果所述宿主机或者容器的运行状态为不可用状态，则确定所述灰度版本的运行状态为不可用状态；

如果所述宿主机或者容器的运行状态为可用状态，则判断所述可用状态的持续时长是否达到预设时长；如果达到所述预设时长，则确定所述灰度版本的运行状态为可用状态；如果未达到所述预设时长，则确定所述灰度版本的运行状态为不可用状态。

5.如权利要求1所述的方法，其特征在于，所述监测软件灰度版本的运行状态是否为可用状态，包括：

查询所述灰度版本的运行日志；

如果所述运行日志未存在访问异常且未存在访问丢包，则确定所述灰度版本的运行状态为可用状态；

如果所述运行日志存在访问异常或者存在访问丢包，则确定所述灰度版本的运行状态为不可用状态。

6.如权利要求1-5中任一项所述的方法，其特征在于，所述监测软件灰度版本的运行状态是否为可用状态之后，所述方法还包括：

统计所述灰度版本的运行状态发生变化的次数；

如果所述次数大于预设阈值，则将所述接收到的请求采用所述软件的所述正式版本响应。

7.如权利要求1-5中任一项所述的方法，其特征在于，所述根据所述灰度规则，将接收到的请求中的第一用户请求采用所述灰度版本响应，以向发送所述第一用户请求的客户端提供灰度服务，以及将所述接收到的请求中的第二用户请求采用所述软件的正式版本响应，以向发送所述第二用户请求的客户端提供正式服务之前，所述方法还包括：

根据所述灰度规则，确定访问流量引入至所述灰度版本和引入至所述正式版本的比例；

根据所述比例，从接收到的请求中，确定所述第一用户请求，以及所述第二用户请求；

或者，

按照灰度规则中的预设条件，对所述接收到的请求中的IP地址进行筛选，确定所述第一用户请求，以及所述第二用户请求；

或者，

根据映射关系，对所述接收到的请求进行筛选，以确定所述第一用户请求，以及所述第二用户请求；其中，所述映射关系，用于指示历史请求的目标标识，与响应所述历史请求的灰度版本或正式版本之间的对应关系，其中，所述目标标识信息包括发送所述历史请求的客户端的IP地址或端口号、http请求中的header字段、user-agent字段、cookie中的至少一个。

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

灰度检测模块，用于在软件的灰度版本发布过程中，实时监测软件的灰度版本的运行状态是否为可用状态；

规则启用模块，用于如果所述灰度版本的运行状态为可用状态，则启用预设的灰度规则；

第一响应模块，用于根据所述灰度规则，将接收到的请求中的第一用户请求采用所述灰度版本响应，以向发送所述第一用户请求的客户端提供灰度服务，以及将所述接收到的请求中的第二用户请求采用所述软件的正式版本响应，以向发送所述第二用户请求的客户端提供正式服务；

确定模块，用于在采用所述灰度版本响应或所述正式版本响应后，建立映射关系，所述映射关系用于指示历史请求的目标标识，与响应历史请求的灰度版本或正式版本之间的对应关系；

第一响应模块，还用于在再次接收到请求时，根据所述映射关系，将所述请求中与所述第一用户请求属于同一个客户端发送的所有请求均由所述灰度版本响应，将所述请求中与所述第二用户请求属于同一个客户端发送的所有请求均由所述正式版本响应，其中，通过定时器对所述映射关系的存储时长进行计时，在所述计时时长达到设定存储时长时，删除所述映射关系；

第二响应模块，用于在监测软件灰度版本的运行状态是否为可用状态之后，如果所述灰度版本的运行状态为不可用状态，则将所述接收到的请求采用所述软件的正式版本响应；

所述灰度检测模块，还用于继续监测所述灰度版本的运行状态；

所述第一响应模块，还用于当所述灰度版本的运行状态恢复为可用状态时，执行所述灰度规则，将接收到的请求中的第一用户请求采用所述灰度版本响应，以向发送所述第一用户请求的客户端提供灰度服务，以及将所述接收到的请求中的第二用户请求采用所述软件的正式版本响应，以向发送所述第二用户请求的客户端提供正式服务的步骤。

9.如权利要求8所述的装置，其特征在于，所述灰度检测模块，具体用于：

访问所述灰度版本的访问地址；

如果访问成功，则确定所述灰度版本的运行状态为可用状态；

如果访问不成功，则确定所述灰度版本的运行状态为不可用状态。

10.如权利要求8所述的装置，其特征在于，所述灰度检测模块，具体用于：

根据所述灰度版本中实例的访问地址，访问所述实例；

如果存在可用状态的实例，则确定所述灰度版本的运行状态为可用状态；

如果不存在可用状态的实例，则确定所述灰度版本的运行状态为不可用状态。

11.如权利要求8所述的装置，其特征在于，所述灰度检测模块，具体用于：

监测运行所述灰度版本实例的宿主机或者容器的运行状态；

如果所述宿主机或者容器的运行状态为不可用状态，则确定所述灰度版本的运行状态为不可用状态；

如果所述宿主机或者容器的运行状态为可用状态，则判断所述可用状态的持续时长是否达到预设时长；如果达到所述预设时长，则确定所述灰度版本的运行状态为可用状态；如果未达到所述预设时长，则确定所述灰度版本的运行状态为不可用状态。

12.如权利要求8所述的装置，其特征在于，所述灰度检测模块，具体用于：

查询所述灰度版本的运行日志；

如果所述运行日志未存在访问异常且未存在访问丢包，则确定所述灰度版本的运行状态为可用状态；

如果所述运行日志存在访问异常或者存在访问丢包，则确定所述灰度版本的运行状态为不可用状态。

13.如权利要求8-12中任一项所述的装置，其特征在于，所述装置还包括：

统计模块，用于在所述监测软件灰度版本的运行状态是否为可用状态之后，统计所述灰度版本的运行状态发生变化的次数；

所述第二响应模块，还用于如果所述次数大于预设阈值，则将所述接收到的请求采用所述软件的所述正式版本响应。

14.如权利要求8-12中任一项所述的装置，其特征在于，所述确定模块还用于：

根据所述灰度规则，确定访问流量引入至所述灰度版本和引入至所述正式版本的比例；根据所述比例，从接收到的请求中，确定所述第一用户请求，以及所述第二用户请求；或者，按照灰度规则中的预设条件，对所述接收到的请求中的IP地址进行筛选，确定所述第一用户请求，以及所述第二用户请求；或者，根据映射关系，对所述接收到的请求进行筛选，以确定所述第一用户请求，以及所述第二用户请求；其中，所述映射关系，用于指示历史请求的目标标识，与响应所述历史请求的灰度版本或正式版本之间的对应关系，其中，所述目标标识信息包括发送所述历史请求的客户端的IP地址或端口号、http请求中的header字段、user-agent字段、cookie中的至少一个。

15.一种计算机设备，其特征在于，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时，执行如权利要求1-7任一项所述的灰度发布方法。

16.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-7任一项所述的灰度发布方法。

Images