共计 7217 个字符，预计需要花费 19 分钟才能阅读完成。
作者：vivo 互联网平台产品研发团队 – He Zhichuang、Han Lei
手机云服务目前作为每家手机厂商必备的一项根底服务，其服务能力和服务质量对用户来说能够说是十分重要。用户将本人大量的信息数据存储在云端，那咱们的云端服务如何保障服务的稳固和数据的平安，以及如何应答越来越多用户群体的应用？本文将次要介绍 vivo 手机云服务零碎的建设历程。
一、背景
简直每家手机厂商都为用户提供了信息存储的云服务能力。通过一个账号，用户能够将手机零碎中的各种罕用的信息备份到云端，以便后续在适合的工夫点查看或复原本身的数据。然而因为用户量级微小，服务在设计零碎的时候须要思考的因素特地多，比方如何保障服务的稳定性，如何保障大文件的传输效率，以及如何保障用户文件的数据持久性等等。
除此之外，随着越来越多的终端用户开始应用 vivo 云服务，存储和计算的老本也一劳永逸。可能有局部人理解，某些手机厂商的云服务产品年度亏损数亿级别，而次要老本之处来自用户私人文件的存储老本。
另外，在平安方面，云服务在这块须要承当的使命更是重中之重。某些厂商的云服务已经呈现过用户数据泄露，竟然能够通过搜索引擎间接查问到用户的私人文件，这种事件一旦呈现，对企业品牌的打击和影响能够说是十分微小。
如上所述，云服务在建设过程中能够说是困难重重，那么 vivo 云服务在建设过程中，又是如何兼顾产品性能、资源老本、服务稳定性、数据安全等等诸多因素而进行设计的？且听后文细细合成。
二、产品能力与设计
2.1 性能介绍
2.1.1 多设施数据同步能力
当今智能设施倒退迅速，各个手机厂商相继推出了 PAD、智能手表等设施。因而不同设施之间的数据互通诉求也随之而来，一个帐号实现数据互通。
拿 vivo 为例，vivo 帐号能够同时在 vivo 手机、vivo PAD、PC 上登录，用户能够在手机、PAD、PC 上同时对联系人、日历等内容进行编辑，一端编辑，多端可见。
这种多设施数据同步互通就是云服务的一项外围性能。以后云服务反对同步的数据项：联系人、日历、便签、书签、黑名单、蓝牙、WLAN，后续会反对更多的数据项。
2.1.2 整机数据打包备份、恢复能力
手机行业性能更新迭代很快，新的亮点性能会吸引用户购买新机。然而新机购买回来后，各种数据的设置、新增对用户来说是个繁琐、头疼的事件。
为了不便用户将旧手机的数据迁徙到新手机上来，手机厂商提供了一些数据迁徙工具。如我司的互传，新老手机放在一起通过蓝牙能够不便的将数据导入新手机上。然而互传必须要求 2 个手机在一起，如果用户旧手机不在身边呢？
此场景下，云服务提供的整机打包性能很好的解决了此痛点。用户在应用旧手机期间，能够关上云服务的整机备份开关，云服务会主动将用户手机数据打成数据包备份至云端。
在用户购买新手机换机时，能够通过云服务疾速抉择老手机的打包数据进行复原，方便快捷。
2.1.3 云盘能力
云盘是一种业余的互联网存储工具，是互联网云技术的产物，它通过互联网为企业和集体提供信息的贮存，读取，下载等服务。具备平安稳固、海量存储的特点。
在 vivo 云服务中，除了诸如联系人、短信等数据类型内容的备份恢复能力之外，文件类型的云端存储能力，即云盘的能力同样重要。
用户能够将本人本地重要的图片、视频、文档等重要文件备份到云端，以便后续能够在云端后者在其余设施上能够拜访到该文件，同时借助于云盘的能力，用户也能够方便快捷的开释整顿本地空间。
除此之外，云盘还提供了丰盛的文件周边性能，例如压缩文件的在线解压，视频的在线播放，以及文档在线合作等等。
2.2 能力建设
2.2.1 多设施数据一致性同步方案设计
云服务数据同步的计划采纳的是相似于 Git 版本治理的概念，次要波及 2 个行为：
- 推数据：将本地设施增量数据推送至云端。
- 拉数据：将云端增量数据拉取至本地。
次要须要理解的有以下 2 点：
- 增量数据辨认；
- 数据抵触解决。
（1）增量数据辨认
云服务采纳的是基于数据版本的辨认计划：云端每条数据都有本身的版本号，版本号逐渐递增。
次要同步流程如下图：
如图可见，增量数据同步过程并不简单，整个流程总结如下：
- 客户端获取云端以后最大的数据版本 sv；
- 若客户端本地数据最大版本 lv < sv，则证实云端数据有更新，客户端须要拉取云端增量数据；
- 若 lv = sv，则客户端判断本地是否存在增量更新数据，若有则将本地增量数据推送到云端。
（2）数据抵触解决
数据抵触呈现在多设施同时应用的过程中，同时对同一条数据进行操作，造成数据抵触的状况。
因而同步数据流程须要思考数据抵触的场景。
常见的抵触解决方案有 2 种：a、主动为用户解决抵触。b、用户手动自行解决抵触。
主动为用户解决抵触个别有以下计划：
- 以最新的数据批改工夫为准，以批改工夫最迟的设施的数据为准。（多设施时钟无奈对立问题，前面上报的数据可能并不是用户实际上最初批改的）
- 2 条数据都保留。（会给用户造成数据反复的错觉，影响体验）
用户手动自行解决抵触：
参照 git 的抵触解决形式，抵触数据展现给用户，由用户自行抉择内容的存留，最初将最终数据推送到云端。
因为云服务对接了很多不同模块的数据：联系人、日程、浏览器书签，不同数据的个性不一样，每种数据的抵触解决的规定也不一样。因而云服务采纳了将抵触数据返回给业务模块，供业务模块自行解决的策略，于业务方采纳上述哪种解决形式，由业务方自行决策。
2.2.2 整机数据打包备份、复原设计
云服务采纳的是将本地不同模块的数据打包成文件，上传至云盘的计划。
通过树形构造，将整个包、不同模块、不同模块的数据文件进行关联，复原数据时，通过父包 parentId 即可获取到所有的数据文件的 metaId，进行复原即可。
此计划的长处：不便疾速扩大备份手机其余模块的数据，服务器基本上不须要进行革新。
当然此计划也存在劣势：设施不同模块的数据格式对服务器属于黑盒，服务器难以针对模块的数据做实时的解析和展现。
2.2.3 云盘方案设计
绝对于数据我的项目的同步备份，云盘模块次要聚焦的是文件类型的云端存取。
和一般业务模型相比，云盘业务的显著特点是逻辑简单，须要思考的细节很多：例如空间占用、数据安全、大文件传输效率等等，因而整个的零碎设计更加简单。
1、对象存储简介
《对象存储》是由云存储供应商提供的一套基于对象的海量存储服务，个别能够为用户能够提供海量、平安、高牢靠、低成本的数据存储能力。
在 vivo 云服务的存储逻辑中，用户的图片、视频、音频等文件目前均存储在对象存储服务中。
因为晚期 vivo 外部并无自建的对象存储能力，故一开始这部分数据均寄存在私有云，随着近两年 vivo 自建对象存储能力的欠缺，目前私有云数据已齐全迁徙到了自建存储。
2、云盘零碎架构
如上图所示，云盘波及到的周边模块泛滥，然而最外围的还是元数据模块、空间治理模块、文件解决这三个模块，概述如下：
元数据模块：次要用来形容文件的属性，例如文件的名称，文件的大小，媒体文件的长宽低等等。更形象的，元数据模块保留了除了文件实体内容之外的所有信息。
然而，为了零碎后续的可扩展性，咱们针对元数据模块还进行了“动静”拆散。
具体如下：
不同的业务所关注的元数据信息不尽相同，比方除了一些名称大小这些公共属性外，云相册业务还会关注诸如文件拍摄工夫，exif 中的特定字段等等，而这些字段在别的业务中却不会应用。
所以咱们持续将动态的不会变动的公共信息持续进行了一层沉降，即上图中的专用元数据层。这一层寄存了文件的大小、状态、文件摘要值，存储在对象存储的路劲等核心内容。
空间模块：和大部分手机厂商一样，云服务默认会容许每个用户收费应用的 5G 空间，如果存储总量级超出了 5G，那么用户则须要购买 VIP 以晋升空间容量。
那么对于用户空间信息的治理，咱们有一个对立的空间模块进行收纳管控。
文件解决模块：此模块次要提供用户文件数据的上下行能力。比方文件的断点上传下载能力，媒体文件的缩略图解决能力，压缩包文件的在线解压能力等等，都由该服务承载。
上面，咱们次要来理解下最外围的文件上传流程，如下图所示。
在理论的业务解决中，文件上传的整个流程其实远远不止上述时序图这么简略，比方文件缩略图的解决，比方用户身份的校验，或者是危险文件的辨认，加密的解决等等。
三、稳定性建设
3.1 分库分表方案设计
因为云服务业务应用用户量级微小，所以在关系型数据库的设计上，也要思考后续频繁扩容的场景。
对于云服务的分库分表实际，这里不再开展形容，感兴趣的能够参考这篇文章：你分库分表的姿态对么？——详谈程度分库分表
3.2 云盘文件大文件稳定性传输
和一般的业务数据交互相比，文件的上下行动作就显得特地 ” 轻便 ”，因为每次解决都要传输大量的文件报文。
那试想，如果用户在上传一个上 G 的文件，忽然遇到了弱网环境而中断了链接，那下次复原链接之后，还须要从头开始上传，这样无非会对整体文件的传输体验带来十分大的影响。
3.2.1 文件分片技术
在客户端进行文件上传时，咱们会约定一个分片大小阈值。咱们会将文件切割成一组组大小不超过阈值的文件片段，而后对每个片段进行传输。
这样如果端上遇到了弱网环境，那么咱们也只有对失败的分片进行重传即可，大大晋升了整体文件传输的性能。
3.2.2 断点下载
同样，客户端进行文件下载时，如果下载一半网络断开了，那么下次又须要对整个文件进行从新下载。
所以，vivo 云盘在对文件下载时，也应用了断点下载能力，次要基于 HTTP 的 Range 头信息，对须要的文件资源进行定位截取。
因为前文形容了文件在上传的时候通过分片技术将文件进行了拆分，那么在断点下载的时候，能够通过 Range 中的范畴计算失去具体波及的存储路劲，无需进行多余的 IO 操作。
四、资源老本
以后云服务用户数据规模颇大，诸如元数据类存储在数据库中的数据总条数曾经超过了 5000 亿、而文件类总占用空间也超过了百 PB。
如此海量数据的存储，每年消耗的磁盘老本和数据库老本都是一笔不小的数目，因而云服务在节省成本上也做了不少动作。
4.1 对象存储降本
随着在网用户的量级越来越大，用户每天须要备份的文件数量也呈日趋增大，那么如何从技术层级进行降本呢？
咱们这边次要进行了以下几个方面的摸索和开掘。
4.1.1 存储分级
在 vivo 对象存储自建实现之前，云盘也是将数据寄存在私有云的对象存储上。
存储分级技术次要是将不同的数据采取不同的存储形式别离存储在不同性能的存储设备上。
一般来说，私有云将对象存储的存储分成三种类型（局部私有云会有四层或更多），即规范存储，低频存储，归档存储。
以下为某私有云的存储分级报价状况：
在规范存储和低频存储的抉择方面，咱们假如：S 为以后存储总量，G 为每月取回总大小，那么通过数据计算，咱们能够推导出：
两者老本统一的临界条件为：G/S = (P1-P2)/R2。
代入私有云报价，G/S = 1.23。
即如果每月的文件取出率小于 123%，则应用规范能有更优的老本，而如果大于 123%，则应该应用低频存储。
然而对于用户行为进行剖析，用户对文件进行存储后，后续拜访源文件的概率十分小，然而用户可能会常常到云端去查看本人的文件，这个时候展现的大部分是缩略图。
于是咱们将源文件和缩略图进行拆散，将源文件应用低频存储，将缩略图进行规范存储，取得了比纯低频更优的最终老本。
4.1.2 文件预上传
和大部分其余厂商技术实现可能存在不同，在 vivo 云盘的文件上传流程中，有一个十分重要的一环，即文件的预上传。
在进行理论文件二进制流的上传之前，云盘客户端会读取文件的各项属性，诸如文件名，大小，长宽、照片的拍摄工夫等信息，将这部分数据传输给服务器，咱们把这一步叫做预上传。
而服务器则会进行用户残余空间大小的逻辑计算，如果残余空间不足以寄存该文件，则会间接终止上传流程。
如果空间足够，此时服务器在此时就会扣减用户空间，而后才会进行下一步的文件体传输。而大部分其余友商只有当文件实现整个上传流程时才进行空间扣减。
该逻辑能保障同一个用户在进行多线程上传，或者多个设施同时上传时，不会呈现空间超用的情景。
4.1.3 文件秒传
不晓得大家平时在应用一些云盘相似工具的时候有没有发现，本人明明上传了一个很大的文件，然而却很快就实现了。
那么这种疾速进行文件上传的能力，咱们这边就成为 ” 秒传 ”，形象的释义就是好像在秒级实现了一个大文件的传输。
“ 秒传 ” 不仅对用户体验有肯定的晋升，而且也能节俭比拟可观的存储老本。
在 vivo 云盘的设计中，秒传又分为用户级秒传和全局秒传，分叙如下：
- 用户级秒传：用户上传本人之前已经上传过的文件时，触发秒传动作。
- 全局秒传：用户上传的文件之前有其他人上传过，触发秒传动作。
秒传的设计思路较为简单，用户进行预上传时，将文件摘要告知服务器，服务器查问该摘要值是否曾经存储，若存在就告知客户端无需进行文件实体的传输。
4.2 MySQL 压缩
云服务用户的非文件类数据次要还是存储在 MySQL 数据库里。海量的数据存储随着带来的是 MySQL 的硬件老本的晋升。以后云服务 MySQL 数据库实例就有将近 30+。
为了尽可能升高 MySQL 的存储老本，云服务对 MySQL 的数据做了相应的数据压缩。
云服务采纳的是 MySQL 官网提供的 innodb 压缩计划：
MySQL5.1.38 版本之前只有 innodb-base 的存储引擎，默认文件格式为 Antelope, 此文件格式反对 2 种行格局（ROW_FORMAT）：COMPACT 和 REDUNDANT，这 2 种都不是数据压缩类型的行格局。
MySQL5.1.38 后引入 innodb-plugin，同时引入了 Barracude 类型的文件格式。Barracude 齐全兼容 Antelope 的文件格式，同时反对另外 2 种行格局 DYNAMIC、COMPRESSED（反对数据压缩）。
云服务通过线上实际，对联系人数据库进行压缩验证：压缩之前磁盘占用空间 2.75T，压缩后空间 1.3T，压缩率可达 50%。
阐明：压缩成果取决于表的字段的类型，典型数据通常具备反复值，因而可能无效压缩。CHAR，VARCHAR，TEXT、BLOB 这类字符串类型的数据通常可能很好地压缩。而二进制数据 (整数或浮点数字)、曾经通过压缩的数据(JPEG 或 PNG 图像) 通常起不到压缩成果。
五、数据安全
5.1 传输平安
矛盾加密
目前客户端和服务器之间的通信对立通过 HTTPS 进行传输，然而有了 HTTPS 肯定就平安了么？
思考以下场景：
- 客户端 HTTPS 的相干校验均是零碎库实现的，那么作为攻击者能够改写这些零碎库的执行逻辑使得相干校验“生效”，从而发动“中间人攻打”
- 若 APK 被 Hook，也可使得 HTTPS 的相干校验生效，从而发动“中间人攻打”。
所以，为了更高的安全性思考，咱们除了基于 HTTPS 的文件传输，云盘在外围接口上还是用了公司外部自研的矛盾 SDK 加密。
这使得就算 HTTPS 被诸如中间人代理形式获取了明文数据后，还是无奈对音讯体的敏感信息进行提取。
5.2 存储平安
文件存储平安有两个重要局部组成：
- 用户能够在当前任意工夫点拜访到存储在云端的残缺文件，须要保障文件的平安存储永不失落。
- 用户的文件存储是私密的，不该有非预期的人或物能非预期的读取到这些私密文件
咱们把上述的 1 称作为数据的持久性平安，2 称作为数据的隐衷平安。
一般来说，第三方私有云提供的对象存储都能保障 11 个 9 的数据持久性，即 99.999999999%，开启异地备份后，能达到 12 个 9，能满足文件在存储上的持久性要求。所以上面咱们次要聊下用户的隐衷平安。
早在 2019 年，就有某大牌手机厂商，其云端的用户私人照片居然全副泄露，集体的隐衷照片居然能在搜索引擎中查问到，这个就是典型的用户私人文件未被受权即被非法读取应用。
该事件一旦产生，非常容易被舆论发酵，进而迅速影响企业的口碑，所以，这块平安方面的设计就显得重中之重。
存储加密
咱们能通过很多技术手段保障本身服务的足够平安，但因为用户文件最终存储在私有云的对象存储中，而各家私有云的技术实现细节咱们并不知悉，是否真正具备了足够高的安全性，咱们并不能得悉。
所以，咱们针对寄存在第三方私有云的用户数据全副进行了加密，这样，连存储方也无奈获取咱们用户的明文文件，咱们只须要保障本身业务足够的平安，而无需关注第三方对象存储泄露文件的可能性。
在对文件的加密时，咱们更是应用了最为严格的加密伎俩：每个用户的每个文件均应用不同的密钥进行了加密。这样即使 ” 黑客 ” 通过某种技术手段拿到了某一个文件的密钥，他也无奈对大量的其余文件进行解密。
该计划尽管大大晋升了文件的安全性，然而因为文件在业务方存在了加密解密动作，除了对性能有肯定的损耗，一些媒体能力也受到了限度。比方咱们没法间接应用第三方的内容审核、图片解决等服务。
5.3 文件防透露
不应用 CDN
家喻户晓，CDN 技术的成熟倒退，使得终端用户能够就近获取各种网络资源。然而因为 CDN 的实质是对内容进行了缓存，如果咱们将用户的私人文件通过 CDN 的计划进行拜访，那么这些文件被 CDN 运营商以明文形式缓存在了各个边缘节点上，存在被非法获取的危险。
和其余网盘模式不同，vivo 云盘次要以寄存用户私人文件为主，目前并没有凋谢文件的流传分享行为。在这种业务场景下，应用 CDN 的效率并不高，缓存的资源并不会被多次重复利用。所以 vivo 云服务不会对用户的私人文件应用 CDN 技术以晋升性能。
令牌有效期设计
云盘的文件以链接的形式裸露给各客户端进行下载。在链接的设计上，云盘携带了下载令牌，该令牌在肯定有效期内会主动过期。
六、写在最初
vivo 云服务的用户量级目前还在继续减少，从用户体验方面着想，目前云服务的性能齐备性还能够有不少挖掘的点，将来咱们还将构筑以下能力：
- 离线下载能力：用户能够应用云端的下载性能将文件存储到用户的云盘中。
- 文档协同编辑：随着 vivo pad 产品的公布，后续用户能够在不同端基于云服务实现文档的协同编辑。
- 无缝换机体验：推动手机 100+ 数据项接入，为用户打造无缝的换机体验。
