vlambda博客
学习文章列表

农业银行:核心系统分布式架构转型实践

农业银行:核心系统分布式架构转型实践

2017年起,农业银行开始启动核心系统分布式架构转型,按照“积极探索、搭建平台、步入深水”的规划路线,先后搭建起BoEing辅助查询平台、总控、运营、客户信息、产品合约、账务等分布式基础应用,构建了全行统一的客户视图、一体化运营体系、开放的产品合约和实时处理的账务体系,有效地承担了核心系统60%的交易量,为产品应用分布式架构转型积累了必要经验,提供了基础前提。2020年8月,首个分布式示范应用成功投产,标志着第二阶段攻坚任务“搭建平台”工作已顺利完成。
农业银行:核心系统分布式架构转型实践 图1:建设路线
核心系统由集中式紧耦合的架构向着更可控、更高效、更开放的云计算和服务化新格局不断演进,运营成本明显降低,弹性可扩展成为可能,高可用性设计有了更多选择,快速交付成为明显优势,分布式架构成为改变核心系统的巨大驱动力量。
当前,高敏感、高并发的对客结算类产品应用即将开展分布式建设,核心系统转型进入真正的深水区。基础应用在完善自身建设、提供基础支撑的同时,需要适应新形势、建设新能力、满足新需求,以公共基础底座护航深水区建设全过程,为产品快速创新、产品应用快速研发、生产稳定运行贡献力量,让基础应用成为产品应用分布式转型中看得见的赋能引擎。

农业银行:核心系统分布式架构转型实践

做实产品创新的效率工厂

自BoEing投产以来,产品工厂在产品快速创新方面发挥着较大作用,产品的构建仅需要参数配置即可实现,简化了产品研发流程。但产品建模由技术部门主导,应用领域广度不够,运行性能有待提升。分布式架构转型过程中,通过厘清职责流程、统一业务语言、优化架构设计、统一装配入口,完成产品工厂从“可用”到“好用”再到“想用”的转变,使产品工厂切实成为产品装配的效率工厂。
产品建模业务化:以企业级架构转型为契机,把产品建模流程贯通业务和技术,统一业务语言,改变产品建模以技术部门为主导的现状,让产品建模成为需求研制的必备环节,充分发挥产品工厂应有的效果。
运行态分离:目前产品工厂管理态和运行态的数据模型是一致的,这样换取了灵活性和通用性,却牺牲了性能,且不利于上层产品应用对产品工厂的理解。后续应加强与产品应用的融合,使运行态模型设计更接近应用的核心诉求和内在逻辑,根据各应用特点,个性化设计不同运行态产品模型,并将管理态的数据模型自动转化为运行态模型,管理态与运行态充分解耦,同时进一步优化矩阵、利率、佣金模型,让灵活性和高性能叠加态的产品模型成为可能。
农业银行:核心系统分布式架构转型实践

做强应用研发的赋能引擎

作为核心系统可复用的能力平台,基础应用通过组件、平台、服务等形式支撑产品应用快速高效研发、保障应用运行安全。在开放灵活的分布式架构下,对外服务的形式和能力均有很大丰富和提升,对产品应用的赋能作用将更加凸显,需更加专注于对产品应用的价值创造,通过“甩包袱、建体系、重价值、磨平台”,打造更强的应用研发的赋能引擎。
农业银行:核心系统分布式架构转型实践

01


甩包袱:柜面运营解耦 

核心系统的最初只面对柜面渠道,前后台一体化开发,柜面操作与核心系统后台交易基本上一一对应。随着渠道越来越丰富,核心系统向着全渠道服务化的方向演进,以后台交易码为粒度的日志、权限管控,不符合柜员操作粒度,核心系统面向全渠道通用服务的定位与柜面渠道面向人工柜员的特性并不匹配,也不利于柜面渠道运营的精细化管理。柜面运营与核心系统的解耦已势在必行。技术人员需要抓住分布式核心建设的机遇,引导并驱动业务流程优化,甩掉历史包袱,构建清清爽爽的基础服务,为产品应用深度赋能准备条件。
农业银行:核心系统分布式架构转型实践

02


建体系:统一模型体系

目前核心系统中部分应用尚未完成产品化,部分应用仍采用独立设计的合约、账务模型,组件化、参数化程度不够,产品创新效率不高,没有享受到基础应用的可复用能力带来的红利,重复功能的建设和维护带来重复的投入,系统间交互的集成和协作成本高昂,沟通中的概念、系统中的模型、交易中的报文等信息需不断地切换转换,不利于业务的沉淀和持续发展。
分布式架构转型过程中,基础应用将同产品应用一道,推进产品合约账务一体化,并将这套服务能力输出至核心系统外,服务于更广阔的业务领域,让所有的产品应用共享一套模型体系,简化应用逻辑的处理流程,扩展基础应用的复用范围,提升复用价值。
农业银行:核心系统分布式架构转型实践

03


重价值:聚焦价值提升

核心系统的客户信息也已不再是简单的自然属性、社会属性、签约属性等信息的集散中心,而是连接产品和合约的关键桥梁,串联交易流程的纽带,客户组、客户标签已经成为产品设计中的关键因素,客户分级成为产品应用风险控制重要信息。分布式架构下,基于客户特征的差异性定价和差异性服务将会更加广泛,千人千面的客户画像信息运用于产品服务领域将会更加全面深入。
未来伴随着单元化的设计和路由中心的建成,客户ID将伴随着交易流程无处不在,客户维度信息也将更加丰富,洞察客户的能力将更加全面,核心系统“以客户为中心”的价值理念将会更加全面和深刻地体现。
农业银行:核心系统分布式架构转型实践

04


磨平台:专注平台赋能

基础应用除了减少产品应用的重复开发外,可以充分利用分布式架构开放灵活的优势,解决传统集中式核心中面临的诸多难题。通过构建应用服务网关、数据同步平台、全局路由中心等基础平台,全面提升服务治理、容延容错、流量镜像、数据同步、多活灾备等全方位能力,实现传统核心系统中无法涉足的领域。
持续提升应用服务网关的服务治理能力,更加专注于为产品应用提供更有效、更贴合应用需求的灰度分流、流控管理、熔断降级等服务。不仅支持微服务系统内的灰度分流,还支持主机到开放微服务的灰度分流,在为分布式核心版本快速迭代创造条件的同时,也为主机产品应用下移提供了安全平稳优雅切换的机制;提升流控管理手段,不仅支持单节点流控,更专注全局流控,提供交易码、微服务、子系统等多种维度的流控能力;优化熔断机制,按微服务维度配置熔断参数,使熔断粒度更加精准。借助应用服务网关的流量镜像能力,为应用构建与主机平行的分布式验证环境,同时可作为故障注入的混沌工程演练环境。
农业银行:核心系统分布式架构转型实践

做优协同作战的最佳实践

 随着分布式下移应用越来越多,系统间关系越来越复杂,系统的复杂度越来越高,运维对象数量级发生了变化,问题定位难度越来越高,对核心系统运维的自动化、智能化以及运维团队的全栈式专业技能提出了更高的要求。
分布式核心以分布式总控为试点,开展SRE建设。集开发、测试、应用运维保障、基础设施运维、业务应用管理于一体,打破部门职能限制,形成跨部门多兵种协作的SRE柔性团队。聚焦系统可用性和处置有效性的核心目标,按照“平时建设、战时应急、平战结合”的工作机制,以MTBF(平均故障时间间隔,Mean Time Between Failure)和MTTR(平均故障修复时间,Mean Time To Repair)为关键指标,用工程化思维提高MTBF,降低MTTR。通过故障演练、容量评估、应用性能管理、高可用性建设预防故障;通过监控告警治理、全链路监控优化、应用日志规范,提升故障快速发现、快速定位能力;依赖系统的限流、熔断、服务降级提升快速恢复能力。建设符合我行生产运维实际的可监控、可灰度、可验证、可应急、可跟踪的智能运维体系。让系统日常运行时能够看得到、摸得着,异常时听得见、处置得了。
农业银行:核心系统分布式架构转型实践
图2:SRE建设目标
通过SRE建设,要实现三个方面的转变。一是将复杂的IT架构的扩展性、可靠性和可管理性嵌入到软件代码,将安全生产意识融入到应用研发过程。二是把运维过程的自动化流程、一键式操作积淀到工具平台中,助力农业银行一体化运维平台建设。三是通过跨部门协作模式的变革,逐步塑造主动、协作、以用户为中心的文化氛围。
通过在分布式基础应用中试点SRE,形成可复制的生产稳定运行经验,并将SRE的思想推广至分布式架构转型全过程中,为系统安全稳定运行保驾护航。

总结

基础应用是分布式核心的基石和底座。秉持服务产品应用、赋能业务发展的理念打造运行稳定、服务优质的基础应用,共建高质量的分布式核心系统是我们共同的目标。道阻且长,行则将至。时光轮转,核心系统的守护者再一次站在了新一代核心系统初生与绽放的路口,征途漫漫、唯有奋斗,大道不孤、德必有邻。

(来自:我们的开心)