近些年金融行业IT技术架构更新迭代快，发展迅速，分布式架构已经成为主流，像云平台、大数据、AI、微服务、分布式架构、敏捷前台、统一中台等技术架构的发展很好地契合了金融行业未来业务发展的需求，而数据库作为其中重要环节贯穿了整个前中后端，重要程度越来越高。此外，受复杂多变的国际形势影响，金融行业自主可控越来越迫切，信创工作逐步进入深水区，数据库也成为一项重要基础研究和应用。本文以我行新核心系统采用分布式数据库的探索和落地过程为主线，分析和总结分布式数据库模式在中小银行核心等关键业务系统应用经验，希望对千亿级中小银行分布式数据库的推广落地提供一定借鉴意义。
张家港农村商业银行金融科技总部运维中心主任 卢丽欢
核心系统应用实践
从2018年起，我行一直对分布式数据库进行探索及实践。2018年，我行对中间业务等外围系统先行试用分布式数据库，验证可行性并积累相关经验。2019年8月我行在传统核心系统使用分布式数据库，成为全国首家案例。而后，开展了规模推广和全栈信创环境适配，核心、信贷、渠道、票据等几十套关键业务系统逐步迁移到分布式数据库。同时，2022年我行顺利投产全栈信创分布式数据库集群环境。
(资料图片仅供参考)
我行新一代核心系统项目建设周期一年，于2019年8月18日上线，核心系统硬件设备采用通用服务器，在应用层面采用基于ARM架构的信创服务器，数据库采用分布式数据库作为新核心数据库，运行至今，一直保持较好的稳定性和高效性。
1.总体架构
我行新核心系统分布式数据库采用“两地三中心”部署，根据业务需求将业务数据进行分片，每分片采用“一主三备”模式部署，同步模式采用“同机房异步，异机房强同步”模式，以实现跨机房数据无丢失。
分布式数据库由计算节点层（图中指接入网关）、存储节点层（图中指数据库）和管控节点层（图中指管理组件）组成，计算节点层主要负责应用系统的接入和数据计算，存储节点层主要负责实际数据的存储更新和主从同步，管控节点层负责集群的管控，全局事务的管理，主备切换，故障隔离与恢复，监控和自动化运维相关事宜。
图 张家港农商行核心系统分布式数据库示意图
计算节点层采用多节点、高可用部署，计算节点不存储数据，只进行数据计算和结果返回，所以单节点故障不影响其他计算节点运行。同城两机房计算节点均部署N台（N由具体业务量和计算量确定），同城两机房均可接入业务，同时实现节点级和机房级高可用，确保业务连续性。
存储节点采取“一主多备”模式进行部署，存储节点数量M由业务量确定，同步模式采用“同机房异步，同城异机房强同步”模式，以确保跨机房数据一致性，此外为减少机房间链路抖动对同步的影响，同城异机房设置两个强同步节点并使用两种不同运营商链路。故障恢复方面，当主DB出现故障时，系统具备自动切换到备DB对外恢复业务的能力，通常在20~30秒，时间太短可能造成性能高峰误切，时间太长会导致业务影响时间长，所以在设计时通常考虑RTO≤30S即可。
管控节点是需要三机房部署，我行仲裁节点部署在异地机房，当单机房出现故障时便于进行仲裁，防止出现脑裂情况。
除管控节点外，异地机房还需要部署对应的计算节点和存储节点，与本地数据库实例进行异步同步，应用根据实际情况在异地机房部署。
此外，为了控制实施风险，方案还提供了分布式数据库到传统集中式数据库的多源同步方案，极端情况可快速切换到集中式数据库。目前这个集中式数据库已经完成了使命，不再被使用，现阶段方案制定时也没有必要制定此类兜底后备方案。
2.应用效果
（1）性能方面。我行新核心采用N台计算节点（接入网关）服务器+M台存储节点（数据库）服务器直接承载业务（图1中红线所示业务流），在5000万账户性能测试中，可以实现每节点1500+TPS的极限性能（核心系统整体极限性能主要与DB节点数M有关。例如，当M=4时，我行实测极限性能可达到6000+TPS），并且具备横向可扩展性，通过增加计算和存储节点实现性能和容量的在线扩展。
新核心实际运行指标也一直比较稳定和高效。日常交易高峰时，系统CPU和IO等负载均在3%以下，一直处于轻载状态；高频查询类交易耗时100毫秒左右（查询类交易单次交易应用与数据库之间的交互次数平均在80次左右），高频账务类交易耗时300毫秒左右（账务类交易单次交易应用与数据库之间的交互次数平均在250次左右），业务交易中，应用与数据库之间的一次交互耗时接近1毫秒，较为高效；批处理方面，新核心日终跑批耗时17分钟，每季度结息日存贷款结息付息耗时16分钟，年终结算日年终结算步骤耗时2分钟。
（2）成本方面。以核心为代表的关键业务系统，如果采用传统集中式架构，需要采用高端大机或者小型机，高端存储和存储双活，成本高昂，而分布式数据库方案全部采用通用服务器，因此其成本优势明显，我行根据通用架构对集中式数据库和分布式数据库硬件投入进行了初步测算，采用分布式架构硬件投入可以节省70%甚至更多，后期的维保费用也较低。对于一般业务系统，由于集中式数据库也可以采用通用服务器和中低端存储，因此分布式数据库的硬件成本优势不明显，经过我行测算，两者硬件成本基本相当。此外，数据库软件授权由于商务差别较大，没法做量化对比，但授权费用总体来说分布式数据库相对集中式成本要低。
（3）安全稳定方面。新核心系统上线后，我行进行了灾备机房全量接管演练，模拟中心机房整体故障情况下（比如断电、网络故障等）灾备中心能够接管全量业务继续运行。通过参演人员密切配合，有效沟通，演练全程顺畅有序，所有参演系统做到了无缝平滑切换，切换后系统运行稳定，演练工作圆满完成。我行全量核心业务在灾备机房全量运行了3天后顺利回切中心机房。
（4）自动化运维方面。分布式数据库提供了较为完备的自动化运维平台（运维+诊断），可以完成绝大部分的自动化运维操作，极大提升了运维人员的工作效率。
经验总结分享
通过5年实践，我行分布式数据库应用从无到有、从核心到外围、从部分信创到全栈信创，在关键业务系统的探索和落地过程中不断总结经验，现将相关经验总结如下。
1.选型考虑
分布式数据库的技术优势和成本优势明显，契合未来数字化转型趋势，是现阶段金融行业解决数据库“卡脖子”问题的一个切实可行的可替代方案。
分布式数据库产品处在“百花齐放、百家争鸣”的时期。有基于开源内核的，有纯自研内核的；有计算存储紧耦合，有计算存储分离；有的擅长交易型OLTP，有的擅长分析性OLAP，也有支持混合负载HTAP的等。然而，现阶段很难找到一款产品能够适合所有业务场景，所以选型需要结合具体的业务场景，建议考虑以下因素。
规划先行：选型要契合未来业务发展和数字化转型发展规划，行内未来重点建设的项目，必须能够适配此类数据库。
选择能满足大部分业务场景的数据库，建议选择偏OLTP型数据库，对于OLAP型可以单独选型，也可以选择HTAP型数据库。
落地很重要：这个从0到1的过程意义重大，建议选择关键业务系统，不要选无关紧要的系统；建议优先选取互联网金融类业务（例如聚合支付、手机银行、网上银行、直销银行等），此类系统比较具有代表性，通常都会采用微服务架构，数据层面可以以客户账户维度进行划分，业务场景不算复杂，跑批类需求较少，相对改造的难度可以接受。
银行核心系统改造讲究时机，结合行内情况开展预研和可研，核心系统升级替换优先采用分布式数据库。
除了业务场景考虑外，还要考虑产品和厂商相关因素，如下。
实施案例：数据库产品行业应用情况，是否有银行核心应用案例。
厂商情况：研发团队和产品后续演进计划；实施和运维团队实力，对本项目的资源投入情况。
产品POC测试情况：基本功能指标、ACID、MVCC、高可用容灾、横向扩展性、高并发和并发控制、其他性能指标、与集中式数据库兼容情况、安装部署运维情况、产品手册完善情况等。
成本投入：建设和运维成本投入，后续扩容投入。
信创生态：信创芯片、信创服务器、信创操作系统、信创中间件以及信创负载均衡等信创生态支持情况，数据库厂商信创的资源投入情况等。
监管政策导向和行内决策层的支持起到了非常关键的作用。
2.难点问题分析
（1）分布式数据库与传统集中式数据库兼容问题。分布式数据库与传统集中式数据库存在的语法兼容性的差异，是适配改造过程中工作量最大的部分。一方面需要对字段类型、SQL语句等进行适配改造，另一方面还需要对一些特殊数据库对象（例如存储过程、序列）进行优化改造，全面适配分布式数据库。
（2）分布式数据库数据分布对性能的影响问题。集中式数据库数据集中存放，分布式数据库对外是一个逻辑库，内部数据实际是分节点存放。原本适配集中式数据库的应用架构直接应用到分布式数据库，由于数据分布的差异，无法充分发挥分布式数据库高性能和可扩展的优势，甚至会导致性能不如集中式的情况。
因此，适配时需要充分考虑数据分布对性能的影响，做好数据切片规划，以达到最优性能。首先，在新建表时要充分考虑表容量规划、合理选择表类型和表分区键，尽可能减少表关联和数据节点间数据的横向流动，提升查询效率；其次，对业务SQL语句进行持续优化，通过表关联拆解、结合广播表或者临时表优化关联、增加冗余关联字段作为分区键、业务重构等方式进行持续优化。
（3）分布式数据库一致性问题。正是由于数据的分散存储，相对于集中式数据库实现一致性的先天优势，分布式数据库的一致性实现难度较大，而金融行业对数据一致性的要求是非常高的，因此在适配改造时需要重点考虑和验证一致性的问题。一致性问题从主备一致性、分布式事务一致性，以及全局一致性三个方面进行了全面的论证和验证，我们通过多轮专家论证、性能测试、业务测试以及极限破坏测试等充分验证了分布式数据库一致性的问题，以满足我行核心等关键业务系统一致性需求。
（4）分布式数据库与信创相关适配问题。分布式数据库、信创操作系统、信创芯片（尤其是ARM架构）以及信创服务器之间的适配难度和复杂度较高，每种组件都是“新东西”，把它们组合在一起难免会出现各种层面的“新问题”，再加上各组件更新迭代速度较快（尤其是数据库和操作系统），进一步增加了验证难度，因为这类问题比较难以排查定位，处理的效率也得不到保障，需要行业侧和产业侧共同去推动。尽管适配难度较大，中间也遇到并处理了不少适配问题（例如分布式数据库与信创操作系统适配时磁盘IO资源无法充分使用影响整体性能的问题），但是我行依然积极推动分布式数据库全栈信创化建设，部署大量业务系统进行生成环境验证，积累相关经验，希望能在行业内起到一定借鉴作用。
写在最后
本文介绍了我行分布式数据库在关键核心业务系统的落地方案和经验，尤其是新核心项目充分验证信创分布式数据库在核心系统应用的技术可行性，为中小银行核心交易系统搭建安全可靠的底层数据库提供可行的解决方案，为千亿级中心银行在信创分布式数据库的应用以及全栈应用方面提供经验借鉴，为金融行业重要系统的信创建设提供优秀参考案例。
张家港农商行作为典型千亿级农商行，于2001年正式挂牌，是全国首家由农村信用社改制组建的地方性股份制商业银行。2017年1月正式挂牌上市，成为全国首批上市农商行。2019年在传统核心系统中采用信创分布式数据库，为全国首家。近年来，我行全面深化转型，秉承“让普惠金融触手可及”使命，坚持支农支小，服务实体民生市场定位，走出了一条特色化、专业化、差异化的高质量发展之路，截至2022年末，张家港农商行共有本异地97家机构网点，已开设南通、无锡、苏州3家分行和山东即墨等17家异地支行，发起设立2家控股村镇银行，投资参股吉林长春、安徽休宁等6家农商行，实现了由地方性银行向区域性银行的成功转型，员工人数约2300人。2022年年末，总资产1875.33亿元，总存款1395.84亿元、总贷款1150.28亿元。
