兼顾敏捷交付和系统稳定运行,大型银行平台化落地实践

​对于IT系统,系统安全稳定运行与快速的敏捷交互业务功能,似乎有一些矛盾,互联网公司落地实践证明,技术能力的平台化是应对稳定性和交付效率的有效手段。对于金融行业更加严格的监管要求,平台化落地又具有自身的特点。

本次分享希望从研发的视角看金融科技平台化落地的探索和实践,将通过行业背景、整体策略及思路、落地实践的回顾,总结平台化落地的经验。

一、行业背景

​1、金融监管对系统研发的要求

金融监管对系统研发的要求包含业务要求和技术要求两方面。

兼顾敏捷交付和系统稳定运行,大型银行平台化落地实践

1)业务要求

业务要求对于银行系统来说更多体现为一些功能性的需求,前些年税改费、自贸区等政策引起的相关需求涉及多个核心银行关键系统的变更,如果出错就是账务问题,同时时间紧,要求高,不能有任何的闪失,那么这种需求对于金融机构而言属于最高优先级的刚性需求。

2)技术要求

技术要求较多体现为非功能的需求,如目前正在推进的灾备体系建设、信创要求,这类要求也是必须完成的。

​2、新场景、新技术、国产化带来的挑战

随着金融科技应用的快速发展,目前系统的稳定性也面临新场景、新技术、国产化等诸多变化因素带来的挑战。

兼顾敏捷交付和系统稳定运行,大型银行平台化落地实践

1)新场景

对于当前账户出海、智慧政务、智慧社区等新场景,原先从事银行系统研发的人员相关领域经验不足,在特定场景下可能会出现业务架构设计和系统架构设计带来的一些不确定因素,最终导致业务流程设计、系统扩展性和非功能方面的考虑略显不足。

2)新技术

云计算、云原生、微服务、人工智能、大数据等新技术如何应用到应用场景中?

各技术领域的应用设计模式、最佳实践、底层技术的掌控能力不足,也会给系统的稳定运行和架构设计的合理性带来一些不确定因素。

3)国产化

由于国外技术的受限,国产化技术成为必然的选择,但是国产化技术普遍商用的时间较短,成熟度有待提升,国产化技术的适配性、供应能力也给应用研发带来了一定的挑战。

​3、“平台化”是应对挑战的必然选择

根据国内外互联网公司的实践证明,技术平台化是应对以上挑战的可行之路。百度百科对于通用技术平台的定义提到,平台化能够带来提升效率、降低风险和降低成本多方面的红利。

兼顾敏捷交付和系统稳定运行,大型银行平台化落地实践

大型金融企业一般都有复杂的企业级架构,从我们在日常工作中的实践证明,平台是承载效率、成本、质量的最佳选择,而我们更多关注能力的复用、团队的协作、领域的聚焦、研发框架的统一和技术资产的沉淀,以上都将成为降本增效和平台需要解决的关键性问题。

兼顾敏捷交付和系统稳定运行,大型银行平台化落地实践

基于平台化的思路,也根据我们多年对金融行业应用研发的理解,我们对应用研发支撑能力进行了建模,理清了狭义的框架、平台与应用之间的关系,进一步明确了技术能力建设的方向,框架是承载应用研发和应用逻辑的核心。

应用开发人员使用IDE工具,基于框架编写应用逻辑,与框架共同组成了应用组件的运行版本包。平台主要提供运行版本包的管理功能,例如运营运维的支持,以及支撑应用运行的业务领域和技术领域的通用功能。

二、平台化整体策略及思路

​1、金融企业系统平台化的典型历程

接下来我回顾一下银行在系统平台化建设的路径。

场景的拓展、架构复杂度的提升、应用规模的增加、新技术的引入和数据量的激增都会带来平台功能和形态的演进。从整体的时间线来看,典型银行在系统平台化建设的路径大概分为5个阶段。

兼顾敏捷交付和系统稳定运行,大型银行平台化落地实践

1)2000年之前,由于系统规模不大,更多以单体应用为主,系统内的复用则更多以公共库的方式承载。

2)2000~2011年,随着系统数量的增加,系统间的协作需求也增加,但是此时系统内部的架构是相对异构的,通过应用集成总线实现异构系统的连接,即可满足应用之间衔接的需求。

3)2011~2017年,开始建设新一代核心银行系统,从业务的流程建模、数据建模和产品建模着手,技术上实现了统一的标准规范。应用采用企业级统一的标准框架进行研发,系统内部标准的同构也带来系统间交付的通讯协议报文规范的同构。应用之间的交付也不需要再通过统一的应用集成总线的中心化方式进行连接,我们建立了ESB的服务总线,它是一种服务注册发现的机制,能够实现直接的通讯进而提升效率。同时,因普通的应用研发人员和要求趋同,在应用研发上也实现了人员的互动,提高了效率。

4)2016~2020年,随着金融科技的出现,开始建设面向不同领域如微服务、大数据、人工智能等相关的金融科技平台,这些平台也承载了一些相关领域的通用经验。

5)直到2021年,随着专业领域的平台能力相对比较成熟,以及云原生、服务化、多租户能力的需求,我们开始将各方向的技术能力平台进行拉通,以技术中台的方式统一对外进行供给,降低应用研发人员的门槛,提升研发的效率。

​2、平台化落地的整体思路

平台化落地来自于领导、架构、研发、运维、运营和支持人员的一些相关需求,他们各自有不同的关注点。

兼顾敏捷交付和系统稳定运行,大型银行平台化落地实践

1)从方案入手

在落地的方面,我们更多结合各方的需求,从应用方案入手,拆解出对平台的需求、研发的规范,以保证我们平台落地的成果能够对接上应用研发的需求。

2)问题驱动

平台的落地也是问题的驱动,我们不断挖掘应用研发的痛点,将痛点落地到平台中,提升研发的效率,降低运行的风险。

3)三态合一

所谓三态就是开发态、测试态和运维态。因为金融行业开发和运维需要一定程度的隔离,这种隔离会给敏捷的交互带来一定的影响,所以在平台落地时我们要充分考虑这个特点,再结合运维合规性、稳定性的要求,在平台设计上实现开发态、测试态到运维版本交互流畅的衔接,以提升我们版本交付的效率。

4)流程闭环

所谓闭环更多是谈到类似于运营的一些能力,因为我们前期在平台建设时,更多考虑平台能力的建设,当平台能力相对成熟和完善时,就面临大规模平台能力的推广,那么就需要通过运营的手段,从运营平台上获取相关的运营数据,识别出应用研发的更多痛点,达到持续提升平台能力的目的。

三、金融科技落地实践

​1、驱动平台演进的因素

1)新业态

兼顾敏捷交付和系统稳定运行,大型银行平台化落地实践

从商业银行发展的阶段来看,新业态也是驱动平台演进非常重要的因素。银行从以银行网点为主的1.0状态,到经历电子化和电算化的以网点为主、网上银行为辅的2.0阶段,再经历银行业务移动化,客户在任何时间和地点都能享受到银行服务的3.0阶段。目前银行已经进入4.0阶段,主要特点就是银行的服务已经无处不在,嵌入到千行百业,融入到大众百姓的生活之中,进而导致一些新的需求产生,比如APP的安全和图片存储服务等方面的需求,我们也逐步在平台中丰富和完善这样的能力。

在原先APP和小程序不多的情况下,我们可能通过手机银行等比较集中的渠道,在应用层面即可解决一些安全性、数据埋点分析和文件服务的问题。但是随着APP的增多和小程序的出现,我们希望通过平台化将很多基础能力沉淀到平台中,以提升研发的效率和解决运维的安全问题。

2)企业架构

兼顾敏捷交付和系统稳定运行,大型银行平台化落地实践

企业架构对平台的整体演进也产生了较大的影响。《软件架构模式》一书提到5种软件架构模式,分别是分层架构模式、基于事件的模式、微内核模式、微服务架构,以及基于空间的架构模式。在每一种架构模式上都有一些架构的关键要素,基于架构的治理和可视化方面,平台需要重点考虑这些要素,否则难以较好地承载该架构模式下的架构要素。

典型银行的平台化落地也离不开企业架构视角的变迁。在单体架构的模式下更多的是系统内部的公共库,而像异构的系统集成方面,更多需要提供EAI总线的能力,到了SOA的架构下,需要在平台层面提供统一的服务目录和注册发现的机制。到了微服务的阶段,随着银行系统规模的增大,我们采用一些分布式技术解决高并发大流量的问题,则出现了单元化等概念,单元化也需要在架构治理和可视化方面对架构予以承载。

到了云原生架构阶段,云原生随着容器、PaaS等技术的出现,带来了一些新的解决方案,如POD、Service,在架构层面也按照云化的方式,出现了控制面、数据面等概念,这些都会对平台的落地带来影响,主要体现在以下三方面:

  • 一是应用架构流程、项目协作、系统架构设计变化;
  • 二是架构规范、架构标准固化到框架平台;
  • 三是新架构带来设计、开发、测试、运维等开发过程的影响。

3)云计算技术

兼顾敏捷交付和系统稳定运行,大型银行平台化落地实践

云计算技术也驱动了平台的演进,从开始的云机房到云就绪,再到现在的云原生,云计算关注的重点逐步向应用靠拢,以应用为中心。我们在平台的建设上也重点落地了面向金融体的稳定应用模型、云原生的基础组件,以及针对金融级的稳定性要求,实现了容器网络的部分隔离以及跨机房综合部署的部分能力。随着架构和云计算的演进我们在平台上增强了以上功能。

4)敏捷研发技术

兼顾敏捷交付和系统稳定运行,大型银行平台化落地实践

我们的敏捷研发技术经历了三个阶段:

  • 第一个阶段:2006年左右,我们开始探索引入CI的工具,以解决项目组内部局部的编译打包问题和代码泄露问题。

  • 第二个阶段:基于新一代核心银行数字化转型的要求,我们在企业级项目里更大规模地使用了DevOps等能力。

  • 第三个阶段:随着金融科技战略TOP 1.0和2.0的建设,我们更加大规模地将DevOps等能力从项目级提升到了企业级,以支撑敏捷交付方面的需求。

到去年为止,由于开源技术本身的不可控,我们需要通过平台的设计进行规避。而基于针对开源软件本身,我们也需要通过安全的测试、功能和非功能的完整测试发现开源软件的问题,在平台的设计上进行规避,在使用平台通过开源软件的包装提供的应用时,我们需要同时提供三方面的能力:

  • 一是相关配套的使用规范、配置规范和最佳实践等方面;
  • 二是以PaaS化的方式提供针对开源软件的云化和快速交付;
  • 三是开源软件本身出现问题时,需要提供技术兜底和技术支持方面的能力。

​2、平台应用效果

兼顾敏捷交付和系统稳定运行,大型银行平台化落地实践

在平台应用中,我们也收到了非常好的效果。通过平台供给链我们可以收集到以下数据:典型银行的代码仓库有7000+个,而有1.7万条CI/CD流水线支撑,覆盖1400+个系统等,我们平台的成熟度达到了信通院的优秀级。

四、经验和教训

1)示范应用的总结和寻找

示范应用可以更好地驱动平台的发展。

2)现有流程的衔接

大型企业的流程非常重要,如果与流程衔接不好,会直接影响到平台落地的效果。

3)兼容性的设计

一般金融科技的变迁与互联网相比时间相对较长,因此兼容性的考虑非常重要,它也会直接影响到平台落地的效果。

4)技术的研究和工程化的落地并行

在保证平台的大规模落地和技术的先进性之间可以找到一个好的平衡点。

5)运维能力的设计

对于稳定性方面是必须满足的要求。

6)针对推广知识体系的建设

平台技术的落地从0到1和从1到100有不同的要求。

7)运营体系的建设

可以保证平台持续地提升。

以上就是我们在平台化落地的一些总结,供大家参考。​

文章版权声明

 1 原创文章作者:583566785,如若转载,请注明出处: https://www.52hwl.com/105049.html

 2 温馨提示:软件侵权请联系469472785#qq.com(三天内删除相关链接)资源失效请留言反馈

 3 下载提示:如遇蓝奏云无法访问,请修改lanzous(把s修改成x)

 免责声明:本站为个人博客,所有软件信息均来自网络 修改版软件,加群广告提示为修改者自留,非本站信息,注意鉴别

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2024年1月17日 下午7:42
下一篇 2024年1月17日 下午7:42