实战丨阳光保险灰度发布的最佳实践

文 / 阳光保险集团科技中心 王卓 李冰 杨清华

随着互联网线上业务的快速开展，金融保险企业对信息技术的依赖程度也在逐步提升，业务发展带来的需求快速迭代对IT系统的稳定性与产品上线效率提出了更高要求。传统的系统版本发布存在发布周期长、影响范围大、异常回滚耗时长等问题，这些问题往往会给企业带来巨大的风险和经济损失。

伴随着微服务化和容器化的推广使用，版本发布过程中的风险已得到了大大缓解，但是因版本内容导致的问题依然是影响系统稳定性的重要因素。如何确保在不影响已上线业务的情况下进行升级，实现业务新老版本的平滑过渡，并且避免升级过程中出现问题对用户造成的影响，成为迫切需要解决的问题。目前，针对版本发布稳定性的问题业内已有一些比较成熟的解决方案，如蓝绿发布、滚动发布以及灰度发布等，每种发布策略都有自己的适用场景，我们需要综合可靠性、效率、效果、成本等因素，选择适合本企业的落地方案。本文主要介绍阳光保险使用灰度发布策略的最佳实践。

灰度发布（又名金丝雀发布）是一种能实现软件新旧版本平滑过渡的一种版本发布方式。它的执行方式是在原有软件生产版本可用的情况下，同时部署一个或多个新的版本，使一个软件产品的多个版本同时运行。常用的灰度发布策略是同时部署AB两个版本，让一部分用户继续使用版本A，另一部分用户开始用新版本B，如果版本B用户使用正常，则逐步扩大范围，把所有用户流量都迁移到版本B上面，从而完成 AB版本的平滑过渡。灰度发布可以在初始灰度阶段发现、修改问题，控制升级影响范围，从而保证版本发布过程中系统的稳定运行。

灰度发布实践

1.灰度发布目的

对于互联网场景来说，灰度发布更多为了优化产品，通过多个版本同时在线的方式让随机用户参与产品测试，从而缩短用户反馈环，及早获得用户意见反馈，以达到完善产品功能，提升产品质量的目的。

与互联网场景不同，金融保险企业应用灰度的目的更多是为了提升版本稳定性，加速产品上线速度，对流量控制的粒度也相对更精细，因此对网关路由策略的管理复杂度和稳定性要求更高。

互联网灰度场景与金融保险的灰度场景的对比如下表所示。结合灰度发布的适用场景和能力，阳光保险引入灰度发布希望达成的目的主要有三点：一是规避发布风险，降低版本迭代影响范围。灰度发布适用于需要控制版本升级影响范围的场景，通过网关的路由配置，控制访问新版本服务的用户范围。二是快速回滚异常版本。灰度发布适用于风险较高的版本，传统全量发布、全量回滚的发布模式耗时长、影响大，而灰度发布通过调整网关路由配置，可将用户流量快速从异常服务切换到正常服务，从而实现异常版本迅速回滚的效果。三是全天候版本发布。灰度发布为白天工作时段生产升级验证提供了条件，无需在夜间版本发布后再耗费大量测试资源做流程验证，可实现版本的快速上线，同时缓解了开发人员的工作压力。

表 互联网灰度场景与金融保险的灰度场景对比表

2.灰度发布原则

根据灰度发布的落地情况，总结灰度发布的原则有以下六点。

（1）不是所有版本都可灰度发布。灰度发布本质还是借助生产流量进行版本验证和试错，由于灰度发布依赖的网关和服务分区主要是基于应用层，考虑系统各层级灰度的实现成本和版本回滚造成的影响，部分场景是不适合进行灰度发布的。不适合灰度发布的场景主要包含：一是监管版本。由于金融保险企业存在较多行业监管要求，往往会要求在某一时间节点将范围内的所有用户都同步使用相同的版本，故对于发布监管需求的版本大部分不适用于灰度发布。二是涉及数据结构变更的版本。某些版本包含底层数据结构变更，如字段删除和字段含义改变，这些情况无法支持新老版本使用相同的数据库，故一些涉及数据结构变更的版本不适用于灰度发布。三是有上下游服务依赖的版本。在微服务的场景下，业务需求的实现往往需要上下游服务协作完成，如果某些版本需要周边服务配合进行版本升级，但周边服务不支持灰度发布，则此版本不适用灰度发布。每次版本发布前，需评审发布方式，不适用灰度发布的版本仍需要通过传统全量发布方式上线。

（2）灰度版本可随时升级。灰度区服务原则上应支持随时进行版本发布。

（3）灰度发布范围可控。灰度区流量切换计划应在版本发布之前与相关负责人及开发人员沟通制定，根据版本需求和用户维度确定灰度范围和版本拉齐周期。原则上灰度版本拉齐生产的周期不宜超过两周。

（4）灰度版本基线独立。灰度区代码需维护至独立代码基线，由版本管理员统一管理。

（5）发布采用滚动升级。由于在灰度版本发布过程中可能存在用户的请求流量，且网关流量切换可能存在迟滞，故版本升级应采用滚动升级的方式将服务分批重启，保证灰度区和生产区的服务可用性。

（6）灰度版本充分验证。灰度发布后需要进行充分的验证，在发布后使用版本相关用户账号和不相关用户账号分别进行流程对照验证。灰度版本上线后，运维及相关开发人员应及时关注生产环境问题反馈，如灰度版本有问题需及时告知对应负责人，并讨论制定后续流量切换计划。

3.技术方案

灰度发布架构体系包括三个主要组成模块，分别是网关、灰度区服务集群、灰度管理平台，分别负责请求路由分发、灰度版本运行以及灰度路由管理。目前，阳光落地的灰度发布场景主要包括基于OpenResty网关的前端请求灰度和基于微服务网关的后端请求灰度。灰度区计算资源以生产区资源1/3的比例规划。

具体实现方面，OpenResty和微服务网关分别解析请求Cookie和Header中包含的JWT（Json Web Token），根据JWT中包含的用户、机构、渠道等信息到缓存或配置中心中获取灰度标识，之后网关根据灰度标识将请求代理至生产或灰度分区的服务集群。除了支持基于用户标识的灰度路由，还实现了百分比流量控制，管理员可以通过灰度管理平台查看和调整用户群的灰度标识和生效百分比，实现多维度的动态路由。

4.灰度发布流程管理

灰度发布的技术实现并不复杂，在引入灰度发布后，还需要制定对应的标准规范来约束灰度发布流程。在经过一段时间的落地实践之后，阳光保险IT团队总结了一套灰度发布流程的最佳实践，主要包含以下三个环节。

（1）代码评审及发布计划制定。版本在测试环境测试通过后，由系统负责人组织代码评审，评审内容主要包括：版本是否适用灰度发布，需切换至灰度区的流量范围，灰度版本验证通过后的拉齐时间，验证不通过的流量切换计划等。评审输出的灰度发布计划维护至需求版本管理系统。

（2）版本发布阶段。灰度区版本滚动升级完毕并确认服务可用后，由版本管理员在灰度管理平台根据灰度发布计划将部分验证工号的请求流量切换至灰度区服务，并进行版本验证。灰度区版本验证通过后，由管理员调整路由策略，逐步将灰度区用户范围扩大至灰度发布计划目标状态。如灰度版本验证出现问题，则由管理员将灰度区用户迁回生产区，之后将灰度区的版本进行回滚或升级补丁版本。

（3）版本发布结束阶段。灰度区版本按计划完成验证周期后，由版本管理员将灰度区版本拉齐至生产区，再将版本相关的所有用户的请求指向到生产区，完成灰度版本发布计划。

5.上线过程与成果

灰度发布最初在阳光产险核心系统落地后，虽然可以实现预期动态流量控制能力，但是也暴露出了灰度策略与发布计划管理缺失的问题，导致一些灰度版本未按预期进行流量试错，影响了灰度发布的效果。随着灰度体系的逐步推广，上下游服务如何保证灰度路由切换步调一致也是亟待解决的问题。针对以上问题，阳光保险内部搭建了统一的灰度管理平台，实现线上化灰度流量控制，并提供针对灰度版本多维度的监控与统计，协助管理人员统筹版本上线节奏，优化灰度发布的效率与效果。

目前阳光产险大部分系统在引入灰度发布体系后，都具备了日间生产版本发布的能力，配合阳光云 DevOps自动化发版流程，实现了版本的快速上线迭代。同时，通过灰度发布请求流量动态路由的能力，较好地控制了版本发布的影响范围，极大降低了版本带来的风险，系统宕机中断时长大幅缩短。

阳光产险核心系统作为最早落地灰度发布体系的系统，常规版本发布时间由过去动辄数小时缩短至从开发提交代码到生产发布最快30分钟内完成上线，月均发布灰度版本200余个，系统不可用时间下降了 92.5%，实现效率与质量的双保障。

灰度发布体系在阳光保险的建立与推广是技术赋能业务的典型体现，是对传统IT系统建设思路的大胆革新。目前灰度发布体系已在阳光产险全面落地，并且逐渐推广至其他各主体子公司，阳光保险IT团队也在落地过程中不断完善灰度体系结构，提升灰度发布覆盖的广度和深度，助力阳光保险数字化运营能力的全面提升。

（栏目编辑 ：韩维蜜）