本文整理自腾讯云数据库资深解决方案架构师贾瓅园在 DIVE 全球基础软件创新大会 2022 的演讲分享。
以下为贾瓅园演讲的精华内容，经编辑。
国内行业 IT 系统中，数据库领域长期被国外产品垄断，国内云计算厂商基于云计算带来的架构升级，以及产业互联网数字化实践，引领了新一代分布式云数据库技术与实践突破。
从金融级场景到传统金融核心系统场景，在云化的技术浪潮下，国产分布式数据库得以在对数据库最高要求的金融行业实现应用，并逐步拓展至政务、运营商、工业制造等，逐步支撑国民经济对数据库的国产化与数字化转型升级需求。
腾讯云数据库 TDSQL 正是走过了这样的历程，在技术突破，到支持客户转型实践过程中，积累了丰富的解决方案与实践经验。本次分享，将围绕“国产金融级分布式数据库在金融核心场景的探索实践”，探讨行业内的经验方案，以及展望未来前沿的探索与实践方向。
回归本源，是什么驱动力促进金融核心场景分布式数据库发展？
一方面是国家机构、监管机构给出的政策及指引，2021 年末，中国人民银行基于“十四五”规划发布了金融科技的发展规划，2022 年初银保监会发布了银行业、保险业的数字化转型指导意见，个人总结为三个词：安全、发展、创新。
第二方面是金融业务的发展对于技术架构的要求，银行业务与需求发展背景下，技术要求、技术多样性、功能细化性、架构复杂度、管理等维度的要求也逐级提高。
第三方面，金融业系统技术与架构的趋势之下所衍生的数据库要求、自主可控的软硬件要求等。
我们当下处在分布式数据库的快速发展过程当中，既要契合金融场景专业特性，技术上也要适配外部环境与生态以及通用性，面临着从技术角度、从公司实力角度、从数据库研发角度的多维度挑战。
分布式数据库在金融领域的挑战与痛点
金融架构里面的挑战维度有哪些？
第一是设计、规划、解决方案能力，相对于新事物，需要行业多方面的接受过程，这个时期国产分布式数据库不能像传统数据库，而是需要更贴合于业务场景和行业特性并抽象和分析使用特点，衍生变化为数据库通用特性和功能，更方便地让金融客户以及开发厂商使用。
第二方面是扩展能力，包括横向和纵向的扩展能力。
第三方面是稳定性和性能，围绕这个维度又衍生了广播表、单表、事务等功能与解决方案。
第四方面是高可用性，满足监管要求和行业特点，支持多中心多活、故障切换等方式。
第五方面是软硬件兼容性要求，我们正在使用的领域有自主可控软硬件、虚拟化、云化等基础底座。
分布式数据库在金融业务领域又面临哪些难点呢？
第一是保证业务系统兼容性，降低改造和引发的风险，比如关键字、函数、语法，甚至常规业务系统使用的软件驱动。
第二是迁移同步的方案与功能，这个往往在金融场景下容易被忽略掉，需要考虑异构迁移工具、方案，考虑如何处理业务场景数据同步、高可用要求下的数据同步。
第三是运维体系，分布式体系下特性带来的管控维度较多，因此可视化、智能化的管理平台和工具尤为重要，同时也要覆盖黑屏命令工具、监控工具等，匹配 DBA 使用习惯。
第四是服务与交付，分布式数据库还处在一个发展和高速迭代过程中，那么如何来契合金融场景设计特点与复杂度，都对人员能力、交付提供了更新的要求，当下走的路线应该既与金融行业系统开发厂商不同，又与传统数据库厂商不同。
第五是生态建设，这涉及到共享知识库如何建立、检索、查阅，社区如何运营、认证培训如何开展更有助于生态合作。
总结来说，分布式数据金融领域落地不仅仅是技术与产品力的考验，也是考验着金融场景理解能力、金融运转体系理解能力与设计能力等。
金融级架构探索、思考与实践
架构体系如何支撑金融核心业务发展和合规? 我们一直在探索和积累，来支撑金融级分布式的架构体系，以满足监管合规的要求，完整的实现自主可控，并契合金融核心的特点。
我们满足了金融级的“四高两低”的要求，包括未来都是以此为原则基础。并且实现了多内核。为什么要多内核？在金融银行业中，不同的金融业务场景，不同的分布式业务架构需求，以及每家银行的建设因素不同、系统历史遗留问题原因不同、系统的 AP/TP 属性等综合多方面和实践经验，因此必须要有多内核的兼容性来保障新旧数据库转换能力，保证业务系统能够平滑下移。
另外，贴近开发，解决“开发不规范，调优困难”的问题。契合金融业运维模式，解决“诊断难、维护难、时效长”的问题。同时也要考虑不单一绑定某一技术形态，采用兼容通用协议的技术形态，降低从业者的学习难度。
业务系统兼容性探索
在做业务系统兼容性探索时，要注意系统背景、特点、场景的不同，不能“通吃”，应按不同类型、不同纬度进行兼容适配，并考虑系统业务与当前的架构现状。
例如：我们按照金融银行业系统传统分类标准做了梳理和归纳，它们都有各自的特点以及兼容思路和技术诉求。
在语法与开发兼容性方面，我们通常关注：
数据结构梳理: 访问频度、数据量、关联关系、分片依据、水平垂直分库设计规则
基础数据类型: 字段数据类型归纳，不兼容类型采用工具化配置
转换对象使用: 存储过程、视图、非标准函数使用分析，与业务系统配合调整
SQL 执行对象: 索引、函数、锁、大查询、大事务分析与调整
数据库基础集成层面: 会话保持、链接池参数、探活机制、驱动设置
数据迁移与同步的兼容和实践
业务 场景数据迁移与异构数据库迁移项结合，数据库须具备异构库数据迁移能力，不同的数据迁移同步场景有着各自的关注点：
异构业务系统迁移场景：
业务逻辑复杂、数据业务关联度高
适用定制化的业务数据迁移程序与方案并配合数据库工具，进行数据迁移
异构对抽迁移场景：
业务逻辑关联少，数据量大, 增量 / 全量数据迁移
适用数据库提供异构库迁移工具进行数据的迁移
业务迁移与异构库结合场景：
兼具两种场景特点
采用组合迁移方案，满足异构业务系统 + 异构数据库数据迁移
在贴源数据同步实践中，各场景的关注点如下：
运维架构探索与实践
从运维角度来看，架构特性从最早的字符界面端到图形化、智能化运维发展迭代，字符界面操作上手速度快，但具有高度依赖人工、管理流程复杂、成本高、容错低、风险高等特点。图形化运维实现了工具化，降低了容错风险和管理成本，而智能化运维更进一步实现了风险预警、主动探测和提前预知，让运维从被动变主动。
探索实践新的实施与服务模式
大多数的开发人员、技术人员都具备一定程度的传统数据库的知识、开发经验和体系，基于系统的成熟稳定，技术的共识性实施角度不存在什么太多的问题。因此传统成熟的数据库厂商在经历了众多行业的积累后不断打磨，已走出了一条成熟的实施道路，即关键节点保障型。面向客户时技术团队基本上是以 DBA/ 架构师 1v1，或 1v 多的模式，不需要完整周期跟进实施全流程。
金融软件的开发厂商聚焦业务系统，这类型厂商为什么走的是需求差异化的路线，原因是业务通用性的同时每家银行的需求不同，业务复杂度不同，涉及每家银行技术架构、厂商特点也不同，导致了整体相关的工作，都需要在银行整体组织下进行大规模的完整周期实施和调整。所以团队有技术架构、DBA、业务专家、项目管理以及开发，基本上团队是一个 1v1 的模式，全周期保证。
基于我们多年的研发、实施经验来讲，当下兼容和融合以上两种相对比较好，既保障了数据库的交付与落地，同时兼顾成本和投入，以及经验回归和产品打磨。
具体的方法论而言，总结大致为：第一，帮助金融行业的客户将数据库融入到行业架构规划中，既然能够协助更好地理解知识体系，也能够为金融客户未来的数据库使用奠定基础。第二，跟进常规的 IT 系统建设，总结系统使用数据库的特点特性。第三，在设计交付之初，我们就考虑到兼容对应的业务性特点来进行分片、运营模式、数据吞吐量设计、数据节点等统筹安排。第四，有别于传统的数据库厂商，我们配备了行业架构师、数据库架构师以及 DBA 等角色来共同完成项目。这样兼顾了数据库以往的交付与服务模式，同时也兼顾了行业的特点，也包含成本管控以及诉求。
生态建设
高校、合作机构、金融 IT 同业、金融客户等，对当前分布式数据库都有一定的深入了解，但认知程度暂时达不到传统数据库所积累的程度，因此需要我们在数据库层面不停深入建设共享知识体系，包含社区、生态合作、培训等体系。
一、这个生态里面不只我们自己，包括分布式数据库领域的众多厂商、金融 IT 开发厂商，实践方案、调优指南、使用指南、技巧经验、系统兼容经验、金融系统运维等丰富到整个金融实践体系中。
二、增强社区广度和深度，聚集于碎片化问题解决、学习笔记、金融场景特点优化，开办技术论坛，让众多的行业以及未来有潜力从事这个行业的人才能够加入到其中。
三、深入生态合作，与学术研究机构、信创基础软硬件厂商、金融软件同业、金融客户合作，推进一些相关的标准甚至研发体系，进行产能体系的升级。
四、认证培训添加，联合第三方进行金融客户服务中知识转移、技术认证模式，通过认证培训普及常规知识，为未来金融 IT 领域人才储备夯实基础。
建设模式探索与实践
聚焦到建设模式共分为两类，一是关键系统 / 模块下移模式，二是业务系统升级 / 建设模式。
关键系统 / 模块下移模式实际是把整体分了 N 个阶段来做，并不是一次完成。这种模式具有很多优点，包括低成本、风险比较低，并且是循序渐进的。但对于系统的规划、建设周期布局以及管控能力要求较高。
分布式数据库要满足“四高两低”的要求，即高可用、高一致性、高扩展、高性能、低成本、低风险。从产品选型到适配业务，原则上必须要保证数据库兼容业务系统，相对来说业务结构要清晰，数据结构容易梳理、系统维护技术能力要强。
在基础适配压测阶段，重点是语义语法、业务使用场景和问题的筛选。在业务系统适配验证阶段，重点是联机业务，批量业务，供数、同步类业务，验证“四高两低”。
业务系统升级 / 建设模式其实相对来说容易一些。因为系统升级自然面临新系统的变化改造，通过开发设计过程，匹配数据库特性，没有历史包袱。此类模式对于管控能力的要求相对会低。
总体而言，从投入成本、核心能力、服务能力来讲，对厂商、银行也会有一定挑战。这些挑战主要集中在升级与适配、系统的架构设计、UAT 测试与基础底座验证、工具化与数据移植、切换投产演练等方面。
未来挑战与探索思考
将来，我们认为金融领域分布数据库仍然需要不断地面对挑战和打磨。
第一个是分布式事务的业务场景，当下我们能够保证分布式数据库的事务处理能力，能保证全金融业务场景，但我们也在不断地努力，探索将来按照分类去做一些实践研发工作，探索如何通过数据库解决事务场景，降低应用的复杂度。
第二是随着外部环境的发展，数据库不断提升兼容生态能力。
第三是全打包的金融级解决方案，符合金融级监管要求的同时，满足客户的个性化特点，最终走向多对一的、统一的数据库产品。
未来数据库时代，云原生数据库发展也在不断进行当中。云时代的特点是 IT 设施从零散走向集中化、规模化，交付方式从软件交付走向服务标准交付，开发方式从底层 (laaS+PaaS) 走向上层 (SaaS)，数据形式及应用场景从单一化走向多样化。
在这样的云时代的背景下，数据库将来要做到单一引擎极致化、多引擎统一智能管控融合、以及 DBaaS 形态在行业应用的探索。
讲师介绍：
贾瓅园 ，腾讯云数据库资深解决方案架构师。15 年金融银行 IT 工作经验，先后经历和主导国内多家银行核心系统架构设计与建设，长期从事银行核心业务系统、分布式技术架构、云原生、信创相关技术工作，现为腾讯云数据库团队行业架构专家，从事金融领域数据库赋能、行业架构设计相关工作。
相关阅读：
惊爆 GitHub！腾讯 T14 级 SQL 首席专家开源分布式数据库架构实践手册
GitHub 典藏版！腾讯 T14 级牛人亲码的分布式数据库实践，再次爆火
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论