来源:infoQ 作者:田晓旭
2019 年 9 月 12 日,腾讯云官方公布了国产分布式数据库 TDSQL 的一个新案例——张家港农商行。据了解,张家港行新一代核心系统采用了腾讯云 TDSQL 来承载核心业务数据,这是银行传统核心数据库首次实现国产化。
张家港行为什么要迁移核心系统?又是如何选定了国产数据库 TDSQL 的解决方案?整个迁移过程是如何做的? 迁移完成之后,效果如何?张家港行案例对其它银行核心系统改造有哪些借鉴意义?...... 为了搞清楚以上问题,我们独家专访了参与张家港行国产数据库迁移全过程的腾讯云 TDSQL 首席架构师——张文。
行业内通常认为银行的业务分为两部分,传统业务和互联网业务。其中,传统业务指的是和实际卡相关的业务,而互联网业务指的是与实际卡无关的业务,例如电子账户、无卡支付等业务。通常来说,针对这两种业务银行会有两套不同的核心系统,分别为互联网核心和传统核心。互联网核心大多为近几年的新系统,没有太多历史包袱,所以针对于互联网核心的数据库改造相对传统核心无论风险还是难度都小得多,并且在行业内已有成功案例。但是张家港行比较特殊,没有区分互联网核心和传统核心,而是出于业务复杂度和用户规模等等的考虑,把互联网核心放到了传统核心里面。
张文用一句话总结了张家港行的业务特点,那就是一套核心系统支撑了全行的传统业务和互联网业务。
张家港行的系统非常多,我们可以简单的划分为两大部分,核心系统和外围系统。如果把核心系统比作心脏,那么外围系统就是四肢,所有与钱相关的操作都要经过核心系统。核心系统的业务逻辑是最为关键的,因为它与银行核心资产数据是直接相关的,而外围更像是一个渠道,最后都要去核心系统中进行核算和清算,比较典型的外围系统:手机银行、贷款、网银、ATM 等等。
据了解,本次迁移的核心系统的数据量在 TB 级,包括了账户、账目、流水、账单、日志等数据。张家港行系统建设方长亮科技表示其核心系统主要分为两大部分,一个为交易子系统,总共有 70 多个结构,覆盖银行卡、资金管理等等;另一个为会计子系统,主要是资金的交易分离、清算总账。
综上所述,核心系统不仅本身系统结构复杂,且还与各个系统都有联系,因此它的数据库迁移是最复杂、难度最大的。
在迁移之前,张家港行使用的是 Sybase 数据库,从业务系统到数据库的整体架构大概还是十多年前的架构,不可避免地会遇到性能瓶颈问题,尤其是在高峰时段,数据库的吞吐量低,机器负载高,业务响应缓慢,已无法满足当前的用户请求量。在张文看来,性能问题是当时张家港行当时的最大痛点。
在选择数据库时,张家港行有哪些关注点呢?
以上是一些比较重要的关注点,除此之外,还有一些其它考虑事项,例如运营成本、员工培训、上手难易程度等等。
2018 年年初,腾讯云首次接触到了张家港行,当时张家港行的一个缴存水电费的外围系统想要尝试国产分布式数据库,经过若干轮 POC 测试最终选择了 TDSQL。2018 年 8 月左右,张家港行准备对核心系统进行改造,原计划数据库采用国外某商用数据库,但是张家港行科技部考虑到目前已有一个外围系统使用了国产分布式数据库,并且运行期间非常稳定,那么这次核心改造是否也可以考虑分布式数据库?
据张文介绍,“当时张家港行有两个选择,一是集中式数据库,二是分布式数据库。大部分银行在做核心系统升级时都会选择国外集中式的商业数据库,虽然技术掌握在别人手中,但它是国内无数银行普遍使用的数据库,并且国内银行核心系统也没有使用国产分布式数据库的先例。”
在改造时,张家港行做了一个大胆的决定:同时开发两套新核心业务系统,一套基于国外某商用数据库而另外一套则基于 TDSQL,然后进行“内部赛马”,一年之后对两个系统的稳定性、性能进行对比测试,根据测试结果再决定使用哪套。张文表示:“经过整整一年的改造,无论是从性能成本,还是易用性,分布式数据库都表现出明显优势,进而最终新核心系统采用了 TDSQL 分布式数据库,而之前采用集中式数据库的核心系统则保留为灾备系统。”
相信很多人都很好奇张家港行核心系统的整个迁移过程,在采访中,张文讲到:“整个实施过程分为两个阶段,第一个阶段是功能性改造,第二个阶段是性能优化。整个改造过程是从简单到复杂,我们是先从高频交易入手,集中处理与高频交易相关的业务以及子系统,然后是跑批类交易,跑批与高频交易相比,SQL 相对复杂冗余但是占总交易类的比重较低。解决了高频交易其实就已经解决了 99% 的问题,这个过程积累了丰富的调优经验,这些经验再应用到其它业务系统中可以更方便迅速地解决问题。”
当然,从集中式数据库转变到分布式数据库由于数据组织方式的差异,不可避免地带来一系列问题,例如语法差异、性能差异、兼容性问题等。
2019 年 8 月 16 日下午 6 点,张家港行挂牌停业,正式开始进行新核心系统的上线工作。首先进行的是数据库割接,在割接期间完成了原有数据的倒出、TDSQL 数据的倒入以及中间数据的加工校验。48 小时之后,也就是 2019 年 8 月 18 日下午 6 点,整个改造工作结束,新核心系统成功跑在了 TDSQL 数据库上,张家港行正式对外开业。从正式上线至今已有一个多月,在这一个多月的时间里,数据库运行稳定各项指标均正常,即使业务高峰期数据库也维持极低负载。
在性能方面,迁移后的核心系统也有了很大的提升,张文列举了一些性能方面的具体数据指标:
张文表示:“批量业务进行时,数据库负载均保持在 10% 以下,这样的性能完全可以满足张家港行未来五到十年业务发展需求。TDSQL 还能发挥分布式数据库在线横向扩展的优势,如果后续业务发展有需要时,只需加入硬件资源,便能够自动水平扩展化解性能瓶颈。”
在成本方面,张文表示不太方便透露具体的数据,但是他给我们算了一笔账,“张家港行在硬件层面采用传统的 X86 服务器,取代了大型机、小型机。以近期上线核心系统的某商业银行为例,传统的商业数据库都得用大型机、小型机,综合硬件成本大概在 4000 万 -5000 万,系统处理能力大约为 8000 TPS。而张家港行这边的硬件成本不到 1000w,综合降低成本 75% 以上,吞吐量达到了 6200 TPS,并且支持横向扩展。”
张家港行的案例对于其它银行有哪些借鉴意义呢?张文表示:“最重要的一个经验就是先跑通再优化。”具体来说,就是先要跑通兼容性问题,兼容性问题解决后再攻克性能问题,并且从兼容性到性能是一个持续优化的过程,同时也是一个寻找分布式数据库最佳实践的过程。根据 TDSQL 团队的经验,按照从高频交易到批量业务的顺序来解决问题是效率最高的,问题的复杂度会逐步降低。
核心系统与外围系统在重要性、业务逻辑复杂度等方面有很大的差异,因而也决定了其改造难度的不同。从重要性来讲,核心系统是所有系统的心脏,所有和钱有关系的操作都要经过核心核算、清算,因而核心系统出现问题会导致全行业务中断甚至瘫痪;相对来说外围系统一般都只关联一个特定业务,其故障一般不会造成全行业务的瘫痪;从业务逻辑来看,由于外围系统一般只涉及特定的业务对其改造只需考虑对应业务即可,而核心系统是所有系统的中枢,对其改造需要梳理所有和其相关的业务;从兼容性来看,外围系统相对来说新系统居多,没有太多的历史包袱,可以从零开始而不需要考虑太多兼容性问题。而核心系统就没有这么简单,例如张家港行核心从集中式平滑过渡到分布式数据库过程中需要考虑无数兼容性适配问题。
针对银行核心系统的数据库,通常银行的做法是沿用、并存或者替代,目前大部分银行的数据库战略是沿用、并存,而地方性股份制银行可能走得更快一点,在沿用、并存的基础上尝试国产化替代。对此,张文表示:“核心系统是银行业务系统的心脏,而核心系统的数据库就是心脏中的心脏,针对核心系统的数据库进行改造的难度无异于做一次心脏更换手术。在国有自主可控的大背景下,再结合性能、成本考虑,银行试水互联网公司的分布式数据库已经成为一个趋势。全国性股份制银行,相比于地方性股份制银行步子迈得可能稍微慢一些,但是也是为了更稳一些,因为大行相对而言历史包袱更重,迁移工作量和难度更大。当然,我们也看到越来越多的大型银行机构也在积极参与,积极探索核心系统数据库的国产化改造。这是一个循序渐进的过程。”
张家港行核心系统数据库改造案例公开之后,很多行业工作者认为这是个标志性事件。对于标志性,张文是这样理解的:“首先,这个案例证明了在银行核心系统中,长期被国外所垄断商用数据库是可以被替换为国产分布式数据库,并且替换后带来更强劲的性能指标,更低廉的软硬件成本以及更符合中国人操作的用户习惯;其次,对于腾讯云来说,这也是一个具有代表性的案例,未来可能会将该模式复制到其它银行客户中。”
本文系转载,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文系转载,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。