CN112835604A - 系统灰度版本发布管理方法、系统、设备和介质 - Google Patents

Abstract

本公开提供了一种系统灰度版本发布管理方法，其中，包括：基于发布配置数据，交付灰度版本；对已交付的灰度版本执行发布验证，以进行灰度版本的执行发布；在执行发布过程中，对已完成发布验证的灰度版本进行持续监控，以实现对灰度版本的发布管理。基于上述管理方法，实现了灰度版本发布过程的统一纳管，降低运维人员的操作难度，提升运维效率，同时还进一步提升了灰度决策策略的准确性和决策智能化，减少人为操作失误的可能及为相关角色提供决策依据。本公开还提供了一种系统灰度版本发布管理系统、电子设备和计算机可读存储介质。

Description

系统灰度版本发布管理方法、系统、设备和介质

技术领域

本公开涉及计算机技术领域，尤其涉及一种系统灰度版本发布管理方法、系统、电子设备和计算机可读存储介质。

背景技术

伴随产品迭代加速，版本投产频度的提高，越来越多的应用发布都选择灰度发布技术作为规避发布风险的有效手段。区别于传统的应用发布方式，灰度发布技术主要在于发布灰度版本后先只在小部分用户中进行试点，经过充分的验证或一定时间的稳定运行后，再逐步完成非灰度环境版本的升级，成为正常应用版本。

发明内容

(一)要解决的技术问题

为解决现有技术中灰度版本发布过程中存在的技术问题至少之一，本公开提供了一种系统灰度版本发布管理方法、系统、电子设备和计算机可读存储介质。

(二)技术方案

本公开的一个方面提供了一种系统灰度版本发布管理方法，其中，包括：基于发布配置数据，交付灰度版本；对已交付的灰度版本执行发布验证，以进行灰度版本的执行发布；在执行发布过程中，对已完成发布验证的灰度版本进行持续监控，以实现对灰度版本的发布管理。

根据本公开的实施例，基于发布配置数据，交付灰度版本，包括：基于发布配置数据，确定灰度版本的部署应用节点；调用持续交付服务选择灰度版本的交付数据包；将交付数据包部署至部署应用节点，实现灰度版本的交付。

根据本公开的实施例，将交付数据包部署至部署应用节点，包括：拉取交付数据包中的灰度版本镜像，部署至部署应用节点对应的物理灰度环境中。

根据本公开的实施例，系统灰度版本发布管理方法还包括：在执行发布过程中，调整灰度流量数据；根据灰度流量数据，扩大灰度版本的执行试点范围。

根据本公开的实施例，对已交付的灰度版本执行发布验证，以进行灰度版本的执行发布，包括：基于灰度策略数据对已交付的灰度版本进行多维度业务验证。

根据本公开的实施例，在执行发布过程中，对已完成发布验证的灰度版本进行持续监控，包括：获取在执行发布过程中产生的历史灰度数据；基于历史灰度数据对灰度决策策略进行管理，灰度决策策略用于灰度版本的执行发布。

根据本公开的实施例，基于历史灰度数据对灰度决策策略进行管理，包括：对历史灰度数据进行策略分析，以获取灰度决策策略的评价模型；根据评价模型与预设决策变更规则，获取灰度决策策略的灰度变更数据；根据灰度变更数据，完成灰度版本的执行发布和/或生成灰度预警信息。

根据本公开的实施例，在执行发布过程中，对已完成发布验证的灰度版本进行持续监控之后，还包括：对与灰度版本对应的正常版本进行升级，以完成灰度版本的发布；或阻隔正常版本的用户访问流量，并切换用户访问流量至灰度版本，完成灰度版本的发布。

根据本公开的实施例，系统灰度版本发布管理方法还包括：在持续监控过程中，基于发布配置数据判断用户访问请求的引流类型；根据引流类型，将用户访问请求引流至灰度版本。

根据本公开的实施例，系统灰度版本发布管理方法还包括：获取灰度版本的灰度应急数据；根据灰度应急数据，将用户访问请求引流至与灰度版本对应的正常版本。

本公开的另一方面提供了一种系统灰度版本发布管理系统，其中，包括持续交付模块、发布验证模块和发布监控模块。持续交付模块用于基于发布配置数据，交付灰度版本；发布验证模块用于对已交付的灰度版本执行发布验证，以进行灰度版本的执行发布；发布监控模块用于在执行发布过程中，对已完成发布验证的灰度版本进行持续监控，以实现对灰度版本的发布管理。

本公开的另一方面提供了一种电子设备，包括一个或多个处理器和存储器；存储器用于存储一个或多个程序，其中，当上述一个或多个程序被上述一个或多个处理器执行时，使得上述一个或多个处理器实现本公开实施例的方法。

本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，上述指令在被执行时用于实现本公开实施例的方法。

本公开的另一方面提供了一种计算机程序，上述计算机程序包括计算机可执行指令，上述指令在被执行时用于实现本公开实施例的方法。

(三)有益效果

本公开提供了一种系统灰度版本发布管理方法，其中，包括：基于发布配置数据，交付灰度版本；对已交付的灰度版本执行发布验证，以进行灰度版本的执行发布；在执行发布过程中，对已完成发布验证的灰度版本进行持续监控，以实现对灰度版本的发布管理。基于上述管理方法，实现了灰度版本发布过程的统一纳管，降低运维人员的操作难度，提升运维效率，同时还进一步提升了灰度决策策略的准确性和决策智能化，减少人为操作失误的可能。本公开还提供了一种系统灰度版本发布管理系统、电子设备和计算机可读存储介质。

附图说明

为了更完整地理解本公开及其优势，现在将参考结合附图的以下描述，

其中：

图1A示意性示出了根据本公开实施例的可以应用系统灰度版本发布管理方法的示例性系统架构；

图1B示意性示出了对应图1A的根据本公开实施例的可以应用系统灰度版本发布管理方法的另一示例性系统架构；

图2A示意性示出了根据本公开实施例的系统灰度版本发布管理方法的流程图；

图2B示意性示出了对应图2A的根据本公开实施例的可以应用系统灰度版本发布管理方法的另一示例性系统架构；

图3示意性示出了根据本公开实施例的灰度版本交付的流程图；

图4A示意性示出了对应图2B的根据本公开实施例的可以应用系统灰度版本发布管理方法的另一示例性系统架构；

图4B示意性示出了对应图2B的根据本公开实施例的可以应用系统灰度版本发布管理方法的另一示例性系统架构；

图4C示意性示出了对应图2B的根据本公开实施例的可以应用系统灰度版本发布管理方法的另一示例性系统架构；

图5示意性示出了根据本公开实施例的发布监控的一示例性架构；

图6示意性示出了根据本公开实施例的判断引流的一示例性架构；

图7示意性示出了根据本公开实施例的系统灰度版本发布管理系统的框图；以及

图8示意性示出了根据本公开实施例的电子设备的框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了上述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。

附图中示出了一些方框图和/或流程图。应理解，方框图和/或流程图中的一些方框或其组合可以由计算机程序指令来实现。这些计算机程序指令可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器，从而这些指令在由该处理器执行时可以创建用于实现这些方框图和/或流程图中所说明的功能/操作的装置。本公开的技术可以硬件和/或软件(包括固件、微代码等)的形式来实现。另外，本公开的技术可以采取存储有指令的计算机可读存储介质上的计算机程序产品的形式，该计算机程序产品可供指令执行系统使用或者结合指令执行系统使用。

灰度发布是指在原有版本与升级版本之间，能够平滑过渡的一种发布方式。基于灰度发布，可以在原有版本的基础上同步进行一灰度版本实现A/B testing，即让一部分用户继续访问原有版本的产品特性A，一部分用户开始访问灰度版本的产品特性B，如果技术和业务范围上对B都具有良好的兼容性，则逐步扩大用户访问范围，逐渐把所有用户都迁移到灰度版本的特性B上面来，从而使得灰度版本转正成为升级版本或者将原有版本升级为升级版本。因此，灰度发布可以保证整体系统的升级稳定，在初始灰度的时候就可以及时发现并调整问题，以保证其影响度和版本质量。其中，在灰度版本执行发布直至其完成发布正式转正或升级的时间，即为灰度期。

目前现有灰度发布过程中所需要各种工具，但各种发布工具如发布监控模块等分散于多个不同的系统中，且由于各系统的功能有别，难以实现系统工具整合。因此，在实际的灰度发布运维操作中，需要多次切换不同的系统，然后通过对应系统中工具分别进行信息确认操作，以最终达到灰度版本发布的目的。

具体地，例如在进行发布配置调整过程中具体流程包括如下步骤S1和S2。在步骤S1中，先对灰度数据的配置中心所处的应用系统进行调用；在步骤S2中，基于对上述应用系统的调用，才可以对该应用系统中的灰度配置中心的相应数据配置功能进行调用。因此，由于灰度发布相关工具过于分散，存在较繁杂的人力操作和线下统计内容，使得发布运维过程严重依赖人力经验，造成灰度发布管理工作整体效率较为低下，且易于发生人为失误；而且，现有的灰度发布过程，决策数据的变更仅基于当前决策数据进行，从而使得灰度发布过程缺少必要的历史决策数据，决策难度较大，决策准确度较低。

为解决现有技术中灰度版本发布过程中存在的技术问题至少之一，本公开提供了一种系统灰度版本发布管理方法、系统、电子设备和计算机可读存储介质。

图1A示意性示出了根据本公开实施例的可以应用系统灰度版本发布管理方法的示例性系统架构。

需要注意的是，图1A所示仅为可以应用本公开实施例的应用示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例的系统灰度版本发布管理方法的不可以用于其他设备、系统、环境或场景。

如图1A所示，根据该实施例的系统架构100可以包括数据请求系统110，以及与该数据请求系统110建立数据通信的服务器系统120，其中服务器系统中包括与数据请求系统110建立数据传输通道的服务器M、121、122、123、124以及125，其中服务器M为主访问服务器，可以获取输入的指令信息。服务器121、122、123、124以及125为副访问服务器，数据请求系统110与服务器M、121、122、123、124以及125可以基于一个内部云端网络服务器C实现。或者，服务器M、121、122、123、124以及125中的主服务器M为一网络服务器时，即与其他终端设备111、112、113、以及114的内网相对，服务器系统120的主服务器M可以位于一外网中。此时，云端网络服务器C此处用以其他终端设备111、112、113、以及114之间提供通信链路的介质。服务器系统120与多个终端设备之间的数据传输通道具体可以通过各种通信连接类型实现，例如有线、无线通信链路或者光纤电缆等等。

需要说明的是，根据本公开实施例，服务器121、122、123、124以及125可以实现无密互联。

用户可以使用终端设备111、112、113、以及114与服务器系统120交互，以接收或发送消息等是实现数据传输或处理，具体涉及对服务器系统中主服务器M中的数据库的访问。例如，终端设备111向终端设备112发送业务数据，服务器系统120在接收到终端设备111的数据请求后，会对相应的业务数据执行转发处理或执行处理，并在特定的需要下对业务数据进行加密，以使得最终到达终端设备112的业务数据得到安全保障。终端设备111、112、113、以及114上可以安装有各种通讯客户端应用，例如管理类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)，以实现人机交互。

终端设备111、112、113、以及114可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机以及各类应用服务器等，以提供人机交互可视化界面。

服务器系统120可以包括提供各种服务的各类型防火墙，例如对用户利用终端设备111、112、113、114所浏览的网站提供支持的过滤型防火墙(仅为示例)。过滤型防火墙可以对接收到的用户请求等数据进行分析等处理，并基于数据源头的地址以及协议类型等标志特征进行分析，确定是否可以通过，从而将不安全因素过滤或阻挡。

需要说明的是，本公开实施例所提供的系统灰度版本发布管理方法一般可以由服务器系统120执行。相应地，本公开实施例所提供的系统灰度版本发布管理系统一般可以设置于服务器系统120中。本公开实施例所提供的系统灰度版本发布管理方法也可以由不同于服务器系统120且能够与终端设备111、112、113、114和/或服务器系统120通信的其他服务器系统120执行。相应地，本公开实施例所提供的系统灰度版本发布管理系统也可以设置于不同于服务器系统120且能够与终端设备111、112、113、114和/或服务器系统120通信的其他服务器系统中。

应该理解，图1A中的终端设备和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、服务器。

图1B示意性示出了对应图1A的根据本公开实施例的可以应用系统灰度版本发布管理方法的另一示例性系统架构。

需要注意的是，图1B所示仅为可以应用本公开实施例的应用示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例的系统灰度版本发布管理方法的不可以用于其他设备、系统、环境或场景。

如图1B所示，上述系统架构100中的服务器系统120可以构成系统灰度版本发布管理系统M，用以实现本公开实施例的系统灰度版本发布管理方法。也即，本公开实施例的灰度版本发布的管理完全依赖于统一的系统M实现相应各个管理工具的相应功能。其中，该系统M可以是一单独的服务器或服务器集群。

系统M可以具有相应的输入模块，输入模块在接收到外界的输入数据或信息指令时，对该数据或信息指令进行执行操作，完成对应的管理功能，最终确保灰度版本的发布完成，从而达到对灰度发布相关功能管理的统一纳管。

此外，系统M还可以接收用户的访问请求，并对用户访问请求进行判断，并将其引流至灰度环境I中，实现灰度版本的访问，或是将其引流至生产环境II中，实现正常版本的访问。其中，正常版本为用户所访问的数据应用相对于灰度版本的原有版本。

其中，生产环节中包括用于执行用户访问请求的应用节点集合A和数据节点B。其中，应用节点集合A用于实现对应用户访问请求的各个业务数据调取和执行，并将调取和执行的记录数据传输只数据节点B进行存储。应用节点集合A可以是多个应用服务器的集群，也可以是单独的应用服务器。数据节点B可以是单个的数据服务器。

相应地，灰度环境I中包括用于部署并执行灰度版本发布的应用节点集合a以及数据节点b。其中，应用节点集合a用于实现对应用户访问请求的各个业务数据调取和执行，并将调取和执行的记录数据传输只数据节点b进行存储。应用节点集合a可以是多个应用服务器的集群，也可以是单独的应用服务器。数据节点b可以是单个的数据库服务器。

应用节点集合a和A之间，以及数据节点b和B之间除对应于所要的升级版本的升级内容的差异，其他的架构和内容基本一致。而且，数据节点b和B之间一直保持有数据同步的进程，以确保二者所具有的存储数据始终完全相同。也即，数据节点b和B互为对方的备份数据库。

因此，本公开实施例的系统灰度版本发布管理方法可以基于系统M实现对灰度发布过程的统一纳管，避免了现有技术中先进行系统调用，才可以对应调用其管理工具的情况，极大地缩减了灰度发布管理的流程，提高了管理效率，同时降低管理难度，避免人为错误。而且，基于该管理系统M，可以实现将多个管理工具的整合，形成统一的灰度发布管理视图，实现管理界面的图形化设置，提升灰度环境的运维可视化水平，进一步避免人为误操作及为相关角色提供决策依据。

图2A示意性示出了根据本公开实施例的系统灰度版本发布管理方法的流程图；图2B示意性示出了对应图2A的根据本公开实施例的可以应用系统灰度版本发布管理方法的另一示例性系统架构。

如图2A所示，本公开的一个方面提供了一种系统灰度版本发布管理方法，其中，包括步骤S201-S203。

在步骤S201中，基于发布配置数据，交付灰度版本；

在步骤S202中，对已交付的灰度版本执行发布验证，以进行灰度版本的执行发布；以及在步骤S203中，在执行发布过程中，对已完成发布验证的灰度版本进行持续监控，以实现对灰度版本的发布管理。

如图1B和图2B所示，该系统灰度版本发布管理方法能够基于管理系统M或200直接基于发布配置数据交付灰度版本，并对灰度版本执行发布和持续监控，也即无需再对交付工具、发布工具和监控工具所在的原有系统进行依次调用。

如图2A、图2B所示，在步骤S201中对应于系统架构单元持续交付220，该持续交付220用于实现持续交付模块的相应持续交付功能，同时按需调拨灰度验证流量。发布配置数据为根据灰度版本相对于正常版本的内容升级、用户访问和/或灰度版本的安装交付所定义的配置数据，例如访问用户的类型、数量等，以及交付部署目的地、交付数据包的相关交付协议数据以及灰度策略等。

对灰度版本的交付数据包进行代码构建、单元测试，并根据测试结果，确定灰度版本的代码和正常版本的原有代码之间的集成关系，并在此基础上，将集成的代码部署到真实的运行环境中，如图1B所示高度模拟生产环境II的灰度环境I中，从而依据相应的发布配置数据实现各种持续交付的功能，相当于将灰度版本安装至相应物理灰度环境I中。

如图2A、图2B所示，在步骤S202中对应于系统架构单元发布验证210，该发布验证210用于实现发布验证模块的相应自动验证功能，相当于自动验证平台。已在物理环境中完成灰度版本交付安装后，可以对交付的灰度版本执行基础信息的自动验证，如对连接串匹配、数据库文件的存储、防火墙的设置等基础技术信息进行自动验证操作，以实现对已交付安装的灰度版本的发布验证。当发布验证通过之后，持续交付220可以进行已安装的灰度版本的执行发布过程，使得用户访问请求的访问流量进入灰度环境I中的应用节点a和数据库节点b，即执行发布。

如图2A、图2B所示，在步骤S203中对应于系统架构单元发布监控230，该发布监控230用于实现发布监控模块的持续监控功能，以对处于执行发布过程中的灰度版本进行流量数据访问、技术架构支撑等全方位的持续性监控。

因此，基于上述管理方法，实现了灰度版本发布过程的统一纳管，降低运维人员的操作难度，极大地缩减了灰度发布管理的流程，提高了运维管理效率，同时降低管理难度，避免人为错误。而且，基于该管理方法，可以实现将多个管理工具的整合，形成统一的灰度发布管理视图，实现管理界面的图形化设置，提升灰度环境的运维可视化水平，进一步避免人为误操作及为相关角色提供决策依据。

图3示意性示出了根据本公开实施例的灰度版本交付的流程图。

如图3所示，根据本公开的实施例，在步骤S201基于发布配置数据，交付灰度版本中，包括子步骤S301-S303。

在步骤S301中，基于发布配置数据，确定灰度版本的部署应用节点；

在步骤S302中，调用持续交付服务选择灰度版本的交付数据包；

在步骤S303中，将交付数据包部署至部署应用节点，实现灰度版本的交付。

对应于步骤S201，步骤S301-S303由持续交付220对应持续交付模块执行完成。部署应用节点可以为如1B所示的应用节点a中的至少一个应用服务器，用于对灰度版本提供物理交付环境和用于用户模拟访问的物理灰度环境。每个部署应用节点还包括相应的数据库节点b，为至少一个数据库服务器。每个应用节点a中各个服务器均具有相应的节点标签，用于定义并区分该应用节点的具体业务功能和技术功能。

发布配置数据中包括与上述各个服务器的节点标签对应的节点标识，以用于管理平台信息，通过该节点标识可以将灰度版本中交付数据包中的交付内容一一对应至应用节点a中的各个服务器中，以最终实现灰度版本准确的交付安装。也即部署应用节点中每个交付服务器均对应一个部署目的地，该部署目的地包括相应的部署环境和部署应用节点信息。

通过关联架构管理系统及配置管理数据库系统(Configuration ManagementDatabase，简称CMDB)的配置管理能力，确定发布配置数据对应的发布版本的部署目的地，即部署应用节点。其中，关联架构管理系统为应用系统架构、运维架构设计以及管理系统的结合，持续交付流水线通过选定的部署策略，关联架构管理系统中的应用群组、服务环境，依托发布配置数据的配置逻辑和CMDB系统的映射关系，实现灰度版本包部署到相应物理灰度环境的目的。CMDB系统为包含配置项全周期的信息以及配置项之间的关系的逻辑数据库，如物理关系、实时通信关系和依赖关系等。

在持续交付220中，持续交付模块可以调用持续交付服务选择相应灰度版本的交付数据包，即全流程实现将源代码生成软件包为交付数据包。交付数据包为灰度版本对应的源文件构成，该源文件具有对应灰度版本的基础配置文件、源代码等信息，通过数据文件的压缩等形式构成数据包。持续交付模块可以通过持续交付服务在定义部署应用节点的情况下，通过持续交付的调取选择，获取输入的灰度版本的交付数据包，同时对该交付数据包的交付安装规则进行定义，如解压缩协议、交付权限、脚本权限等。

依据前述所定义的交付安装规则，将交付数据包进行相应权限下的解压缩处理，并执行应用节点的部署操作，将灰度版本的相应交付安装内容部署至对应的部署应用节点和部署环境中，以最终实现灰度版本的交付、部署，并按需调拨灰度验证流量，保证交付灰度版本的交付质量。

如图2B和图3所示，根据本公开的实施例，在步骤S303将交付数据包部署至部署应用节点中，包括：拉取交付数据包中的灰度版本镜像，部署至部署应用节点对应的物理灰度环境中。

在持续交付220中，持续交付模块可以通过关联架构管理系统及配CMDB系统的配置能力，拉取交付数据包中对应的灰度版本镜像，将灰度版本交付数据包部署到部署应用节点的物理灰度环境中。

图4A示意性示出了对应图2B的根据本公开实施例的可以应用系统灰度版本发布管理方法的另一示例性系统架构；图4B示意性示出了对应图2B的根据本公开实施例的可以应用系统灰度版本发布管理方法的另一示例性系统架构；图4C示意性示出了对应图2B的根据本公开实施例的可以应用系统灰度版本发布管理方法的另一示例性系统架构。

根据本公开的实施例，系统灰度版本发布管理方法还包括：在执行发布过程中，调整灰度流量数据；根据灰度流量数据，扩大灰度版本的执行试点范围。

如图4A-图4C结合上述的图2B所示，本公开实施例的系统架构200中，还具有架构单元数据配置410，用于实现数据配置模块的数据配置功能。其中，发布配置数据可以通过运维人员的输入数据获取，或者响应于该输入数据生成。

此外，灰度流量数据可以是在灰度版本的执行发布过程中，与用户访问流量数据相关的数据，例如用户类型、对应用户类型的用户数量或占比、用户手机尾号为偶数或奇数、用户客户端的系统版本为安卓系统或是IOS系统等用户相关数据。例如，在执行发布过程中，发布配置数据所定义的正常版本的访问用户为城市A的用户，或者年龄位于18-35周岁之间的用户(即用户类型)，同时为对应该城市A或年龄18-35周岁之间所有用户中30％占比随机用户(即用户数量或数量占比)。因此，非发布配置数据所定义的用户仍然正常访问生产环境的正常版本。当对该灰度流量数据进行调整时，如在城市A用户的基础上，增加城市B和C的用户指定灰度版本的访问，则可以实现对灰度版本的执行试点范围的进一步扩大。因此，数据配置模块在上述灰度版本的执行发布过程中，用于接收发布配置数据，同时实现对灰度流量数据的调整。其中，在此过程中还涉及对灰度验证范围的逐步调整。

持续交付模块配合数据配置模块用于在灰度版本的执行发布过程汇总，根据灰度流量数据的调整结果，持续扩大灰度版本的执行试点范围，也即扩大了灰度版本的访问用户类型和用户数量，模拟生产环境中大流量访问场景，同时还能减轻正常版本的访问压力，改善用户访问体验。

其中，在此过程中，数据配置模块的中心接口统一对接，以确保灰度版本的执行试点质量。

如图4A-图4C结合上述的图2A、图2B所示，根据本公开的实施例，在步骤S202对已交付的灰度版本执行发布验证，以进行灰度版本的执行发布中，包括：基于灰度策略数据对已交付的灰度版本进行多维度业务验证。

本公开实施例的系统架构200，在发布验证210中，发布验证模块可以通过调整不同的灰度用户策略，针对灰度版本进行多维度业务验证，以确保灰度版本发布质量，其中该与用户访问策略相关的灰度用户策略数据即本公开实施例的灰度策略数据。发布验证模块为在执行发布过程中实现对灰度版本的基础技术验证以及多维度业务验证的自动验证平台。其中，基础技术验证为系统架构层面的错误，如连接串匹配错误、防火墙设置错误或被攻击侵入等技术内容的验证。多维度业务验证则涉及业务访问过程中如转账业务、查询业务、注册信息变更等业务内容的验证。

图5示意性示出了根据本公开实施例的发布监控的一示例性架构。

如图4A-图5结合上述的图2A、图2B所示，根据本公开的实施例，在步骤S203在执行发布过程中，对已完成发布验证的灰度版本进行持续监控中，包括：获取在执行发布过程中产生的历史灰度数据；基于历史灰度数据对灰度决策策略进行管理，灰度决策策略用于灰度版本的执行发布。

如图4A-图4C结合上述的图2B所示，本公开实施例的系统架构200中，还具有架构单元发布监控230，用于实现发布监控模块在灰度版本执行发布过程中的数据监控功能。其中，发布监控模块主要获取的是技术类监控数据和业务类监控数据。

如图5所示，架构单元发布监控230进一步包括架构子单元技术监控231和子单元业务监控232。子单元技术监控231用于获取技术类监控数据，包括：日志检查类、系统性能容量类、响应时间、数据库连接类以及事件告警类等；子单元业务监控232用于获取业务类监控数据，包括：交易覆盖率、高频交易成功率、重点改造交易成功率、重点或敏感交易成功类等。

其中，历史灰度数据为通过系统架构200对灰度决策策略进行管理，同时与独立的灰度环境进行关联所获取的在执行发布过程中的监控反馈数据，如版本失败与灰度执行场景的关系，具体可以是用户端的问题(例如用户手机客户端系统不支持、兼容性差等)，也可以是灰度版本的问题(如灰度版本的自身bug等)，即技术类监控数据和业务类监控数据。其中，该历史灰度数据为一动态变更数据集合，以自交付安装之后所产生的灰度监控数据进行累加。

相对于现有技术中只考虑实时灰度数据的情况，本公开实施例可以将历史灰度数据的内容进行分类、整合汇总等管理操作，以生成相应的灰度决策策略，该灰度决策策略可以实现对当前执行发布过程中灰度版本的完善，亦可以用于对其他后续灰度版本的开发和设计，以进一步降低人为操作的难度，提升灰度版本的执行发布效率、准确率和自动化程度。

根据本公开的实施例，基于历史灰度数据对灰度决策策略进行管理，包括：对历史灰度数据进行策略分析，以获取灰度决策策略的评价模型；根据评价模型与预设决策变更规则，获取灰度决策策略的灰度变更数据；根据灰度变更数据，完成灰度版本的执行发布和/或生成灰度预警信息。

具体地，在执行发布过程中，随着用户访问所产生的灰度数据越来越多，历史灰度数据的信息也越来越多。架构系统200的架构单元数据配置410所对应的数据配置模块，能够针对历史灰度数据进行智能策略分析，并对灰度决策策略进行完善，促使决策系统依据灰度决策策略在准确性和智能化方面不断演进。该决策策略分析的具体过程涉及对历史灰度数据中的错误判断-人为纠偏的累积学习，继而得到一累积学习的评价模型用于评价灰度决策策略。

依据上述的累积学习的评价模型以及实际决策变更映射关系(即预设决策变更规则)，以发出恰当的变更决策，即获得灰度决策策略的灰度变更数据。当该灰度决策变更数据对应的灰度版本质量优，则持续交付模块自动完成灰度版本的执行发布，例如自动完成生产环境中正常版本的版本升级，完成灰度发布。当该灰度决策变更数据对应的灰度版本质量差，则发布监控模块发出相关模板的告警信息(即灰度预警信息)并提供决策过程日志，供后续版本的修复参考。

其中，若无法准确匹配决策模型，则通知对应运维人员手动接入处理，并将处理结果录入系统，从而实现灰度决策策略的升级更新，推进决策系统完善。

因此，本公开实施例的可以通过运维变更，实现灰度决策策略的参数调整，进一步提升灰度环境的运维可视化水平，降低决策难度，以尽可能避免人为误操作的发生，同时也有利于后续版本的开发管理。

如图1B、图2A-图2B、图4A-图4C所示，根据本公开的实施例，在步骤S203在执行发布过程中，对已完成发布验证的灰度版本进行持续监控之后，还包括：对与灰度版本对应的正常版本进行升级，以完成灰度版本的发布；或阻隔正常版本的用户访问流量，并切换用户访问流量至灰度版本，完成灰度版本的发布。

当判断灰度版本质量优的情况下，可以对灰度版本执行转正，即将灰度版本作为正常版本的替代，使得用户访问请求全部切换至灰度版本，其中包括升级和转正两种情况。

升级：系统架构200的子单元220对应的持续交付模块依据灰度环境中灰度版本的灰度决策策略以及相应的灰度升级数据，对生产环境中的正常版本进行升级，使得升级后的正常版本与灰度版本一致，从而完成灰度版本的发布。

其中，升级过程中，正常版本和灰度版本仍然可以保持用户访问请求功能。在完成灰度版本的升级之后，阻隔灰度版本的用户访问流量，并将灰度版本的用户访问流量全部切换至正常版本，同时灰度版本的数据库节点b作为正常版本的备份节点使用。

转正：系统架构200的子单元220对应的持续交付模块依据灰度版本的灰度决策策略，阻隔正常版本的用户访问流量，并将正常版本的用户访问流量全部切换至灰度版本，同时将原正常版本的数据库节点B作为原灰度版本的备份节点使用。也即生产环境切换为备用环境，生产版本切换为备用版本，灰度环境切换为正常环境，灰度版本转正为正常版本，并接收用户访问请求。

如此，可以极大地保证用户数据的安全性，同时可以更好地实现决策策略的实时参数调整，提升灰度环境的运维可视化水平，尽可能避免人为误操作。同时，有利于对灰度发布实现统一纳管，降低运维人员的操作难度，提升运维效率，有利于DevOps相关工作的推进。

图6示意性示出了根据本公开实施例的判断引流的一示例性架构；

根据本公开的实施例，系统灰度版本发布管理方法还包括：在持续监控过程中，基于发布配置数据判断用户访问请求的引流类型；根据引流类型，将用户访问请求引流至灰度版本。

如图4A-图4C所示，系统架构200还包括子单元判断引流420，其中判断引流420对应的判断引流模块用于接收用户的访问请求，并对该访问请求进行引流判断，并依据判断结果对该访问请求进行引流。

引流类型包括灰度版本引流和正常版本引流两种类型，对应不同引流类型，访问请求被引流的访问版本不同。其中，访问请求只能被引流至灰度版本和正常版本中之一。

如图6所示，判断引流模块进一步包括子单元灰度判断421和灰度引流422。其中，灰度判断421用于在发布监控模块对灰度版本的持续监控过程中，对用户的访问请求进行判断，例如判断访问请求对应用户是否具有灰度版本的访问权限或访问资格，如灰度版本的发布配置数据设定的灰度版本的防问限定用户类型为城市A、年龄位于18-35周岁之间、同时手机尾号为奇数，用户发起业务访问请求时，会自带相应的用户类型标签，当该用户类型标签与该访问限定用户类型一致，则说明该访问请求对应的用户具有灰度版本的访问权限或访问资格，因此，该用户属于灰度版本引流的引流类型，相反则属于正常版本引流的引流类型，从而完成该访问请求的判断过程。

当判断用户具有灰度版本引流的引流类型之后，灰度引流422用于根据该灰度版本引流的引流类型，将用户的访问请求引流至灰度环境的灰度版本，实现用户对灰度版本的业务访问。

根据本公开的实施例，系统灰度版本发布管理方法还包括：获取灰度版本的灰度应急数据；根据灰度应急数据，将用户访问请求引流至与灰度版本对应的正常版本。

如图1B、图2A-图2B、图4A-图4C所示，在持续发布过程中，用户对灰度版本的业务访问会产生的各类访问数据和业务变更数据，同时也会出现各类与灰度版本的技术支持和业务支持相关的灰度应急数据，如用户在进行转账业务访问过程中，转账页面无法打开、打开显示不全或者页面打开过程超时等应急情况。

持续监控230对应的持续监控模块能够对该灰度应急数据进行检测监控，并将其转达至判断引流420对应的灰度判断引流模块，灰度判断421用于获取灰度应急数据并进行灰度引流判断。灰度引流422根据该灰度应急数据的灰度引流判断，将正处于灰度版本访问的用户访问请求切换并引流至与正常版本，以解决用户当前的灰度访问应急情况。具体地，灰度引流422可以阻隔灰度版本的用户访问流量，并切换用户访问流量至正常版本。

其中，灰度判断引流模块可以在持续交付模块的控制下实现相应灰度判断和灰度引流的功能。此外，如图4B和图4C所示，持续交付220可以包括数据配置410的相应数据配置功能，也可以与之并列集成构成系统架构200。同样，发布监控230可以包括判断引流420的相应判断引流功能，也可以与之并列集成并与持续交付210和数据配置410构成系统架构200。也即，本公开实施例的系统灰度版本发布管理方法能够实现对灰度版本发布过程中的多种灰度工具的统一纳管，进而可以实现对该管理系统架构的界面图形化设计，从而降低灰度发布的运维难度，增强其可视化水平，提升运维效率。

以下结合图7和图8，对本公开提供的系统灰度版本发布管理系统、电子设备及计算机可读存储介质作进一步的详细说明。

图7示意性示出了根据本公开实施例的系统灰度版本发布管理系统的框图。

如图7所示，本公开的另一方面提供了一种系统灰度版本发布管理系统700，其中，包括持续交付模块720、发布验证模块710和发布监控模块720。持续交付模块720用于基于发布配置数据，交付灰度版本；发布验证模块710用于对已交付的灰度版本执行发布验证，以进行灰度版本的执行发布；发布监控模块730用于在执行发布过程中，对已完成发布验证的灰度版本进行持续监控，以实现对灰度版本的发布管理。

其中，该系统灰度版本发布管理系统还具有相应的灰度策略管理模块，用于标准化灰度策略管理及灰度流量控制，在此不作赘述。

需要注意的是，图7所示仅为可以应用本公开实施例的系统架构200的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

需要说明的是，系统灰度版本发布管理系统部分的实施例方式与系统灰度版本发布管理方法部分的实施例方式对应类似，并且所达到的技术效果也对应类似，在此不再赘述。

图8示意性示出了根据本公开实施例的电子设备的框图。

如图8所示，本公开的另一方面提供了一种电子设备800，包括一个或多个处理器801和存储器；存储器用于存储一个或多个程序，其中，当上述一个或多个程序被上述一个或多个处理器执行时，使得上述一个或多个处理器801实现本公开实施例的方法。

图8示意性示出了根据本公开实施例的电子设备800的框图。图8示出的电子设备800仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图8所示，电子设备800包括处理器801、计算机可读存储介质802。该电子设备800可以执行根据本公开实施例的方法。

具体地，处理器801例如可以包括通用微处理器、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器801还可以包括用于缓存用途的板载存储器。处理器801可以是用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

计算机可读存储介质802，例如可以是非易失性的计算机可读存储介质，具体示例包括但不限于：磁存储装置，如磁带或硬盘(HDD)；光存储装置，如光盘(CD-ROM)；存储器，如随机存取存储器(RAM)或闪存；等等。

计算机可读存储介质802可以包括计算机程序821，该计算机程序821可以包括代码/计算机可执行指令，其在由处理器801执行时使得处理器801执行根据本公开实施例的方法或其任何变形。

计算机程序821可被配置为具有例如包括计算机程序模块的计算机程序代码。例如，在示例实施例中，计算机程序821中的代码可以包括一个或多个程序模块，例如包括模块821A、模块821B、……。应当注意，模块的划分方式和个数并不是固定的，本领域技术人员可以根据实际情况使用合适的程序模块或程序模块组合，当这些程序模块组合被处理器801执行时，使得处理器801可以执行根据本公开实施例的方法或其任何变形。

本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，上述指令在被执行时用于实现本公开实施例的方法。

具体地，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的灰度发布管理方法。

或者，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

本公开的另一方面提供了一种计算机程序，上述计算机程序包括计算机可执行指令，上述指令在被执行时用于实现本公开实施例灰度发布管理方法。

至此，已经结合附图对本公开实施例进行了详细描述。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，尽管已经参照本公开的特定示例性实施例示出并描述了本公开，但是本领域技术人员应该理解，在不背离所附权利要求及其等同物限定的本公开的精神和范围的情况下，可以对本公开进行形式和细节上的多种改变。因此，本公开的范围不应该限于上述实施例，而是应该不仅由所附权利要求来进行确定，还由所附权利要求的等同物来进行限定。

以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (13)

1.一种系统灰度版本发布管理方法，其中，包括：

基于发布配置数据，交付所述灰度版本；

对已交付的所述灰度版本执行发布验证，以进行灰度版本的执行发布；

在所述执行发布过程中，对已完成发布验证的所述灰度版本进行持续监控，以实现对所述灰度版本的发布管理。

2.根据权利要求1所述的方法，其中，所述基于发布配置数据，交付所述灰度版本，包括：

基于所述发布配置数据，确定所述灰度版本的部署应用节点；

调用持续交付服务选择所述灰度版本的交付数据包；

将所述交付数据包部署至所述部署应用节点，实现所述灰度版本的交付。

3.根据权利要求2所述的方法，其中，所述将所述交付数据包部署至所述部署应用节点，包括：

拉取所述交付数据包中的灰度版本镜像，部署至所述部署应用节点对应的物理灰度环境中。

4.根据权利要求1所述的方法，其中，还包括：

在所述执行发布过程中，调整所述灰度流量数据；

根据所述灰度流量数据，扩大所述灰度版本的执行试点范围。

5.根据权利要求1所述的方法，其中，所述对已交付的所述灰度版本执行发布验证，以进行灰度版本的执行发布，包括：

基于灰度策略数据对已交付的所述灰度版本进行多维度业务验证。

6.根据权利要求5所述的方法，其中，所述在所述执行发布过程中，对已完成发布验证的所述灰度版本进行持续监控，包括：

获取在所述执行发布过程中产生的历史灰度数据；

基于所述历史灰度数据对灰度决策策略进行管理，所述灰度决策策略用于所述灰度版本的执行发布。

7.根据权利要求6所述的方法，其中，所述基于所述历史灰度数据对灰度决策策略进行管理，包括：

对所述历史灰度数据进行策略分析，以获取所述灰度决策策略的评价模型；

根据所述评价模型与预设决策变更规则，获取所述灰度决策策略的灰度变更数据；

根据所述灰度变更数据，完成所述灰度版本的执行发布和/或生成灰度预警信息。

8.根据权利要求7所述的方法，其中，在所述执行发布过程中，对已完成发布验证的所述灰度版本进行持续监控之后，还包括：

对与所述灰度版本对应的正常版本进行升级，以完成所述灰度版本的发布；或阻隔所述正常版本的用户访问流量，并切换所述用户访问流量至所述灰度版本，完成所述灰度版本的发布。

9.根据权利要求1所述的方法，其中，还包括：

在所述持续监控过程中，基于发布配置数据判断用户访问请求的引流类型；

根据所述引流类型，将所述用户访问请求引流至所述灰度版本。

10.根据权利要求9所述的方法，其中，还包括：

获取灰度版本的灰度应急数据；

根据所述灰度应急数据，将所述用户访问请求引流至与所述灰度版本对应的正常版本。

11.一种系统灰度版本发布管理系统，其中，包括：

持续交付模块，用于基于发布配置数据，交付所述灰度版本；

发布验证模块，用于对已交付的所述灰度版本执行发布验证，以进行灰度版本的执行发布；

发布监控模块，用于在所述执行发布过程中，对已完成发布验证的所述灰度版本进行持续监控，以实现对所述灰度版本的发布管理。

12.一种电子设备，包括：

一个或多个处理器；

存储器，用于存储一个或多个程序，

其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现权利要求1至10中任一项所述的方法。

13.一种计算机可读存储介质，存储有计算机可执行指令，所述指令在被执行时用于实现权利要求1至10中任一项所述的方法。

Images