作者｜顾欣

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

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

业界传统灰度发布

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

1. 蓝绿发布

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

图 1  蓝绿部署

2. 滚动发布

滚动升级就是在升级过程中，不是同时启动所有新版本，是先启动一台新版本，再停止一台老版本，以此类推，直到升级完成。但是滚动升级存在风险，在开始滚动升级后，流量会直接流向已经启动起来的新版本，但是新版本是不一定可用的，比如需要进一步的测试才能确认。那么在滚动升级期间，整个系统就处于非常不稳定的状态，如果发现了问题，也比较难以确定是新版本还是老版本造成的问题。

图 2  滚动发布

3. 灰度发布

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

图 3  灰度发布

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

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

随着 IT 架构转型，分布式体系支撑的服务的底层架构和平台系统日益复杂，生产运行不确定因素相较于主机明显增加，这就对生产系统稳定运行提出了更高的要求。工行于 2020 年上半年已支持分布式全链路灰度发布方式，旨在复杂分布式场景中，针对行内重点产品线、重点应用、公共支撑平台，形成统一的灰度发布规范，为重点产品线提供了全链路灰度发布能力的技术支撑。

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

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

图 4  工行全链路灰度流程

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

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

1）软负载灰度流量分发

软负载通过识别流量中的灰度标签，把灰度流量路由发送至对应标签的灰度环境，实现灰度流量的第一级分发。

图 5  软负载灰度路由

2）服务框架灰度路由

灰度请求流量流转到业务层服务化节点后，后续流量就由服务框架代管，通过 RPC（Dubbo）协议流转，服务框架的标签路由层会自动识别本次请求是否携带灰度流量标识，并筛选特定的灰度环境并转发请求。

图 6  服务框架灰度路由

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

在业务服务层，服务框架负责灰度标签的传递。Dubbo 提供了优雅的隐式参数机制，方便地传递上下游的一些标记和控制消息，而实现对业务无感的能力。工行微服务框架在此机制上，将灰度标签作为一隐式参数，在消费方发起请求切面中自动将该参数设置在请求中，使得灰度流量在链路传递过程中，其携带的灰度标识能被层层传递下去，实现全链路灰度发布能力。

图 7  灰度标识透明传递

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

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

图 8  灰度降级

3. 总结

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

未来展望

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

想要加入中生代架构群的小伙伴，请添加群合伙人大白的微信

申请备注（姓名+公司+技术方向）才能通过哦！

阿里技术精彩文章推荐

往期推荐

深度：揭秘阿里巴巴的客群画像

多隆：从工程师到阿里巴巴合伙人

阿里技术专家楚衡：架构制图的工具与方法论

蚂蚁集团技术专家山丘：性能优化常见压测模型及优缺点

阿里文娱技术专家战獒: 领域驱动设计详解之What, Why, How?

阿里专家马飞翔：一文读懂架构整洁之道

阿里专家常昊：新人如何上手项目管理？

蚂蚁集团沈凋墨：Kubernetes-微内核的分布式操作系统

阿里合伙人范禹：常挂在阿里技术人嘴边的四句土话

阿里技术专家都铎：一文搞懂技术债

支付宝研究员兼OceanBase总架构师杨传辉：我在数据库梦之队的十年成长路

阿里技术专家麒烨：修炼测试基本功

阿里计算平台掌门人贾扬清：我对人工智能方向的一点浅见

蚂蚁资深算法专家周俊：从原理到落地，支付宝如何打造保护隐私的共享智能？

阿里高级技术专家箫逸：如何画好一张架构图？

阿里高级技术专家张建飞：应用架构分离业务逻辑和技术细节之道

蚂蚁科技 Service Mesh 落地实践与挑战 | GIAC 实录

阿里6年，我的技术蜕变之路！

蚂蚁集团涵畅：再启程，Service Mesh 前路虽长，尤可期许

阿里P9专家右军：大话软件质量稳定性

阿里合伙人程立：阿里15年，我撕掉了身上两个标签

阿里高工流生 | 云原生时代的 DevOps 之道

阿里高级技术专家邱小侠：微服务架构的理论基础 - 康威定律

阿里P9专家右军：以终为始的架构设计

阿里P8架构师：淘宝技术架构从1.0到4.0的架构变迁！12页PPT详解

阿里技术：如何画出一张合格的技术架构图？

蚂蚁资深技术专家王旭：开源项目是如何让这个世界更安全的？

阿里资深技术专家崮德：8 个影响我职业生涯的重要技能

阿里儒枭：我看技术人的成长路径

阿里高级技术专家宋意：平凡人在阿里十年的成长之旅

阿里技术专家甘盘：浅谈双十一背后的支付宝LDC架构和其CAP分析

阿里技术专家光锥：亿级长连网关的云原生演进之路

阿里云原生张羽辰：服务发现技术选型那点事儿

蚂蚁研究员玉伯：做一个简单自由有爱的技术人

阿里高级技术专家至简: Service Mesh 在超大规模场景下的落地挑战

阿里巴巴山猎：手把手教你玩转全链路监控

阿里涉江：你真的会学习吗？从结构化思维说起

蚂蚁金服资深技术专家经国：云原生时代微服务的高可用架构设计

   END
#架构师必备#点分享点点赞点在看