在对数据库要求最苛刻的金融行业，为什么会突然出现这种架构？

在对数据库要求最苛刻的金融行业，为什么会突然出现这种架构？

引言|在金融行业IT系统国产化背景下，国内金融行业开始推进IT基础设施国产化，逐步摆脱对传统IOE架构的依赖。 WeBank自成立之初就摒弃了传统的IOE架构Luhong，结合腾讯金融级分布式数据库TDSQL，建立了基于DCN单元化架构模型的分布式基础平台。 如今，这一架构支撑着微众银行的数亿用户、数百个银行核心系统，以及每天数亿笔的金融交易。 本文由微众银行、腾讯云TVP数据库平台办公室经理胡盼盼在Techo TVP开发者峰会“数据的冰与火之歌——从在线数据库技术到海量数据分析技术”发表于《分布式》 《微众银行核心系统实践之数据库》演讲分享编译，重点介绍金融行业的数据库趋势、微众银行基于单元化的分布式架构、基于单元化的数据库架构，分享微众银行未来数据库的演进方向.

点击观看精彩演讲视频

一、金融行业的数据库趋势

今天分享的主要内容包括四个方面：第一是介绍数据库在金融行业的发展趋势； 二是介绍微众银行的单元化架构； 三是如何根据微众银行的单元化架构做数据库架构； 四是微众银行内部未来数据库架构的演进方向。

金融业是一个相对传统的行业。 IT 基础设施的选择是保守的。 一直稳定在传统的IOE架构中。 但是，近年来发生了一些变化，主要有以下三个趋势：

首先是本土化趋势。 近年来的国际形势众所周知。 在金融行业等重点领域，关键IT基础设施国产化是国家层面正在推动的一个方向。 另一方面，得益于国产化的推进，国内的数据库产品也应运而生，让国内的金融企业有很多国产数据库可供选择。

第二个趋势是去中心化。 互联网行业的发展带来了数据的爆发式增长。 传统银行现在正在慢慢走向互联网化和在线服务，比如手机银行APP。 以前很多业务需要到线下网点办理，现在可以在手机上办理。 成功了，所以带来的数据量也成倍增长。 原有的中心化架构，如单机存储或共享存储，可能无法支撑这种性能或容量的爆发式增长。

第三个趋势是开源。 几年前，金融业，尤其是传统银行，并不真正信任开源产品模式。 他们觉得开源产品的稳定性得不到保障，没有固定的技术团队支持。 但近年来，这种看法逐渐发生了变化。 很多同行业的传统银行已经开始尝试一些开源数据库上报金融数据库会怎么，比如MySQL、Redis。 在开源数据库平台上运行一些非核心业务场景，规模不小。 此外，我国正在逐步加大对整个开源软件生态建设的支持力度，国内的开源社区建设也在慢慢走向成熟。 进一步推动了开源数据库在金融行业的应用。

本图取自国内某数据库排名网站，均为目前国内数据库产品。 我们可以看到这张图中，有腾讯、阿里、华为等大厂的数据库产品，也有热门的开源产品，也有一些传统厂商的产品。 可以说，这真是一个百花齐放的时代。 这在五六年前是不可想象的。

2.微众银行的单元结构

下面介绍微众银行的内部单元结构是如何构建的。 微众银行从2014年开始筹备，作为中国第一家民营银行，我们在IT基础设施方面没有历史包袱，可以从头开始构建全新的架构。 因此，当时确定的路线是不采用传统银行的IOE架构，而是确定采用基于分布式架构的模型来承载整个银行的核心系统。

最后我们选择单元化作为我们架构的基础。 这里的unitization怎么理解？ 用传统线下银行类比，传统银行一般每个省都有一个分行，每个省分行只负责每个省的客户。 微众银行的单元化类似于分行的概念。 我们还将所有的客户拆分成单元进行管理，每个单元就是固定数量的用户。 比如我们一个单元只承载500万用户。 当单元满了，我们直接整体扩充一个单元。 这个单元我们有一个名字：DCN，是最小的单元化部署单元。 DCN包括应用层、中间件和底层数据库。 可以理解为一个DCN就是一个自成体系的小型WeBank。 DCN承载的用户数量是固定的，比如500万或者800万用户。 当DCN满员后，会横向扩展一个新的DCN，新的用户会被放置在新的DCN中。

这种 DCN 架构带来了两个问题。

第一个问题：比如你是微众银行用户，想使用微众银行服务，你怎么知道你在哪个DCN？ 这里有一个关键的组件：GNS，GNS负责所有用户的DCN路由信息的存储和查询。 当有用户请求进来时，首先会查询GNS获取其所在DCN的位置，然后再去对应的DCN进行后续请求。

第二个问题：DCN和DCN是隔离的，A DCN的用户想给B DCN的用户转账，如何实现转账的消息交互？ 这里提到另一个关键组件：RMB，中文名称为：Reliable Message Bus。 RMB 的主要功能是负责 DCN 之间的消息交换。 通过GNS和RMB这两个组件，基本解决了整个DCN的路由和消息交互功能。

当然，DCN不能承载所有的业务场景。 对于一些归档场景，可能会从DCN中采集统一存储和计算，而有些数据是全局数据，DCN无法拆分，所以我们看到下面会有一个全局数据。 管理和后台管理的区域称为ADM区域。 用来解决这类业务场景。

在不断的线上实践过程中，这种DCN架构带来了很多优势：

第一个优点是它减少了故障的影响面。 由于DCN是从软件层面独立拆分到硬件层面，DCN硬件故障的影响是有限的。 比如微众银行最大的业务：微微贷，现在有20多个DCN，某个DCN的故障可能只影响整体业务的1/2，可以有效控制故障的影响范围。

第二个优势是可以实现高效扩张。 目前，我们通过自动化部署可以在一个小时内完成一个DCN的扩容，相当于在一个小时内完成了500万用户从软件到硬件层面的扩容。

第三个优点是它可以实现高效的灰度变化。 因为每个DCN相当于是完全同构的，所以可以设置一个专门的灰度DCN来容纳少量用户。 每个版本发布，比如数据库的DDL或者应用的版本发布，都可以先在这个小DCN灰度化，灰度验证没有问题，然后全量发布到其他DCN，这样可以有效降低版本风险。

最后一个优势是DCN单元架构简化了数据库架构。 DCN的用户规模是有限的，所以DCN中的数据库规模，包括数据库TPS、IO/CPU负载、数据量都有上限。 因此，DCN中的数据库无需采用相对复杂的分布式或基于中间件的数据库来提供可扩展性。 在DCN中，我们采用了最简单的TDSQL单实例架构，不需要考虑分布式事务带来的数据库复杂度。

当然，这种DCN单元结构也会带来一些缺点：

第一：DCN之间的物理资源相互独立，每个DCN可能预留一些buff资源，可能导致整体资源利用率低。

第二：DCN架构对运维自动化要求非常高。 我们现在已经生产了100多个DCN，需要对多个DCN的版本管理、版本发布、日常变更进行自动化运维。

第三：要求应用层实现跨DCN的分布式事务框架。 比如我在A DCN，你在B DCN。 我需要转一笔钱给你。 如果在原来的中心化架构下，可能直接使用数据库事务来保证一致性，但在这种跨DCN架构下，可能需要应用层实现类似的事务框架来保证整体事务的一致性。

3. 基于单元的数据库架构

上面介绍了微众银行的DCN单元架构。 基于这个架构的前提，我们将介绍微众银行的数据库架构是如何实现的。 在介绍数据库架构之前，需要了解一些背景知识。

一、微众银行IDC架构

微众银行目前的IDC建设是2网点7中心的IDC架构。 我们在深圳有5个生产机房作为生产中心，在上海有2个灾备机房作为灾备中心。 这五个机房在深圳同城的选址也有规定。 两个IDC之间的距离控制在10-50公里范围内，保证IDC之间的网络时延在2毫秒左右。 跨同城IDC部署副本的前提条件。

2、微众银行TDSQL部署架构

先介绍一下TDSQL这个产品。 TDSQL是腾讯推出的金融级分布式数据库产品。 目前，微众银行所有核心系统基本都由TDSQL承载。

如下图，从横向维度来看，最左边的APP请求通过一个负载均衡组件进入，负载均衡组件将请求转发给TDSQL代理模块。 这个代理实际上实现了SQL解析，读写分离，流量控制。 该功能相当于一个中间件。 TDSQL代理收到请求后，将请求转发给后端对应的SET链表。 TDSQL的最小单位是SET，本质上就是MySQL。 TDSQL针对MySQL内核做了一些定制化的优化。 SET一般采用一主两备的架构。 一主两备之间采用TDSQL优化的强同步机制，保证数据多副本的一致性。 一个TDSQL代理下可以挂载多个TDSQL SET。

再看看垂直维度。 它可以在垂直维度上得到支持。 TDSQL 还有两个关键模块。 一个是zookeeper，它是整个TDSQL配置的管理系统。 监控上报的所有元数据信息和统计信息都会上报给zookeeper集群。 在zookeeper之上还有一个叫做schduler的模块，负责调度整个TDSQL任务流程。 比如SET1的主节点现在可能宕机了，需要进行主备倒换。 这个主备切换过程是由整个schduler模块来调度的。 ，它会控制每一步的切换过程，直到最后切换成功。

我补充一下TDSQL的两种使用模式，一种是NO Shard模式，也就是TDSQL的单实例模式。 在这种架构下，TDSQL proxy只是简单的执行了一个SQL转换的功能。 到达底层SET后，每个STE都是一个独立的单实例架构。 SET 之间的库是无关紧要的。 这种 No Shard 架构不在中间。 软件层分为数据库和表，逻辑会简单很多。 但是这种模式下的SET如果需要扩展，只能在SET内部垂直扩展。 这种架构的优点是不涉及分布式事务，也不涉及数据库分片，所以语法完全兼容，架构简洁。

第二种模式是TDSQL Shard模式。 Shard模式可以简单理解为基于中间件分库分表的模式。 通过TDQSL代理，将某个库做成三个分片，这三个分片分别分布在SET1、SET2、STE3这三个SET中。 这种模式的好处是可以实现横向扩容。 但是它带来的问题是语法兼容性并不完善，因为需要在中间件层面实现分片，需要一些特殊的语法兼容性。 比如在创建表的时候，需要包含share key，在SQL中可能还需要包含share key。 应用层需要适配和改造。

刚才我们提到微众银行的单元化架构是基于DCN单元化架构，对数据库的性能和容量需求是可控的，所以我们不需要通过这种Shard模式进行扩展，直接采用No Shard模式，从而大大简化了我们在数据库架构和运维方面的工作量。

基于以上背景知识，我们来看看微众银行TDSQL的部署架构。 从纵向来看，每个方框代表一个IDC，左边是三个生产IDC，右边是跨城容灾——上海两个IDC。 从底层来看，最底层是我们的数据库，采用TDSQL数据库，一主两备架构，三副本分布在同城三个IDC，比如Master在南山机房，Slave1可能在观澜机房，Slave2可能在福田机房。 TDSQL强同步机制用于Master和Slave之间的数据同步。 在一个DCN中，我们可能有多个SET来承载数据库。

在数据库的上层，每个机房都会有一个独立的访问层，在访问层之上会有一个独立的负载均衡功能，最上层是应用层。

基于这种部署架构，我们实现了同城多活应用的概念。 业务流量可以从生产IDC的任意一个IDC进来，经过应用层到达同机房负载均衡的接入层，但是从接入层到上层数据库可能会涉及到跨机房的流量访问。 比如从IDC1进来的业务流量，数据库的master可能在IDC2，所以可能会涉及到从接入层到IDC2 Master的跨机房流量访问。

我们在上海的跨城容灾除了生产的三个副本外，还会有两个副本：一个Master，一个Slave。 跨城容灾与生产IDC之间的数据同步由于网络延迟是异步的，没有强同步。

这种架构的好处是可以实现同城IDC级别的容灾。 也就是同城的生产IDC，如果有哪个IDC挂了，比如某个机房断电，整个机房就没电了，那我也能保证业务快速恢复，因为我的数据库也可以自动切换到另外两个IDC。

大家可能会有疑问：同城一主两备，分布在三个机房之间。 机房之间可能会有延迟。 我们把它控制在两毫秒之内，但是它会对性能有什么影响吗？ ？ 首先，在基础设施方面，我们会在机房建设上定下一些原则。 刚才我们提到同城IDC之间的距离要控制在50公里以内，IDC之间会建立多条专线，保证带宽和稳定性。 我们现在都是10G的网络基础设施，这是硬件层面的保证。 另外，软件层面是针对TDSQL的。 TDSQL本身针对这种主备强同步机制做了一些异步和批处理的性能优化，保证跨机房强同步的性能损失尽可能控制在10%以内。

根据我们的实测结果，同城同机房和跨同城机房强同步带来的性能损失可能只有10%以内，对于我们的业务水平来说是可以接受的。

接下来我们来看TDSQL的运维管理系统。

支持TDSQL的运维管理平台也叫赤兔平台上报金融数据库会怎么，负责实现TDSQL的监控和运维功能。 可以监控所有TDSQL实例的多个指标，包括各种指标，慢查询，IO，CPU等； 大部分运维操作也都集成在平台上，如主备切换、迁移、扩容、节点更换等，可以实现高度自动化的运维功能。

TDSQL另一个重要的运维组件叫做Cloud DBA。 是一个智能故障定位模块，可以替代DBA的部分工作，比如分析SQL性能，给出索引建议，自动分析定位故障原因。 Cloud DBA会主动从TDSQL实例中收集各种能耗指标、慢查询SQL和执行计划，最终生成健康报告和优化建议。

在CLOUD DBA的界面上，左上角的图片是打分功能。 可以每天对某个实例进行全面的检查，最终打分生成健康报告，指出实例可能存在的缺陷和风险。 比如对某条SQL的检查优化，可以分析出哪些索引可能缺失，并提出额外的优化建议。

下面是实时诊断界面，可以实时诊断实例当前的运行状态，比如是否有新的锁丢失、锁等待、异常等指标。 这些工具对我们的日常运维有很大的帮助。

目前，微众银行整个TDSQL数据库的规模有400多个SET，全网2000多个实例。 整个数据量达到PB级，承载了上百家银行的核心系统。 金融交易量应该达到6亿。 左右，最高TPS峰值超过100,000+。

4.未来架构演进方向

最后跟大家分享一下微众银行数据库未来的演进方向。 总体演化方向分为三个。

第一个方向就是我们正在做的：推进硬件国产化。 现在我们的大部分硬件还是基于X86平台的Intel CPU架构。 从去年开始，我们一直在尝试将底层服务器硬件平台迁移到国产ARM平台上。 我们目前使用的是华为鲲鹏的CPU架构。 去年在某业务中，从硬件层到中间件再到数据库的整个链路都运行在华为鲲鹏ARM服务器平台上。 今年，我们可能会继续推动和扩大规模向国产ARM平台迁移。

第二个方向是云原生。 目前整个TDSQL还是基于物理机和虚拟机两种资源模式进行部署。 这种部署方式会带来一些问题，比如资源管理成本比较高，资源交付效率低，因为物理机涉及到上架和初始化。 各种资源的进程分配比较麻烦，整个资源的隔离效果会比较差，资源利用率会比较低。 因此，我们今年打算做的是逐步将TDSQL向K8S+Docker等容器架构迁移，提高资源交付的利用率和效率。 K8S+Docker的架构在无状态应用上是比较成熟的，因为无状态的场景比较简单，但是在数据库等有状态的应用中，会出现更多的问题和复杂性，所以我们会谨慎尝试。

第三个方向是智能预警和运维。 对于DBA来说，头疼的是很多时候问题还没解决定位就已经发生了，而此时已经对业务和交易产生了影响，比较被动。 所以我们一直在做的就是希望通过一些智能化的方法提前发现和预警这样的风险和故障，提前解决。 这也是我们目前的痛点。

举两个例子，一个是我们推出的基于深度学习的智能故障预测与告警。 我们会将数据库的性能指标，如IO使用率、CPU使用率、慢查询SQL数量等聚合到深度学习平台，并基于这个深度学习平台对曲线进行合理的预测。

当我们发现某个实例的某些性能指标不在预期范围内时，我们会对其进行预警。 从实际应用情况来看，这还是很有效的，可以提前发现一些潜在的风险。

第二个我们做的是一个基于数据库日志和ES的日志分析系统。 我们会将整个TDSQL的所有日志，包括中间件、监控、调度日志，都存储到ES库中，然后做一些SQL耗时统计和SQ执行计划分析。 基于这些分析，一些可能现在还没有生成，但是提前挖掘出可能造成风险威胁的SQL，从而可以优化业务。

讲师简介

胡盼盼

微众银行数据库平台办公室经理，腾讯云TVP

微众银行数据库平台办公室经理，腾讯云TVP。 毕业于华中科技大学，获硕士学位。 毕业后加入腾讯任高级工程师，从事分布式存储和云数据库的研发和运营。 2014年，在微众银行筹备成立之际，他加入了微众银行的基础设施团队。 亲身经历和见证了微众银行分布式核心架构从无到有的构建和发展，也参与了微众银行基础设施1.0到基础设施2.0的重大演进。 目前全面负责微众银行数据库平台的建设和运营，包括关系数据库平台和KV数据库平台。

点击观看精彩的峰会总结视频