导语 | 在金融行业IT系统国产化的大背景下，国内金融行业开始推动IT基础设施国产化，逐渐摆脱对于传统IOE架构的依赖。微众银行自成立之初，就放弃了传统IOE架构路红，结合腾讯金融级分布式数据库TDSQL，建立了基于DCN单元化架构模式的分布式基础平台。如今这套架构承载了微众银行数亿级别的用户规模，数百套银行核心系统，和每天数亿次的金融交易。本文由微众银行数据库平台室室经理、腾讯云TVP 胡盼盼在 Techo TVP开发者峰会「数据的冰与火之歌——从在线数据库技术，到海量数据分析技术」 的《分布式数据库在微众银行核心系统的实践》演讲分享整理而成，为大家着重介绍金融行业的数据库趋势、微众银行基于单元化的分布式架构，以及基于单元化的数据库架构，并分享微众银行数据库未来的演进方向。

一、金融行业数据库趋势

今天分享的主要内容包含四个方面：第一是介绍金融行业数据库的趋势；第二是介绍微众银行的单元化架构；第三是基于微众银行的单元化架构的数据库架构是怎么做的；第四是微众银行内部对于数据库未来架构的演进方向。

金融行业是相对传统的行业，对于IT基础设施的选型，都是偏保守，之前一直都很稳定走传统IOE架构。但是，近几年产生了一些变化，主要有三个趋势：

第一是国产化的趋势。最近几年的国际形势众所周知，在金融行业这种关键的领域，对于关键的IT基础设施的国产化，是一个国家层面在推动的方向。另一方面，得益于国产化浪潮的推动，国产数据库产品也是百花齐，使得国内的金融企业有很多可以选择的国产数据库。

第二个趋势是去中心化。互联网行业的发展带来数据爆炸性的增长，传统银行现在也在慢慢走互联网化和服务在线化，比如手机银行APP，原来很多业务需要到线下网点去办理，现在手机很行上就可以办理成功，所以带来的数据量的也指数级的增长，原来中心化的架构，比如单机存储或是用共享存储的方式，不管是性能还是容量上可能都没办法承载这种爆炸性的增长。

第三个趋势是开源化。在几年前，金融行业，特别是传统的银行，对于开源这种产品模式其实是不太不信任的，觉得开源的产品，稳定性上没有保证，也没有固定的技术团队支持。但是最近几年这个认知慢慢变化了，很多同行业的传统银行都开始去尝试一些开源数据库，比如MySQL，Redis等。把一些非核心的业务场景跑在开源数据库平台上，而且规模都不小。另外，我们国家对整个开源软件生态建设也在逐渐加大支持，国内开源社区的建设也在慢慢走向成熟。进一步促进了开源数据库在金融行业的应用。

这张图是从国内的一个数据库排名网站上截的，都是现在国内的数据库产品。我们可以看到这张图里，有包括腾讯、阿里、华为这种大厂的数据库产品，也包括目前开源比较流行的产品，还包括一些传统的厂商产品，可以说真的是百花齐放的时代，这在五六年前都是不可想象的。

二、微众银行单元化架构

下面介绍一下微众银行内部的单元华架构到底是怎么做的。微众银行于2014年开始筹办，作为国内第一家民营银行，我们在IT基础架构方面是没有历史包袱的，可以从零去做一个全新的架构。所以当时定的路线是不会再用传统银行的IOE架构，确定了要走基于分布式架构的模式去承载整个银行的核心系统。

最终我们选择了单元化作为我们的架构基础。这里的单元化怎么理解呢？以传统的线下银行类比一下，传统银行，一般在每个省都有一个分行，每个省的分行只负责各个省的客户。微众银行的单元化，就类似这种分行的概念。我们把所有的客户也拆成一个一个单元去管理，每个单元就是固定的用户数量。比如说一个单元里面我们就只承载500万用户的数量，当这个单元用满了以后，就直接再整体去扩一个单元。这个单元我们内部有一个名字：DCN，即最小化的单元化部署单位，DCN里包含了从应用层到中间件、到底层的数据库，可以理解为一个DCN就是一个自包含的小的微众银行。DCN承载的用户数量是固定的，比如说固定的500万或者800万用户，DCN用满之后，再横向扩展一个新的DCN，新的用户就放到新的DCN里。

这个DCN架构会带来两个问题。

第一个问题：比如你是微众银行的用户，要使用微众银行的服务，怎么知道自己在哪一个DCN呢？这里就有一个关键组件：GNS，GNS是负责所有用户的DCN路由信息存储与查询。当一个用户的请求进来，会首先查询GNS，得到所在DCN的定位，再去对应的DCN做后续的请求。

第二个问题：DCN与DCN之间是隔离的，A DCN的一个用户想给B DCN的一个用户转账，转账的消息交换要怎么实现？这里就要提到另一个关键组件：RMB，中文名为：可靠消息总线。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架构对于运维自动化的要求非常高。我们现在生产整个DCN数量已超过100个，对于多DCN的版本管理、版本发布和日常变更都需要自动化运维去做。

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

三、基于单元化的数据库架构

上面介绍了微众银行的DCN单元化架构，基于这个架构的前提，再介绍一下微众银行的数据库架构到底是怎么做的。在介绍数据库架构之前，需要先介绍一些背景知识。

1. 微众银行IDC架构

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

2. 微众银行TDSQL部署架构

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

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

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

再补充一下TDSQL的两种使用模式，一种是NO Shard模式，也就是TDSQL的单实例模式。这种架构下，TDSQL proxy单纯做一个SQL转换的功能，到底层的SET以后，每个STE就是一个独立的单实例架构，SET之间的库是没有关系的，这种No Shard架构没有在中间件层做分库分表，所以逻辑会简单很多。但这种模式的SET需要扩容的话，就只能在SET内部去做垂直扩容。这种架构的优势在于它不涉及分布式事务，也不涉及数据库的分片，所以它的语法是完全兼容的，且架构简洁。

第二种模式是TDSQL Shard模式，Shard模式可以简单理解为一种基于中间件分库分表的模式。通过TDQSL proxy，把某一个库做成三个Shard分片，这三个分片分别分布在SET1、SET2和STE3这三个SET里。这种模式的优点是可以实现容量的水平扩容。但它带来的问题在于对语法的兼容不完美，因为需要在中间件层面实现Shard，就需要一些特殊语法的兼容，比如需要建表的时候带Share key，SQL里面可能也需要带Share key，就需要应用层做适配改造。

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

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

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

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

除了生产的三个副本，我们在上海的跨城容灾还会有两个副本：一个Master、一个Slave。跨城容灾和生产IDC的数据同步由于网络时延的原因是异步的，没有做强同步。

这种架构带来的好处是可以实现同城IDC级别的容灾。也就是同城的生产IDC，挂掉任何一个IDC，比如某一个机房断电了，整个机房失联了，那我也可以保证业务的快速恢复，因为我的数据库也可以自动切换到其它两个IDC。

大家可能会有一个疑问：同城的一主两备是分布在三个机房之间的，机房和机房之间可能会有延迟，我们是控制在两毫秒内，但对性能会不会有什么影响？首先我们在基础设施方面，在机房建设上会设定一些原则，刚才也提到同城IDC的距离控制在50公里之内，IDC之间会建立多条专线，保证带宽和稳定性。我们现在全部都是万兆网络的基础设施，这是硬件层面的保证。另外软件层面是针对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峰值10万+以上。

四、未来的架构演进方向

最后分享一下微众银行数据库未来的演进方向，整体有三个演进方向。

第一个方向是我们正在做的：推进硬件国产化。现在我们大部分的硬件都还是基于X86平台的英特尔CPU架构去做的。从去年开始，在尝试把底层的服务器硬件平台迁移到国产的ARM平台上。我们目前用的是华为鲲鹏的CPU架构，去年在某一个业务上已经实现了从硬件层到中间件、到数据库全链路运行在华为鲲鹏ARM服务器平台之上，今年可能也会继续推动加大规模往国产的ARM平台上迁移。

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

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

举两个例子，一个是我们已经上线的基于深度学习的智能故障预测告警。我们会把数据库的性能指标，比如IO使用率、CPU使用率、慢查询的SQL数量等全部汇总到深度学习的平台上，而基于这个深度学习平台去做曲线的合理预测。

当我们发现某一个实例的某些性能指标不在预期范围内，就会提前把它预警出来。从实际的应用情况来看，这还是非常有效的，可以提前发现一些潜在的风险。

第二个我们正在做的是一个基于数据库日志和ES的日志分析系统。我们会把整个TDSQL所有的日志，包括中间件、监控、调度的日志，全部入库到ES库里，再做一些SQL的耗时统计、SQ执行计划的分析，基于这些分析把一些可能它现在还没有产生，但可能产生风险、威胁的SQL提前挖掘出来，让业务去优化。