近些年，随着系统中心化和微服务化改造工作的推进，上一代系统也逐渐拆分为一个个高内聚、低耦合、数据自治的“微服务”或能力中心。拆分后的系统应用架构如下：
系统架构现状
在当前模式下， 我们在更新发布一个生产版本时，需要按照如下流程进行：
生产版本发布流程现状
然而在这种发布流程下，往往会存在几个方面的问题：
版本需要停止应用，对业务感知会产生一定影响，因此版本发布只能选择业务量相对较少的时间段进行；
版本发布时间需要选择在晚上12点后，版本人员经常需要通宵发布版本；
版本验证时间不足，凌晨发布版本后给运维和测试人员做业务验证的时间不够，且当验证出现问题时，很多情况下只能采取版本回退的方式处理。
因此，我们亟需在现有系统的架构上，引入灰度发布模式，从而解决日常需求快速迭代发布、缩短版本发布周期以及减少通宵发布版本频次等核心诉求。
在探索灰度发布方案的过程中，我们参考了业界比较成熟的蓝绿发布方案，但是根据我们系统运行的情况，蓝绿发布仍存在一些不足之处：
1）机器资源的冗余浪费，采用蓝绿发布方案，需要使用与生产一样多的应用服务器，这种情况下会有一套机器资源是闲置的状态，造成资源的浪费；
2）客户体验问题，采用蓝绿发布方案在版本更新后对用户切换全量切换，如果存在版本问题需要回退时，对客户体验会带来一些影响。
因此综合了业界比较成熟的几种方案并结合浩鲸产品的运营特点，我们逐渐摸索了一套适用于我们生产系统使用的灰度发布方案。
灰度发布目标
我们借鉴并优化了几个较为成熟的灰度发布方案，制定了符合我们产品的灰度发布方案，主要满足以下几个目标：
1）白天无感知升级：版本完成验证后，能够在白天进行无感知升级，快速支撑需求的迭代更新；
2）资源最大化利用：不采用灰度和生产机器1：1的模式，合理利用现有机器资源，达到低成本高价值目标；
3）滚动发布：在发布时，能够根据资源配置情况，自定义滚动发布模式，实现自动化更新发布；
4）快速回滚：在新版本出现问题时，能够一键回滚版本，快速还原版本恢复生产服务。
灰度发布方案
1部署架构调整
为解决目前生产单环境部署的情况，我们引入了灰度环境，因此对现有生产系统架构进行了调整，调整后的架构如下：
调整后的生产应用部署架构
生产系统在架构调整后，发生了以下几个方面的变化：
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点左右就能发布，让熬夜通宵发版本逐步变成历史。
声明：本站部分文章内容及图片转载于互联 、内容不代表本站观点，如有内容涉及侵权，请您立即联系本站处理，非常感谢！