這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。
【編者的話】本次分享介紹七牛資料處理團隊的容器技術實踐經驗，分享七牛如何通過自主研發的容器調度架構打造易擴充、易部署、高自由度、高可用、高效能的資料處理平台。
主要內容包括四個方面：
- 海量資料處理的業務情境
- 海量資料處理平台的挑戰
- 自研容器調度架構介紹
- 海量資料處理平台實踐
一、資料處理業務情境
首先介紹一下七牛資料處理業務的背景。七牛雲目前平台上有超過50萬家企業客戶，圖片超過2000億張，累積超過10億小時的視頻。 使用者把這些圖片和視頻儲存在七牛上後會有一些資料處理方面的需求，如縮放、裁剪、浮水印等。這些檔案持續線上且資料種類多樣，如果使用者把這些檔案在自己的基板上處理好後再上傳到七牛，是非常不合算的事情。而七牛最先提供基於儲存的資料處理功能方便使用者去做資料處理，這些資料處理通常放在企業的用戶端或伺服器端來操作，對接上七牛雲端儲存的資料處理介面後，即可對圖片和音頻進行豐富的即時轉碼功能，轉碼產生的新規格檔案放在七牛提供的緩衝層供App調用，不用佔用儲存空間，對企業來說不僅成本大大降低，還可提高開發效率。 為一個圖片裁剪的資料處理樣本：
七牛的檔案處理常式簡稱FOP（File Operation），不同的檔案處理操作使用不同的FOP。使用者只需上傳一個原檔案就可以通過使用七牛的資料處理功能得到各種樣式豐富的檔案。為檔案從上傳儲存到處理到分發的流程圖：
二、海量資料處理平台的挑戰
七牛雲的海量資料成就了Dora十分強大的資料處理能力，目前七牛的資料處理服務已經日處理數近百億次。面對這樣海量的資料處理請求，原有的資料處理平台也面臨著新的挑戰：
日均請求量百億級，CPU 密集型計算
目前系統每天有近百億的資料處理請求量，擁有近千台的計算叢集，整個存量、增量都非常大。而資料處理叢集中絕大部分的機器都是用來跑圖片、音視頻轉碼的，這些都是CPU密集型的計算，這意味著後台需要很多台機器，而且CPU的核心數越多越好。在年底資料處理平台可能會在目前近千台的計算叢集基礎上翻好幾倍，需要有快速物理擴充和高效智能管理的能力。
伺服器負載不均衡，資源使用率不高
即時線上處理的業務處理時間短，但是量大，需要大量的執行個體來應對高並發的情況。而非同步處理的業務處理時間長，也需要分配足夠的資源來。當即時業務並不繁忙而非同步處理業務增長時，並不能使用分配給即時業務的資源， 這種靜態資源分配機制帶來的分配不合理問題，導致伺服器負載不均衡，資源使用率不高。
突發流量不可測量， 大量冗餘資源
在新接入使用者並不能完全正確的預測請求量，原來的模式是通過快速擴容機器並驗證上線，需要一定的處理時間，對於這種非計劃內的請求量需要準備大量的冗餘資源來應對突發流量。
叢集負載過重，不能自動按需擴充
個別使用者突增資料處理請求時導致叢集負載壓力過大，CPU處理變慢， 請求時間變長，請求任務堆積，影響其他業務，並不能在現有的資源基礎上進行快速擴充，也不能根據實際的業務壓力進行按需自動擴充叢集執行個體。
使用者自訂應用（UFOP）品質及規模未知
七牛除了提供官方的資料處理服務，也支援客戶將自訂資料處理模組部署到七牛雲端儲存的就近計算環境，避免遠程讀寫資料的效能開銷和流量成本，滿足使用者多方位的資料處理需求。但是各種UFOP運行在同一個平台上就可能會存在部分UFOP的品質問題或請求量過大而分配的資源不足導致影響平台上其他服務的正常運行。
三、自研容器調度系統介紹
為瞭解決以上問題，七牛基於資源管理系統Mesos自主研發了一套容器調度架構（DoraFramework），通過容器技術打造了易擴充、易部署、高自由度的資料處理平台Dora。整體架構圖如下所示：
各組件介紹：
Mesos：由ZooKeeper、Mesos Master、Mesos Agent構成了基礎的Mesos資料中心作業系統，可以統一管理機房中的所有物理機，負責資源層面的調度，是二層調度系統最基礎的運行環境 。
DoraFramework：業務層調度架構，通過DoraFramework使用Mesos管理所有的物理機資源，完成業務進程的調度與管理。
Consul：包含服務發現，健全狀態檢查和KV儲存功能的一個開源叢集管理系統，DoraFramework調度系統使用Consul的服務發現和健全狀態檢查機制提供基礎的服務發現功能，使用KV儲存功能來儲存DoraFramework的metadata。
Prometheus：一個開源的監控系統，實現機器層級，容器層級及業務系統層級的監控。
Pandora： 七牛的內部的日誌控制管理系統，負責生產環境所有日誌的匯聚及處理。
在這個架構中，我們選擇通過容器技術實現跨機器實現彈性的即時調度。調度架構可以根據具體的業務負載情況動態調度容器的個數， 很好的解決了靜態配置導致的資源使用率不高的問題 。而容器秒啟的特性也解決了當有大量突發請示進入，可以快速啟動服務的問題。在網路方面，由於UFOP是使用者部署啟動並執行服務，並不知道使用者是否有開啟其他的連接埠使用，所以使用的是Bridge模式，需要對外使用連接埠的都需要通過NAT進行暴露，這樣服務內部使用了什麼連接埠並不會對外界環境造成影響 ，對平台環境做了非常好的安全隔離。
資料處理平台的調度系統我們選擇的是Mesos 自研容器調度架構（DoraFramework）。選擇Mesos做為資源管理系統一個是因為Mesos的相對其他的容器調度系統更成熟，Kubernetes是2015 才發布可生產環境啟動並執行版本，Docker Swarm則是2016年才發布，這兩個產品的生產實踐在調研時基本還沒什麼大型生產實踐經驗，而Mesos則已有七八年的曆史，且資源管理方面已經在如蘋果，Twitter等大型公司得到生產實踐，穩定性比較好；第二個是因為Mesos支援調度成千上萬的節點，以七牛目前已經達到近千台物理機的規模，且每年都在大幅度增長的情況，Meoso這種支援超大規模調度的資源管理架構更合適七牛的業務發展； 第三是因為Mesos的簡單性，開放性及可擴充性，Mesos是一個開源的分布式彈性資源管理系統，整個Mesos系統採用了雙層調度架構：第一層由Mesos收集整個資料中心的資源資訊，再將資源分派給架構；第二層由架構自己的調度器將資源分派給自己內部的任務。Mesos自身只做資源層的管理，這種簡單性帶來的則是穩定性。而容器的調度架構則可以使用開源架構如Marathon/chronos或自主研發。Kubernetes雖然功能很豐富，但是也比較複雜，組件及概念都比較多，並且缺乏開放性和可擴充性，只能使用它提供的調度功能，而不能根據自身業務的情況定製調度架構，會造成對Kubernetes過於依賴的情況。
為什麼不選擇Mesos的核心架構Marathon 而選擇自研，出於三方面的考慮：1. Marathon有些方面不支援我們期望的使用姿勢，比如不太好無縫對接服務發現；2. Marathon採用Scala開發，出了問題不好排查，也不方便我們做二次開發；3. 如果選用Marathon的話，我們上面還是要再做一層對 Marathon的封裝才能作為Dora的調度服務，這樣模組就會變多，部署營運會複雜。
DoraFramework是七牛使用go語言自研的容器調度架構。DoraFramework實現了Mesos兩層調度中業務進程的調度，是Dora調度系統中的核心組件，通過與Mesos和consul組件之間的互動， 對外提供API介面。架構圖如下：
DoraFramework主要功能介紹：
- 自動化應用的部署
- 服務註冊與發現
- 彈性調度容器數量
- 負載平衡
- 支援在指定機器上增加或減少執行個體
- 支援高可用
- 應用的版本和升級管理
- 支援擷取執行個體的狀態及日誌資料
- 支援業務層級的監控
- 支援執行個體的損毀修復
DoraFramework與Marathon調度架構的對比：
- DoraFramework調度系統的服務註冊與發現使用Consul實現， Consul是用於實現分布式系統的服務發現與配置，支援跨資料中心的內部服務或外部服務的發現， 對外提供DNS介面，而Marathon-lb並不支援跨資料中心的服務發現。
- Marathon是通過Marathon-lb所在節點的servicePort服務連接埠或VHOST來探索服務 ，要求網路模式必須為Bridge。因為Marathon-lb還負責負載平衡的功能，在大型的業務環境下，如果Marathon-lb出現異常，則會影響架構正確的服務發現。
- Dora調度系統可以做更精確的彈性調度。因為它不僅支援做資源使用層面的監控，還支援做業務層級的監控，在對執行個體進行調度時就可以根據實際的業務壓力進行調度。
- Dora調度系統內的負載平衡組件是通過從Consul中擷取到所有的可用執行個體的地址進行負載分發，並可以根據每個執行個體的業務負載情況進行更精確的分發。而Marathon-lb並沒有業務層的監控資料。
- Consul提供系統級和應用級健全狀態檢查，可以通過設定檔及HTTP API兩種方式來定義健全狀態檢查，並支援TCP、HTTP、Script、Docker和Timeto Live（TTL）五種方式做Check。Marathon的預設的Health Checks只檢查Mesos中的任務狀態，當任務為running時，就被認為是health狀態，這樣不能做應用級的健全狀態檢查。Marathon通過REST API可以查看應用的健康狀態， 但只支援TCP、HTTP和Command三種方式。
- Dora調度系統提供的監控棧在業務進程運行過程會匯總採集業務健全狀態指標，如請求次數，請求延時等資訊，業務進程對外暴露一個標準的http監控介面，監控介面的資料產出符合Prometheus監控資料格式。Prometheus通過配置Consul作為服務發現地址，會從Consul中擷取需要收集監控資料的業務進程列表，從業務進程暴露的http監控介面pull監控資料。
我們使用Consul做註冊中心，實現服務的註冊與發現。Consul內建key/value儲存，可通過DNS介面做服務發現，且具體健全狀態檢查的功能，並支援跨資料中心的服務發現。API Gateway可以通過Consul提供的DNS介面查詢到服務所有的可用執行個體的列表資訊，並將請求進行轉寄。
服務的自動註冊和撤銷
新增微服務執行個體時，採取的原則是等待執行個體為運行狀態後將執行個體的訪問地址註冊到Consul Client的Service Registration，並配置這個服務的健全狀態檢查，再將資料同步到 Consul Server的服務註冊表中。
對於減少執行個體時，採取的原則是先將執行個體從Consul Server的服務註冊表中刪除，等待冷卻時間之後，再從通過調度系統將這個執行個體銷毀。從而完成服務的自動註冊和撤銷。
服務發現
外在系統想訪問服務時，可通過服務名稱從Consul Server提供的DNS介面查詢到當前服務在Consul Server中註冊的所有健康執行個體的訪問地址， 再將請求發送給執行個體。
四、海量資料處理平台實踐
我們生產環境的組態管理採用的是Ansible，Ansible預設使用SSH進行遠端連線，無需在被管節點上安裝附加軟體，可以批量系統配置、批量部署、批量運行命令等，非常適合七牛的大規模IT環境。而Playbooks 是一種簡單的組態管理系統與多機器部署系統的基礎，使用非常簡單，且具有可讀性，非常適合於複雜應用的部署。我們通過Ansible可以實現資料處理平台的一鍵式安裝和刪除，新增和刪除節點，還包括對組件版本的升級及回退，以及生產環境的大量設定修改等操作，簡化了複雜的營運組態管理工作。
在實踐中，選擇一台主機做為中控機，安裝Ansible，再配置這台中控機與所有遠程主機的SSH互信，再在中控機上配置Playbook檔案，即可對多台主機進行大量操作。對於簡單的操作，可執行如下命令：
$ansible-playbook main.yml -i hosts
在main.yml裡編輯所有需要做的操作，在hosts檔案裡寫入所有需求操作的主機IP地址，即可完成對hosts檔案裡所有主機的大量操作。而對於複雜的操作，則可通過編寫Playbook進行配置。roles裡存放不同的角色任務，比如Mesos Master上執行的任務和Mesos Agent上執行的任務不同，則可放在不同的roles裡，也可以把Mesos、Zookeeper、Consul放的不同的roles裡。tasks裡則是role裡具體執行的任務，handlers則是tasks裡觸發執行的任務。template則是模板檔案，比如我們需要個性Consul的預設設定檔，可以修改後的設定檔放在這個目錄下，在執行時用這個檔案替換預設的設定檔。
在監控方面，資料處理平台擁有完整的監控體系，包括了主機監控，容器監控，服務監控，流量監控，日誌監控。主機和容器的監控主要通過Prometheus的各種Exporter來做，採集到包括CPU、記憶體、網路以及磁碟的即時使用方式，服務監控和流量監控則通過七牛自己的監控程式進行監控，可以監控到服務的狀態、存活性、控制代碼數、及所有處理命令的請求數、失敗數等。日誌監控則是通過七牛內部的日誌平台Pandora系統進行監控，包括收集系統日誌，容器日誌和業務進程日誌。通過修改開源的檔案收集器Filebeat的output，將採集到的日誌全部傳送到七牛內部的日誌監控系統Pandora進行日誌監控。
監控資料顯示如下：
以上就是七牛雲資料處理平台基於容器技術實踐的情況。目前七牛的資料處理平台具備零營運、高可用、高效能的資料處理服務能力，可讓使用者輕鬆應對圖片、音視頻及其他各類資料的即時、非同步處理情境。七牛的資料處理業務系統不僅可以處理來自七牛雲端儲存的資料處理請求，也支援來自非七牛雲端儲存的資料處理請求，還可以直接處理來自七牛雲分發Fusion的資料處理請求，用來提高CDN中間來源資料的處理速度。而資料處理平台Dora則是一個開放的平台，不僅可以運行七牛自己的資料處理服務，也支援運行使用者自訂的資料處理服務，並具備豐富的營運管理功能，可以使使用者從繁雜的營運管理和架構設計中脫離出來，從而專註於實現資料處理單元。 七牛資料處理平台的業務支撐能力如下：
Q&A
Q：請問管理系統是基於什麼開發的？這個系統會開源嗎？
A：Dora的調度架構是基本GO語言開發的。目前不會開源，但提供私人部署。
Q：剛開始看Mesos架構實現，請問自訂的Scheduler中如何調用自訂的executor？
A：Schesuler跟executor這個都是按照Mesos最新的v1版的HTTP API去做的，這個沒有不相容的問題，只是mesos go版本的SDK有些老舊，更新也比較緩慢，這個地方我們自己根據需要做了些更改。
Q：請問目前Consul叢集是多大規模呢？有沒有考慮Consul擴充的效能瓶頸呢？
A：Consul是在每個slave節點上會有一個Consul的Agent ，我們一個機房有200多台專門用於資料處理的機器，所以Consul的叢集規模也就這麼大，單機房。對我們當前來說不存在瓶頸，因為我們對Consul的使用的情境相對單一簡單：作為Metadata的可靠儲存，Metadata的更新其實並不是很頻繁，這個我們參考過別人做過的一些效能測試和我們自己的一些測試，效能是滿足需求的。另外一個功能就是服務發現與執行個體的健全狀態檢查，健全狀態檢查是由運行在每個機器上的Consul Agent負責的，均攤到每個機器上，其實單個機器上的執行個體數不會特別的多，所以這部分也沒有太大的壓力。當然了，這個也是跟業務規模相關的，假定哪天Consul的擴充性成我們的問題了，也說明我們的業務量特別特別的大了，我們也是很期望這一天到來的。
Q：Dora是否可以支援MySQL的自動調整擴容？
A：Dora系統的應用情境還是運行一些資料處理命令這類無狀態的服務。MySQL這類系統不適合直接跑在Dora這個裡面，如果期望MySQL跑在Mesos上面的話，需要自己實現一個專門針對MySQL的調度器，因為MySQL執行個體的擴縮容，執行個體故障的修複都有MySQL自身特定的需求。我們公司MySQL這類具狀態服務的容器化是由公司另一個容器平台實現的。MySQL的用的是Percona XtraDB Cluster方案，我們利用另一個容器平台的API寫了一個Percona XtraDB Cluster的調度器，把Percona XtraDB Cluster的大部分營運操作在容器平台上自動化了。
Q：你們的Ansible host檔案是動態產生的嘛？程式碼推送也是通過Ansible嘛？新增刪除節點，以及復原等操作是如何?的？
A：最開始實踐的時候不是動態產生的，其實我們是可以從Consul中擷取到當前叢集裡面的節點和節點的一些簡單的配置資訊，後面有考慮從Consul裡面拿節點資訊，動態產生用於Ansible灰階的host檔案。程式碼推送也是使用的Ansible，如果能和外網串連的機器，也可以使用GitHub。因為我們的Playbook的角色是通過組件區分的，新增刪除節點只需要修改Host檔案，把相應的節點加入安裝或刪除相應的組件。如復原操作：
$ ansible-playbook rollback.yml -i hosts -e "hosts_env=XXX app_env=XXX version_env=XXX"
參數說明：
- hosts_env：表示要復原的主機群組，如Master
- app_env：表示要復原的組件，如ZooKeeper
- xxx_version：表示要復原組件的版本號碼，如v1.0.1.20160918
Q：Dora的調度策略是怎麼樣的？可否簡單介紹一下。
A：首先保證同一種資料處理命令的執行個體盡量均勻分散在不同的機器上，然後再是保證均衡每個機器上的負載。
Q：Prometheus目前是單機的，資料量大了怎麼辦？Prometheus 的監控資料是存在InfluxDB嗎？
A：目前我們是按業務拆分server，資料量可以支撐。我們沒有使用InfluxDB，還是用的原生的LevelDB。
Q：這麼大檔案量，你們在儲存技術方面有什麼特別的處理嗎？怎麼實現高效能和海量儲存之間均衡？
A：七牛雲端儲存的設計目標是針對海量小檔案的儲存，所以它對檔案系統的第一個改變也是去關係，也就是去目錄結構（有目錄意味著有父子關係）。所以七牛雲端儲存不是檔案系統，而是KVStore for Redis，或Object Storage Service。我們每個大檔案都是切割成小檔案儲存體下來的，元資訊單獨存放在資料庫中，使用者請求的時候通過業務層合并處理後返回。因此理論上磁碟只儲存小檔案，大檔案儲存體和讀取的效能主要在於檔案切割和合并。
以上內容根據2016年11月1日晚群分享內容整理。分享人
陳愛珍，七牛雲佈道師，負責DevOps ，容器，微服務相關技術的落地研究與佈道。多年企業級系統營運管理經驗，對大型分布式系統架構設計及營運有豐富的經驗。 DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加：liyingjiesz，進群參與，您有想聽的話題或者想分享的話題都可以給我們留言。
