国产金融级分布式数据库在金融核心场景的探索与实践

转载赞收藏评论

举报 2022-05-09

扫描,分享朋友圈

金融核心场景分布式数据库发展驱动力

本部分的分享将围绕以下问题展开，即金融行业为什么会产生分布式数据库的需求。回归本源，分布式数据库是基于业务与技术的需求和发展以及监管要求下，解决当下以及未来趋势发展等问题，更优更稳定地满足金融银行业发展的选择。短期看虽有不足，用长远和发展的眼光看，对支撑金融需求、满足监管要求、提升自主可控能力、有效降低风险、合理控制系统建设成本等诸多方面都有助力和支撑作用，是金融银行业基础设施、基础软件建设的重点之一。

具体来看，这主要源于以下三方面的驱动：金融监管政策的指引、金融业务发展要求、金融业系统技术与架构的发展趋势之下衍生的数据库要求。

金融监管政策指引

众所周知，传统老牌的数据库厂商的产品有很深厚的用户基础。要在新兴的分布式数据库领域中去契合金融核心场景的需求，我们仍有很多不足需要改进。在发挥分布式数据库优势的同时，我们需要解决以往在其他领域从未出现过的新问题，同时还要在既有的技术体系并综合历史客观现状之上进行延续，这也是我们当下面临的困难和挑战。

2021 年末，中国人民银行发布了《金融科技发展规划 2022-2025 年》。2022 年初，中国银保监会也发布了《银行业保险业数字化转型指导意见》（以下简称《指导意见》）。该文件将安全视为首要因素，在安全的基础上去实现发展和创新。聚焦到分布式数据库以及金融核心场景、技术领域上，《指导意见》也从多方面提出了明确的要求：

基本原则部分中提到，要“协同推进组织架构、业务模式、数据治理、科技能力等方面的变革”，“推动机制创新，实现业务创新和技术创新相互带动”，“确保网络安全、数据安全”。

科技能力建设部分中提到，要“提高科技架构支撑能力”，“推动传统架构向分布式架构转型，主要业务系统实现平台化、模块化、服务化，逐步形成对分布式架构的自主开发设计和独立升级能力”，要“加快数据库、中间件等通用软件技术服务能力建设，支持大规模企业级技术应用”。

同时还要“优化数据中心布局，构建多中心、多活架构，提高基础设施资源弹性和持续供给能力”，“推进基础设施虚拟化、云化管理，建立对信息科技资源全方位覆盖的统一监控平台”，“提高运维侧研发能力，积极运用大数据加强态势感知、故障预警和故障自愈，不断提高运维智能化水平”。

战略规划与组织流程建设部分中提到，要“注重引进和培养金融、科技、数据复合型人才，重点关注数据治理、架构设计、模型算法、大数据、人工智能、网络安全等专业领域”。

对金融核心场景分布式数据库的发展，中国人民银行、银保监会等行业主管部门在金融监管政策方面给予明确指引，从整体方向上对技术架构、实践、客户交付等方面都进行了全方位的指导。

金融业务发展对技术架构的要求

近年来，银行业在内外部金融环境的快速变化中持续进行转型和发展，从零售转型到互金 / 直销以及多渠道丰富金融产品的兴起，从追求业务多元化到追求场景化创新，基于持续不断的技术发展、业务创新积累下，再到金融数字化转型深入推进，这些对金融系统的技术架构有了更为严格的标准和要求以及诉求。

面对此背景和发展的时代，我们首先要满足高可用，这是银行或金融业对技术架构最基本的要求，在此基础之上要满足交易高频高效、低延迟的金融场景处理要求，再衍生到高吞吐能力。因此，需要首先从性能的角度切入，来考虑如何在实时高频的交易下保证数据吞吐能力和处理能力、统计与分析能力，当单机性能已达到一定瓶颈，这就需要引入分布式、数据切分等概念。在银行业务多元化背景下，数据关联度和复杂度更高，这对数据库的技术架构和应用设计提出了新的挑战，包括数据的模型、主题设计、建模、业务模型关联、数据库适应性、统一的运维管控平台和版本的在线分布等技术业务关键能力。

当前，在场景化创新和数字化转型的趋势下，国际形势以及外部金融环境背景下，安全可控成为不断强调的关键词。在此背景下，要求实现多中心多活的可控性，包括 OLTP、OLAP 场景以及 HTAP 混合场景（金融业务系统 TP、AP 场景混合的系统较多，很难单一划分）。同时在分布式技术架构下，运维成本、运维难度也是一项巨大挑战，那么智能运维就成为必要条件。此外，在保证高性能、高可靠的情况下，还要从架构、开发、设计等角度推动产品做到低风险。

总而言之，在银行业务和需求发展的背景下，技术架构高要求、技术栈多样性专项化、功能细化性、架构复杂度、管理等维度的要求也逐级提高。

金融业系统技术与架构的发展趋势

金融业系统技术架构从广义架构层面经历了三个阶段：

单体架构：计算处理能力有限，但在代码或场景层面融合地比较紧密，高耦合度，运维即使不依赖体系化工具与管理也依然较简单。

集群架构：拥有了一定解耦能力，业务与技术的需求变化响应较单体架构有一定优势，同时也带来了设计、开发、运维的辅助化工具和管理能力，具备一定的自主可控与研发能力。

分布式 / 微服务架构：趋势之下，软件层转向全面自研的道路。引入分布式的技术本质是为解决高吞吐难以支撑的问题，但也引入了新的问题，总体而言要解决两方面的问题：一方面，我们要解决大数据吞吐量下的性能提升。以银行转账中最简单的业务场景为例，实现平均 150 毫秒的响应速度，在大数据量下对数据库自身、SQL 各类场景执行的要求非常高；另一方面，在上述场景的基础上依据业务设计，进行垂直 / 水平的切分以及业务之间数据关系使用和同步，这就需要进行一定的设计取舍。本质而言，就是利用有限的资源，或者说虚拟化、云化后的资源，来保证业务的扩展性和高吞吐能力，自然会产生一定的损耗。如何平衡性能和损耗，这也是我们当前结合业界经验以及技术发展的前瞻性需要解决的问题。

因此，虽然当前的架构做到了松耦合和强扩展性，但对高并发能力以及对金融行业的适应能力反而要求更高。

本文系作者授权数英发表，内容为作者独立观点，不代表数英立场。
转载请在文章开头和结尾显眼处标注：作者、出处和链接。不按规范转载侵权必究。