金融行业现状

目前国内大中型银行主要以国外厂商提供的大型主机和数据库解决方案来进行系统构建。由于近年来金融业务量的不断增长，以及银行数字化转型成为必然趋势。目前以国外大型主机和数据库为核心的架构已无法满足大规模交易和数据处理的需求。

一方面：性能无法满足业务不断激增的处理需求，存在系统过载风险；另一方面：本身价格比较昂贵，维护成本居高不下。

以手机银行、网上理财、互联网保险等为代表的金融业务创新快速发展，推动新技术正以前所未有的速度与力度发生深层次变革。

这些技术发展，对金融服务模式带来重大影响，使得金融行业向数字化、分布式转型成为必然趋势，金融业务创新与科技创新正在相互促进，重塑金融行业系统能力。

1、分布式数据库领域的百家争鸣

| 多种架构长期共存：分布式数据库经过这么多年的发展，实际上并不是一种新兴的技术了，从最早基于中间件的模型开始到现在基于分布式存储的架构，这些架构一直在并存着往前发展，谈不上哪个更优秀，因为都各有各的应用场景。

| 多种技术栈卡位竞争：分布式技术目前发展的方向是，技术栈有兼容 MySQL 的，也有兼容 Oracle 的，也有兼容 PG 的，各技术栈现在互相卡位，在国内的厂商之间，几乎每个厂商都跟着一条线。

l 厂商互相 PK：目前投入的厂家，特别是在这两年国家对这块的支持力度和资本介入之下，做分布式数据库的厂家越来越多，形成了互相竞争的关系。

2、金融客户应该如何选择分布式数据库

抛开所谓的金融产品的可靠性、可用性等技术点以外，选择一个金融分布式数据库最核心的要点我认为是以下四方面：

l 质量可靠：产品应该成熟可靠，经过大规模业务持续验证，拥有较多的客户案例和 ISV 集成经历。

l 团队建设：建立能用、会用、用好国产数据库的人才队伍；形成一支具备高水平维护能力的队伍。

l 持续演进：背靠优质平台或生态，产品可以持续演进发展；厂商拥有一流的研发团队和长期投入。

l 服务能力：在国内主要地市建立健全分销体系、培训能力、服务团队。不仅包括数据库，更能覆盖金融全技术栈的服务能力。

3、腾讯云分布式数据库解决方案

腾讯云分布式数据库最早源自于腾讯的增值业务，从充值 Q 币开始一直到财富通、微信支付、微众银行，腾讯的分布式数据库一直是基于开源的自主研发。最近几年我们开始逐渐面向产研结合和产用结合，在产研结合方面我们和国内顶级高校建立了联合实验室，也在国际上发表了多篇顶级论文；在产用结合方面我们和很多银行建立了联合实验室，共同促进产品发展，目前主要应用的是我们 TDSQL 和 TBase 两条产品线。

金融应用实践

接下来将分享一个关于某金融客户主机下移过程的真实案例，希望能真正给到大家一些启发。

抛开细枝末节，只聚焦在数据库上，我们怎么样把数据库的核心往下切？当时我们总结出了以下六个问题：

如何选择分布式技术栈；

如何设计信息技术创新节奏；

如何使用分布式数据库；

新老系统的切换；

分布式的扩展容灾方案；

如何对国产数据库进行运维；

1、分布式技术栈的选择：对主流方向都有布局和应用

对于分布式技术栈的选择，目前有两个主流方向，一个是兼容 MySQL，一个是兼容 Oracle。

兼容 MySQL 的优势是其分布式技术栈比较成熟，易于团队建设。基于 MySQL 的分布式协议最早来自于国外的一些互联网厂家，后逐渐引入到国内的互联网厂家，包括国内的微信支付、蚂蚁金服等几个巨头的支付厂家，其底座都是以兼容 MySQL 协议为主，再加上这么多年国内开发者对 MySQL 的研究，所以在此背景之下，金融机构的相关团队建设是比较容易成型的。

兼容 Oracle 的优势是对整个金融系统的改造、迁移、使用成本相对较低，有可复用的部分并且方案相对简单。

所以说这两个技术栈方向都各有优势，腾讯云因为金融业务足够大所以覆盖了这两个方向的产品，都有自己的产品线，我们现在都把它叫做分布式数据库产品线，分别是 MySQL 技术栈的以及 Postgre 技术栈的产品。

2、技术创新节奏

1）某大型银行客户的主机下移“五年计划”

了解过技术栈的选择，接下来就是考虑自身团队适合哪款产品、选择这款产品后怎么设计核心系统等。以下是某大型银行真实计划的缩影，他们给整个过程设定了五年计划原则：

技术团队：建立一支熟悉分布式数据库技术栈的技术团队；

分批改造：根据业务重要性，分批分阶段改造业务系统；

业务磨合：技术方案应在不影响宏观稳定，确保业务与数据库磨合；

技术复用：该技术应该是可以复用或容易建立的；

全量切换：应该是在完全磨合好以后，再全量切换。

并且分成四种节奏开展落地：

2018~2019 年，团队招聘与培养：确定基于 Oracle+MySQL 实现双技术栈团队建设，并选择互联网银行业务选择开源 MySQL 方案打磨团队；

2020 年，（试点）核心系统改造：团队对 MySQL 熟悉后，实现核心业务系统基于腾讯云 TDSQL 上线并开始运营；

2021 年，新老系统并行，剩余系统改造：老业务系统不下线，数据保证实施同步回老业务系统，如果新业务系统一旦故障确保老系统可用；

2022 年，最终核心交易全量切换：在运行一段时间后，确保新系统完全稳定后，再封存老系统。

3、数据层下移的拆分策略

水平拆分 &垂直拆分

在执行了相应的规划以后，就要考虑数据库改造中数据层下移的拆分策略。说到水平拆分就不得不提及垂直拆分，垂直拆分一般是在 SOA 时代，基于业务垂直拆分。分布式改造最主要的还是对其中一些业务核心户进行水平拆分，使其能够适应新时代新的科技金融业务的发展。但也并不是所有的系统都需要分布式改造，有些规模比较小的系统就没必要。腾讯的产品是集中式和分布式组合在一起的，便于客户只买一个产品，能满足几乎所有数据库的需求。

水平拆分的主要方案主要面向集团，其业务是基于分公司维度展开的，主要有几个特点——业务按分公司维度展开；交易/清算等以该维度展开；不同分公司交易规模区分明显；总部搭建业务系统和数据收口；分公司总数少但交易数量多。所以腾讯提供了一种叫虚拟组的能力，可以在分公司分布的基础上再进行拆分，帮助用户去提升。比如一个发展比较快的东南亚分公司，可能原来只需要一个小的分片，两年后爆发式增长就可以基于这种架构进行快速无缝的扩展。

第三种是按时间维度拆分：如上图所示，通常是订单类的系统，而且按时间维度会涉及到大促时期呈峰值增长的问题。这种场景下，腾讯的产品可以提供一种二级分区的能力，可以按照时间分区，这就意味着无论归到历史库也好还是这一时间阶段交易规模比较大也好，都可以均衡地负载性能。

4、新老系统的切换：DTS-DBBridge

接下来就会涉及到研发，一旦涉及到研发就要考虑整个业务系统迁移的流程。这个流程从最开始的业务沟通，腾讯就可以开始介入，腾讯的技术人员可以通过我们成熟的迁移工具 DBBridge 输出对业务系统迁移的评估报告，同时配合开发人员进行业务系统改造、实施、新老系统的并行上线以及到最后的切换，整个服务体系都可以形成一个闭环。

5、国产数据库的运维：DBBrain&分布式数据库管理系统

迁移完成后就涉及到如何管理数据库，这里涉及到我们另一个方案 DBBrain，它能够帮助用户从全局角度分析分布式数据库运行的情况，其中积累了腾讯海量的运维经验。

6、分布式多活多 SET 化扩展容灾方案

运维起来以后，随着运行一年到两年，某些核心就要开始考虑是否要符合监管的要求，是否要做两地三中心和容灾，甚至随着金融业务呈爆发式发展，原有的机房已经不能满足需求，需要换多机房方案。

传统的两地三中心容灾方案，从金融科技发展角度会呈现出一些小问题，比如容灾需要人工干预，当真的面临事故时，是否敢做切换的决策？实际上很多金融 IT 从业者都不敢打包票。另外就是备机房常态下无流量，利用率较低，所以现在发展出多活的容灾方案，简单来说就是把业务系统通过一层网关进行一个按 SET 的划分，每一个 SET 下面都对应一套数据库，这个数据库既可以是集中式也可以是分布式。腾讯里像微信支付，都是使用多 SET 的模型。

SET 的主从之间是采用数据库的强同步，SET 与 SET 之间同类业务采用数据同步模型，因为上层的 SET 做了业务拆分，所以两个 SET 组之间的数据是不冲突的，可以互相进行同步。这类架构目前也在国内的某头部保险公司，同样是腾讯云的客户，已经试验了两地四中心的架构，到目前为止已经稳定运行超过 9 个月，单个 SET 能承载的理论容量是 10TB，理论 TPS 是 5K 以上，而且性能可以基于 SET 化的分布式扩展往上加，所以 SET 化可以扩展的能力是很强的。