田清波
腾讯云数据库专家工程师
10 多年数据库领域从业经验，擅长 MySQL 数据库应用系统的性能调优、高可用和可扩展架构设计。曾参与金融、医疗、通信和政府等领域数据库架构设计和技术咨询工作，拥有丰富的千万以上日活跃会员数据架构设计及直接研发管理经验，传统行业多个超大型业务系统的去 IOE 化和分布式数据架构设计。热衷于技术探讨和分享，目前主要专注于国产分布式数据库领域。
数字化时代，企业普遍面临数据库种类多、业务多、数量多等挑战。数据库管控和智能运维的能力，对于企业的数字化转型、降本增效、保障数据库安全可控，都有非常重要的意义。因此，企业对 DBA、对数据库运维架构设计和优化都提出了新的课题。
腾讯云数据库专家工程师田清波带来了主题为《金融级分布式数据库架构设计与对接实践》的分享，介绍了腾讯云数据库在金融行业的设计和部署实践。
腾讯云数据库解决方案
腾讯云数据库的技术演进方向分为四个垂直领域，第一是关系型数据库，在腾讯公有云及腾讯私有云上提供给客户。第二个非关系型数据库。第三个是本次分享重点介绍的腾讯在线下、私有云上主推的国产分布式数据库 TDSQL。第四个是数据库 SaaS 产品。腾讯做私有云项目过程中也会遇到很多共性问题，除了数据库产品本身的能力之外，客户也需要提供数据库异构迁移平台、智能管家，以及金融客户存量的 DB2、Oracle、SQL Server 等异构数据库的纳管能力。
TDSQL 的发展历程大概分为三个阶段。第一个阶段我称之为沉淀阶段，在 2002-2014 年期间，更多是腾讯数据库团队结合自己的业务场景打磨自己的产品，主要供内部使用。第二个阶段是 2014-2018 年，依托腾讯云自研自有业务的场景打磨出来的基础数据库软件开始服务于 ToB 客户，帮助客户实现数字化转型。第三个阶段叫全面开放，从 2018 年至今。2018 年我们参与了国内第一个传统核心下移到 TDSQL 的项目，2020 年平安信用卡大机下移也是 TDSQL 来承接和构建的。2021-2022 年，TDSQL 在金融领域深耕发展了银行清算、农行、中国银行、招商银行等不少金融客户。
一款国产分布式数据库软件应该具备哪些特性？我们自己总结了六点。
1. 架构开放性：兼容 MySQL 接口和标准开放，技术人才通用、已有生态复用，TDSQL 内核 TXSQL 完全开源；
2. 线性水平扩展：无论资源还是功能均提供良好的扩展性；
3. 金融级高可用：确保 99.999%以上高可用；跨区容灾；同城双活；故障自动恢复。完善的两地三中心方案保证 RPO=0，RTO<30 秒；为业务保驾护航；
4. 企业级安全性：数据库防火墙；透明加密；自动脱敏等；减少用户误操作/黑客入侵带来的安全风险；
5. 数据强一致：确保多副本架构下数据强一致，避免故障后导致集群数据错乱和丢失；
6. 便捷运维：全白屏运维操作，包括智能化运维（扁鹊 DBBrain）、自助化运营管理台（赤兔）等，帮助 DBA 快速上手。
TDSQL 是一个整体数据资源池解决方案，产品架构分为三个组件：管理节点是右边的资源池化管理，包括智能化运维、智能化分析、自动化测试验收。因为我们产品是交付到客户的生产环境，所以要做全链路的自动化测试验收，便于后期转维，所以管理节点包含这些功能。计算节点是无状态的，所以能够天然地做到水平扩展。第三块是数据节点，底下通过资源池化可以做到资源隔离。比如说大的实例可以做到独占，通过物理机资源做到隔离，满足业务场景。这里面的资源池化构建方式很灵活，我们依靠平台可以按需选择集中式实例还是分布式实例。
除了这三大组件之外还有一些配套，比如说生产数据从 TDSQL 同步到下游的 Oracle、Kafka。我们囊括了很多组件，像多源同步，甚至还有备份一体机，这是我们产品的整体架构。
除了提供产品之外，因为我们替代客户现有业务系统时必须要面对的一个问题是异构数据怎么迁移到 TDSQL，怎么把 TDSQL 里的数据用起来。相当于我们必须要提供给客户一个基于 TDSQL 的数据库，提供迁入和迁出的能力。所以我们结合业务场景打造了自己的一款数据库同步工具，叫 DBbridge。
DBbridge 做两件事情，第一是帮助客户解决存量的商业数据库替换需求。在替换过程中有两种方式，更经济有效的方式是数据库平移，这种平移要考虑到商业数据库兼容性，所以我们结合客户现有系统做兼容性方案。以 Oracle 为例，我们会在应用角度评估业务系统迁移到 TDSQL 之后的量化结果，去实现应用侧改造。数据库层面，数据库的表、索引等数据库对象这一层通过 DBbridge 做评估。从应用层和数据库层两个评估，帮助我们更低成本做到数据库平移。
还有一种场景是新建数据库，新建数据库完全不考虑异构数据库迁移能力，但它希望新建数据库系统数据能给下游做分发，DBbridge 也能做这个事情。这个产品获得了信通院给腾讯数据库团队的《数据库应用迁移服务能力评估等级证书》，这也是行业里少有的。
比如说我们对 Oracle 数据库做了兼容性评估，通过这样的评估结果很清楚地看到到底哪些不兼容，比如说 Oracle 使用 DBlink，TDSQL 上并不支持。所以我们通过产品实现了 Oracle 的兼容性，后续再遇到类似的数据库连接场景，就有了通用和可复制的方案。
TDSQL 的安全解决方案拆解来看分为三种场景。事前，TDSQL 在应用层到数据库层请求的链路上、传输上是加密的，数据存储层面上除了有通用加密算法，我们还对接了国密 SM4 加密算法去实现数据加密。数据库的权限、角色、粒度更精细化。事中，我们经常遇到这种情况，针对危险的 SQL 我们内部有 SQL 防火墙，通过内置高危 SQL 的规则帮助我们主动拦截和预防高危 SQL。事后，任何一起安全事故或者故障事后都要分析复盘，所有操作都有留痕，基于事后审计系统做复盘，这就是 TDSQL 的安全能力。
现在故障不确定性越来越多，我们在设计新一代核心系统都会考虑同城多中心或异地灾备架构。我们给客户做核心下移的方案时首推同城多中心、两地双中心方案，帮助客户真正做到 5 个 9 的可靠性。做同城双活系统时面临一个挑战，同城双中心之间的网络抖动对于业务系统带来的影响需要从产品层面评估、解决。针对这种问题我们做到了强同步可退化，或者强同步不可退化。如果我们追求业务连续性就可以做到强同步，同城两个 IDC 之间降级来保障业务的连续性。但如果我们追求业务一致性，要牺牲可用性，我们可以做强同步不退化，按需设置。有了强同步技术，我们达到了同城双中心 RPO=0，在同城双中心自动切换过程中 RPO＜30s，这是我们两地双中心的解决方案。
最后一块是运维。针对几十台、上百台，多则上千台的规模，怎么帮助客户运维？早期很多客户选择第三方厂商帮他们做运维工作，但行业运维人员肯定希望自己通过数据平台解决日常工作。所以我们结合腾讯公有云的多年经验，把我们的运维、DBA 调优能力产品化给到了客户。
比如说我要新建一套业务系统，大概需要 7 套环境，每套环境就需要 2 分钟之内创建 7 套环境实例，按传统方式来申请服务器、安装、部署，这样肯定需要几天时间。现在通过赤兔平台只需点一下按钮就能创建一个实例，批量帮我创建 7 套环境实例，这个体验非常舒服。我们同时还能做到资源可重用，因为我可以做到实例全生命周期管理，日常工作都交给赤兔，通过一个按钮完成。同时我们的赤兔也具备开放 API 能力，和客户的数字化运维平台、监控平台做对接。
TDSQL 还提供了扁鹊平台。因为我要优化 SQL 或者对性能瓶颈做优化，通过以前的方式就要搜集很多信息，通过自己的能力分析，找到可能的瓶颈点在哪里，这种分析思路非常依赖于个人能力。那么我能不能把很擅长做调优经验的人的能力做到产品里给到客户，让所有人都具备这种能力呢？我们结合了腾讯公有云的运维、性能诊断经验，沉淀了 300 多个模型，通过 Agent 采集这些数据来以不同维度、不同指标去做智能化分析。我们还有一款 SaaS 类服务在扁鹊基础上再做全链路性能诊断和调优，寻找瓶颈点。
腾讯云数据库如何对接金融行业客户
很多银行客户系统早期都是基于很成熟的商业化数据库，框架都很标准。国产分布式数据库算新鲜事物，在这个新鲜事物里我们要做核心下移，会面临哪些挑战呢？我简单提炼 5 个点。
第一点，比如说我们要基于新的分布式数据库去做业务系统，我怎么建立新的开发规范、运维规范、标准流程，这些东西肯定要重新去构建，去满足于新的数据库产品或者技术栈的要求。
第二个是应用适配。因为你的数据库有 SQL 差异，所以一些差异也会对应用开发有影响，这个过程我们有很成熟的体系去帮助客户。
第三块是我要展开讲的，分布式数据库运维能力。因为传统商业化数据库可能就两台服务器应对生产环境，但当今你如果选择 TDSQL，它可能是上百台服务器规模，来做分布式数据库资源池化能力。在这个能力上会带来很多挑战。
第四块也是数据库同城多活能力，因为传统集中式架构它的双活也好，异地灾备也好，可依赖于技术的路线很多，比如说我依赖存储级别去做灾备。分布式数据库本身没有存储概念，所以当我不依赖存储的时候怎么做同城双活、异地灾备多活的能力也是问题。
最后一块，在分布式数据库架构，行业里做核心下移有两个路线，我到底做单元化架构，还是基于微服务的方式做分布式数据架构。这两种架构的选择维度、优缺点会有不同，扩容路径也就有所区别。以单元化为例，我以 300 万或者 500 万用户做单元化，怎么保证用户数到 1000 万、5000 万时，业务和数据库水平联动扩容，也是我们要考虑到的问题。我的应用系统或者扩容系统怎么联动，应用业务单元和业务数据库单元如何联动，这些都要考虑。
这次我主要谈数据库运维。首先，TDSQL 提供了赤兔和扁鹊这样成熟标准化的产品服务于客户，让他们可以零成本或低成本掌握分布式数据库资源池运维能力和诊断能力。
第二个是 API 开放，很多行会有自己的自动化运维方案，有统一的监控大屏、统一的告警平台。如果说每引入一个产品都是各自独立，就会形成烟囱式架构。所以 TDSQL 开放了接口，内置几百个标准 API 接口，可以把这种能力和行里面现有的运维平台对接起来。
第三块是增值服务，比如说 DBbridge 也是在我们公有云上面做过很多场景训练和打磨之后，再提供给线下客户使用。它的侧重点是在扁鹊基础上提供更加深度和细粒度的智能化分析服务。扁鹊只是看数据库层面的一个性能诊断，DBbridge 是从端到端，从应用发起请求到执行，做全链路性能诊断，所以它的侧重点不一样。以上就是当前 TDSQL 能够提供的一些运维能力。
金融项目案例分享
金融企业自己原本有系统，引入腾讯的 TDSQL 要和自己的平台对接。我们一个国有大行的客户，基于 TDSQL 开放的 API 能力和自己的自动化运维平台对接起来了。
有了自动化运维平台之后要能发现或者识别实例关系，比如说一个实例是集中式实例，它利用哪些组件，组件在哪些机器上，机器运行情况怎么样，如果这个机器出现故障之后它能关联到哪些实例。我们通过拓扑图的关系可以看到它的请求链路是动态的，通过这个图可以清晰看到哪条链路出现问题，然后针对性地定位解决问题。
TDSQL 平台提供了例行巡检、季度巡检的能力。客户把 TDSQL 自动化巡检能力集成到了自己的运维平台，通过统一平台对所有不同类型数据库做自动化巡检，一套平台管理所有数据库。
对于监控，行里面一些架构做的很标准、规范，所以客户基于 TDSQL 的 API 开放能力，通过一套天眼平台把所有数据库实例，包括其他数据库产品一起对接，这也得益于 TDSQL 对外开放 API 的能力。
下面我想通过几个案例简单说一下 TDSQL 在金融行业里核心系统大机下移落地情况。
第一个案例是我们今年 5 月份上的国有大行核心系统。它的客户数大概 6 亿，账户数大概 15 亿。当时定一个目标是部署四地八中心，做多地多中心业务多活或者数据多活。根据客户提供的诉求，我们设计了单元化架构，把业务单元和数据库单元水平联动扩容，集成一个平台。
一方面单元化能做到资源隔离，背后还有另外一个深层的原因。我们现在都在做国产化改造，所以我们拿了其中一个单元做全链路国产化替代。我可以把这个单元放一部分生产业务数据去成长。我们当时一个单元选 TDSQL，真正实现在一套资源池上一云双芯，既可以跑通用的 x86，同时还可以跑国产芯片。
第二个案例是商业银行，体量相比国有大行小一些。它选择架构的时候从运维复杂度、基础设施考量，选择的是基于微服务的架构。它的应用做微服务改造，数据库选用了 TDSQL 布式实例。在分布式实例里因为做单元化或者微服务，对应的每个服务有自己的数据库实例，必须要数据库平台支持一套资源池多实例方式。
因为它要考虑到数据库多活，所以必须在刚开始规划两地三中心架构。左边这两个 IDC 中间有一个强同步。TDSQL 能够做到双中心的 RPO=0 是依赖于它的强同步技术。我有同城双中心架构，异地是一套灾备，大概 2000 公里的距离，在 2000 公里的距离通过 TDSQL 提供 DCN 数据同步，DCN 可视化搭建，可以来回切换。
数据库的设计分了三个微服务。TDSQL 本身可以申请小规格单实例架构。比如说它的外围库可能是一些其他的扩展模块，我们专门申请外围库的实例；它的账务和历史库数据量都比较大，所以我们就做分布式实例，叫 Group Sharding。我在一套集群上要部署四个实例，实例与实例资源怎么隔离？这个就是我们做资源池化要必须解决的问题，我们做到了单集群上 CPU 内存资源隔离。
图上有个公共库到账务库的数据同步，因为我的账务库需要公共库一部分数据去关联，要解耦。怎么保证公共库到账务库的同步？用 DBbridge。我们通过 DBbridge 数据同步工具去实现公共库到账务库的数据同步。我们还把账务库和历史库拆成两个不同的库，账务库交易数据同步到历史树，都是通过 TDSQL 实现。核心系统一般都会有 Sharding，这是整个核心系统数据库的设计要点。
最后一个案例是 TDSQL 的另外一种形式，因为 TDSQL 本身可以做独立软件输出，也可以结合腾讯专用云全家桶的方式输出，还可以通过一体机方式输出。某城商行系统也面临着核心下移需求，我们当时给了一体机方案。一体机方案有个好处，TDSQL 在一体机上做性能专项调优，腾讯数据库团队为一体机硬件层面和软件层面做技术兜底。
