云栖大会分享：买单侠的数据库架构之路

互联网金融行业快速发展的浪潮中，面对海量增长的数据，买单侠走出了自己的数据库架构之路。

本文是买单侠DBA负责人赵怀刚在杭州云栖大会上的分享，介绍了数据库运维中遇到的问题、基于阿里云平台数据库架构的演变和案例和云数据库运维的思考。图1 赵怀刚在分享

秦苍科技是一家专注于为年轻人提供消费分期服务互联网消费金融公司，目前有“买单侠”和“星计划”系列产品，“买单侠”面向中国年轻蓝领用户，提供移动端消费分期服务。“星计划”为年轻女性用户提供医疗美容的消费金融服务。

我们目前有数百万用户，日活在百万以上，每月新增20万用户，增长速度快。

消费金融区别于电商，电商重在库存管理和物流，而分期业务则更偏重于风控。因为有主动借款需求的用户信用度较差，买单侠获客的渠道偏于跟线下手机门店合作。图2 买单侠数据库的发展

互联网金融行业发展速度很快，买单侠从2014年3月成立到现在三年半时间，数据库的规模和数量级也在不断的增长。

目前生产中的数据库实例已经达到200+，DB数量达到了400+，在线数据量在3TB左右（不包含归档历史数据）。

买单侠的技术栈

买单侠后台技术采用的是基于 SpringCloud Netflix + Node.js的微服务架构。

服务部署采用的是阿里云的容器服务，目前微服务数量达到了400+，大部分核心业务已容器化。

目前生产中使用了SQL Server、MySQL等关系型数据库，缓存采用的是Redis，另外一些数据源和第三方的数据采用的是MongoDB存储。

风控技术上有自研抱团算法，风控决策模型可以协助区分好人和坏人，底层使用的是一组图数据库neo4j的集群，生产持久层90%以上是以MySQL为主。

因为最早的技术栈是.net& SQL Server，还有少部分的SQL Server在使用。

发展中遇到的问题

DBA属于运维的一种，买单侠的DBA属于大的运维部门，也是把脑袋拴在别人裤腰带上干活的。

要对生产稳定负责，功劳难量化，有锅就得背，但这也体现了我们的专业性。

即使经常会看到上海陆家嘴的日出，但我们也有自己的目标：

不仅要活着，更要活得好。我们还要有理想，万一实现了呢？

说到这肯定会有人要问，数据库服务都托管到阿里云上，你们DBA每天还要干什么呢？

其实我们也一直在思考这个问题，怎样才能顺应时代的发展，完成个人和DBA工作的升级迭代。

我们的系统最早是单体架构数据库层全部耦合在一起，数据存放在一个实例一个库下面，数据库服务的可用性没办法保证。

在服务改造和拆分过程中同样存在大量的数据迁移，包括大量的异构数据迁移等。

随着公司业务快速发展和数据量增加，DBA面临大量的数据运维工作，如SQL脚本审核、频繁的生产发布以及在安全的前提下满足生产数据查询和变更等需求。

随着阿里云数据库产品的不断完善和升级迭代，怎样结合公司业务很好的集成应用将成为我们工作的重点。

架构演变和案例

最早的架构
最早的架构比较简单，是All in one的单体架构，没有缓存层，所有请求直接访问持久层，在公司初期阶段能满足当时的业务需求。

但随着业务量的增加问题不断的暴露出来，一个慢SQL导致实例CPU飙高而使所有的数据库服务不可用，数据库架构升级迫在眉睫。

为了解决这个问题，接下来我们完成了数据库的拆分和代码的解耦，先是纵向拆分，迫不得已再横向拆分。图3 分组分层的架构

数据库架构的主体设计思路是：分组分层、分而治之。

首先从业务需求特征出发进行数据分类，划分主题域，根据主题域分层，分层的本质是职责的分离，让每层更清晰并且获得更好的伸缩性。

然后从较高的层次对业务数据进行的抽象、归纳，也就是分组（逻辑组）。

因为微服务粒度太细对数据库的管理会是很大的挑战，我们跟后台微服务架构做好映射，但不是一一映射。

我们最终划分了四个层次，分别为业务线层、平台功能层、路由管理层和第三方交互层。

每个层次包含多个逻辑组，例如每个产品线可以定义为一个逻辑组，每个逻辑组会根据功能模块垂直拆分为多个物理实例。

例如有信贷核心平台组，下面会包含账务、账户、借据和交易等功能模块，每个模块分散到不同的物理实例，相互间不会产生影响。

个别业务数据量大的实例根据业务键的哈希算法进行水平拆分。业务数据通过垂直和水平拆分后全部打散部署。

中间的架构
在分组分层垂直拆分的基础上，我们增加了Redis作为缓存层，储存一些数据量小但是访问频率很高的数据，比如字典服务、产品配置、费率等相关数据。图4 中间的架构
跟之前的单体架构相比，除了增加缓存层和架构上垂直拆分打散部署外，部分业务还增加从库实现读写分离和负载均衡。

现在的架构
随着业务发展和微服务化的推进，发现服务层做了很好的管控，但数据层并没有区分，运营和生产做单等还是访问同一份数据。

于是我们根据业务重要性把数据库分为了两类，一个是小核心的做单系统，一个是非做单系统的大外围，也就是瘦核心的思想。

跟上面中间架构的区别主要有三点：
图5 现在的架构

1.增加了一个数据集成区或者叫数据交换平台，是一个数据交换的枢纽，实现核心业务系统与外围系统间的数据交换。

上面这个OLTP定义为小核心层提供联机实时、小数据量的数据服务，保证核心业务服务请求做到实时快速的响应。

数据交换平台层提供批量、大数据量、准实时的数据服务，为运营和准实时数据分析提供数据支持。

举个例子，如放款服务要依赖于审核服务，要等到审核返回结果后才能继续处理，这种实时性要求高而且报文不大的可以走OLTP小核心层。

如果对实时性要求不高，可以准实时传送、数据量又比较大的就走数据交换平台，如每天的对账业务、运营平台查询和大数据平台的对接等业务场景。

数据交换平台是一个大的数据资源池，必须满足两点要求：一个是要能够足够的大，而且能够很好的水平扩展，第二要兼容MySQL协议。

HybridDB 是阿里云自研的数据库产品，同时支持海量数据在线事务（OLTP）和在线分析（OLAP）的混合型分布式关系型数据库，高度兼容SQL，支持海量数据，类似于AWS的Redshift，结合阿里云的DTS服务可以完全满足我们的架构需求。

2.对大数据回流数据做了规范化和集中管控，之前是直接回推到生产各个OLTP实例，做法也比较暴力，直接truncate后全量插入，问题是比较分散而且容易对已有实例产生影响。

我们对所有回流数据进行梳理，把所有回流数据当做是其中一个数据集市，不同业务服务所需数据对应到不同的库和账号存放在同一个数据集市，采取增量推送模式，同时要求线上业务服务做好容错机制，如果推送失败后做好处理避免产生强依赖。

3.引入了DMS数据管理工具，用户可以通过DMS直接访问数据交换平台，在安全、稳定的前提下可以满足研发对生产数据的自助访问，而且支持数据变更和SQL审核，为数据库运维提供了一站式的DevOps解决方案，可以释放DBA做更有价值的业务模型和架构设计。

如何进行数据迁移？

图6 分表分库案例

微服务分布式架构演变过程中少不了数据迁移，数据迁移必然会涉及到对老模型分析、新模型设计以及新老模型之间的映射和转码等问题，所以迁移之前要做好充分准备。

首先要制定迁移总体方案，包括迁移准备、实施步骤、关键点控制、应急预案等。

我们核心账务系统的迭代过程分三步：

1.代码做服务化数据库层不做变动，从单体架构中拆分到独立的数据库实例。

2.将数据库从SQLServer迁移到MySQL并实现读写分离。

3.使用DRDS实现对大表的切分，解决了单表数据量大的问题。

右边虚线框内为第三步Sharding的预案，使用阿里云DTS的数据迁移先把RDS数据实时同步到DRDS，借助DTS订阅和补偿机制实现对DRDS Sharding 后数据的汇总实现上线后的应急预案。

而且这两个操作都可以在线提前执行，服务上线时只是做个配置变更和重启秒级完成，大大缩减了停机时间。

如何部署？

图7 数据运维Pipeline

SQL脚本的部署借鉴了系统发布的思路，首先要有个思维上的转变，把SQL当做是代码的一部分来运维（这里主要是指发布的DDL&DML SQL），即SQL ascode，从最初的数据库设计到审核到发布和优化看做是SQL 运维的pipeline。

研发设计好数据库后，会提交一个SQLrequest到gitlab代码仓库，DBA收到请求后做脚本的审核，通过后会把SQL代码merge到release分支（只能DBA merge）。

未通过的SQL DBA会备注审核建议后驳回到研发进行调整，调整后继续走刚才审核流程。

上线发布时我们采用了flyway，实现自动部署和以及跟代码发布的集成，上线相关DDL/DML的SQL会被当做代码推送到代码仓库，代码部署完成服务启动时会检查本次变更是否存在SQL脚本，有的话就执行没有就跳过。

flyway具备版本控制、rollback机制，因为数据库是有状态的服务，我们没使用这些功能。

如果执行过程中报错或失败，将不再启动服务人工介入排查。数据库发布和代码部署做了很好的集成，这样提高了数据库运维和发布效率，跟上互联网快速发展的节奏。

上线后的优化中，主要是慢SQL的管理分为两类，一类是索引类由DBA后台空窗期维护，另一类是SQL需改写通过Bug管理流程进行跟踪，这样整个数据库的运维从设计-审核-发布-优化完成了闭环。

上面流程中SQL审核还是人工执行，肯定会存在瓶颈。

最初我们想做一个类似于代码检测或扫描的工具：SQL Scan，可以基于预先定义好的规则进行SQL自动发现并审核，审核有问题的SQL再抛出来给DBA确认，这样可以节省80%以上的审核时间。

后来我们发现阿里云的DMS已具备类似功能，目前正在跟DMS做研发流程上的集成，也算是基于云端DevOps的快速实现。

数据库的监控

数据库的监控分为两个部分：基础资源监控和数据监控。

基础资源监控主要借助阿里云监控实现，包括对CPU、磁盘、IOPS、QPS/TPS等常规指标监控，报警方式支持短信、邮件和集成钉钉通知。

数据监控我们主要借助Zabbix对数据库的业务数据进行探测，发现异常后上报到灵犀报警。

灵犀报警是一个第三方监控平台，支持电话报警，紧急事件可以打电话给第一责任人处理，并且支持报警升级，第一责任人未响应的情况下会继续上报到backup人员，确保报警得到尽快解决。

另外阿里云的监控存在两个问题，一个是跨度周期长的监控数据会被平均化，很难定位到当时的负载和问题，二是有固定的保留期限，很难查到半年前的监控历史数据。

而且上面两种监控都属于事中监控，事前监控现在比较传统主要靠DBA主动优化和巡检提前发现并解决。

阿里云的RDS有对所有监控提供API，能够通过API获取到监控数据明细，导入到ELK等做进一步的处理和分析，算是大数据应用在数据库监控的场景，目前在尝试。

AI会取代DBA么？云数据库运维的思考

最近Oracle的OOW大会有提出一个新的名词：自治数据库，把18c定位为可以自动驾驶的自治数据库，结合机器学习实现了自我管理、自我调节、自我安全和自我修复等功能。

目前阿里云已有16种数据库产品，最近阿里云也有发布CloudDBA、PolarDB，而且我们所有的数据库都托管在阿里云上。

云最大的好处是开箱即用和弹性伸缩，基础运维的工作基本已被取代，再加上CloudDBA、DTS、DMS等DevOps把云端整个数据库运维打通，形成了闭环。

在云端不需要开发运维就可以快速实现运维的自动化和智能化，感觉我们的末日就要来了。

但仔细想想AI要完全取代DBA的工作，其实还需要漫长的过程。就好像自动驾驶技术落地一样。

DBA的工作进化

基于云平台，我们的工作也发生了很大的变化，云使工作前置化成为可能，使DBA转向DA成为可能，从底层运维转向结合业务场景的数据库设计，从数据库管理转向数据管理和数据应用。

我们目前要求DBA也要参加架构评审，从项目开始便了解业务，多与产品和研发沟通，搞清楚业务的商业价值和后台技术实现，站在DBA的视角给出与数据设计相关的建议，这也是DBA工作前置化的表现，变被动为主动。

DBA主动了解数据库以外的知识，了解业务、平台、云等，这样才能在众多选择中做好合理规划而不至于迷失，完成从DBA到DA的转型。

数据库生命周期管理

站在产品的角度看每个系统都是有生命周期的，数据也是一样，未来会发展成什么样子？

将一个在其生命周期内不会产生高并发和大数据量的数据库，设计成高并发和水平扩展的架构，这种行为就是在耍流氓。
图8 数据生命周期管理

要充分考虑到数据架构是否对当前业务支持。过度或不合理的设计会带来额外的运维和经济成本。

所以我们认为数据生命周期管理将会成为DBA未来工作的重点，DBA将围绕数据展开工作。

这就要求我们站在系统或产品运营的角度来看待数据运维，这将是一件非常有意义的事情。对于数据的设计我们看做是产品的迭代一样，采用IPO（input-process-output）的方式，数据从输入-处理-输出完成整个生命周期迭代。

思考和总结

梳理下DBA的工作可以分为：运维DBA、应用DBA和业务DBA。

每一个角色的工作重点各不一样，运维DBA更加偏重于数据库的安装和配置、HA高可用、备份容灾以及升级扩容等。
图9 思考和总结

应用DBA是我们当前所处的阶段，主要偏重于数据库相关技术选型、容量规划、性能优化和运维自动化等。

其实阿里云也在将该部分工作实现自动化和智能化，包括CloudDBA、DMS、DTS等外围增值服务。

随着云产品的不断完善和数据库技术的快速发展，会向业务DBA发展，注重于结合业务场景的数据库设计，数据管理和数据应用，用数据来驱动业务为企业创造更大价值。