作为首家获得互联网牌照的保险公司，众安保险与云计算携手走过了5年的时间，这五年的时间内，众安保险见证了阿里云的成长和成熟，也走出了属于自己的一条上云之路，那么众安保险云上的数据库设计有哪些故事呢？本文中，众安保险数据库负责人钟海平将为大家揭晓。

众安保险业务背景介绍

众安保险是首家获得互联网牌照的保险公司，同时也是全国最大的互联网保险公司，累计销售保单超过百亿，具有5个整体生态和200多家合作伙伴。因为需要支持很多的互联网业务场景，因此在基础架构设计初期就提出了四个基本要求：在线业务数据存储百T级、“4个9”、毫秒级响应、符合金融监管要求。

众安保险的大部分核心业务都是基于MySQL之上的，主要采用了阿里云RDS，目前Redis尝试向阿里云迁移，其他的数据源是自建的，部分借助阿里云ECS部署。众安保险的DBA团队在2013年底尝试将核心业务系统迁到阿里云上，2014年引进了淘宝分布式中间件并做了数据层水平拆分以及数据库垂直拆分，2015年做了一些配置管理工具，2016年之后主要在自动化运维以及自研数据库中间件进行了一些尝试。

云数据库应用实践

在2013年时，众安保险的数据库架构比较落后，每个产品独立部署数据库，最终所有数据库汇总到财务数据库进行对账。当时大部分核心系统都是外采的，数据模型基本上都是行业通用的。但是在2013年刚使用RDS时也有所收获，使用RDS帮助整个基础环境部署节约了很多事情。不再需要经过繁琐的步骤完成数据库部署，只需要购买即可。

目前，众安所使用的RDS实例大概有300~400个。实际的数据源DB层大概有近2000个，在这种规模化使用的背景下会发现阿里云账户管理以及监控排查等都是很痛苦的。虽然阿里云提供了一整套的产品解决方案，但是如果希望排查某一个数据源某一个指标的异常，需要登录不同的阿里云账号，之后选择不同的实例再看不同的DB，这是非常痛苦的。

MySQL的权限是基于“用户+IP”的，最初阿里云只能提供“只读”和“读写”两种权限，而且后台运维是不可视的。现在阿里云有一个设置“可维护时间段”，这对于用户而言非常好，因为这样在使用云数据库的后台的运维只会在时间窗口进行变更。

初版的优化架构中首先对于RDS进行了分层，不再将RDS看做单独的实例，而是看成RDS实例资源池，并根据不同规格以及资源要求进行了分类。在DB层，对于应用数据源按照不同的产品进行了拆分。其上一层是中间件层，最上面则是应用层，应用提供了整体的查询方案。

对于离线的计算需求，通过Datax回流到ODPS进行支持做BI分析。此外，众安还自己实现了监控方案来排查分库分表等问题。阿里云RDS售卖的其实是数据库服务，其主机是不可访问的。正因如此，宿主机的物理资源是不可见的，所以在监控时对接了阿里云API获得实时的监控数据。此外，众安DBA团队还自己实现了DB Agent用于采集纯DB级别的指标，将采集的数据冗余地存储在时序数据库中。对于一些监控配置项用MySQL存储，对于汇总报告，则使用文件存储。通过实时和离线分析，最终满足各种监控应用场景。

对于有数据库维护经验的人而言，肯定会有资源使用瓶颈的体验。而大部分资源瓶颈就是CPU、内存以及磁盘IO，很少因为磁盘空间不足而产生问题。而在2015年，众安发现阿里云RDS单个实例只支持2T存储空间。在大量的分库分表的情况下，其实单表空间会压缩得很小，因为做了大量分布式事务的拆分，因此效率其实非常高。曾经在迁移的最高峰，用到了上限存储空间的98.7%，达到上限的时候阿里云RDS就会变成只读模式，这是很可怕的事情。解决思路就是使用阿里云DTS做数据迁移，引入了阿里数据TDL中间件做规则路由的调整，重新实现数据散列和分布。

阿里云的DTS数据迁移服务都是在页面上完成配置的。因为有分库分表，那么单个库就能达到上万张表，手动通过页面配置迁移任务是不现实的。此外，任务的异常调度不可知，虽然DTS服务能够帮助将数据全链路地迁移到另外一个数据源，但是迁移过程却是不可感知的。此外，还有毫秒级的延迟，其延迟显示就是几毫秒，而在数据库中一毫秒的QPS就是上万，那么几毫秒的延迟就意味着丢失大量的业务数据。同步效率不可控，在迁移数据的过程中其实业务还是在运行的，怎样尽量减少对于在线业务的影响，是同步效率所需要考虑的。而TDL就完全是一个黑盒了，虽然完成了迁移，但对于具体实现不可知。

针对以上两点，众安尝试做了一些自研，做了内部自研的数据库中间件平台，采用了Proxy代理模式，与MyCat类似。在连接池与配置管理上做了深度优化，借助中间件基本上可以达到直连数据库，在效率上没有什么损耗，甚至于在高并发场景下会优于原生的直连。最大的区别，就是众安内部的DTS在监控管理上做了很多事情，希望迁移过程是可控的，在业务高峰发生异常的时候可以降低速度，但是不用停止，支持在线数据库和备份数据集。众安自研的DTS在启动任务的时候就会采集BinLog，并且通过内部工具进行解析，通过消息消费存储起来。而数据迁移管理工具将会贯穿数据迁移的整个过程，首先迁移数据结构，之后全量迁移数据，之后利用增量的BinLog构建出全新的数据库，借此构建出准实时的数据库。在中间增加缓冲代理DMDS，不仅支持TDL客户端也支持Proxy模式。

业务应用实践

众安保险在业务方面最为突出的三个挑战包括，高频的业务开发，全年纯数据库开发发布超过2万次，日均发布超过60次，线上数据变更也很可怕；此外，众安保险有多个事业部以及孵化的子公司，那么如何让数据在各个子公司之间共享；第三部分就是性能效率的保障。

针对于每天要做的繁琐数据库发布，众安引入了开源组件，加入了自己的流程管理机制，做了自动发布和维护的支持。提交的数据库支持仓库，也支持本地数据文件。预检查就是检查本次发布是否会造成冲突，是否可以发布，是否有业务影响，是否处于业务高峰期，当然还有很多校验。拆分可执行文件就是做了很多分库分表的工作。执行简单而言就分成了三部分，创建类、变更类和DML更新类。整个过程DBA都可以参与监控，实时进行干预。

针对于数据安全共享，众安保险搭建了一个平台，实现了一些补充和完善。实现了安全保障和风险管控，以及用户内部账号赋权等。对于实时发现的异常可以实时进行阻断，还有贯穿全程的审计，包括数据库层面的审计、提交需求应用的审计以及最终展现的审计。

对于性能效率方面的解决方案，主要分为资源环境类、SQL执行类。在用RDS的时候用几个不同的规格做了内部的针对自身业务场景的性能测试，也沉淀了一些容量预估经验。在SQL执行这部分引入了很多分析方法，比如索引分析以及碎片分析，对应到后台就是一些定时任务以及自动扫描，嵌套到管理工具里面，发生需求的时候可以实时判断是否去做。由于阿里云帮助做了很多，因此DBA不需要太多关注底层的事情。主要一套监控体系即可，发生问题再去处理，而主要精力用于支持业务，更多地参与到业务本身的模型设计和架构设计本身上去。

借助自研的DTS和数据库中间件可以实现任意地水平拆分。当发生故障的时候可以实时地捕获数据库的状态。而对于很多企业而言，经常会因为一些运维人员或者运营人员的误操作误删了数据，使用备份数据恢复是一件很痛苦的事情，因为变更的是一条简单的数据，所以在众安通过反解析BinLog实现了应急闪回，精准地定位到需要闪回的数据，通过BinLog解析恢复数据，进而大大地节省了时间成本。