七牛數據處理架構變遷

據統計，互聯網數據量正以每三年翻一番的速度膨脹，其中， 95%以上都是非結構化數據，且這個比例仍在不斷提高。現在，互聯網已全面覆蓋你們生活的方方面面，每一個人的消費行爲、娛樂行爲和社交行爲都將產生海量的圖片、音視頻、網絡日誌等非結構化數據。非結構化數據的持續在線及數據種類的多樣對數據的處理提出了很高的要求。做爲國內最專業的數據管理平臺，七牛已覆蓋國內 50%以上的互聯網用戶。那麼，七牛數據處理架構都通過了哪些演變呢？小編帶你一探究竟。

七牛雲存儲的數據處理主要分爲實時處理和異步處理，對於較小的文件（如圖片），通常推薦使用實時處理的方式。

對於實時處理，用戶可簡單經過 URL 對已有的文件進行實時處理。當用戶將文件上傳到七牛 KODO 對象存儲平臺，會獲得相應的 key ，可經過 URL 訪問。例如 http://xxx.com/key ，當須要對該文件進行實時處理時，能夠經過http://xxx.com/key?&lt;fop>/<param1_value>/<param2_name>/<param2_value>/….進行處理。具體操做參數能夠參考七牛官方文檔。參數過多過長時能夠設置樣式，若涉及操做複雜多變能夠採用管道技術。

異步請求能夠經過 Portal 、命令行工具、 SDK 發起請求。通常適合處理較大文件，好比較大的音視頻，這種狀況下實時響應的效果並不理想，則能夠採用異步持久化處理方式，返回的結果是處理後的文件在七牛雲存儲中的相關元信息（ bucket 、 key 等），用戶能夠經過設置回調服務器地址，將結果 POST 到本身的接收服務器，也能夠主動查詢數據處理狀態和結果信息。

上圖描述了簡單的實時處理的基本架構，用戶能夠經過七牛雲存儲的 I/O 入口發起請求，判斷出是合法的數據處理請求後，就會將其傳給數據處理調度服務，經過調度分發給計算處理集羣。每一個 worker 處理的流程爲參數檢查->下載數據->結合原數據信息對參數進行檢查（若數據的相關信息不須要 download 下來就能夠獲取，那麼能夠和前面的步驟對調）->本身編寫算法實現或者調用工具對數據進行處理，好比轉碼、圖像縮略等操做->結果返回（異步請求通常會持久化保存，經過對象存儲服務，將結果上傳，獲得文件上傳後的相關信息，例如 bucket 、 key 等，返回的是文件的相關信息）。這裏能夠簡單的把數據處理調度看作負載均衡器，請求根據接口判斷，經過調度指向對應服務，而後將結果原路返回給用戶。

上面的結構簡單清晰，但同時面臨幾個問題：

數據處理調度這個服務相對比較重，它不只僅須要實現負載均衡，還須要對全部處理終端服務進行管理，單臺計算型服務器上可能有多個服務 worker （多個圖片處理、音視頻處理服務 worker ），隨着業務發展，管理的 worker 數量是很是多的。
內部實現緩存機制，使得讀寫緩存的流量所有集中在數據處理調度這個服務。
數據的處理離不開原數據，通常咱們能夠在 worker 中待前面的步驟順利經過後，調用七牛的對象存儲服務開始下載，那麼每一個 worker 都必須配置對象存儲服務的地址信息，而後才能 download 原數據，這套地址信息對全部 worker 都是共用的。前面提到 1 臺物理機器上可能有多個服務 worker ，每一個 worker 自身有不一樣的屬性參數（最起碼端口號不一樣），並且可能機器上的服務 worker 有 Image Worker 也有 Video Worker ，共用一套配置顯然不能知足，若每一個 worker 都將這些廣泛共用的信息寫入配置，那麼維護起來很是不方便。所以，七牛的數據處理架構有了一些演變，就有了以下的架構。

首先，將 Data Cache 獨立出來，理由很是簡單，在不少環節都須要緩存服務，而且根據緩存數據大小、熱度選擇是 SSD 或者 HDD 進行緩存，小文件且熱度高適合 SSD ，大文件且熱度較低適合 HDD 。

其次，爲每臺服務器添加了 agent 服務。一臺服務器可能有多個 worker 且多是不一樣種的 worker ，數據處理調度服務只須要知道該請求的對應 worker 存在於哪些機器便可，剩下的判斷則交由 agent 處理。由於整個計算集羣的服務器存在性能差別，採用權重輪詢調度，這時某個 worker 對應所在的機器一目瞭然，也不須要對 worker 總體標記序號，只須要知道某臺服務器有哪些 worker 。 agent 能夠承擔 download 原數據的責任，至關於提取各個 worker 的一些公共操做均可以都交給 Agent ，同時， agent 分擔了向 Data Cache 寫入數據的任務。

值得一提的是，對於返回失敗的數據也能夠緩存。假如請求量巨大，天天 100 億條請求，確認是客戶端請求信息不當的錯誤約佔 5%，那麼就有 5 億錯誤請求，即便服務迭代升級，也會保持原有接口功能不變。那麼，如果同一個文件的同一個錯誤請求，基本上必然重現，這樣的請求實際上就能夠被緩存，一來用戶那邊得到快速響應，二來減小計算壓力並且減小拖取數據的流量。後來發現這個方案存在一個瑕疵，就是給 Data Cache 形成的壓力略微變大，且有部分錯誤請求響應並無加快，至少爲了得到緩存數據而讀盤會有時間消耗。先前 worker 的設計是檢查參數是否合法->download 數據->結合原數據信息檢查參數是否合法。這裏咱們對錯誤請求作了細化，單獨屏蔽了 download 數據以前所產生的錯誤請求，由於這部分響應很是快，自己也沒有多少計算，無需寫入緩存。

最後，經過 Discover 服務來監控服務狀況的變化，全部的 agent 和 worker 都須要向 Discover 上報心跳狀態， Load Balancer 會從 Discover 讀取各個服務狀態、服務相關信息（地址、權重等），同時容許人工經過 Discover 修改各個服務的狀態。

異步請求的架構，則是在整個實時處理架構前面加上異步隊列服務、異步請求狀態服務等，每一個 worker 的處理結果須要持久化，返回的是結果文件持久化保存後的相關信息。

如今的整個數據處理架構，看上去中規中矩，同時也存在一些弊端，即便作到了能夠對單條請求大體消耗資源的預估，通過屢次數據回滾壓力測試以及峯值比對肯定一臺服務器應該部署多少個 worker ，實現較爲合理的調度，但機器上的 worker 數量基本上是固定的，沒法跨機器實現彈性的實時調度，服務器的資源仍然不能充分利用。例如，當實時處理服務的機器在非峯值階段，能夠將異步請求的服務 worker 遷移到該機器上，分擔一部分任務，使得每臺機器的負載較爲均衡；當實時請求到達峯值的時候，能夠遷移部分 worker 處處理公有隊列異步請求的機器（付費的私有隊列用戶不受影響），分擔部分壓力。

所以，七牛後續將會對整個數據處理的架構作一些關於 Container 的嘗試，但願打破原有的一些束縛，帶來比較好的效果，能夠把 agent 和 worker 放在一個 Container 內部，成爲 1:1 的關係。 Container 自身具備隔離性，能夠依據系統的資源狀況選擇這臺機器有多少 Container 運行。當某一臺服務器資源已經接近飽和時，就會在下一臺服務器上啓動一個新的 Container 繼續接收請求。一旦某臺服務器空閒下來，那麼這臺服務器就屬於 Container 待運行的機器，整個計算服務器集羣就是個資源池， worker 無需被機器束縛，哪裏空閒就啓動在哪裏，不再用擔憂機器資源浪費了。