近期，在《Oracle等25家巨头断供俄罗斯，国产数据库能不能打？》一文中，dbaplus社群进行了一次国产化进程调研，目前已征集到近800份有效数据。调研结果显示：81%的从业者认为，目前国内对外国IT软硬件的依赖程度高，其中，数据库被选为依赖度高且替代难度大的第二位。对于数据库国产替代的进程，半数从业者认为，目前进度还不超过20%。
《国产化进程调研》数据统计结果
立足当前国内外形势，中国企业在打破国际技术封锁、突破国产化技术瓶颈上迫在眉睫，尤其是IT基础设施中重要一环的数据库，加快国产化步伐，结合云化部署实现自主可控，是时代给予企业和厂商的共同课题。
那么，对于信息安全性要求极高的金融行业，到底需要怎样的数据库？怎么选择和改造最适合自身的数据库？怎么实现国产化自主可控？针对这些痛难点，dbaplus社群采访到了工商银行软件开发中心三级经理-魏亚东、平安银行数据库技术总监-王鹏冲、渤海银行总行科技部高级经理-曹啸三位金融数据库专家，希望通过汇集三位专家的研究成果和实践经验，给金融企业的核心数据库选型、数据库国产化改造等提供借鉴和启发：
Q1金融核心数据库重点专注于哪些方面？
魏亚东
“业务支撑、成本、自主可控、生态都要关注”
去年我在dbaplus社群直播时也说过，金融核心数据库一般关注在四个方面，一是强大的业务支撑能力，像高并发、可扩展、海量数据存储及访问、数据强一致性保证，以及两地三中心高可用性；二是降低使用成本，降低商业产品依赖；三是具备自主可控能力，允许结合金融场景进行适配定制；四是生态要好，要支持自动化的运维能力，毕竟随着大数据时代的蓬勃发展，分布式数据库体量会日益蓬勃发展。
王鹏冲
“具备三高两可一低，还有良好生态”
数据库应具备的核心能力是基础，这是毋庸置疑的。系统架构设计都是围绕数据库进行关键数据的存取访问，一个数据库要满足应用程序对它的最基本要求：事务的ACID、多版本并发控制、SQL优化器等，在此基础上我定义一个高标准的数据库要具备“三高二可一低”：高可用、高性能、高并发、可水平扩展、可维护性、低成本。
-
高可用意味着任何故障场景，均具备自动发现和恢复的能力，这里还包括高可靠的概念，不会因为故障而引起数据丢失或不一致等。
-
高性能也就是低延时，从连接到解析到执行到存取各个环节优化到极致，尤其是在线交易系统的延时指标都是以毫秒计算的。
-
高并发意味着吞吐量，支持数千TPS、数十万QPS是最基本的要求。
-
可水平扩展意味着系统的弹性扩容，而且应该可以支持分布式架构，从单体能力向集群能力的架构变化要很灵活。
-
可维护性更多侧重在运维层面，一个系统的生命周期是从系统上线才真正开始，运维才是它长期的宿命，一个产品再好如果可运维性很差，那也没有价值。这里的可运维性包括运维工具的丰富性、交付体验的便捷性、DBA上手和技术能力的通用性等等。
-
低成本的要求是显而易见的，好的技术架构必须预计到未来长期的投入产出，像最早之前银行使用的大型机成本动则上亿，是不可持续发展的。
在上述核心能力之外，我认为金融核心数据库重点应该放在生态建设上面，只有生态系统形成规模，比如社区、第三方、学校、培训机构等等，还比如在银行业核心系统开发市场比较占据头部的一些公司，如果数据库产品能够跟他们的核心系统的产品设计融合为一整套方案，这未尝不是一个更优的解决方案。
曹啸
“常忽视的非核心方面，更容易带来风险”
这个问题涉及的面就有些广泛了，如果从数据库产品的架构、功能、语法兼容性、高可用性等方面逐一去说，可能三天三夜也罗列不完。换个角度，我们倒是可以思考一些目前数据库产品普遍比较薄弱同时又是金融机构重点关注的问题，例如金融级数据库强烈需要的同城和异地容灾能力。对于金融机构的关键业务系统，同城灾备的RPO=0和RTO尽可能小的监管要求是无法回避的，但这一点又恰恰是很多数据库厂商所忽视的问题。即便有些大厂的数据库产品声称在技术架构上能够满足RPO和RTO的要求，但实际情况则是这些产品或者完全没有经过海量金融关键业务流量的考验，或者在实际场景中需要行方投入巨量的人力物力去弥补产品本身存在的不足。这种问题对于无法投入大量成本的中小型金融机构来讲无疑是极高的风险。
Q2银行等金融机构对于核心系统的改造都非常谨慎，那么金融核心场景要达到什么客观条件才适合上分布式数据库？
魏亚东
“数据处理能力和峰值吞吐量的高要求”
如果核心场景对数据处理能力和峰值吞吐量有很高要求的话，而且存在数量级递增的趋势，原则上就应该上分布式数据库。对工行来说，新上的应用原则上都要求使用类似于MySQL的分布式数据库，特别是主机下平台的改造，大家知道IBM主机处理能力极强，但是X86硬件远远不及，所以模拟主机体系建成分布式体系实际上一直在追赶的路上，但是大家要注意数据一致性保证，一般建议SAGA模式或TCC模式。
王鹏冲
“不是让业务适应分布式，而是要让分布式适应业务”
我认为不是说达到什么条件才上分布式数据库，而是说当现有的业务系统已经、或者预见会遇到一些问题、瓶颈，会阻碍到业务发展，而这些问题又不能通过常规的优化和改造来彻底解决，这个时候不得不考虑现有系统重构，甚至重新设计一套新核心系统，这个时候就是要考虑数据库架构重构的时候。而数据库架构重构，不只有分布式数据库一种手段，例如最近Github升级了他们的核心系统，他们的数据库就没有采用分布式架构，是按照垂直功能拆分的思路来做的，条条大路通罗马。
曹啸
“充分的客观条件还相对苛刻”
这个问题的出发点确实非常谨慎，因为在目前国内各家银行业金融机构在尝试核心系统分布式数据库试用的时候确实没办法做到“万事俱备，只欠东风”，更多的要靠主观的内部驱动力和数万银行IT从业人员的埋头苦干才得以完成。
但如果一定要为分布式数据库的推广普及寻求一个万全的前置条件，我们不妨类比一下上个世纪初代银行系统是如何从无到有引入数据库的？这个答案目前依然存在于各个国有大行的核心系统中。那就是基于IBM z/OS大机体系的一整套银行核心架构，其中包括联机交易处理中间件CICS，批量作业处理产品JCL，为DB2量身打造的开发语言COBOL等等。这个体系中的所有产品无一例外的在方方面面为DB2这个数据库提供了强力支持，也为它能够坚挺在我国金融IT体系中提供了丰厚的土壤。
反观对于现在分布式数据库能够完美适配的各类产品有多少呢？也许真的需要某个数据库厂商能够提供一整套从前端到后端、从联机到批量都涵盖的产品链，才能称得上分布式数据库的充分客观条件吧，但这个要求确实有些苛刻。
Q3银行在选用分布式数据库时，如何解决复杂业务逻辑问题、应用适配度问题、人员能力匹配性问题？
魏亚东
“要从常规使用场景和应用重要程度考虑”
对于银行来说，要按照常规使用场景和应用重要程度来区分，一般会分为OLAP、OLTP、HTAP（新瓶装旧酒，比如Oracle）数据库。对于OLTP数据库来说，对于复杂业务逻辑来说建议放在应用程序中进行解决，数据库只需要满足存取要求即可满足吞吐量要求；关于应用适配度的问题，原则上要根据应用场景选择合适的分布式数据库，一招鲜打遍天下的年代已经过去了，没有最好的数据库，只有最合适的数据库，比如MongoDB、ClickHouse等都是很好的数据库，只是使用场景不一样而已；关于人员能力匹配性问题，必须要通过自动化的门禁去落实管控原则，确保规范可以落地，否则就相当于没有规范。
王鹏冲
“把问题归类后，会发现三种有效思路”
银行的业务类型确实很复杂，系统之间的紧耦合、关联调用更是常态，但是做为底层的数据库服务，其实可以抽象出来，把问题分类后会发现解决思路就那么几种。比如我们目前主要有三个方向的思路：
1、对于单实例容量已经达到瓶颈，无法进行垂直扩容的时候，就要推动研发进行分布式架构改造。比如MySQL我们有些负载高、并发高、容量大的系统会进行分库分表，采用开源的ShardingSphere技术；如果系统改造比较复杂，时间工期又比较紧张的时候，我们会直接把它迁移到一个支持MySQL协议的分布式数据库上。
2、对于核心系统的“去O”或重构场景，我们的思路一向是既然做就做得彻底一些。从最开始就明确项目目标，要去掉对老数据库的特性的依赖，在重构的过程中进行业务流程重塑、微服务拆分、去存储过程上移到应用程序代码等等工作，底层数据库尽量按照某个维度进行切分，把大系统做小，例如我们信用卡新核心系统的单元化架构。
3、对于非核心系统或小系统的架构改造，我们更多会选择一个与老架构兼容性较强的方案，以加速整个过程、降低风险、降低成本。
至于人员能力培养方面，从开发侧其实技术壁垒不高，都是标准的SQL语法，顶多有一些写法上的区别，其实更多是应用程序和驱动的兼容，这个要做到全面的测试用例。从运维侧确实挑战很大，不同的数据库其架构原理、运维操作、问题诊断都有天壤之别，我们目前已经一个人要负责3-4种不同类型的数据库，所以在国产信创、分布式等新的数据库产品引入上我们慎之又慎，既要满足当下业务开发的实际需求，解决当前系统架构的痛点，又要着眼于未来，也就是对当前自动化运维平台已有能力的匹配度、与现有人员的技术栈的兼容度，以及它在行业要有竞争力和发展前景，否则也没有人愿意去学。
曹啸
“单元化思路方案+技术驱动”
关于复杂业务逻辑和应用适配度问题的解决，个人觉得单元化是一个很好的思路，但实现起来并不简单。理想的业务单元化模型确实可以较为良好的适应一些分布式数据库的架构，但问题的关键在于如何抽象出最合理的单元化模型。目前主流的按地域划分单元在实际操作中不适用于大多数银行。所以如果采用业务单元化的方案，根据银行自身数据特点抽象出最佳的单元化模型才是解决问题的根本所在，糟糕的单元化划分将成为分布式数据库的灾难。
对于人员能力匹配这个问题，个人不觉得通过广撒网式的招聘是解决问题的有效办法。在各类技术日新月异的当下，所有人都是技术大潮中的小学生。与其舍近求远，不如从自身解决问题。对银行而言，过去十几甚至几十年积累下来的各领域专家，从能力上来讲其实已经具备匹配的基础，要知道“万变不离其宗”，从多位业内比较理解数据库核心原理的专家视角来看，集中式数据库和分布式数据库本质上是有很多相通之处的，企业需要提供的是一份对技术纯粹的尊重，以技术为驱动，就不存在人员匹配度的差异；对个人而言，应该懂得“学习的终点不是年龄，而是默许自己无法提升的心态”，以谦虚的心态面对不断更新的技术，勇于面对和接受更好的变化，就能够成为银行业所需的人才。
Q4如何看待目前国产数据库百花齐放的态势？作为金融用户该如何做出技术战略选择？
魏亚东
“去粗取精，开源为先”
国产数据库百花齐放实际上是一种好现象，去粗取精，后面逐步归拢到几个大型数据库，全栈国产化未来肯定可以实现，但是这个也是建立在世界开源成果的基础上。
王鹏冲
“百花齐放，需慎重且全面选择”
当前国产数据库行业应该说是进入了一个春天，所以才会百花齐放，这说明有了国产数据库发展的土壤，包括国家政策、行业需求、人才资源等，所谓天时地利人和。金融用户选择国产数据库还是要非常慎重，不但要看重其产品本身的能力，包括功能、性能、兼容、可扩展、高可用等，还要看其软实力，比如研发的持续投入、运维标准体系建立完备度、产品的生态圈丰富程度等。
Q5金融核心数据库接入国产化是否有可参考的落地步骤和技术路线？这当中一直没解决的最大痛点是什么？
魏亚东
“生态尚未健全”
关于国产化落地的步骤和路线，多家数据库厂商其实都有相关落地步骤，但是落地过程中还是需要因材施教，即需要与厂商做深度沟通协调才能成功。首次落地会比较波折，这也体现了国产数据库最大的痛点，就是生态不健全，相当于我买了一个很大气的毛坯房，无法进行装修和安装水电。
王鹏冲
“不少银行有着通用的技术路线”
我们调研过多家国内做核心系统分布式架构改造+国产化的银行案例，几乎都选择了同样的技术路线：
1、应用层通过单元化、分库分表路由来实现分布式架构，不依赖数据库本身的分布式的能力。这样做系统架构更灵活、自主可控，可扩展性更强；
2、分布式事务处理框架基于Saga、TCC等来构建。如果涉及到跨单元的分布式事务，通过RPC接口调用来实现。例如某银行的开户交易涉及5次外调，平均事务响应时间130ms；
3、每个单元（分片）的数据库选型，尽量剥离某类数据库本身的特性，也就是说只把数据库做简单的数据存取、简单查询，复杂的业务逻辑在应用上层实现。这样系统的可移植性更高，后期架构演进业更加灵活，也不容易绑定在某一个数据库厂商品牌上，是真正的自主可控。千万不要从绑定在A上，变成绑定在B上，这是得不偿失的。
Q6企业逐渐进行全栈国产化，有什么相对稳妥的推进方案或建议？
魏亚东
“并行转换策略”
全栈国产化不是一个一蹴而就的过程，为了稳妥起见，原则上建议分批次进行处理，注意此时需要实施并行转换策略，原则上建议三个批次，顺序可以随企业自行定义：
-
硬件和操作系统等底层支撑可纳入一个批次；
-
服务器和数据库等中间件可纳入一个批次；
-
国密算法等应用适配性改造可纳入一个批次。
王鹏冲
“有章可循、稳定为主、循序渐进”
我们的推进路线大致规划是：
-
首先在OA办公系统先开始推动全栈国产化替代；
-
在分布式系统的部分单元的一部分应用服务器，使用国产X86或ARM芯片的服务器以及国产操作系统，灰度逐步推广；
-
对部分开源数据库进行国芯国魂的适配测试，比如MySQL、PG等，并试点到外围非关键系统中。
-
在外围系统的部分数据库直接试点使用国产数据库，并采用国产服务器和操作系统。
总而言之，要有章可循、稳定为主、循序渐进。
同时，针对国产化这一话题，魏亚东老师和王鹏冲老师提出了以下期许，并总结道：
魏亚东
我一直强调技术有国界，国产化以及支持云化部署是一种必然的趋势，我们可以看到资本市场实际上是非常敏感的，国产数据库井喷出数百个，实际上就是一种佐证。但是国产数据库生态始终没有健全，这个实际上是国产化最大的痛点，简单来说，MySQL在sun公司的时候，大家对其前景并不看好，但是随着Oracle的收购，一方面提升了产品质量，一方面参照Oracle数据库完善生态建设，逐步成为业界明星。现在国内很多国产数据库，性能很好，但是没有把生态建起来，后面我理解国产数据库也会将生态做起来，比如现在的国产开源浪潮就是很好的一步棋。
点击下方查看专访视频↓
金融行业核心系统改造，不能只有科技部门来驱动，必须让业务参与进来。通过核心系统的改造契机，进行业务流程的全面梳理、企业建模、系统重构，进而带来更大的价值。
点击下方查看专访视频↓
特别鸣谢
数据库主题干货