CN114840248A - 一种基于企业级分布式应用服务的系统灰度发布方法 - Google Patents

Abstract

本发明公开了一种基于企业级分布式应用服务的系统灰度发布方法，通过对流量的流入转发规则进行配置，来控制流量进入灰度环境的应用实例，给流量打上灰度标记。EDAS的金丝雀发布能力，提供了多个版本同时在线的能力，并且提供了灵活的配置规则给不同的版本进行流量分配。本发明方法可实现服务系统托管，同时可提供服务系统开发、部署、监控、运维等全栈式解决方案，实现系统在线发布和无损回退，降低系统发布风险，提升系统服务质量。

Description

一种基于企业级分布式应用服务的系统灰度发布方法

技术领域

本发明涉及一种基于企业级分布式应用服务的系统灰度发布方法，属于流量控制技术领域。

背景技术

灰度发布也叫金丝雀发布，起源是，矿井工人发现，金丝雀对瓦斯气体很敏感，矿工会在下井之前，先放一只金丝雀到井中，如果金丝雀不叫了，就代表瓦斯浓度高。在灰度发布开始后，先启动一个新版本应用，但不进行流量切换，而是测试人员对新版本进行线上测试，启动的这个新版本应用，即为“金丝雀”测试。如果没有问题，则可将少量的用户流量导入到新版本上，再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做数据对比，就是所谓的A/B测试。

当确认新版本运行良好后，再逐步将更多的流量导入到新版本，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力。直到将100％的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。如果在灰度发布过程中(灰度期)发现了新版本有问题，应立即将流量切回老版本，这样，就会将负面影响控制在最小范围。

目前，生产环境应用发布大多采取单批发布(滚动发布)，所谓滚动发布，是在升级过程中，并不一次性启动所有新版本，而是先启动一个新版本，再停止一个老版本，继而再启动一台新版本，再停止一台老版本，直到升级完成，如图1所示。但是滚动升级有一个问题，在开始滚动升级后，流量会直接流向已经启动起来的新版本，这个时候，新版本是不一定可用的，需要进一步的测试才能确认。在滚动升级期间，如果发现了问题，也比较难以确定是新版本还是老版本造成的问题。

发明内容

为解决上述问题，本发明提供一种基于企业级分布式应用服务的系统灰度发布方法，通过设置发布策略和灰度规则，来控制流量进入灰度环境的应用实例，让部分用户或者流量先进入到新版本中，对新版本做进一步的测试，当新版本测试没有问题后，在把所有版本升级到最新，让全部用户使用新版本。

为达到上述目的，本发明所采用的技术方案如下：

本发明提供一种基于企业级分布式应用服务的系统灰度发布方法，对需要灰度发布的版本按照设置的部署参数、发布策略和灰度规则进行灰度发布；

其中，设置部署参数包括配置镜像、设置应用运行环境、Java环境、文件上传方式、版本和时区；

设置发布策略包括设置首批灰度数量、剩余批次、分批间处理方式以及批次内部署间隔；

设置灰度规则包括设置协议类型、条件模式和条件列表。

进一步的，所述配置镜像适用于镜像部署的应用，镜像不可更改。

进一步的，所述应用运行环境包括JAR包应用运行环境和WAR包应用运行环境；

所述JAR包应用运行环境为标准Java应用运行环境，不可更改；

所述WAR包应用运行环境为Apache Tomcat，不可更改。

进一步的，所述文件上传方式采用以下任意一种方式：

上传部署包；

输入部署包地址。

进一步的，所述设置版本包括：采用时间戳作为版本号。

进一步的，所述设置首批灰度数量包括：

首批进行灰度发布的应用实例个数为正常实例个数的一半；

首批发布后，剩余的应用实例按照设定的剩余批次进行分批发布。

进一步的，所述分批间处理方式包括：

根据预设的发布时间间隔自动分配分批发布；

和，

手动触发下一个批次的发布。

进一步的，所述协议类型包括Spring Cloud和Dubbo；

其中，Spring Cloud需要设置path；Dubbo需要选择服务和方法。

所述设置条件列表包括：

Spring Cloud：包含Cookie、Header和Parameter3种方式，根据实际需求设置；

Dubbo：根据应用实际的参数、参数值获取表达式设置。

进一步的，还包括：

通过配置emss-scp-gateway网关微服务的header参数，筛选特定IP地址或者用户ID，给对应的流量打上灰度标签，使用链路传递的特性使该流量流向下游灰度的应用，实现特定IP或者用户ID进入灰度环境。

进一步的，还包括：是否对微服务进行灰度发布还需要对自身的业务进行分析，基本原则如下：

与外部系统连接的服务不进行灰度发布；

涉及MQ、SchedulerX、OTS外部组件的微服务不进行灰度发布；

所有数据微服务及提供基础平台的微服务不进行灰度发布；

设置了HPA弹性扩缩的微服务不进行灰度发布；

涉及Redis的微服务不进行灰度发布；

本发明的有益效果为：

本发明提供的基于企业级分布式应用服务的系统灰度发布方法，可实现服务系统托管，同时可提供服务系统开发、部署、监控、运维等全栈式解决方案，实现系统在线发布和无损回退，降低系统发布风险，提升系统服务质量。

附图说明

图1是滚动发布示意图；

图2是本发明实施例提供的灰度发布示意图。

具体实施方式

下面对本发明作进一步描述。以下实施例仅用于更加清楚地说明本发明的技术方案，而不能以此来限制本发明的保护范围。

本发明实施例提供一种基于企业级分布式应用服务的系统灰度发布方法，实现过程如下：

在新版本上线时，无论是从产品稳定性还是用户对新版本的接受程度上考虑，将老版本应用升级到新版本应用都有很大风险。一般的做法是，保证新老版本同时在线，并且先将少部分流量切换到新版本应用上，同时在此期间对新版本的应用请求进行观察。在确认新版本没有问题后，逐步将更大比例的流量切换到新版本上。这个过程的核心是可以对流量的流入转发规则进行配置，企业级分布式应用服务EDAS的金丝雀发布能力，提供了多个版本同时在线的能力，并且提供了灵活的配置规则给不同的版本进行流量分配。

在EDAS微服务发布时，选择灰度发布，按提示设置需要灰度发布的版本。在灰度环境中，通过规则条件来控制流量进入灰度环境的应用实例，给流量打上灰度标记。让部分用户或者流量先进入到新版本中，对新版本做进一步的测试，当新版本测试没有问题后，在把所有版本升级到最新，让全部用户使用新版本。具体参见图2。

同时用户还可以控制属于灰度环境的应用实例，给应用实例打上了灰度标记。

生产环境中，没用Cookie参数，同时EDAS的Header和Parameter配置参数无法实现根据客户端的ip或者用户id进入灰度环境中，本实施例中，结合配置emss-scp-gateway网关微服务的header参数，筛选特定条件(例如IP地址、地址段或者用户ID)，根据条件给该流量打上灰度标签，使用链路传递的特性使该流量流向下游灰度的应用，实现特定IP或者用户ID进入灰度环境。该方法需要研发对网关微服务emss-scp-gateway的代码进行修改，加入对指定IP或者ID的判断筛选的流程。

作为一种优选的实施方式，对发布批次进行设置，设置发布灰度批次，首批进行灰度的pod实例个数为正常实例个数的一半，分批间处理方式。

作为一种优选的实施方式，对流量灰度规则进行配置，选择按流量内容进行灰度。允许满足条件的流量进入灰度环境。协议模式选择springcloud，条件模式设置参数类型为Parameter。将客户请求参数version值为grey的流量转入灰度环境。以及，修改要进入灰度环境的客户地址请求url，在地址后面加入参数version＝grey。

需要说明的是，基于EDAS的灰度方案中，所有的外部组件(例如：Redis、MQ、SchedulerX、OTS等)共用一套。而在灰度时，无法保证2个版本的微服务对这些组件是否产生影响。因此，本实施例中所有涉及这个核心外部组件的微服务不建议采取灰度发布。

需要说明的是，全局事务服务GTS是一款高性能、高可靠、接入简单的分布式事务中间件，主要用于解决分布式系统数据一致性的问题。而分布式系统即多个子业务或者服务去完成同一个服务，类似灰度上不同版本处理同一个事物。当两个版本处理同一条数据出现差异时，由GTS对事物进行回滚，保证数据的一致性。因此涉及到GTS的微服务进行灰度后将不会有影响。

需要说明的是，例如，数据、工单、消息这类微服务只提供基础平台，与业务逻辑关系不大，并且该类应用的版本具有兼容上一个版本的特性，只需最新版本。而针对系统的核心服务，不建议进行灰度发布。

需要说明的是，基于EDAS的灰度发布与HPA(弹性扩缩)、Rancher、Istio、或者依赖Deployment.Metadata.Name或Deployment.Metadata.Uid等K8s原生功能存在冲突。系统中有多个微服务设置了HPA，所有对这些微服务不能进行灰度发布，否则，应用部署之后，这些K8s原生功能或配置将出现异常。

具体来说，是否可以对该微服务进行灰度发布还需要对自身的业务进行分析，基本原则：

与外部系统连接的服务，例如业务链接平台、物联等不进行灰度。

涉及MQ、SchedulerX、OTS外部组件的微服务不灰度。

所有数据微服务及提供基础平台的微服务不灰度。

设置了HPA弹性扩缩的微服务不灰度。

考虑涉及Redis都不支持灰度。

本发明第二个实施例提供的一种基于企业级分布式应用服务的系统灰度发布方法，具体操作过程如下：

1.登录EDAS控制台。

2.在左侧导航栏中单击应用列表，在顶部菜单栏选择地域并在页面上方选择微服务空间。

3.在应用列表页面的集群类型下拉列表中选择容器服务/Serverless K8s集群，单击目标应用名称。

4.在应用总览页面右上角选择部署。

5.在选择部署模式页面的金丝雀发布(灰度)区域右上角单击开始部署。

6.在灰度发布(金丝雀)页面设置新版本应用的部署参数、发布策略和灰度规则，单击确定。

表1部署参数

表2发布策略参数

表3灰度规则

灰度发布启动后，先在指定的灰度分组中部署新版本应用。基本信息页面提示应用有变更流程正在执行，处于执行中状态。单击查看详情，进入变更详情页面查看部署进度和状态。

应用处于金丝雀发布状态，并且该变更已经被终止。请先回滚应用，再进行其他操作。

7.首批灰度流量验证完成后，在变更记录页面右侧单击开始下一批，完成后续分批发布。如果在验证过程中发现新版本应用有问题，可以在变更记录页面右上角单击回滚，并在弹出的确认对话框单击确认。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

最后应当说明的是：以上实施例仅用以说明本发明的技术方案而非对其限制，尽管参照上述实施例对本发明进行了详细的说明，所属领域的普通技术人员应当理解：依然可以对本发明的具体实施方式进行修改或者等同替换，而未脱离本发明精神和范围的任何修改或者等同替换，其均应涵盖在本发明的权利要求保护范围之内。

Claims (10)

1.一种基于企业级分布式应用服务的系统灰度发布方法，其特征在于，对需要灰度发布的版本按照设置的部署参数、发布策略和灰度规则进行灰度发布；

其中，设置部署参数包括配置镜像、设置应用运行环境、Java环境、文件上传方式、版本和时区；

设置发布策略包括设置首批灰度数量、剩余批次、分批间处理方式以及批次内部署间隔；

设置灰度规则包括设置协议类型、条件模式和条件列表。

2.根据权利要求1所述的一种基于企业级分布式应用服务的系统灰度发布方法，其特征在于，所述配置镜像适用于镜像部署的应用，镜像不可更改。

3.根据权利要求1所述的一种基于企业级分布式应用服务的系统灰度发布方法，其特征在于，

所述应用运行环境包括JAR包应用运行环境和WAR包应用运行环境；

所述JAR包应用运行环境为标准Java应用运行环境，不可更改；

所述WAR包应用运行环境为Apache Tomcat，不可更改。

4.根据权利要求1所述的一种基于企业级分布式应用服务的系统灰度发布方法，其特征在于，所述文件上传方式采用以下任意一种方式：

上传部署包；

输入部署包地址。

5.根据权利要求1所述的一种基于企业级分布式应用服务的系统灰度发布方法，其特征在于，所述设置版本包括：采用时间戳作为版本号。

6.根据权利要求1所述的一种基于企业级分布式应用服务的系统灰度发布方法，其特征在于，所述设置首批灰度数量包括：

首批进行灰度发布的应用实例个数为正常实例个数的一半；

首批发布后，剩余的应用实例按照设定的剩余批次进行分批发布。

7.根据权利要求1所述的一种基于企业级分布式应用服务的系统灰度发布方法，其特征在于，所述分批间处理方式包括：

根据预设的发布时间间隔自动分配分批发布；

和，

手动触发下一个批次的发布。

8.根据权利要求1所述的一种基于企业级分布式应用服务的系统灰度发布方法，其特征在于，

所述协议类型包括Spring Cloud和Dubbo；

其中，Spring Cloud需要设置path；Dubbo需要选择服务和方法；

所述设置条件列表包括：

Spring Cloud：包含Cookie、Header和Parameter3种方式，根据实际需求设置；

Dubbo：根据应用实际的参数、参数值获取表达式设置。

9.根据权利要求1所述的一种基于企业级分布式应用服务的系统灰度发布方法，其特征在于，还包括：

通过配置emss-scp-gateway网关微服务的header参数，筛选特定IP地址或者用户ID，给对应的流量打上灰度标签，使用链路传递的特性使该流量流向下游灰度的应用，实现特定IP或者用户ID进入灰度环境。

10.根据权利要求1所述的一种基于企业级分布式应用服务的系统灰度发布方法，其特征在于，还包括：是否对微服务进行灰度发布还需要对自身的业务进行分析，基本原则如下：

与外部系统连接的服务不进行灰度发布；

涉及MQ、SchedulerX、OTS外部组件的微服务不进行灰度发布；

所有数据微服务及提供基础平台的微服务不进行灰度发布；

设置了HPA弹性扩缩的微服务不进行灰度发布；

涉及Redis的微服务不进行灰度发布。

Images