对于IT系统来说，安全稳定的系统运行与快速敏捷的交互业务功能之间似乎存在一些矛盾。互联网公司的实施实践证明，技术能力平台化是处理稳定性和交付效率的有效手段。针对金融行业更为严格的监管要求，平台的实施各有特色。本次分享希望从研发的角度来看待金融科技平台落地的探索与实践。通过对行业背景、整体战略与思路、实施实践的回顾，总结平台实施的经验。一、行业背景1、系统开发的金融监管要求系统开发的金融监管要求包括业务要求和技术要求。1）业务需求业务需求更多的体现在对银行系统的一些功能需求上。前几年税费改革、自贸区等政策引发的相关要求涉及多个核心银行关键系统的变更。如果出了问题，就是会计问题，同时时间紧，要求高，不能出错，所以这种需求是金融机构最优先的刚性需求。2）技术需求技术需求主要体现在非功能性需求上，比如目前的灾备系统建设和信创需求，也是必须要完成的。2、新场景、新技术、本土化带来的挑战随着金融科技应用的快速发展，当前系统的稳定性也面临着新场景、新技术、本土化等诸多变化因素带来的挑战。1）新场景针对当前的转账、智慧政务、智慧社区等新场景，原本从事银行系统研发的人员在相关领域经验不足，带来的一些不确定性业务架构设计和系统架构设计可能会出现在特定场景下的因素，最终导致在业务流程设计、系统扩展性、非功能性方面的考虑略有欠缺。2）如何将云计算、云原生、微服务、人工智能、大数据等新技术应用到应用场景中？各技术领域对应用设计模式、最佳实践、底层技术的把控不足，也会给系统的稳定运行和架构设计的合理性带来一定的不确定性。3）本土化由于国外技术的限制，本土化技术成为必然选择，但本土化技术的商业化时间普遍较短，成熟度有待提高。出现了一定的挑战。3、“平台化”是应对挑战的必然选择根据国内外互联网公司的实践，技术平台化是应对上述挑战的可行途径。百度百科对通用技术平台的定义中提到，平台化可以在提高效率、降低风险、降低成本等方面带来红利。大型金融公司通常具有复杂的企业级架构。我们的日常工作证明，该平台是承载效率、成本和质量的最佳选择。我们更加注重能力的复用、团队协作、领域的聚焦，研发框架的统一和技术资产的沉淀，都将成为平台降本增效需要解决的关键问题.基于平台化的思路，基于我们多年在金融行业应用研发的理解，对应用研发支撑能力进行建模，理清了狭义的框架，平台与应用的关系，进一步理清了技术层面能力建设框架是承载应用开发和应用逻辑的核心。应用开发者使用IDE工具基于框架编写应用逻辑，并与框架一起构成应用组件的运行版本包。平台主要提供运行版本包的管理功能，如运维支持，以及支持应用运行的业务和技术领域的通用功能。二、平台化的总体战略和思路1、金融企业系统平台化的典型流程下面回顾一下银行在系统平台建设上的路径。场景的扩展、架构复杂度的增加、应用规模的增加、新技术的引入和数据量的激增，都将带来平台功能和形态的演进。从整体时间轴来看，典型银行的系统平台建设路径大致可分为五个阶段。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）企业架构企业架构对平台的整体演进也产生了较大的影响。《软件架构模式》一书中提到了五种软件架构模式，即分层架构模式、基于事件的模式、微内核模式、微服务架构和基于空间的架构模式。每个架构模型都有架构的一些关键元素。在基于架构的治理和可视化方面，平台需要关注这些元素，否则很难更好地承载这个架构模型的架构元素。典型银行的平台化也离不开企业架构视角的变化。在单体架构模式下，系统内部的公共库较多，在异构系统集成方面，更需要提供EAI总线能力。在SOA架构下，需要在平台层面提供统一的服务目录和注册中心发现机制。在微服务阶段，随着银行系统规模的增大，我们使用一些分布式技术来解决高并发、大流量的问题，出现了单元化等概念。单元化还需要在架构治理和可视化方面加强架构。承载。在云原生架构阶段，随着容器、PaaS等技术的出现，云原生带来了一些新的解决方案，比如POD、Service。在架构层面，控制平面和数据平面已经按照基于云的方法出现。概念，这些都会对平台的实施产生影响，主要体现在以下三个方面：第一，应用架构流程、项目协作、系统架构设计的变化；二是将架构规范和架构标准固化到框架平台中；进行设计、开发、测试、运维等开发流程。3）云计算技术云计算技术也推动了平台的演进。从最初的云机房到云就绪，再到现在的云原生，云计算的重心逐渐向应用靠拢，以应用为中心。在平台建设中，我们还着重实现了金融实体的稳定应用模型、云原生基础组件和金融级的稳定性需求，实现了容器网络的部分隔离和跨机房综合部署的部分能力。随着架构和云计算的演进，我们在平台上增强了上述功能。4）敏捷研发技术我们的敏捷研发技术经历了三个阶段：第一阶段：2006年前后，我们开始探索引入CI工具，解决项目组内部的编译打包问题和代码泄露问题。第二阶段：基于新一代核心银行数字化转型的要求，我们在企业级项目中更大规模地运用了DevOps等能力。第三阶段：随着金融科技战略TOP1.0和2.0的建设，我们将DevOps等能力从项目层面更大规模升级到企业层面，支撑敏捷交付的需求。直到去年，由于开源技术本身的不可控性，我们需要通过平台的设计来规避。基于开源软件本身，我们还需要通过安全测试、功能和非功能完整测试，找出开源软件存在的问题，并在平台的设计中加以规避。在使用平台通过开源软件封装提供的应用时，我们需要同时提供三个方面的能力：第一，相关配套使用规范、配置规范、最佳实践；第二，以PaaS的形式为开源软件提供云化和快速交付；三、开源软件本身的问题到时候需要提供技术后备和技术支持能力。2、平台应用效果在平台应用上，我们也收到了很好的效果。通过平台供应链，我们可以收集到以下数据：一个典型的银行有7000+个代码仓库，17000个CI/CD流水线支撑，覆盖1400+个系统等。我们平台的成熟度达到了研究院的卓越水平。信息与通信技术类。4、经验教训1）总结示范应用，寻找示范应用，可以更好地带动平台的发展。2）将现有流程与大企业的流程对接非常重要。如果与流程衔接不好，会直接影响平台落地的效果。3）兼容性设计与互联网相比，一般金融科技的变化需要较长的时间，因此兼容性的考虑非常重要，直接影响到平台落地的效果。4）技术研究与工程实施并行，可以在保证平台规模化实施与技术进步之间找到很好的平衡点。5）运维能力设计必须满足稳定性要求。6)知识体系建设平台技术从0到1和从1到100的提升有不同的要求。7)操作系统的建设可以保证平台的持续改进。以上是我们登陆平台的一些总结，供大家参考。
