导语 | 在金融行业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提前开掘进去，让业务去优化。
讲师简介
胡盼盼
微众银行数据库平台室室经理、腾讯云TVP。硕士毕业于华中科技大学，毕业后退出腾讯，任高级工程师，从事分布式存储与云数据库相干的研发与经营工作；2014年在微众银行操办之时，就退出了微众银行基础架构团队，亲历和见证了微众银行分布式外围架构从无到有的建设与倒退，也参加了微众银行基础架构1.0到基础架构2.0的重大演进。目前全面负责微众银行数据库平台的建设和经营，包含关系数据库平台和KV数据库平台。