本文依据 Xiao Bo 老师在“2021 vivo 开发者大会 “ 现场演讲内容整顿而成。公众号回复【2021VDC】 获取互联网技术分会场议题相干材料。

一、数据库与存储平台建设背景

以史为鉴，能够知兴替，做技术亦是如此，在介绍平台之前，咱们首先来一起回顾下 vivo 互联网业务近几年的倒退历程。

咱们将工夫拨回到三年前来看看 vivo 互联网产品近几年的倒退情况，2018 年 11 月，vivo 挪动互联网累计总用户冲破 2.2 亿；2019 年利用商店、浏览器、视频、钱包等互联网利用日活冲破千万大关；2020 年浏览器日活冲破 1 亿，2021 年在网总用户（不含内销）达到 2.7 亿，数十款月活过亿的利用，数据库和存储产品的也达到了 4000+ 服务器和 5 万 + 数据库实例的规模。

那三年前的数据库和存储平台是什么样呢?

2018 年的数据库服务现状如果用一个词形容，那我感觉“岌岌可危”最适宜不过了，次要体现为以下几点；

• 数据库线上环境的可用性因为低效的 SQL、人为的误操作，基础架构的不合理，开源产品的健壮性等问题导致可用性常常受到影响。
• 变更不标准，变更和各种运维操作的效率低下，没有平台撑持，应用命令行终端进行变更。
• 数据库应用的老本极高，为了应答日益简单的业务场景，减少了很多额定的老本。这些就是 2018 年过后 vivo 的数据库现状。
• 平安能力不够健全，数据分类分级、明码账号权限等不足标准。

咱们再看看这些年 vivo 数据库一些经营数据上的变化趋势。

从 17 年底，18 年初开始计算，这三年工夫外面数据库实例的规模减少了靠近 5 倍，所保护的数据库服务器规模减少了 6.8 倍，数据库实例的单机部署密度减少了 5 倍以上，DBA 人均运维的数据库实例规模减少了 14.9 倍。

通过以上这些数字，咱们发现近几年 vivo 互联网业务其实是处于高速倒退的状态，在高速倒退的过程中无论是从用户感触到的服务质量上来看还是从外部的老本效率来看，解决数据存储的问题是火烧眉毛的事件，于是咱们在 2018 年启动了自研数据库与存储平台的打算，通过几年工夫的建设，咱们初步具备了一些能力，当初就这些能力给大家做下简略的介绍。

二、数据库与存储平台能力建设

首先来整体对数据库与存储平台产品做下介绍，次要分为 2 层。

• 第一层咱们的数据库和存储产品，包含关系型数据，非关系型数据库，存储服务三大块。
• 第二层次要是工具产品，包含提供数据库和存储对立管控的研发和运维平台，数据传输服务，运维白屏化工具，还有一些 SQL 审核，SQL 优化，数据备份等产品。

工具产品次要以自研为主，上面一层的数据库和存储产品咱们会优先选用成熟的开源产品，同时也会在开源产品的根底上或者纯自研一些产品用来更好的满足业务倒退，上面就局部产品的能力做下简略的介绍。

DaaS 平台是 Database as a Service 的缩写，该平台旨在提供高度自助化、高度智能化、高可用、低成本的数据存储应用和治理的平台，涵盖了数据库和存储产品从服务申请、部署、保护直至下线的全生命周期，次要从四个方面为公司和用户提供价值。

• 第一是晋升数据库产品的可用性，通过巡检、监控、预案、故障跟踪等对故障进行事先防备、事中及时处理、预先复盘总结进行全流程闭环。
• 第二是晋升研发效力，研发自助应用数据库，提供变更检测、优化诊断等性能，缩小人工沟通流程，我的项目变更标准流程清晰，晋升研发效率。
• 第三是晋升数据安全性，通过权限管控、明码管控、数据加密、数据脱敏、操作审计、备份加密等一系列伎俩全方位的保障数据安全性。
• 第四是升高数据库和存储产品的经营老本，首先通过自动化的流程缩小 DBA 的反复工作，进步人效，其次通过服务编排和资源调度，晋升数据库和存储服务的资源应用效率，继续升高经营老本。

通过几年工夫的建设，以上工作获得了一些停顿，其中每月数以千计的需要工单，其中 90% 以上研发同学能够自助实现，服务可用性最近几年都维持在 4 个 9 以上，平台对 6 种数据库产品和存储服务的平台化反对达到了 85% 以上，而且做到了同一能力的全数据库场景笼罩，比方数据变更，咱们反对 MySQL、ElastiSearch、MongoDB、TiDB 的变更前语句审查，变更数据备份，变更操作一键回滚，变更记录审计追踪等。

vivo 的 DTS 服务是基于本身业务需要齐全自研的数据传输服务，次要提供 RDBMS、NoSQL、OLAP 等数据源之间的数据交互。集数据迁徙、订阅、同步、备份的一体化服务，从性能上来看，次要有三个个性；

• 第一是同步链路的稳定性和数据可靠性保障，通过联合各个数据源产品的本身个性能够做到数据不重不丢，给业务提供 99.99% 的服务可用性保障。
• 第二是性能层面反对异构的多种数据库类型，除了同步、迁徙、订阅等这些通用性能外，咱们还反对变更数据的集中化存储和检索。
• 第三是故障容灾层面，反对节点级别故障容灾，能够做到同步链路秒级复原，也反对断点续传，能够无效的解决因硬件、网络等异样导致的传输中断问题。

上面咱们再来看看咱们在底层数据存储层做的一些我的项目，首先来看看 MySQL 数据库。

MySQL 作为最风行的数据库，在 vivo 同样承当了关系型数据库服务的重任，上图的 MySQL2.0 是咱们外部的架构版本，在这几年工夫外面，咱们的架构演变了 2 版。

第一版为了疾速解决过后面临的可用性问题，基于 MHA+ 自研组件做了 1.0 版本。

目前曾经演变到了 2.0 版本，MHA 等组件依赖曾经没有了，从架构上看，2.0 版本的服务接入层咱们反对业务应用 DNS 或者名字服务接入，两头退出了一层自研的代理层 Proxy，这一层做到了 100% 与 MySQL 语法和协定兼容，在 Proxy 下面咱们又实现了三级读写拆散管制，流量管控，数据通明加密，SQL 防火墙，日志审计等性能。

Proxy 层联合底层的高可用组件独特实现了 MySQL 集群的自动化、手动故障转移，通过 RAFT 机制保障了高可用管控组件本身的可用性，当然 MySQL 用的还是主从架构，在同地区能够跨 IDC 部署，跨地区同步能够用后面提到的 DTS 产品解决，跨地区多活目前还未反对，这块属于布局中的 3.0 架构。

Redis 作为十分风行和优良的 KV 存储服务，在 vivo 失去了大量的利用，在 vivo 互联网的倒退历程中，有应用过单机版的 Redis，也有应用过主从版本的 Redis。到目前为止，曾经全副降级到集群模式，集群模式的主动故障转移，弹性伸缩等个性帮咱们解决了不少问题。

但当单集群规模扩充到 TB 级别和单集群节点数扩大到 500+ 当前还是存在很多问题，基于解决这些问题的诉求，咱们在 Redis 下面做了一些革新开发，次要包含三部份：

• 第一是 Redis Cluster 的多机房可用性问题，为此咱们研发了基于 Redis Cluster 的多活版本 Redis。
• 第二是对 Redis 的数据长久化做了增强，包含 AOF 日志革新，AEP 硬件的引入，包含正在布局中的 Forkless RDB 等。
• 第三是 Redis 同步和集群模式的加强，包含异步复制，文件缓存，水位管制等，还有对 Redis Cluster 指令的工夫复杂度优化，Redis Cluster 指令的工夫复杂度已经给咱们的运维带来了很多的困扰，通过算法的优化，工夫复杂度升高了很多，这块的代码目前曾经同步给社区。

咱们在 Redis 上做了这些优化后，发现仅仅有内存型的 KV 存储是无奈满足业务须要，将来还有更大的存储规模需要，必须有基于磁盘的 KV 存储产品来进行数据分流，对数据进行分层存储，为此咱们研发了磁盘 KV 存储产品。

咱们在启动磁盘 KV 存储服务研发我的项目时就明确了业务对存储的根本诉求。

第一是是兼容 Redis 协定，能够很不便的从原来应用 Redis 服务的我的项目中切换过去。

第二是存储老本要低，存储空间要大，性能要高，联合运维的一些根本诉求比方故障主动转移，可能疾速的扩缩容等。

最终咱们抉择了以 TIKV 作为底层存储引擎实现的磁盘 KV 存储服务，咱们在下层封装了 Redis 指令和 Redis 协定。其中抉择 TIKV 还有一个起因是咱们整体的存储产品体系中有应用到 TiDB 产品，这样能够升高运维人员学习老本，可能疾速上手。

咱们还开发了一系列周边工具，比方 Bulk load 批量导入工具，反对从大数据生态中导入数据到磁盘 KV 存储，数据备份还原工具，Redis 到磁盘 KV 同步工具等，这些工具大大的升高了业务的迁徙老本，目前咱们的磁盘 KV 存储产品曾经在外部宽泛应用，撑持了多个 TB 级别的存储场景。

咱们晓得业务运行过程中除了须要对一些结构化或者半结构化的数据有存取需要之外，还有大量的非结构化数据存取需要。vivo 的对象与文件存储服务正是在这样的背景上来建设的。

对象和文件存储服务应用对立的存储底座，存储空间能够扩大到 EB 级别以上，下层对外裸露的有规范对象存储协定和 POSIX 文件协定，业务能够应用对象存储协定存取文件、图片、视频、软件包等，规范的 POSIX 文件协定能够使得业务像应用本地文件系统一样扩大本人的存取需要，比方 HPC 和 AI 训练场景，能够撑持百亿级别小文件的 GPU 模型训练。

针对图片和视频文件，还扩大了一些罕用的图片和视频解决能力，比方水印，缩略图、裁剪、截祯、转码等。后面简略介绍了 vivo 数据库与存储平台的一些产品能力，那么上面咱们再来聊聊在平台建设过程中，咱们对一些技术方向的摸索和思考。

三、数据库与存储技术摸索和思考

在平台建设方面，运维研发效率晋升是陈词滥调的话题，在业内也有很多建设得不错的平台和产品，然而对于数据存储这块怎么晋升运维研发效率讲的比拟少。

咱们的了解是：

• 首先是资源的交付要足够的麻利，要屏蔽足够多的底层技术细节，为此咱们将 IDC 自建数据库、云数据库、云主机自建数据库进行云上云下对立治理，提供对立的操作视图，升高运维和研发的应用老本。
• 其次要晋升效率就不能只关注生产环境，须要有无效的伎俩将研发、测试、预发、生产等多种环境对立管控起来，做到体验对立，数据和权限平安隔离。
• 最初是咱们使用 DevOps 解决方案的思维，将整个平台逻辑上分为两个域，一个是研发域，一个是运维域：

在研发域，咱们须要思考如何解决研发同学对于数据库和存储产品的效率问题。交付一个数据库实例和反对他们在平台上能够建库建表是远远不够的，很多操作是产生在编码过程中的，比方结构测试数据，编写增删改查的逻辑代码等等。

咱们心愿在这些过程中就和咱们的平台产生交互，最大水平的晋升研发效率。

在运维域，咱们认为目前有一个比拟好的掂量指标就是日常运维过程中须要登录服务器操作的次数，将运维的动作全副标准化、自动化，并且将来有一些操作能够智能化。在研发和运维交互的局部，咱们的建设指标是缩小交互，流程中参加的人越少效率就越高，让零碎来做决策，实现的计划是做自助化。上面咱们在看看平安这块的一些摸索和思考。

平安无小事，为此咱们将数据库安全和数据安全的局部独自拿进去进行布局和设计，根本的准则就是权责明显，数据库体系波及到账号密码等。

咱们联结 SDK 团队独特研发了明码加密传输应用计划，数据库的明码对研发、运维而言都是密文，在我的项目的配置文件中仍然是密文，应用时对接公司的密钥管理系统进行解密。

针对数据的局部，咱们联结平安团队对敏感数据做了主动标注辨认，分类分级，对敏感数据的查问、导出、变更上做了严格的管控，比方权限管控、权限降级、通过数字水印技术进行应用追踪，通过预先的审计能够追溯到谁在什么时刻查看了什么数据。针对敏感数据咱们也做了通明加解密操作，落盘到存储介质的数据是通过加密存储的。

同理，备份的数据和日志也做了加密存储，这些是目前咱们做的事件，将来平安这块还有很多的能力须要建设。上面咱们再来看看变更这块。

针对数据变更的场景，咱们关注的次要有两点；

• 第一是数据变更自身会不会影响已有的业务，为此咱们建设了不锁表构造、不锁表数据的变更能力，针对上线前、上线中、上线后三个环节设置三道防线。杜绝一些不好的 SQL 或者 Query 流入到生产环境，针对变更过程中或者变更完结后如果想回滚，咱们也做了一键回滚计划。
• 第二是变更效率问题，针对多个环境、多个集群咱们提供了一键同步数据变更计划，同时为了更好的晋升用户体验，咱们也提供了 GUI 的库表设计平台。有了这些根底之后，咱们将整个场景的能力全副凋谢给研发同学，当初研发同学能够 24 小时自助进行数据变更操作，极大的晋升了变更效率。

四、摸索和思考

接下来咱们再介绍下老本这块的一些思考。

对于老本这块咱们次要从四个方面进行治理；

• 第一是估算的管控，资源去物理化，业务以资源为粒度进行估算提报，在估算管控层面对服务器的耗费进行预测和一直的修改，保障水位的衰弱。
• 第二是数据库服务的部署，这块咱们经验了几个阶段，最晚期是单机单实例，节约了很多资源，前面倒退为标准化套餐部署，同一类型的存储资源不同的套餐混合，通过算法的优化一直的晋升资源的应用效率。
• 第三是咱们做了一系列不同属性资源的混合部署，比方数据库的代理层和对象存储的数据节点混合部署，这两种资源一个是 CPU 型的，一个是存储型的，正好能够互补，再往后倒退的下一个阶段应该是云原生存储计算拆散，还在摸索中。
• 第四是服务部署之后还须要一直的关注运行中的情况，对容量做巡检和预警，对集群及时的做升降配操作，保障整个运行状态有序。同时须要关注业务运行状态，及时回收下线数据存储集群，缩小僵尸集群的存在。

老本这块还有一点就是硬件资源的迭代，这块也很要害，这里就不做过多的介绍。而后咱们再来看下存储服务体系这块。

对象与文件存储这块咱们次要关注的是两个点；

• 第一个是老本，对于老本这块咱们在数据冗余策略这块应用了 EC，并且做了跨 IDC 的 EC，单个 IDC 全副故障也不会影响咱们的数据可靠性。咱们还引入了高密度大容量存储服务器，尽可能多的晋升单机架存储密度，须要留神的是服务器洽购之后的运行老本也不可漠视，仍然有很大的优化空间。咱们还提供了数据无损和通明压缩的能力和生命周期治理的能力，及时清理过期数据和对冷数据进行归档。通过多种手段继续升高存储老本。
• 第二是性能，对于性能这块咱们提供了桶 & 对象粒度底层存储引擎 IO 隔离，通过引入一些开源组件如 alluxio 等提供了服务端 + 客户端缓存，晋升热点数据读取性能，在底层存储引擎这块咱们引入了 opencas 和 IO_URING 技术，进一步晋升整机的磁盘 IO 吞吐。

以上就是咱们目前在建设的能力的一些摸索和思考，最初再来看下咱们将来的布局。

五、将来的布局

在整个存储服务层，咱们会一直的欠缺存储服务矩阵，打磨产品，提供更多元的存储产品，更好的满足业务倒退诉求。同时在存储服务层会基于现有存储产品做一些 SAAS 服务来满足更多的业务诉求。在性能层，咱们拆解为 4 局部：

• 数据根底服务，这部分提供存储产品基本功能，包含部署、扩缩容、迁徙、监控告警、备份复原，下线回收等等。
• 数据服务，存储产品实质上是存储数据的载体，针对数据自身咱们也有一些标准，最根本的比方数据的查问变更性能优化，数据治理和如何深刻到业务编码过程中去。
• 存储自治服务，初步划分为性能自治、容量自治、智能诊断、场景服务四大块，通过自治服务一方面能够晋升 DBA 工作的幸福感，一方面也能够大大的晋升咱们零碎自身的健壮性和稳定性。
• 数据安全服务，目前尽管建设了一些能力，然而不够体系，将来还须要加大投入。

将来整个存储服务体系会融入到公司整体的混合云架构中，给用户提供一站式和标准化的体验。以上就是分享的全部内容。

作者：vivo 互联网数据库团队 -Xiao Bo