Docker 是當前最火熱的開源項目之一，它從頭界說了措施開拓測試、交付和陳設進程，可以做到「Build once，Run anywhere」。在上周的 DockerOne 社群分享會上，七牛云布道師陳愛珍分享了七牛云如何通過自主研發的容器調治框架打造易擴展、易陳設、高自由度、高可用、高機能的數據處理懲罰平臺。以下是對她分享內容的整理?！　?/p>

陳愛珍 七牛云布道師

7 年以上企業級系統運維打點履歷，對大型漫衍式系統架構設計及運維有富厚的履歷?，F轉向 DevOps ，容器相關技能規模。

一、數據處理懲罰業務場景

首先先容一下七牛數據處理懲罰業務的配景。七牛云今朝平臺上有高出50萬家企業客戶，圖片高出2000億張，累積高出10億小時的視頻。 用戶把這些圖片和視頻存儲在七牛上后會有一些數據處理懲罰方面的需求，如縮放、裁剪、水印等。這些文件一連在線且數據種類多樣，假如用戶把這些文件在本身的基板上處理懲罰好后再上傳到七牛，長短常不合算的工作。而七牛最先提供基于存儲的數據處理懲罰成果利便用戶去做數據處理懲罰，這些數據處理懲罰凡是放在企業的客戶端或處事器端來操縱，對接上七牛云存儲的數據處理懲罰接口后，即可對圖片和音頻舉辦富厚的及時轉碼成果，轉碼生成的新規格文件放在七牛提供的緩存層供App挪用，不消占用存儲空間，對企業來說不只本錢大大低落，還可提高開拓效率。 下圖為一個圖片裁剪的數據處理懲罰示例：　　

七牛的文件處理懲罰措施簡稱FOP(File Operation)，差異的文件處理懲罰操縱利用差異的FOP。用戶只需上傳一個原文件就可以通過利用七牛的數據處理懲罰成果獲得各類樣式富厚的文件。下圖為文件從上傳存儲處處理懲罰到分發的流程圖：　　

二、海量數據處理懲罰平臺的挑戰

七牛云的海量數據成績了Dora十分強大的數據處理懲罰本領，今朝七牛的數據處理懲罰處事已經日處理懲罰數近百億次。面臨這樣海量的數據處理懲罰請求，原有的數據處理懲罰平臺也面對著新的挑戰：

1、 日均請求量百億級，CPU 麋集型計較

今朝系統天天有近百億的數據處理懲罰請求量，擁有近千臺的計較集群，整個存量、增量都很是大。而數據處理懲罰集群中絕大部門的呆板都是用來跑圖片、音視頻轉碼的，這些都是CPU麋集型的計較，這意味著靠山需要許多臺呆板，并且CPU的核數越多越好。在年底數據處理懲罰平臺大概會在今朝近千臺的計較集群基本上翻好幾倍，需要有快速物理擴展和高效智能打點的本領。

2、 處事器負載不平衡，資源操作率不高

及時在線處理懲罰的業務處理懲罰時間短，可是量大，需要大量的實例來應對高并發的環境。而異步處理懲罰的業務處理懲罰時間長，也需要分派足夠的資源來。當及時業務并不忙碌而異步處理懲罰業務增長時，并不能利用分派給及時業務的資源， 這種靜態資源分派機制帶來的分派不公道問題，導致處事器負載不平衡，資源操作率不高。

3、 突發流量不行丈量， 大量冗余資源

在新接入用戶并不能完全正確的預測請求量，本來的模式是通過快速擴容呆板并驗證上線，需要必然的處理懲罰時間，對付這種非打算內的請求量需要籌備大量的冗余資源來應對突發流量。

4、 集群負載過重，不能自動按需擴展

個體用戶突增數據處理懲罰請求時導致集群負載壓力過大，CPU處理懲罰變慢， 請求時間變長，請求任務會萃，影響其他業務，并不能在現有的資源基本長舉辦快速擴展，也不能按照實際的業務壓力舉辦按需自動擴展集群實例。

5、 用戶自界說應用(UFOP)質量及局限未知

七牛除了提供官方的數據處理懲罰處事，也支持客戶將自界說數據處理懲罰模塊陳設到七牛云存儲的就近計較情況，制止長途讀寫數據的機能開銷和流量本錢，滿意用戶多方位的數據處理懲罰需求。可是各類UFOP運行在同一個平臺上就大概會存在部門UFOP的質量問題或請求量過大而分派的資源不敷導致影響平臺上其他處事的正常運行。

三、自研容器調治系統先容

為了辦理以上問題，七?；谫Y源打點系統Mesos自主研發了一套容器調治框架(DoraFramework)，通過容器技能打造了易擴展、易陳設、高自由度的數據處理懲罰平臺Dora。整體架構圖如下所示：　

各組件先容：