深度|蚂蚁金服分布式金融核心套件:金融核心系统变革助推器

简介: 分布式金融核心套件是蚂蚁金服针对分布式核心系统全新推出的金融科技产品,该套件包含客户、产品、资产平台等多个应用组件,业界首创将融合核心业务能力组件与技术平台于一体,可有效解决金融机构应用研发效能、数据治理和运营、全域风控管理、技术架构升级等问题。

小蚂蚁说:

分布式金融核心套件是蚂蚁金服针对分布式核心系统全新推出的金融科技产品,该套件包含客户、产品、资产平台等多个应用组件,业界首创将融合核心业务能力组件与技术平台于一体,可有效解决金融机构应用研发效能、数据治理和运营、全域风控管理、技术架构升级等问题。


本文是对蚂蚁金服高级技术专家李玄的采访,他全面阐述了对于分布式金融核心套件实践以及思考,一起来看看吧!

  相关阅读:预践数字金融:详解蚂蚁金服分布式金融核心套件


过去,传统金融机构经常会用二八原则来定义客户,优先服务高端企业以及个人业务……

 

过去,传统金融机构通常会依靠传统物理网点的铺设,扩大覆盖面以及客户使用体验……

 

过去,传统金融机构内部的系统经常各自为政,系统之间很难融合统一,信息架构与技术架构往往存在巨大差异,形成无法打通的壁垒那更是司空见惯的事儿……


然而随着数字化进程的逐步推进,客户边界越发模糊,小微客户的价值潜力一路凸显;人人都拿着手机,金融服务的高频化以及移动化让服务与场景结合的越加紧密;再加上数字化对数据的要求早就不再是将其简单做一些记载或者披露,更重要的是“打通”各个环节……

 

当今发生的诸多变化究竟为金融核心系统带来了怎样的挑战?

 

有人总结道,当前金融机构的核心系统已经遇到了很大的瓶颈,如何转型为驱动业务创新的引擎,应该是所有金融机构的痛点之一。

 

客户习惯已然发生变化,业务要求与现有系统能力的差距突出,金融机构迫切希望从传统的信息化转型为数字化。

 


abcb0298e1f298d03bdf658f865253019cb42c23

蚂蚁金服高级技术专家李玄


关于这个问题,蚂蚁金服高级技术专家李玄表示,“经过多年实践,我们总结归纳出下一代金融核心的特征,分别是灵动的应用以及坚实的底盘。其中,灵动的应用不仅仅是功能的可配置等,更多是对高效协作和应用交付的考量;而坚实的底盘更倾向于关注任何人在任何时间、任何场景都能够享受到不间断的、极致、顺滑的服务。”

 

076be76927411a869c5a37da3faa4ccf7fa9ba97


一直以来,核心系统被誉为金融系统这个皇冠上的明珠,解决核心系统的问题,其他周边系统出现的“小毛病”也自然不在话下。回顾蚂蚁金服这十多年来核心系统随着业务和技术不断演变的历程,或许我们能更加深刻的了解到“灵动的应用、坚实的地盘”的内涵。

 

据了解,蚂蚁金融核心系统发展可以大致分为四个阶段,分别为集中式架构、分布式服务化、云支付和云金融,每个阶段都凸显出蚂蚁金服在时代背景下的思考和践行。

 

97ef3a77ecb50b5ad43472748ba3cf79786fb9b2

 

在集中式架构阶段,我们知道,当时的业务场景比较简单直接,都是纯粹的支付服务,提供给集团内部电商平台,单体应用并采用开放的Java生态技术栈,十分契合业务和技术初创期的要求。

 

但很快业务规模增长速度远远超出预期,核心的交易、支付、账务的核心逻辑耦合在一起,势必会造成更高的业务研发迭代成本和不可控的系统风险。

 

这时,互联网技术也在马不停蹄的蓬勃发展,很多新理念纷纷冒出,人们逐渐意识到传统的SOA确实存在很多的问题 ,例如模式和协议太重,难以扩展和维护等。

 

在此背景下,蚂蚁金服从2007年开始落地分布式、服务化和敏捷研发。李玄提到,在当时行业内的企业还没有做过这种尝试的先例。

 

“我们选择从核心系统开始试点,先后完成交易、会员、支付、账务的四大核心领域服务化改造,应用和数据按照领域垂直拆分开来。时间虽然很长但效果明显,自此组织的分工也更加明确,协同更加顺畅。”李玄总结道。

 

大家耳熟能详的快捷支付在这个阶段已经收官,蚂蚁金服也开启和催生了更多样支付场景创新,多种泛资产,例如集分宝、权益卡券、余额宝等层出不穷。

 

随着技术的进步,企业又开始探索云支付的开放体系,系统间层次结构、系统边界和服务粒度更加清晰,将关联紧密的领域沉淀为平台,进而利用通用服务编排进行服务整合,高效屏蔽了业务接入的复杂性。

 

0a27dccab95fd2622bda0acc5e1d1d49da8b5f16


据了解,该阶段伴随着每年双11大促练兵 ,核心应用面临的容量和稳定性挑战逐年成倍增长。核心系统与中间件、运维体系经过打磨历练,逐渐沉淀和集成了不少具有创造性的技术解决方案,并率先完成了金融核心系统去IOE的动作。

 

后来,大家更熟悉的蚂蚁金服出现了。

 

从支付到理财、微贷、银行、保险等领域的百花齐放,从内部多机构之间的协作到金融科技,通过对外业务与技术开放的融合,蚂蚁金服正在着力创造全新的技术底盘构架一体化的金融核心系统,这套核心系统如今承载着整个蚂蚁金服的所有业务,但过程并不是一帆风顺的,其中面临了很多挑战。

 

李玄表示,蚂蚁金服在2007年开始的服务化进程,并不是一蹴而就的。

 

据悉,系统拆分先后持续了3-4年才完成,通过多个服务化和平台化的项目,把最核心的账务,支付,清算系统都推进到一个前所未有的阶段。

 

但哪些先拆,哪些后拆,层次关系上下左右怎么摆放,期间有很多鲜为人知的故事,也经过了大量论证。此外,服务粒度怎么确定?太粗不便于复用和修改,变更和隔离风险难度变大;太细的话,服务管理成本以及整合复杂度变高,服务使用方系统体感不好。

 

“对此,我们先后划分了一级域、二级域,每个架构域都是足够闭环的领域,其中又包含了很多系统和组件,各自明确以服务的形式进行交互、管理数据且协作分工,此时领域驱动设计就已经在内部备受推崇。”他说。

 

那时候,参数和配置驱动很早就成为了蚂蚁金服系统的基本设计原则,至此也诞生了类似资产交换、产品工厂等系统,用来快速组合复用原子能力,为前端业务提供轻量化接入。

 

此外,事前、事中和事后的三层质量保障体系,准实时核对平台、日常巡检平台等平台工具也同时应运而生。进一步确保不同系统之间的信息和数据的核对一致性,日常巡检又能不停巡查出各类业务漏洞和规则错误。

 

当然,如今所见的系统和服务太多。接受了服务化带来的巨大的优势和收益后,确实还要面对很多看似头疼的问题。

 

实践中,蚂蚁金服并没有陷入这些矛盾中,反而主动加快了信息标准建设,以及分布式监控、跟踪和数据总线等工具的配套,而且效率更高 ,秒级就能识别和定位链路中的问题节点,数据的打通和融合也让依赖数据的应用因此而受益。

 

不容忽视的一点,长时间以来,核心系统的非功能性挑战更加凸显,系统容量,容灾,风险,成本在互联网和移动化时代已然成为制约大多数金融机构的难题。


2d78708c644d36c527c32d77e99829eeb27aed08


众所周知,蚂蚁金服在之后的时间里,每年都要花大量的精力来保障核心系统的技术指标提升。

 

核心系统分布式和服务化之后,容量预估、系统管理协作、链路交互模式、资金风险识别和处置,包括资源管理分配回收各方面的复杂度会陡然增加。

 

李玄认为,金融机构要做的不是单个系统或某几个系统的容量评估,而是全链路,关键链路的评估,越真实、越精准,最好是用实际场景来检验。

 

例如,每天不间断的系统压测、修复、再压测、再修复以及总结提炼方法;每个月数次的生产环境通宵容灾演练,失败了总结再来……如此反复,金融核心系统就是这样高强度被“折腾”出来的。


776a9a28dc6d5f0b647889cbd8d31ddce22e32ea


目前为止,其金融核心系统及配套设施的能力沉淀,始终没有什么产品和系统是独立存在的。

 

经过仔细打磨之后,针对分布式核心系统,才有了如今这样一个完备的解决方案,也就是全新推出的金融科技产品“分布式金融核心套件”。

 

蚂蚁金服深知,不同金融机构存在着差异和特色,并不想提供单一的业务模式去生搬硬套,系统也是如此,于是提炼出这样一组分布式金融核心套件。

 

套件整合了金融类应用最核心的业务领域能力,向上提供平台化领域服务、开放式的编程接口来帮助快速构建存贷汇、互金等各类业务产品;同时封装了金融级分布式架构中的技术复杂性,降低分布式转型的学习曲线,提升分布式转型速度。

 

需要注意的是,分布式核心系统不可能是简单使用开源技术的拼凑,也不可能是任何技术拿来就能百分百兼容,即使有些技术产品本身再好,也很难避免两面性,不扬长避短很容易造成负面影响。

 

对此,李玄强调,蚂蚁金服力求寻找一种最佳实践方式,可以将技术优势和行业理解,也包括行业内各方的实践情况一起融合进来。


598d42b7bfed977678ac32cdb1d341b41d4eb1c3


一方面,分布式金融核心套件整合了蚂蚁金服金融级分布式云原生分布式架构以及金融级分布式数据库,保证应用和数据弹性扩展,同时具备高可用和一致性。


另一方面,通过蚂蚁金服自身业务沉淀的“资金核对体系”、“全链路压测”等技术风险防控组件,可以保障分布式架构下的资金安全和技术风险得到有效控制。

 

据介绍,采用分布式金融核心套件后,三地五中心异地多活能力能够有效为业务连续性保驾护航。此外,分布式金融核心套件作为金融核心业务的重要支撑,还拥有众多令人瞩目的特性。 


2533f64f5943b3d4b05365aed1e5d7c83c641385



  • 热点账户智能策略

传统的解决方案,通常是发现热点账户之后,运维人员根据热点账户的属性手工分析并制定解决方案并在业务系统中进行配置,如果下次再发生同样场景时,就可以缓解热点问题。

 

但在分布式金融核心套件中,考虑到移动互联网时代金融业务系统触发热点账户的场景越来越多,发生次数越来越频繁,如果仅仅靠事后的人工反馈流程,显然是不够的,因此分布式金融核心套件首先内置了缓冲记账,汇总记账模式这些基本的系统处理能力。

 

基于这些基本能力,一方面会对系统运行情况进行监测,当发现热点账户现象时,根据既定策略自动选择合适的解决方案并实时生效,快速解决线上问题。

 

另一方面,智能分析决策系统能够根据系统日常的运行状态分析系统运行趋势,分析模型来判断未来可能发生热点问题的账户,进而提前做出预测以及优化配置。

  • 统一资产交换策略

蚂蚁金服认为,金融领域的各类业务,例如支付、结算、存款、贷款等,都是基于不同形态的资产之间的交换动作来完成。

 

例如,在线上或者线下进行消费,假设使用账户余额和红包进行支付,那么在这一行为的背后,就是用户的存款类资产、红包这一权益类资产转换成了商户的存款资产。因此,蚂蚁金服进行提取和抽象,构建了统一的资产交换层。

 

做到向下以统一的接口对接各种资产,提供不同资产间按规则交换的编排引擎,并且封装这个过程中的复杂技术实现;向上提供给各种业务场景统一的资产使用服务。

 

通过统一资产交换,当新的业务场景出现后,可以快速使用已经存在的资产完成业务逻辑;另一方面当一个新的资产形态出现后,一点接入,即可被已有场景所使用,大大提升了业务创新和接入的速度,并同时降低了技术风险。

  • 离在线一体化计息策略

通常来说,客户规模不同,对于计息的能力要求也是有区别的。对于规模不是特别大的客户,分布式金融核心套件可以不依赖于离线计算平台,通过自身的服务调用完成计结息动作。

 

当客户规模很大时,也能够切换到离线计算模式,利用离线计算平台的大规模计算能力进行高效的计结息处理。在分布式金融核心套件中,这样的特性还有很多,例如交易核算分离、多层次账户体系以及灵活的产品工厂等。

 

同时,分布式核心套件,不仅仅是一套应用系统。

 

因为我们知道,仅有核心系统肯定是不够的,如果无法建立包括核心系统以及周边其他系统在内的统一架构标准和信息标准,也就无法真正做到授人以渔,系统协作的问题、数据质量问题、研发运维效能问题甚至是未来系统升级治理问题仍然还是会存在。

 

“因此,我们不仅仅输出应用系统本身,我们也会利用自己的实践经验输出对行业系统建设规划的理解,包括在实践过程中积累的应用迁移经验、架构设计标准、微服务拆分原则以及信息标准等,我们乐意与业内技术合作伙伴一起联合打造百花齐放、有竞争力的完整解决方案,更希望可以带给技术合作伙伴和金融机构促成各方能力升级与技术转型的机遇。” 李玄说。

 


— END —










相关文章
|
14天前
|
存储 运维 负载均衡
构建高可用性GraphRAG系统:分布式部署与容错机制
【10月更文挑战第28天】作为一名数据科学家和系统架构师,我在构建和维护大规模分布式系统方面有着丰富的经验。最近,我负责了一个基于GraphRAG(Graph Retrieval-Augmented Generation)模型的项目,该模型用于构建一个高可用性的问答系统。在这个过程中,我深刻体会到分布式部署和容错机制的重要性。本文将详细介绍如何在生产环境中构建一个高可用性的GraphRAG系统,包括分布式部署方案、负载均衡、故障检测与恢复机制等方面的内容。
68 4
构建高可用性GraphRAG系统:分布式部署与容错机制
|
1月前
|
消息中间件 中间件 数据库
NServiceBus:打造企业级服务总线的利器——深度解析这一面向消息中间件如何革新分布式应用开发与提升系统可靠性
【10月更文挑战第9天】NServiceBus 是一个面向消息的中间件,专为构建分布式应用程序设计,特别适用于企业级服务总线(ESB)。它通过消息队列实现服务间的解耦,提高系统的可扩展性和容错性。在 .NET 生态中,NServiceBus 提供了强大的功能,支持多种传输方式如 RabbitMQ 和 Azure Service Bus。通过异步消息传递模式,各组件可以独立运作,即使某部分出现故障也不会影响整体系统。 示例代码展示了如何使用 NServiceBus 发送和接收消息,简化了系统的设计和维护。
46 3
|
1月前
|
存储 开发框架 .NET
C#语言如何搭建分布式文件存储系统
C#语言如何搭建分布式文件存储系统
69 2
|
29天前
|
消息中间件 存储 监控
消息队列系统中的确认机制在分布式系统中如何实现?
消息队列系统中的确认机制在分布式系统中如何实现?
|
1月前
|
存储 分布式计算 监控
C# 创建一个分布式文件存储系统需要怎么设计??
C# 创建一个分布式文件存储系统需要怎么设计??
33 0
|
1月前
|
NoSQL Java Redis
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
Redis分布式锁在高并发场景下是重要的技术手段,但其实现过程中常遇到五大深坑:**原子性问题**、**连接耗尽问题**、**锁过期问题**、**锁失效问题**以及**锁分段问题**。这些问题不仅影响系统的稳定性和性能,还可能导致数据不一致。尼恩在实际项目中总结了这些坑,并提供了详细的解决方案,包括使用Lua脚本保证原子性、设置合理的锁过期时间和使用看门狗机制、以及通过锁分段提升性能。这些经验和技巧对面试和实际开发都有很大帮助,值得深入学习和实践。
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
|
3月前
|
NoSQL Redis
基于Redis的高可用分布式锁——RedLock
这篇文章介绍了基于Redis的高可用分布式锁RedLock的概念、工作流程、获取和释放锁的方法,以及RedLock相比单机锁在高可用性上的优势,同时指出了其在某些特殊场景下的不足,并提到了ZooKeeper作为另一种实现分布式锁的方案。
110 2
基于Redis的高可用分布式锁——RedLock
|
3月前
|
缓存 NoSQL Java
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
这篇文章是关于如何在SpringBoot应用中整合Redis并处理分布式场景下的缓存问题,包括缓存穿透、缓存雪崩和缓存击穿。文章详细讨论了在分布式情况下如何添加分布式锁来解决缓存击穿问题,提供了加锁和解锁的实现过程,并展示了使用JMeter进行压力测试来验证锁机制有效性的方法。
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
|
7天前
|
NoSQL Redis
Redis分布式锁如何实现 ?
Redis分布式锁通过SETNX指令实现,确保仅在键不存在时设置值。此机制用于控制多个线程对共享资源的访问,避免并发冲突。然而,实际应用中需解决死锁、锁超时、归一化、可重入及阻塞等问题,以确保系统的稳定性和可靠性。解决方案包括设置锁超时、引入Watch Dog机制、使用ThreadLocal绑定加解锁操作、实现计数器支持可重入锁以及采用自旋锁思想处理阻塞请求。
40 16
|
1月前
|
缓存 NoSQL Java
大数据-50 Redis 分布式锁 乐观锁 Watch SETNX Lua Redisson分布式锁 Java实现分布式锁
大数据-50 Redis 分布式锁 乐观锁 Watch SETNX Lua Redisson分布式锁 Java实现分布式锁
59 3
大数据-50 Redis 分布式锁 乐观锁 Watch SETNX Lua Redisson分布式锁 Java实现分布式锁

热门文章

最新文章