对数据库要求最苛刻的金融行业，这套架构凭什么异军突起？

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

点击可观看精彩演讲视频html

1、金融行业数据库趋势

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

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

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

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

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

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

2、微众银行单元化架构

下面介绍一下微众银行内部的单元华架构究竟是怎么作的。微众银行于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的架构下，可能须要应用层去实现相似的事务框架，来保证总体事务的一致性。

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

上面介绍了微众银行的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分片，这三个分片分别分布在SET一、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万+以上。

4、将来的架构演进方向

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

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

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

第三个方向，是智能化预警和运维。对于DBA来讲，很头痛的问题是不少时候是问题发生了再去解决、定位它，但这时候已经对业务和交易产生了影响，比较被动。因此咱们一直在作的是但愿能经过一些智能化的方式提早把这种风险和故障发现并预警，提早解决，这也是咱们如今的痛点。

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

当咱们发现某一个实例的某些性能指标不在预期范围内，就会提早把它预警出来。从实际的应用状况来看，这仍是很是有效的，能够提早发现一些潜在的风险。

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

讲师简介

胡盼盼

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