分布式全链路灰度发布的探索与实践

分布式全链路灰度发布的探索与实践

作者|顾欣
来源|阿里巴巴云原生公众号

互联网金融时代下,金融产品和服务模式不断创新,金融系统容量需求急剧增长,为进一步满足运维标准提升工作的需求,提升服务连续性2 G x M P水平。中国工商银行(后简称工行)从 2014 年开始分布式架构转型的技术预研工作,通过对开源微服务框架深入调研和技术选型后,确定了基于开源 Dubbo 自主研发建设分布式服务平台,并结合K Z k 5金融场景,工行在 Dubbo 基础上对服务的注册、发现等核心能力进行了三十余项定制,以支持单注册中心超x D T I l 70 万提0 ` v供者的超大规模业务场景。分布式服务作为分布式体系的核心能力,助力工行应用架构向分布式、服务化转型,承载未来开放平台核心银行系统。

在分布式系统中,由于分布式全链路灰度发布因其链路复杂、技术门槛高、落地难度高逐渐成为金融科技实现F @ L全链路灰度发布的难点所在。工行在分布式系统建设方面一直走在同业前列,积极探索分布式全链路灰度发布,致力于R u G解决分布式架构下跨应用、跨服务的全链路灰度发布能力。

业界传统灰度发布

灰度发布是业界一种规避发布风险的有效的手段,通常可以蓝绿部署、滚动发布、灰度发布等几种方式实现。

1. 蓝绿发布

蓝绿部署是指同时运行两个版本的应用,如图1所示,蓝绿部署的时候,原有版本不停止服务,直接部署一套新版本,新版本正常运行后,再将流量切换到新版本。但是蓝绿部署要求在升级过程中,同时运行两套程序,对硬件的要求就是日常所需的两倍。

分布式全链路灰度发布的探索与实践
图 1 蓝绿部署

2. 滚动发布

滚动升级就是在升级过V ( r _ J ; D程中,不是同时启动所有新版本,是先启动一台新版本,再停止一台老= m Z e 9版本,以此类推,直到升级完成。但是滚动升级存在风险,在开始滚动升级后,流量会直接流向已经启动起来的新. o + )版本,但是新版本是不一定可用S / K r 0 1的,比如需要进一步的) O / p测试才能确认。那么在滚动升级期间,整个系统就处于非常不稳定的状态,如果发现了问题,也比较难以确定是新版本还是老版本造成的问题。

分布式全链路灰度发布的探索与实践
图 2 滚动发布

3. 灰度发布

灰度发布即先启d n ?动一个新版本应用,但是并不直接将流量切过来,而是测试人员对新版本进行线上测试。如果没有问题,那么可以将少量的用户流量导入到新版本上,然后再对新版本做运行状态观察,收集各种运行时数据,如果此时对新旧版本做各种数据对比,就是所谓的 A/B 测试。当确认新版本运行良好后,再逐步将更多的流量导入到新版本上,在此期间,还可以不断地调整新旧两个版本的运行的服务器副本数量,以使得新版本能N | ^ @ z够承受越来越大的流量压力。直到将 100% 的流量都切换到新版本上,最后关闭剩下的老版本服务B y r,完成灰度发布。如果在灰度发布过程中(灰度期)发现了新版本有问题,就应该立即将流量切回老版本上,这样,就会将负面影响控制在最小范围内。

分布式全链路灰度发布的探索与实践
图 3 灰度发布

工行对企业级链路灰度发布能力探索

工行从 2015 年开启了 IT 架构转型工程,分布式体系已覆盖百余个关键应用,已有上万V i E 3 I @ v 6 |分布式服务节点,日均服务调用量超 60 亿,交易峰值逾 10 万 TPS,实现了远程* j $ P h | k主机性能容量的集群处理能力。截至 2019 年,工行各项目主要通过滚动升级、蓝绿发布、业务开关三种方式实施了灰度发布。

随着 IT 架构转型,分布式体系支撑的服务的底层架构和平台系统日益复杂,生产运行不- . C确定因素相较O 4 S G B 8 X m y于主机明显增加,这就对生产系统稳定运行提出了a n ` x z h F更高的要求。工行于 2020 年上半年已支持分布式全链路灰度发布方式,旨在复杂分布式场景中,针对行内重点产P : : 0 | U品线、重点应用、公共支撑平台,形成统一的灰度发布规范,为重点产品线提供了全链路灰度发布能力的@ M B z O技术支撑。

1. 面对多样化金融业务场景,构建企业级全链路灰度能力

工行目前已有近 10 亿账户,每日通过多种渠道处理近 2 亿笔支付结算业务,对系统的高可用能力要求极高v a D e。面对不同产品线,迫切需要端到端的全链路灰度发布,来降低版本发布的风险。工行全链路灰度发布能力通过对业务流量进行染色,联合软负载均衡、网关、服务框架等多个组件,实现染色流量按标签进行路由,支持跨应用、跨节点的全链路灰度路由能力,并建立灰度发布运维监控体系和管控机制。

分布式全链路灰度发布的探索与实践
图 4工行全3 0 y q链路灰度流程

2. 流量标签级灰度路由能力,驾驭金融业务场景

全链路灰度发布采用标签路由的方式,通过软负载和服务框架识别染色流量中的标签和灰度环境节点标签,实现对应染色 + * ] ; +流量只在对应标签的灰度环境中流转。

1)软负载灰度流量分发

软负载通过识别流量中的灰度标签,把灰度流量路由发送至Q * J E = & 2对应标签的灰度环境,实现灰度流量的第一级分发。

分布式全链路灰度发布的探索与实践
图 5软负载灰度路由

2)服务框架灰度路由

灰度请求流量流转到业务层服务化节点后,后续流量就由服务框架代管,通过 RPC(Dubbo)协议流转,服务框架的标签路由层会自动识别本次请求是否携带灰度流量标识,并筛选特定的V W S G $ P + o 9灰度环境并转发请求。

分布式全链路灰度发布的探索与实践
图 6服务框架灰度T 6 } S路由

3)灰度标签链路透明传递

在业: K q $务服务层,服务框架负责灰度标签的传递。Dubbo 提p 9 J m供了优雅的隐H X c ] X * f O式参数机制,方便地传递上下游的一些标记和控制消息,而实现对业务无感的能力。工行微服务框架在此机制上,将灰度标签作为一隐式参数,在消费方发起请求切面中自动将该参X e y e数设置在请求中,使得灰度流量在链路传递过程中,其携带的灰度标识能被层层传递下去,实V a N现全链路灰度发布能力。

分布式全链路灰度发布的探索与实践
图 7灰度标识透明传递

4)灰度降级保障业务交易安全执行

当链路中存在环节所有服务节点灰度标识均无法匹配灰度请求标识,则灰度请求在该环境通过正常节点处理,且保证灰度标识能继续向下游传递。保障系统高可用能力,防止流量找不到对应标识节点[ E i d v b而出现交易失败的情况。

分布式全链路灰度发布的探索与实践
图 8灰度降级

3. 总结

目前工行已建设统一的全链路灰度发布标准,降低了各应用实现灰度发布的改造人力成本及灰度环境建设难度,提高了研发z , %效率,最终实z - {现跨应用、跨服务的一致性灰度发布能力。已在聚合支付业务线、手机银行业务线等二十余个应用实现了全链路灰度发布能力。

未来展望

随着工行 IT 架构转型的持续推进,工行将持续构建以主机和平台双核心的金融信息系统,保证金融服务的稳定运行,支撑高频业务快速增长。以“开放性、高容量、易扩展、成本可控、安I . l k f o ] 0全稳定、便捷研发”为建设理念,在分布式全链路灰度发布领域积极推动技术创新、管控升级$ p / M &,覆盖银行核心交易链路场景,持续完善全链路灰度发布模式,减少应用接入成本,提升全链路灰度发布中各组件兼容适配能力,以适应复杂的分布式金融交易场景,为智慧银行建设提供有力* ^ 5 [支撑。