近年来，随着系统中心化和微服务化改造工作的推进，上一代系统也逐渐分割为一个个高凝聚、低耦合、数据自治的“微服务”或能力中心。 分割后的系统APP体系结构如下。

系统体系结构现状

在当前模式下，更新和发布生产版本时，必须执行以下步骤：

生产发行流程的现状

但是，在这样的发布过程中，经常会出现一些问题。

由于需要停止版本的应用，对业务识别有一定的影响，所以版本的发布只能选择业务量相对较少的时间段

发布时间必须选择晚上12点以后，版本负责人必须通宵发布版本

版本验证时间不足。 上午发布版本后，没有足够的时间对运输和测试人员进行业务验证。 另外，如果验证出现问题，大多数情况下只能用版本返还的方法来应对。

因此，为了满足日常需求的快速迭代发布、缩短发布周期、减少通宵发布频率等核心需求，需要在现有系统的体系结构中引入灰度发布模式。

在探索灰度发布方案的过程中，参考了业界较为成熟的青绿发布方案，但根据本公司系统的运行情况，青绿发布还有一些不足之处。

1 )设备资源的冗余浪费，需要采用青绿分发方案，使用和生产一样多的APP服务器，这种情况下设备资源配套闲置，造成资源浪费

2 )客户体验问题，采用蓝绿发布方案，版本更新后，全量切换给用户，如果有版本问题，需要回滚的，会影响客户体验。

为此，整合行业较为成熟的几种方案，结合浩鲸产品的运营特点，我们逐渐探索出了适合我们生产系统使用的灰度发布方案。

灰度发布目标

我们参考了一些比较成熟的灰度发布方案进行了优化，制定了适合我们产品的灰度发布方案，主要满足了以下目标。

1 )白天无感知升级)版本验证完成后，白天进行无感知升级，可以快速支撑需求的迭代更新；

2 )资源最大化利用)不采用灰度和生产机械1:1的模式，合理利用现有的机械资源，实现低成本高价值目标

3 )滚动发布)发布时，可以根据资源配置情况定制滚动发布的模式，实现自动更新发布；

4 )快速回滚)如果新版本出现问题，可以单击一次回滚版本，快速恢复版本并重新启动生产服务。

灰度发布方案

1部署体系结构调整

为了解决当前的生产环境部署情况，引入了灰度环境。 为此，我们调整了现有生产系统的体系结构。 调整后的体系结构如下

协调的生产APP部署体系结构

生产系统在体系结构调整后进行了以下更改：

1 )增加灰度环境，灰度环境可以按照资源的20%进行配置，可以合理有效地利用机械资源

2 )增加灰度引擎，通过引入灰度引擎，可以按照流量、工序号、本地网络等参数对业务进行引流

3 )独立配置缓存，独立配置生产和灰度redis集群，避免规格、静态数据等缓存数据相互影响的问题。

2灰度级发动机设计

在灰度环境下，通过引入灰度引擎，实现了多维灰度战略的切换，保障了顾客的体验。 通过管理规则的灰度策略和用户路由规则，管理员可以在用户通过灰度引擎请求输入时

行智能路由时，根据灰度策略路由到灰度环境还是正式环境。

灰度引擎的实现基本原理如下：

灰度引擎原理

灰度引擎处理基本逻辑如下：

当APP或者Web端通过HTTP协议请求经过业务网关时，灰度引擎会从HTTP请求头解析灰度标识（如请求中的custId），如果存在灰度标识，则直接路由到灰度环境，如果不存在灰度标识，则路由到正式环境。

判断基本逻辑如下：

灰度引擎处理逻辑

灰度标识解析规则：支持可配置的HTTP Head提取规则，可以配置HTTP请求头的哪个字段用于提取灰度标识，例如custId。当灰度引擎解析到custId的值在灰度策略中时，灰度引擎则会将请求分发到灰度服务上。

灰度引擎策略支持多种维度的配置规则：

按照工号、本地网等维度配置；

按照客户标识等取末方式；

按照业务量的流量比进行灰度规则配置；

按照token值进行偏移量计算规则配置等。

3应用侧改造

在增加灰度环境和灰度引擎后，为了保障两套环境平稳地运行，同时能够适配灰度引擎的路由规则管理要求，应用侧需要做如下调整：

1）session共享：灰度引擎解析http请求时，http请求中的参数字段内容如useid（用户标识）、systemid（系统标识）、lanid（本地网）等信息都是需要从cookie中获取。为保障生产和灰度环境的cookie数据一致，需要灰度和生产环境能共享session信息。

2）优雅启停改造：应用侧为支持优雅启停功能，需要增加对Tomcat关闭事件的监听，保障已经进到应用服务的请求，必须完成当前请求任务后才能停止整个服务。同时为了保证服务请求的正常关闭，需要增加处理zookeeper服务注销事件。

3）多维度灰度策略改造：针对前台登录和外围接口请求的各种业务特性，系统需要实现根据工号、本地网、用户id以及业务请求业务流量等多个灰度策略，因此需要在门户登录及接口层对业务请求参数进行适配性改造。

4）APP应用下载管理：对于APP类应用，当客户使用APP进行操作时，系统需要根据登录的用户信息，判断是否需要提示客户进行版本更新。

5）Web应用更新：增加页面刷新事件，当最新版本页面发生变化时，如果在线客户正在处理当前界面信息，则系统判断当前请求未完成时，不刷新当前界面。当请求完成后，客户再次请求进来时，页面刷新事件则需要监听并加载最新的界面。

4外围服务改造

对于外围系统，通常我们一个服务会提供给外围不同的系统。因此，在对某一个服务进行改造后，为了不影响外围系统的请求，需要对改造的服务提供版本号的控制策略。服务请求解析时，应用侧可以按照接入系统标识，判断使用最新服务还是老版本的服务，从而保障在灰度切换过程中，新版本服务更新不影响外围其他系统。

5滚动更新发布

我们在灰度发布方案上并未直接选择采用蓝绿发布模式，而是通过滚动更新发布方式有效利用机器资源。滚动更新发布模式的实现基本原理如下：

滚动更新发布示意图

• 红色：表示正在停止的应用

• 绿色：表示正在更新加入到灰度集群的应用

• 蓝色：表示正在运行的应用

为保障机器资源的有效利用，生产集群和灰度集群会交替变更。当灰度集群完成版本更新后，可以按照资源配置情况和业务请求量设置每次生产集群滚动更新的数量，最后能够让灰度集群的应用承接全部业务量。

5开发流程管理

为保障需求版本能够顺利使用灰度策略，通过灰度发布模式快速更新版本。我们必须制定一套规范化的灰度版本开发和发布流程，在需求设计阶段需要明确当前的需求是否适合进行灰度发布模式。因此在需求版本管理上，我们制定了以下几个原则：

1）当前需求版本是否涉及模型变更；

2）当前需求版本是否涉及到接口协议的变化；

3）当前是否存在全量缓存刷新；

4）当前版本是否存在数据割接。

当需求和设计人员在分析某个需求时，需要确认该需求是否适用灰度发布，在版本交付时，版本管理人员会根据该标识确认是否能够发布灰度版本。

6灰度发布管理

灰度环境标记：生产环境和灰度环境采用同一套业务网关，为了让灰度引擎能够准确识别并路由，因此需要对生产环境和灰度环境分别设置不同的标签，用于区分环境的不同。灰度规则管理：在配置灰度发布规则时，当选择“全量”规则时，所有请求会无条件全部路由到灰度环境，当选择“标识”规则时，则会通过规则引擎来解析请求报文，从报文中抓取标识信息，用于灰度引擎判断请求路由。灰度发布流程管理：为保障灰度版本的稳定性和可靠性，需要严格按照以下流程进行灰度版本验证和更新操作：

灰度发布验证流程

7可视化配置操作

应用系统需要对接ZCM平台，进行规则策略配置和灰度滚动更新发布等操作，ZCM平台也提供一整套可视化的操作界面，实现整个过程可视化操作和展现。

灰度发布规则配置

滚动更新发布策略

实践效果

灰度发布方案在电信采购平台和BSS3.0两个项目成功实施以来，获得了不错的效果：

采购平台

该平台完全参照京东、苏宁易购等模式，在互联网业务诉求下，该平台对业务运营支撑提出了更高的要求。很多业务流程长、商品数据的差异，很多业务在测试环境很难覆盖，引入了我司的灰度发布模式后，可以在灰度版本上引部分流量进行生产真实测试，提高了版本质量。另外项目组制定了白、灰、黑三种发版本等级阶段：

白：白天发布，白天测试，白天切换全范围。

灰：白天(21:00前)发布，白天（21:00前）测试，晚上切换全范围。

黑：晚上（21:00后）发布，晚上（21:00后）测试，晚上切换全范围。

在实施三种版本发布等级后，项目组晚上熬夜发布版本的频次比之前已经减少了六成以上。

BSS3.0

在BSS3.0项目组，CRM产品引入灰度发布方案后，省份的版本质量也得到了大幅提升，每月因版本质量导致的故障几乎为0。同时省份的日常紧急需求已经能够白天发布，晚上发布版本频次由原来每个月3-4次降到每月1次，且晚上发布版本时，不需要再等到0点再发布，可以直接选择在晚上8点左右就能发布，让熬夜通宵发版本逐步变成历史。