本文根据Xiao Bo老师在“2021 vivo开发者大会"现场演讲内容整理而成。公众号回复【2021VDC】获取互联网技术分会场议题相关资料。
[图片上传失败...(image-75f88f-1643073893186)]
以史为鉴，可以知兴替，做技术亦是如此，在介绍平台之前，我们首先来一起回顾下vivo互联网业务近几年的发展历程。
我们将时间拨回到三年前来看看 vivo 互联网产品近几年的发展状况，2018年11月，vivo移动互联网累计总用户突破2.2亿；2019年应用商店、浏览器、视频、钱包等互联网应用日活突破千万大关；2020年浏览器日活突破1亿，2021年在网总用户（不含外销）达到2.7亿，数十款月活过亿的应用，数据库和存储产品的也达到了4000+服务器和5万+数据库实例的规模。
那三年前的数据库和存储平台是什么样呢?
2018年的数据库服务现状如果用一个词形容，那我觉得“危如累卵”最适合不过了，主要表现为以下几点；
数据库线上环境的可用性由于低效的SQL、人为的误操作，基础架构的不合理，开源产品的健壮性等问题导致可用性经常受到影响。
变更不规范，变更和各种运维操作的效率低下，没有平台支撑，使用命令行终端进行变更。
数据库使用的成本极高，为了应对日益复杂的业务场景，增加了很多额外的成本。这些就是2018年当时vivo的数据库现状。
安全能力不够健全，数据分类分级、密码账号权限等缺乏规范。
我们再看看这些年vivo数据库一些运营数据上的变化趋势。
[图片上传失败...(image-57be35-1643073893186)]
从17年底，18年初开始计算，这三年时间里面数据库实例的规模增加了接近5倍，所维护的数据库服务器规模增加了6.8倍，数据库实例的单机部署密度增加了5倍以上，DBA人均运维的数据库实例规模增加了14.9倍。
通过以上这些数字，我们发现近几年vivo互联网业务其实是处于高速发展的状态，在高速发展的过程中无论是从用户感受到的服务质量上来看还是从内部的成本效率来看，解决数据存储的问题是迫在眉睫的事情，于是我们在2018年启动了自研数据库与存储平台的计划，通过几年时间的建设，我们初步具备了一些能力，现在就这些能力给大家做下简单的介绍。
首先来整体对数据库与存储平台产品做下介绍，主要分为2层。
工具产品主要以自研为主，下面一层的数据库和存储产品我们会优先选用成熟的开源产品，同时也会在开源产品的基础上或者纯自研一些产品用来更好的满足业务发展，下面就部分产品的能力做下简单的介绍。
[图片上传失败...(image-47652b-1643073893186)]
[图片上传失败...(image-695b3b-1643073893186)]
DaaS平台是Database as a Service的缩写，该平台旨在提供高度自助化、高度智能化、高可用、低成本的数据存储使用和管理的平台，涵盖了数据库和存储产品从服务申请、部署、维护直至下线的全生命周期，主要从四个方面为公司和用户提供价值。
通过几年时间的建设，以上工作取得了一些进展，其中每月数以千计的需求工单，其中90%以上研发同学可以自助完成，服务可用性最近几年都维持在4个9以上，平台对6种数据库产品和存储服务的平台化支持达到了85%以上，而且做到了同一能力的全数据库场景覆盖，比如数据变更，我们支持MySQL、ElastiSearch、MongoDB、TiDB的变更前语句审查，变更数据备份，变更操作一键回滚，变更记录审计追踪等。
[图片上传失败...(image-7d0478-1643073893186)]
[图片上传失败...(image-634fc3-1643073893186)]
vivo的DTS服务是基于自身业务需求完全自研的数据传输服务，主要提供RDBMS、NoSQL、OLAP等数据源之间的数据交互。集数据迁移、订阅、同步、备份的一体化服务，从功能上来看，主要有三个特性；
下面我们再来看看我们在底层数据存储层做的一些项目，首先来看看MySQL数据库。
[图片上传失败...(image-f12f6d-1643073893186)]
[图片上传失败...(image-ef909-1643073893186)]
第一版为了快速解决当时面临的可用性问题，基于MHA+自研组件做了1.0版本。
目前已经演化到了2.0版本，MHA等组件依赖已经没有了，从架构上看，2.0版本的服务接入层我们支持业务使用DNS或者名字服务接入，中间加入了一层自研的代理层Proxy，这一层做到了100%与MySQL语法和协议兼容，在Proxy上面我们又实现了三级读写分离控制，流量管控，数据透明加密，SQL防火墙，日志审计等功能。
Proxy层结合底层的高可用组件共同实现了MySQL集群的自动化、手动故障转移，通过RAFT机制保障了高可用管控组件自身的可用性，当然MySQL用的还是主从架构，在同地域可以跨IDC部署，跨地域同步可以用前面提到的DTS产品解决，跨地域多活目前还未支持，这块属于规划中的3.0架构。
[图片上传失败...(image-81dba6-1643073893186)]
Redis作为非常流行和优秀的KV存储服务，在vivo得到了大量的应用，在vivo互联网的发展历程中，有使用过单机版的Redis，也有使用过主从版本的Redis。到目前为止，已经全部升级到集群模式，集群模式的自动故障转移，弹性伸缩等特性帮我们解决了不少问题。
但当单集群规模扩大到TB级别和单集群节点数扩展到500+以后还是存在很多问题，基于解决这些问题的诉求，我们在Redis上面做了一些改造开发，主要包括三部份：
我们在Redis上做了这些优化后，发现仅仅有内存型的KV存储是无法满足业务需要，未来还有更大的存储规模需求，必须有基于磁盘的KV存储产品来进行数据分流，对数据进行分层存储，为此我们研发了磁盘KV存储产品。
我们在启动磁盘KV存储服务研发项目时就明确了业务对存储的基本诉求。
第一是是兼容Redis协议，可以很方便的从原来使用Redis服务的项目中切换过来。
第二是存储成本要低，存储空间要大，性能要高，结合运维的一些基本诉求比如故障自动转移，能够快速的扩缩容等。
最终我们选择了以TIKV作为底层存储引擎实现的磁盘KV存储服务，我们在上层封装了Redis指令和Redis协议。其中选择TIKV还有一个原因是我们整体的存储产品体系中有使用到TiDB产品，这样可以降低运维人员学习成本，能够快速上手。
我们还开发了一系列周边工具，比如Bulk load批量导入工具，支持从大数据生态中导入数据到磁盘KV存储，数据备份还原工具，Redis到磁盘KV同步工具等，这些工具大大的降低了业务的迁移成本，目前我们的磁盘KV存储产品已经在内部广泛使用，支撑了多个TB级别的存储场景。
[图片上传失败...(image-39666-1643073893186)]
我们知道业务运行过程中除了需要对一些结构化或者半结构化的数据有存取需求之外，还有大量的非结构化数据存取需求。vivo的对象与文件存储服务正是在这样的背景下去建设的。
对象和文件存储服务使用统一的存储底座，存储空间可以扩展到EB级别以上，上层对外暴露的有标准对象存储协议和POSIX文件协议，业务可以使用对象存储协议存取文件、图片、视频、软件包等，标准的POSIX文件协议可以使得业务像使用本地文件系统一样扩展自己的存取需求，比如HPC和AI训练场景，可以支撑百亿级别小文件的GPU模型训练。
针对图片和视频文件，还扩展了一些常用的图片和视频处理能力，比如水印，缩略图、裁剪、截祯、转码等。前面简单介绍了vivo数据库与存储平台的一些产品能力，那么下面我们再来聊聊在平台建设过程中，我们对一些技术方向的探索和思考。
[图片上传失败...(image-f4c97b-1643073893186)]
[图片上传失败...(image-59039f-1643073893186)]
在平台建设方面，运维研发效率提升是老生常谈的话题，在业内也有很多建设得不错的平台和产品，但是关于数据存储这块怎么提升运维研发效率讲的比较少。
我们的理解是：
在研发域，我们需要思考如何解决研发同学关于数据库和存储产品的效率问题。交付一个数据库实例和支持他们在平台上可以建库建表是远远不够的，很多操作是发生在编码过程中的，比如构造测试数据，编写增删改查的逻辑代码等等。
我们希望在这些过程中就和我们的平台发生交互，最大程度的提升研发效率。
在运维域，我们认为目前有一个比较好的衡量指标就是日常运维过程中需要登录服务器操作的次数，将运维的动作全部标准化、自动化，并且未来有一些操作可以智能化。在研发和运维交互的部分，我们的建设目标是减少交互，流程中参与的人越少效率就越高，让系统来做决策，实现的方案是做自助化。下面我们在看看安全这块的一些探索和思考。
[图片上传失败...(image-f55452-1643073893186)]
[图片上传失败...(image-65ac67-1643073893186)]
安全无小事，为此我们将数据库安全和数据安全的部分单独拿出来进行规划和设计，基本的原则就是权责分明，数据库体系涉及到账号密码等。
我们联合SDK团队共同研发了密码加密传输使用方案，数据库的密码对研发、运维而言都是密文，在项目的配置文件中依然是密文，使用时对接公司的密钥管理系统进行解密。
针对数据的部分，我们联合安全团队对敏感数据做了自动标注识别，分类分级，对敏感数据的查询、导出、变更上做了严格的管控，比如权限管控、权限升级、通过数字水印技术进行使用追踪，通过事后的审计可以追溯到谁在什么时刻查看了什么数据。针对敏感数据我们也做了透明加解密操作，落盘到存储介质的数据是经过加密存储的。
同理，备份的数据和日志也做了加密存储，这些是目前我们做的事情，未来安全这块还有很多的能力需要建设。下面我们再来看看变更这块。
[图片上传失败...(image-b2c8bc-1643073893186)]
[图片上传失败...(image-e95a08-1643073893186)]
接下来我们再介绍下成本这块的一些思考。
关于成本这块我们主要从四个方面进行管理；
成本这块还有一点就是硬件资源的迭代，这块也很关键，这里就不做过多的介绍。然后我们再来看下存储服务体系这块。
[图片上传失败...(image-ffd765-1643073893186)]
以上就是我们目前在建设的能力的一些探索和思考，最后再来看下我们未来的规划。
[图片上传失败...(image-4e906-1643073893186)]
在整个存储服务层，我们会不断的完善存储服务矩阵，打磨产品，提供更多元的存储产品，更好的满足业务发展诉求。同时在存储服务层会基于现有存储产品做一些SAAS服务来满足更多的业务诉求。在功能层，我们拆解为4部分：
数据基础服务，这部分提供存储产品基本功能，包括部署、扩缩容、迁移、监控告警、备份恢复，下线回收等等。
数据服务，存储产品本质上是存储数据的载体，针对数据本身我们也有一些规范，最基本的比如数据的查询变更性能优化，数据治理和如何深入到业务编码过程中去。
存储自治服务，初步划分为性能自治、容量自治、智能诊断、场景服务四大块，通过自治服务一方面可以提升DBA工作的幸福感，一方面也可以大大的提升我们系统本身的健壮性和稳定性。
数据安全服务，目前虽然建设了一些能力，但是不够体系，未来还需要加大投入。