董朝：打造雲存儲服務——移動端數據存儲與分發

歡迎你們前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~

做者：董朝，騰訊雲存儲業務終端負責人，2013年加入騰訊，主要負責手Q紅點運營系統、會員、騰訊云云存儲、移動開發平臺的研發和優化工做。在移動端APP構建上面有豐富的經驗，目前主要負責騰訊雲存儲業務終端相關的工做。

先作一個簡單的自我介紹，2011年我畢業之後，一直從事IOS的開發，目前爲止大概有七年的工做經驗，前四年的時間主要在作APP裏開發，以後三年主要作SDK相關的工做開發。

我今天的演講包括兩個部分，第一個部分是關注存儲這一方面，從終端的角度出發，來看看存儲這個東西對咱們來講意味着什麼。第二個部分，簡單分享一下咱們在製做SDK上的經驗和探索。

COS服務介紹

數據存儲 一個通用的基礎服務

爲何要從終端角度考慮呢？當咱們從終端的角度來看待咱們數據存儲的場景的話，更多狀況下，會從業務場景出發，好比有一些頭像上傳、Feed圖片上傳、音頻上傳、視頻上傳、短視頻非結構化的數據，這時注重的是數據集反饋的URL，爲此，咱們須要去匹配相關的上傳及下載接口。

從終端講，其實很簡單，咱們作到了一個倉儲服務，真正的將數據存儲當作了一個透明的事情。對於用戶來說，只須要關注傳輸所關注的事情，給用戶返回一個URL，由URL進行處理。

COS服務

騰訊云爲了完成上面所述的目標，向用戶提供了一套總體的COS服務，一套面向用戶的對象存儲服務。這裏不是數據或者非結構化數據存儲，而是對象存儲。對於端上來說，咱們更多關注數據和URL，COS更偏向於PaaS層的服務，這個URL能夠理解爲一個指向的數據內容，沒有限定具體什麼樣的格式，如音頻、視頻都是能夠存儲的。

當這些數據傳上來以後，首先，騰訊雲會在總體COS的系統內部幫助你們將數據總體倉儲起來，其次，咱們也會配合騰訊雲已有的CDN的能力幫助你們去分發。這樣，對於用戶來說，您只須要咱們的一個SDK，剩下全部的事情在騰訊雲幫你託管。固然這裏咱們這裏只是一個簡單的上傳和下載，對倉儲還有不少事情須要處理的，後面去講。

高併發，高可用

爲了達到圖中高可用、高可靠的11個九的要求，數據的可用性、輸入可訪問性達到3個九的要求，咱們作了不少努力！

對於基於大量併發，端上來說面臨一個問題，咱們屬於分發類的軟件，好比QQ、微信或者本身內部的一些APP，他們有大量的用戶，可能同一秒出現大量同時的上傳或者下載請求，這些都在內部作的一些處理去支持大量的併發。

那這塊如何去解決呢？

當數據傳上來以後，除了上傳、下載通信需求以外，還會有不少管理類的需求。舉個很是典型的例子，好比剛纔說的業務場景，其中一個是頭像的上傳和Feed，或者用戶UGC的內容傳上來以後，最典型的業務是鑑黃。當您的服務數據有少兒不宜的內容後，你將面臨不少問題。因此你的數據傳上來以後，像這些鑑黃、水印處理等工資，原先本身構建服務的狀態下是本身後臺去處理，很是麻煩，你不只須要去構建整套的鑑黃體系，機器學習、人工去處理等，並且這些處理其實很是消耗時間。咱們針對這些需求，整合數據、倉儲處處理的需求，在COS內部幫助你把通用性的需求解決掉，真正作到端上處理您面臨的全部需求。

我這裏分三個層次來說解，咱們在知足這些常見訴求上作了什麼事。

• 一是咱們最關注的數據接口層，如何使用咱們這個服務。這裏經過咱們經常使用的各類各樣的方式，包括API、SDK、控制檯等，如何把服務提供到咱們的客戶或者終端開發人員，這一層能夠簡單地歸結爲一個使用界面層。我如今從事SDK的開發也是在使用界面層的工做，後面也會着重講一下。
• 二是分佈式的高可用集羣，應用接入層，除了API層，上面還有一個應用接入。應用接入的時候會把像剛纔提到的鑑黃的一些服務，水印的服務，接入進來。這樣能夠給用戶提供一個能力，你能夠自主去選擇你上層須要的能力，而後把這些能力集成進去以後，用戶服務端不須要再進行二次開發。
• 三是傳輸的服務。這塊是最開始一直提到的問題，就是上傳和下載的問題，上傳主要是安全和數據穩定性的問題。關鍵還有下載分發的問題，這裏有成體系化的CDN的一些加速的策略、動態加速的策略，就近接入讓你的數據更快的能從雲端下載到客戶端上。

權限與安全

除了剛纔說到上傳、下載，接下來可能更關注的是權限與安全。爲何單獨講這一塊，由於以前作APP和SDK過程當中會咱們發現COS服務是一種數據服務，而數據是一種資源。這種資源自然會帶着必定的權限，涉及誰能夠訪問，誰不能夠訪問的問題。

訪問控制的策略

咱們在處理這個問題的時候引入了一整套的訪問控制的策略（CAM）。內部有一個總體的訪問控制策略，一個請求從端上發過來以後，首先使用非對稱加密的策略，客戶端實際上是拿着一個臨時密鑰，實際上是一個公鑰加密，加密整個請求，整個請求來到服務器端，服務器端判斷他是否是合法用戶，纔會讓他訪問後面的資源。在訪問後面資源的時候會有ACL的策略，去控制對應的人、對應的請求是否有權限訪問你對應的這些資源。

對於端上來說，咱們在構建的時候會遇到一些問題。端上用這種公鑰的時候進行遷移請求，遷移請求的時候必然發現端是一個分發性的軟件，只要你的公鑰存在二進制當中，一旦分發出去，別人就很容易去反編譯，很簡單就能把公鑰破解。當破解出來後，整個的服務就暴露在別人面前，因此這裏咱們採起臨時密鑰的策略，爲了避免存儲永久密鑰，創建了臨時密鑰。這個臨時密鑰，至關於一個永久密鑰的二次分發，在用戶的服務器端，拿着用戶本身的永久密鑰去本身的服務器簽發一個臨時密鑰，臨時密鑰是有有效時間的，咱們甚至加一些機制，限制他去訪問哪些資源，把一個臨時密鑰下發到客戶端，在客戶端使用是一個相對來講更加安全的策略。

這裏能夠看到，由於大多數狀況使用的是APP cad的策略，所以特別容易被反編譯和破解，因此這裏臨時引入了臨時密鑰策略。

數據落地

加密

固然咱們考慮的問題，咱們的數據最後存哪兒，怎麼落地的。落地的過程也考慮了不少的問題，好比剛纔說的安全性的問題，這裏支持服務端加密，能夠在請求中攜帶一個特定頭部，攜帶數據會用一個用戶指定的密鑰去進行加密，即便被人偷庫了，拿到的數據也是不可讀的數據。同時也支持像客戶端加密，服務器的非對稱加密一些這樣的策略，主要也是安全性。

生命週期

同時，像咱們常說的數據的生命週期，好比一個Feed，常見的Feed有生命週期的，假如一個月以後這條Feed就沒人看了，咱們可能要刪掉，而生命週期能夠直接在對象上，一個月以後過時，過時以後就無效了，不須要再手工的在整個倉儲裏排除這列數據。

跨域複製

還有一個咱們比較關注的問題，這個東西在哪裏是可用的。咱們能夠看到這張圖，COS的產品在世界各地分佈了很是多的點，就是咱們的接入點數據倉儲的落地，如今標記的就是在這些地域已經有了接入點和數據倉儲。也就是說若是你的服務如今須要出海或者跨國服務，使用咱們的COS是一個很是好的選擇。

SDK

我這幾年的工做經驗主要圍繞COS-SDK產品的開發，我和你們分享一下咱們在製做這個COS-SDK上的一些經驗。

這裏所謂的SDK對用戶來講，只是一個服務界面，而COS服務來講，更像是後端服務。爲了更好的易用性，咱們將COS服務封裝成了SDK，只讓用戶看到上傳和下載，其餘不須要考慮。

作這個事情的時候，咱們可能會面對第一個問題，什麼樣的SDK是一個合格的或者說是一個更容易去使用的SDK？首先有一些感性的認知，好用，快速上手、高性能。對端上來說，不會宕機、服務是穩定的，這是一些比較感性的詞。

這些感性的詞，是比較難去實現的一個目標，若是轉化一下，咱們轉化到SDK具體的形態上，能夠把SDK分紅幾個模塊。第一個是咱們最核心的，代碼或者二進制，這是咱們的分發形態。第二個是咱們和SDK用戶交互的API，傳統意義上SDK的開發，只有API和代碼或者二進制，咱們經常就是把這兩個東西丟給客戶，客戶本身去摸索吧。可是的文檔和Demo，是一個合格的SDK必備的部分。在製做SDK的時候，須要把每個模塊都去作好。

以前咱們做爲一個程序開發人員來講，更多關注的是代碼、API，但這幾年的經驗告訴我，若是真正能讓用戶把你的SDK用起來，或者以爲好用能快速上手，你須要把Demo、文檔補充好。這一點，也是咱們在作整個的移動研發平臺的時候，會着重考慮的一些點。

靠譜SDK

如何制把這個SDK作成一個靠譜的東西，怎麼作呢？這是咱們如今正在作的一個流程化、工程化的圖。

這裏很是強調設計的。由於對於SDK來講特別強調API的重要性，API是設計出來的。這裏設計架構設計，類結構的設計，類關係的設計，模塊化，一些東西咱們都須要考慮到。剛纔也說到一個API的設計，好比針對COS的API來說，咱們就會考慮它會有一個基礎的模型，它是一個請求回覆的模型。針對這個模型，就須要把請求須要的參數給描述出來就行了，描述出來以後，使用者能快速的把這個請求構建出來，丟給COS層就OK了。因此咱們在設計這一個COS的API的時候，咱們遵循請求回覆的模型，去進行總體的設計。

設計完成以後下一個階段，實施。把我設計的東西翻譯成代碼，讓它變成一個可跑的東西。設計好總體的API，設計好總體的模塊化以後，發現一個比較有意思的現象，咱們大概有幾十個API，這裏包括幾個生命週期的管理、bugly的管理等其實都是基於請求回覆的模型，惟一區別是每個API的地址、參數、回參不同，這樣徹底能夠用代碼生成的策略。

咱們自定義了一套模板語言，把剛纔說的API的請求回覆模型描述好，只要描述好以後，加一個簡單的模板，就能夠經過卡梅隆的代碼生成策略，一次性把全部的API生成。咱們最開始的想法是爲了優化效率，若是說人工的去寫每個API的話可能須要投入不少的人力成本，可是若是是代碼生成的話，整個效率提升的。把整個事情作完以後，咱們設計好帶有模型性的能代碼，質量提升的也令咱們感到很恐怖的一個地步。

針對不一樣網絡優化

由於咱們是作SDK，對SDK來說，在處理質量的時候會面對的一個和APP不同的問題，APP如今測試基本上是基於，咱們有一個開發人員，開發人員來寫。但SDK不可能寫一個Demo，因此咱們把整套的測試體系創建起來了，好比常見的UT、代碼檢查，同時對全部歷史性版本，作了一整套的測試。SDK是持續發佈的，只要發出去的SDK，線上必定會有用戶在跑着，好比如今個人SDK版本號是1.1，以前發過五個版本，那麼咱們的線上總共有六個版本，不可能說我測試的時候只測當前的版本，就能保證歷史的版本是沒有任何問題的。只要發一個版本，就加入到one box當中，在每次發版以前就會把全量的SDK跑一遍。

固然這裏並不單指端上，安卓、IOS甚至後臺的SDK，這些SDK都統一收攏進來，收攏進一個one box測試，把這些全跑一遍，只要有改動咱們全跑。這樣保證你使用了咱們的SDK，在你沒有更新的狀況下，後臺有變動，也不會影響你的現象服務。這種對界面性的SDK是一個很是關鍵的問題，你須要保證你發出去的SDK運行是沒有任何問題的。這是咱們在測試上作的一些事情。

最後會把整套東西提交給客戶使用，在客戶使用的過程當中，咱們其實也有不少的思考。好比說咱們會使用統一的配置服務框架。後面也會考慮把整套的基礎，你使用騰訊其它服務的話，也可使用咱們這套端上的統一配置服務的框架，而後去作一個集成。

支持動態加速

再切回到COS這個單獨的產品，它主要作上傳服務，上傳更多的是和網絡進行交互。進行交互的時候這裏有一些常見的優化策略，前面三個不用說了，這多是你們基本上會造成一個共識的東西。第四個支持動態加速，同時在SDK內部有了一個更好的任務併發處理。

更好的任務併發控制

咱們在上傳的時候會同時上傳很是多的任務，並且網絡庫有不僅是專門用來處理像咱們這種文件上傳的任務，有可能也是處理一些常見的IPC的任務，就是一個簡單的請求一個Feed，或者請求一個用戶名稱的東西。而常見的文件上傳的任務，是一個很是耗時的任務。若是你把這些任務和剛纔咱們說的不耗時的任務放在一塊兒的話，會造成一個瓶頸，阻礙你正常的流程，因此這裏作一個併發控制。將所謂的耗時任務下降優先級，讓正常的IPC的命令能更快的響應，而不是更快的響應文件併發的任務，實際上是業務細節上有優化了。

接口封裝OOP化

最後在接口上，咱們是請求回覆的模型，徹底是OOP化的模型。咱們在API設計的時候嚴格按照OOP的思想去設計的，這樣你們更容易去使用。由於我在使用其它SDK的時候，我看到更多C化的一些API接口，基本上是靜態函數或者一個類方法拋給你去使用。其實這樣的話不會造成一個總體上的概念，由於OOP命名對象更多的是講究抽象，這樣能夠把總體的COS一個宏觀的概況，能夠看這個類結構圖，能很好的理解概況或者每一個類的設計意圖，怎麼去用，能夠更好的理解這些東西。

Q/A

Q：我們COS-SDK是每一個應用都要申請一個SDK，一個用戶手機上須要安裝多個應用，咱們多個應用能夠共用這一個SDK嗎？由於咱們的應用資源可能須要進行共享的。

A：能夠，由於咱們這個不是和應用綁定的。

Q：關於存儲，首先想到的問題，像圖象、視頻流，壓縮和解壓縮是怎麼作的？保證不失真。最後上傳和優化，關於COS的對象存儲和阿里雲的OSS的對象存儲，它的優點在哪裏？

A：先回答第一個問題，關於音視頻的問題。其實COS做爲一個通用的數據服務，咱們在傳輸上並無作太多的關於特定數據的優化，若是你對音視頻壓縮或者數據傳輸有一些訴求，多是上層業務。好比上層業務會提供短視頻SDK，短視頻SDK會進行數據壓縮或者一些設定，是分層的業務來處理這個問題。應對不一樣的場景，可能有不一樣的分層。

第二個問題，我做爲一個終端開發人員經過個人角度回答這個問題，非官方的回答。可能以爲咱們支持更多的存儲的上層業務邏輯的處理，咱們把整個存儲的事情不僅僅當成一個倉儲的東西，咱們會作更多的上層業務邏輯的事情，幫助你們更好地接入使用。

Q：COS這款產品在實現文件上傳的時候，提供的接口須要先設定一個遠程的內經存放路徑和本地的文件路徑是嗎？

A：您這麼說是對的，先嚐試解釋一下看看我說得是否是跟您同樣。你要存一個東西，第一要知道存什麼，第二要知道存哪兒，因此您問的這兩個必定要有的。

Q：我是作web開發的，若是要上傳一個文件到web後端，但經過這個文件可能沒辦法去到那個服務器緩存的本地文件的路徑。那那邊若是須要上傳的話，能夠直接把這個文件上傳嗎？

A：能夠直接上傳，其實剛纔說的對象存儲系統的時候，咱們會有一個對象鍵的概念。就是你遠端的一個地址的概念，這個遠端的地址，其實能夠在本地生成，而後上傳。

更多相關資料，請點擊下方連接獲取：
移動端數據存儲與分發-董朝.pdf

問答
雲存儲Redis的實例怎麼備份？
相關閱讀
Docker解決數據存儲問題的方案
楊列昂：騰訊移動分析與服務架構
胡澤銳：移動開發即服務——騰訊雲移動開發平臺技術分享

此文已由做者受權騰訊雲+社區發佈，原文連接：https://cloud.tencent.com/developer/article/1138213?fromSource=waitui

歡迎你們前往騰訊雲+社區或關注雲加社區微信公衆號（QcloudCommunity），第一時間獲取更多海量技術實踐乾貨哦~