作者 | 贾瓅园
金融行业作为国民经济的命脉和枢纽，对数据库有着极为严苛的要求。近年来，国产金融级分布式数据库迈上了发展的快车道，在多个领域不断取得新突破。
哪些因素在驱动和促进金融核心场景分布式数据库发展？分布式数据库在金融领域会遭遇哪些挑战与痛点？如何支撑、解决金融场景架构转型需求并以延续性发展的思路进行思考、探索与实践？今天为大家带来腾讯云金融行业架构专家贾瓅园老师在金融级架构方面的分享，主题为“国产金融级分布式数据库在金融核心场景的探索实践”。以下是分享实录：
1 金融核心场景分布式数据库发展驱动力
本部分的分享将围绕以下问题展开，即金融行业为什么会产生分布式数据库的需求。回归本源，分布式数据库是基于业务与技术的需求和发展以及监管要求下，解决当下以及未来趋势发展等问题，更优更稳定地满足金融银行业发展的选择。短期看虽有不足，用长远和发展的眼光看，对支撑金融需求、满足监管要求、提升自主可控能力、有效降低风险、合理控制系统建设成本等诸多方面都有助力和支撑作用，是金融银行业基础设施、基础软件建设的重点之一。
具体来看，这主要源于以下三方面的驱动：金融监管政策的指引、金融业务发展要求、金融业系统技术与架构的发展趋势之下衍生的数据库要求。
金融监管政策指引
众所周知，传统老牌的数据库厂商的产品有很深厚的用户基础。要在新兴的分布式数据库领域中去契合金融核心场景的需求，我们仍有很多不足需要改进。在发挥分布式数据库优势的同时，我们需要解决以往在其他领域从未出现过的新问题，同时还要在既有的技术体系并综合历史客观现状之上进行延续，这也是我们当下面临的困难和挑战。
2021 年末，中国人民银行发布了《金融科技发展规划 2022-2025 年》。2022 年初，中国银保监会也发布了《银行业保险业数字化转型指导意见》（以下简称《指导意见》）。该文件将安全视为首要因素，在安全的基础上去实现发展和创新。聚焦到分布式数据库以及金融核心场景、技术领域上，《指导意见》也从多方面提出了明确的要求：
- 基本原则部分中提到，要“协同推进组织架构、业务模式、数据治理、科技能力等方面的变革”，“推动机制创新，实现业务创新和技术创新相互带动”，“确保网络安全、数据安全”。
- 科技能力建设部分中提到，要“提高科技架构支撑能力”，“推动传统架构向分布式架构转型，主要业务系统实现平台化、模块化、服务化，逐步形成对分布式架构的自主开发设计和独立升级能力”，要“加快数据库、中间件等通用软件技术服务能力建设，支持大规模企业级技术应用”。
- 同时还要“优化数据中心布局，构建多中心、多活架构，提高基础设施资源弹性和持续供给能力”，“推进基础设施虚拟化、云化管理，建立对信息科技资源全方位覆盖的统一监控平台”，“提高运维侧研发能力，积极运用大数据加强态势感知、故障预警和故障自愈，不断提高运维智能化水平”。
- 战略规划与组织流程建设部分中提到，要“注重引进和培养金融、科技、数据复合型人才，重点关注数据治理、架构设计、模型算法、大数据、人工智能、网络安全等专业领域”。
对金融核心场景分布式数据库的发展，中国人民银行、银保监会等行业主管部门在金融监管政策方面给予明确指引，从整体方向上对技术架构、实践、客户交付等方面都进行了全方位的指导。
金融业务发展对技术架构的要求
近年来，银行业在内外部金融环境的快速变化中持续进行转型和发展，从零售转型到互金 / 直销以及多渠道丰富金融产品的兴起，从追求业务多元化到追求场景化创新，基于持续不断的技术发展、业务创新积累下，再到金融数字化转型深入推进，这些对金融系统的技术架构有了更为严格的标准和要求以及诉求。
面对此背景和发展的时代，我们首先要满足高可用，这是银行或金融业对技术架构最基本的要求，在此基础之上要满足交易高频高效、低延迟的金融场景处理要求，再衍生到高吞吐能力。因此，需要首先从性能的角度切入，来考虑如何在实时高频的交易下保证数据吞吐能力和处理能力、统计与分析能力，当单机性能已达到一定瓶颈，这就需要引入分布式、数据切分等概念。在银行业务多元化背景下，数据关联度和复杂度更高，这对数据库的技术架构和应用设计提出了新的挑战，包括数据的模型、主题设计、建模、业务模型关联、数据库适应性、统一的运维管控平台和版本的在线分布等技术业务关键能力。
当前，在场景化创新和数字化转型的趋势下，国际形势以及外部金融环境背景下，安全可控成为不断强调的关键词。在此背景下，要求实现多中心多活的可控性，包括 OLTP、OLAP 场景以及 HTAP 混合场景（金融业务系统 TP、AP 场景混合的系统较多，很难单一划分）。同时在分布式技术架构下，运维成本、运维难度也是一项巨大挑战，那么智能运维就成为必要条件。此外，在保证高性能、高可靠的情况下，还要从架构、开发、设计等角度推动产品做到低风险。
总而言之，在银行业务和需求发展的背景下，技术架构高要求、技术栈多样性专项化、功能细化性、架构复杂度、管理等维度的要求也逐级提高。
金融业系统技术与架构的发展趋势
金融业系统技术架构从广义架构层面经历了三个阶段：
- 单体架构：计算处理能力有限，但在代码或场景层面融合地比较紧密，高耦合度，运维即使不依赖体系化工具与管理也依然较简单。
- 集群架构：拥有了一定解耦能力，业务与技术的需求变化响应较单体架构有一定优势，同时也带来了设计、开发、运维的辅助化工具和管理能力，具备一定的自主可控与研发能力。
- 分布式 / 微服务架构：趋势之下，软件层转向全面自研的道路。引入分布式的技术本质是为解决高吞吐难以支撑的问题，但也引入了新的问题，总体而言要解决两方面的问题：一方面，我们要解决大数据吞吐量下的性能提升。以银行转账中最简单的业务场景为例，实现平均 150 毫秒的响应速度，在大数据量下对数据库自身、SQL 各类场景执行的要求非常高；另一方面，在上述场景的基础上依据业务设计，进行垂直 / 水平的切分以及业务之间数据关系使用和同步，这就需要进行一定的设计取舍。本质而言，就是利用有限的资源，或者说虚拟化、云化后的资源，来保证业务的扩展性和高吞吐能力，自然会产生一定的损耗。如何平衡性能和损耗，这也是我们当前结合业界经验以及技术发展的前瞻性需要解决的问题。
因此，虽然当前的架构做到了松耦合和强扩展性，但对高并发能力以及对金融行业的适应能力反而要求更高。
2 分布式数据库在金融领域的挑战与痛点
前述内容中，我们介绍了趋动和促进金融核心场景分布式数据库发展的因素，实际上是从衍生需求或痛点问题角度，提供了技术架构发展的思路方向。在当前的金融监管政策及数字化转型背景下，结合金融发展历史，我们如何走出金融创新之路、走好数字化转型之路，以及走稳金融安全可控、自主可控、风险可控之路，这些都需要我们深入金融核心场景，切实去解决分布式数据库在金融领域的挑战与痛点。
金融架构领域
与以往系统建设不同的是，在满足“四高两低”要求的同时，还要满足“开放技术架构”原则。既要满足常规监管要求，同时又要与业务系统既有使用规则相匹配。这主要是受历史因素的影响，传统主流数据库的用法、特点深入各行各业，业务系统建设时自然也围绕其特点进行设计与实现。因此，在建设分布式数据库时就需要兼容业务系统既有使用规则，降低使用成本。此外，我们还需要兼容自主可控的软硬件环境。
具体而言，分布式数据库在金融架构领域遇到的挑战可分为以下五点：
- 设计与规划能力：我们不能像以往一样做单纯的工具化数据库，而是应该更贴合于业务场景，进行抽象化通用化，让金融客户更方便地使用，这就需要具备设计规划能力，令数据库产品在建设实施与研发中不断循环打磨；
- 扩展能力：需要具备金融级横纵向扩展能力；
- 性能与稳定性：为了提升数据库性能，我们会进行分片操作，同时也需要划分场景来保证事务的稳定性；
- 高可用能力：这是必须具备的能力，具体包括多活（数据）、多中心（架构）、故障切换（低延迟、高稳定）等。
- 软硬件兼容要求：包括国产芯片、操作系统等自主可控的软硬件，以及虚拟化、云化资源等。
金融业务领域
除了遇到架构方面的挑战，分布式数据库在金融领域落地还需要解决金融业务领域的难点，这是以往常常被我们忽视掉的部分。
一是业务系统兼容方面，当前大部分业务系统已经趋于基本的解耦化或分布式 / 微服务化。在框架之上，驱动能否兼容、语法能否兼容，在无法让所有业务系统重构的前提下，兼容性是我们必须考虑的方面。
二是迁移、同步方面，以异构库之间的迁移为例，我们不能仅仅停留在工具化层面。客户在业务系统切换阶段、场景同步阶段当中也会出现很多需求，基于数据分布式场景，并不能像以往一样单纯由系统开发厂商、银行 IT 编写程序工具解决，这就需要我们的数据库提供整体解决方案。
三是运维体系方面，过去我们已经习惯了传统数据库的命令行操作。但当下面对分布式体系下的管理要求，面对众多数据节点、参数等，我们更多的还是需要一体化可视化工具来完成，例如运维平台、黑屏命令工具、监控工具等一体化运维解决方案与运维系统。
四是服务与实施方面，传统数据库阶段，我们提供的是“来料加工型”服务，即问题支持模式，此模式是建立在长期的技术共识与生态之上。在分布式数据库阶段，分布式领域的业务复杂度、技术复杂度、设计复杂度以及金融核心场景，都对人员、服务、交付实施提出了更高的要求。要探索出一条既不同于金融厂商又区别于传统的数据库厂商的服务实施路线。
五是生态建设方面。以常规数据库为例，很多技术人员都很熟悉，应用得心应手。但面对新的生态，技术人员要如何去使用、遇到问题如何排查找寻方案，生态合作中的软硬件如何研发、如何满足自主可控要求，这些都需要通过生态建设来解决。具体来说，生态建设包括了知识体系、社区、认证、培训、生态合作等维度。
总而言之，分布式数据库金融领域落地不仅仅是技术与产品力的考验，也是在考验我们对金融场景、金融运转体系的理解能力，以及考验我们的设计能力、服务能力。
3 金融级分布式数据库架构探索
根据上述分析与要求，结合分布式数据库在金融领域的挑战与痛点，我们在金融级分布式架构体系方面进行了探索。
我们认为，架构体系首先要满足监管合规要求，实现安全自主可控，同时要契合金融核心特点，最为关键的是我们纳入了开发和可视化智能化运维，从整体上为运维、开发提供友好的可视化帮助，结合金融场景的复杂度和多样化，提出建立多种内核引擎的思路，包括统一管理台、多内核引擎、基础环境底座、统一管控、开发和诊断。
全方位的架构，满足解决当下及未来金融级交付与服务等问题：
- 满足合规要求，符合金融级“四高两低”原则；
- 多内核，兼容金融业务系统 OLTP 及 OLAP 场景、存量系统、业务场景；
- 探索与实践自主安全可控路线；
- 贴近开发，解决“开发不规范、调优困难”等问题；
- 融入金融业运维模式，解决“诊断难、维护难、时效长”的问题；
- 不单一绑定某一技术形态，采用兼容通用协议的技术形态，兼容多种形式的部署架构和底座。
业务系统兼容探索
在金融行业中，分布式场景和模块 / 系统会带来更高的复杂度，且每家银行的建设背景、历史遗留问题、系统划分维度也不同，任何数据库产品，应用在不同的业务系统时都可能会遇到相关的问题。
我们将金融行业的系统兼容关注进行分类，例如渠道域、管理域、产品域，相关业务都有各自的特点、各自的技术诉求及建设思路。因此要按照不同类型、不同维度进行兼容适配，并考虑系统业务与当前架构现状。关注的维度与特点如下图所示：
从语法兼容的角度来看，主要关注数据结构、基础数据类型、对象使用、SQL 执行对象、数据库驱动等方面。我们利用工具化手段去分析当前存在的历史问题，来保证实现快速兼容适配。
从系统简单的分类来看待兼容性，渠道域、前置域、产品域和管理域等都有不同的特点：
- 渠道域：数据结构相对简单、高频、执行消耗低、响应时间短；
- 产品域：数据结构与 SQL 最为复杂、高低频、执行消耗高、数据量大，OLTP 场景多，OLAP 兼具（数据适当解耦、针对性优化）；
- 前置 / 服务整合域：数据结构复杂度相对中等，多表关联、子查询、级联查询、高频、执行消耗低、响应时间短；
- 管理决策域：PISA、1104、T 1 等，依赖上游系统供数，时效要求低，OLAP 偏多。
聚焦到核心业务系统上，数据结构复杂性，索引、查询相关的业务量以及相关用法，甚至部分不规范的函数可能都是关注的点，也是适配兼容过程中的难点与重点，需要针对性地进行分析与优化，也包括配合行业客户、开发厂商进行数据模型分析、解耦等工作。
数据迁移与同步的兼容与实践
数据迁移（静态）通常应用在金融领域系统投产、演练过程、并行期等，不局限于源到目标的导入导出，更多要考虑数据结构的变化、异构的差异、业务系统及金融机构实施步骤与模式，因此金融级分布式数据库所提供的工具、方法论以及解决方案成为了必要因素；其基于场景大体划分有三类：
- 异构业务系统迁移场景：业务逻辑复杂、数据业务关联度高，适合用定制化的业务数据迁移程序及方案进行数据迁移；
- 异构对抽迁移场景：业务逻辑关联少、数据量大、增量 / 全量数据迁移，适合用数据库提供异构库迁移工具进行数据迁移；
- 业务迁移与异构库结合场景：兼具上述两种场景特点，适合采用组合定制化业务迁移方案，辅助数据库异构库迁移工具相配合，以满足金融级技术、业务、实施、管理要求。
未来，提供类似于 SaaS 的接口型服务、以抽象化、工具化、底座化完全融入到业务迁移场景也将成为客观发展中的必然需求，提供系统开发厂商和金融 IT 服务，也避免了“重复造轮子”的情况。
数据迁移（静态）场景外，金融行业具有贴源数据同步场景，此类应用场景也是是当下传统数据库、国产分布式数据库百家争鸣背景下的必然。具体而言，可概括为：
- 金融交易数据向日终批处理 / 账务核算 / 数仓库同步场景：在准实时业务场景中，提供基础数据服务无侵入形式实现数据级同步，配合业务系统实现准实时分录、数仓 / 数据湖、核算等相关数据场景同步。数据库本质的架构特性，可提供可靠的同步逻辑，避免业务系统为数据一致、准确性而耗费大量资源；
- 金融在线数据向近线库同步场景：配合业务场景，可将相关交易历史信息同步至历史近线库，减轻联机业务库数据访问压力和数据增长压力。
- 异构库的备份同步场景：常出现在分布式服务跨异构场景以及异构备份库兜底场景，实现异构的数据服务基础以及切换基础。
以上是我们腾讯云研发与交付团队在实践中进行的技术探索与总结。我们希望在金融级的交付与服务中保障客户的安全风险可控，同时我们也为众多的金融领域 IT 厂商提供相应的工具，令业务系统的建设可以更专注于业务本体。
运维架构探索与实践
在运维模式方面，金融级数据库运维从长期发展的角度看，先后经历字符界面运维、图形化运维以及未来智能化运维三个阶段：
- 字符界面运维阶段：实现基础的数据库运维操作，人工管理流程复杂，且过度依赖人员能力，对 DBA 个人能力的要求高，本质上属于被动式运维。
- 图形化运维阶段：图形化操作学习成本与误操作降低，降低 DBA 日常运维工作强度，实现统一监控、告警、消息推送，数据库问题辅助分析及自助巡检、一站式备份 / 恢复、版本升级及扩缩容。其特点是工具化、容错风险低、管理成本低，此阶段也是当前我们所采用的成熟模式；
- 智能化运维阶段：实现全可视化、运行异常感知、异常 / 问题智能化根因分析、智能切换及避障联动、告警指标智能收敛、无人化运维。其特点是主动风险预警、主动探测及提前预警，将运维风险、缺陷开发修复调整为原有被动问题趋动转化为主动需求趋动，降低不可预见性风险以及突发风险管控难度，为未来融入 DBASS 奠定基础，这也是我们当前研发与前瞻探索努力的方向。
未来，我们要走智能化运维的道路，实现全可视化和运行异常感知，帮助和服务金融领域客户运维工作，同时推动安全可控体系更加完善。
探索实践新的实施与服务模式
传统的数据库厂商的实施模式属于“来料加工型”，即问题型支持和“关键节点”保障型。其服务团队构成基本上以 DBA 为主，服务模式多是 1V1 甚至 1V 多为主。这源于其系统的成熟稳定性与技术的共识性，大多数技术人员都对传统数据库有一定了解，在实施过程中自然会规避部分常见的问题。
金融软件厂商则是需求差异化路线，主要原因在于每家金融机构基本业务相同但需求、业务场景、服务模式不同，甚至业务结构都不同，导致系统需要进行差异化定制。团队构成方面配置了众多专业分工不同的角色，包括技术架构、DBA、业务专家、项目管理和开发等，提供团队 1V1 的全周期服务。
在当前的分布式数据库实践中，我们走的路线看似与传统数据库厂商比较类似，但实际上我们的路线是兼容并济，即“增强一步、递进一步、两个兼顾”。
- “增强一步”是指相比传统数据库厂商而言，我们在服务方面增强一步，区别于“来料加工”型，为客户的业务系统建设提供周期性服务，提前感知风险与系统建设融合。
- “递进一步”是指相比以往的传统数据库而言，向金融 IT 厂商服务模式学习，在数据库的规划和建设上向前递进一步。
因此，我们探索的实践道路主要包含：
- 首先是帮助金融行业客户融入分布式特性的数据库架构，帮助客户更好地理解与运用；
- 其次是跟进系统建设；
- 再者是兼顾兼容业务系统特点，我们在设计之初就考虑到业务系统的特点，如聚合、路由、数据切分、业务模式和业务吞吐量的设计；
- 行业架构师、数据库架构师及 DBA 三种角色共同协作，配合金融 IT 厂商与金融客户完成系统建设；
兼容并济的实施路线，既兼顾了数据库以往的交付与服务模式，同时也兼顾了成本和金融行业特点、服务诉求。
生态建设的探索与实践
目前分布式数据库在行业内已经实现了一定程度的认知和普及，高校、合作机构、金融同业、金融客户等群体都对分布式数据库有所了解。但在终端使用层面，分布式数据库的知识普及度和技术共识度还远远落后于传统数据库。
我们在长期的实践中探索出一条生态建设的路线，主要包括以下方面：
- 丰富知识体系，分布式数据库领域的众多厂商，需要去丰富金融实践体系，对系统兼容性经验进行归纳整理，也同时包括系统运维、调优体系等内容。
- 增强社区广度和深度，通过碎片化问题解决摘录、学习笔记、短视频、技术论坛、自媒体等形式，吸引更多有潜力的人才加入到行业中来。
- 深入生态合作，推动学术研究机构、信创基础软硬件厂商、金融软件同业、金融客户之间的深度合作，共同推进相关技术标准的制定，甚至是研发体系、产品体系的升级。
- 认证、培训，加强人才培养和人才储备，通过认证培训提高共识感，为未来金融领域的分布式数据库提供丰富的储备与发展创新。
建设模式探索与实践
金融领域核心业务系统分布式数据库的建设模式大体可以分为两种模式，即关键系统 / 模块下移模式、业务系统升级 / 建设模式。
第一类模式（关键系统 / 模块下移），下移的过程可以划分为多个阶段来实施，其优点是低成本、低风险、循序渐进，先期模块的下移经验可以为后续模块的迭代下移提供借鉴和经验储备。
其建设的具体过程可以分为三个方面：一是产品选型、适配业务系统选择。在满足“四高两低”要求的基础上，应该以业务结构相对清晰、数据结构易梳理、系统维护能力强为标准来选择，这样可以将问题简单化，为分布式数据库落地提供更多支持。二是基础的适配、压测。三是业务系统的适配、验证。
从系统聚焦的角度来看，SQL 筛选、非标对象、向存储过程下移等环节，更多的是以分模块建设的方式循序渐进地进行。这对管控能力和迭代设计能力都有一定的要求，例如具体到跨库的聚合场景，需要有非常丰富的金融级分布式实践经验。
此类循序渐进的模式主要适用于两类金融机构 / 银行：第一类是国有大行 / 大型股份制银行，其系统众多、业务丰富度高，系统交互繁杂，其中稳定性、风险性是考虑的首要因素；第二类是比较有实力的中型 / 开展众多跨地域金融的城商行。
第二类模式（业务系统升级 / 建设模式），对技术实施能力的要求相对较低。基于系统升级 / 新建，自然面临着新系统的变化、改造，利于直接适配分布式数据库特性。因此在进行数据库兼容改造时，可以适当加速。
- 此类模式主要基于业务系统的升级与新建特点，能够快速适配数据库，没有改造 的“历史包袱”；
- 同时，也是对业务系统中的非标用法、数据层级的解耦检核过程，帮助厂商和金融客户提升系统数据架构设计的规范性。
这种模式主要适用于希望一次升级关键业务系统的股份制银行，也适用于中小型城商行系统换代时期，对管控能力的要求相对较低，周期建设相对短。在金融核心或者关键业务系统建成以后，同样具备经验输出到相关的其他关键业务系统。但从投入成本、科技能力、服务能力来看，厂商和银行也会面临一定的挑战。
这两种建设模式各有优劣，在实际建设中，我们需要一事一议，分银行或金融机构来探索如何建设。
具体案例模型
分布式数据库建设 - 核心业务系统升级 / 建设模式：
下图展示的是高并发的互联网银行 / 城商行级别架构实践模型，其日均交易量达到 3.6 亿，TPS 峰值超过 10 万。要支撑如此庞大的业务量，在架构体系上需要利用自身的数据架构体系，即数据、应用的单元切分以及组合层分布式事务处理能力，部分聚合场景、同步场景依赖数据库分布式能力。在符合金融监管政策的基础上，数据多活架构既贴合了该类型银行的高并发要求，也满足了未来的扩展性。
分布式数据库建设 - 核心关键模块 / 系统下移模式：
下图展示的是关键模块下移的案例模型。数据分布式下，分布式事务的不同场景应用的技术方式也不同。采用两地三中心架构，满足业务系统 / 模块等初次落地实践，多中心同步依赖数据库自身能力。
未来挑战与探索趋势
未来，分布式数据库在金融领域的应用落地仍有许多方面需要不断地去挑战和打磨，具体可分为六个维度：
- 探索分布式事务业务应用场景，我们需要根据业务场景的分类，如数据强一致（账务）级、跨库级、跨微服务级等，开展系统实践和研发。探索通过分布式数据库可以解决哪些事务场景，降低应用复杂度。
- 兼容信创环境，自 2018 年 3 月开始至今，随外部金融环境形势变化，当下的金融环境、金融基础设施建设的生态也在变革中发展，数据库研发与建设需要在变化的生态中持续迭代兼容。
- 完善金融级整体解决方案，我们必须要在满足金融级监管要求的同时，满足金融客户各类建设特点，以抽象思路和通用化的设计回归到统一的数据库产品。
- 深入金融业务场景探索。
- 打磨高可用和稳定性。
- 创新金融 DB 级 SaaS 服务。以前述提及的数据迁移体系、运维模式、建设模式为例，它能否对未来的金融级厂商、客户提供专业的数据库金融场景服务，这些都需要我们不断地去创新和探索。
4 结语
随着云计算的发展，IT 基础技术正在发生翻天覆地的变化，未来展望：
- IT 设施：从零散走向集中化、规模化、管理化模式，同时借助大量工具体系，降低人工成本。
- 交付方式：从软件交付走向服务交付。
- 开发方式：从底层（laaS PaaS）走向上层（SaaS）。
- 数据形式及应用场景：从单一化走向多元化。
在云时代背景及 IT 基础技术变化趋势下，数据库的发展与当前的分布式架构及金融场景要求并不冲突，将会在多维度进行不断迭代。
首先是单一引擎极致化，努力实现性能、业务场景兼容的极致化。同时考虑到未来可持续的多引擎形态仍会并存，因此需要实现多引擎统一智能管控的融合。最后是在数据库软件服务即 DBaaS 体系方面进行优化。它是包含了运维、开发、诊断以及架构体系等在内的完整的 DBaaS 服务体系，能够从技术软件层、底层硬件层和芯片硬件层等方面，来降低金融机构、银行业客户的设计成本、实施成本，同时也为未来分布式数据库在金融领域落地提供更好的人性化软件服务。
