导语 | 在金融行业 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 数据库平台。