作者：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+數據項接入，爲用戶打造無縫的換機體驗。
END
猜你喜歡
本文分享自微信公衆號 - vivo互聯網技術（vivoVMIC）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。