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

互联网金融时代下，金融产品和服务模式不断创新，金融零碎容量需要急剧增长，为进一步满足运维规范晋升工作的需要，晋升服务连续性程度。中国工商银行（后简称工行）从 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 架构转型的继续推动，工行将继续构建以主机和平台双核心的金融信息系统，保障金融服务的稳固运行，撑持高频业务快速增长。以“开放性、高容量、易扩大、老本可控、平安稳固、便捷研发”为建设理念，在分布式全链路灰度公布畛域踊跃推动技术创新、管控降级，笼罩银行外围交易链路场景，继续欠缺全链路灰度公布模式，缩小利用接入老本，晋升全链路灰度公布中各组件兼容适配能力，以适应简单的分布式金融交易场景，为智慧银行建设提供无力撑持。