大家晚上好，我是七牛雲的佈道師陳愛珍，主要負責容器技術的落地研究和佈道，很高興今晚可以在這裡跟大家分享七牛雲容器技術實踐的經驗。

今晚分享的是七牛雲基於容器技術的海量資料處理平臺實踐。分享的內容包括三個方面：

1. 海量資料處理的業務場景
2. 海量資料處理平臺的挑戰
3. 自研容器排程框架介紹
4. 海量資料處理平臺實踐

首先簡單介紹一下七牛資料處理業務的背景。

七牛雲目前平臺上有超過50萬家企業客戶，圖片超過2000億張，累積超過10億小時的視訊。 使用者把這些圖片和視訊儲存在七牛上後會有一些資料處理方面的需求，如縮放、裁剪、水印等。這些檔案持續線上且資料種類多樣，如果使用者把這些檔案在自己的基板上處理好後再上傳到七牛，是非常不合算的事情。

而七牛最先提供基於儲存的資料處理功能方便使用者去做資料處理，這些資料處理通常放在企業的客戶端或伺服器端來操作，對接上七牛雲端儲存的資料處理介面後，即可對圖片和音訊進行豐富的實時轉碼功能，轉碼生成的新規格檔案放在七牛提供的快取層供App呼叫，不用佔用儲存空間，對企業來說不僅成本大大降低，還可提高開發效率。

下圖為一個圖片裁剪的資料處理示例：

七牛的檔案處理程式簡稱FOP（File Operation），不同的檔案處理操作使用不同的FOP。使用者只需上傳一個原檔案就可以通過使用七牛的資料處理功能得到各種樣式豐富的檔案。

下圖為檔案從上傳儲存到處理到分發的流程圖：

七牛雲的海量資料成就了Dora十分強大的資料處理能力，目前七牛的資料處理服務已經日處理數近百億次。面對這樣海量的資料處理請求，原有的資料處理平臺也面臨著新的挑戰：

1、日均請求量百億級，CPU 密集型計算

目前系統每天有近百億的資料處理請求量，擁有近千臺的計算叢集，整個存量、增量都非常大。而資料處理叢集中絕大部分的機器都是用來跑圖片、音視訊轉碼的，這些都是CPU密集型的計算，這意味著後臺需要很多臺機器，而且CPU的核數越多越好。在年底資料處理平臺可能會在目前近千臺的計算叢集基礎上翻好幾倍，需要有快速物理擴充套件和高效智慧管理的能力。

2、伺服器負載不均衡，資源利用率不高
實時線上處理的業務處理時間短，但是量大，需要大量的例項來應對高併發的情況。而非同步處理的業務處理時間長，也需要分配足夠的資源來。當實時業務並不繁忙而非同步處理業務增長時，並不能使用分配給實時業務的資源， 這種靜態資源分配機制帶來的分配不合理問題，導致伺服器負載不均衡，資源利用率不高。

3 、突發流量不可測量， 大量冗餘資源
在新接入使用者並不能完全正確的預測請求量，原來的模式是通過快速擴容機器並驗證上線，需要一定的處理時間，對於這種非計劃內的請求量需要準備大量的冗餘資源來應對突發流量。

4、叢集負載過重，不能自動按需擴充套件
個別使用者突增資料處理請求時導致叢集負載壓力過大，CPU處理變慢， 請求時間變長，請求任務堆積，影響其他業務，並不能在現有的資源基礎上進行快速擴充套件，也不能根據實際的業務壓力進行按需自動擴充套件叢集例項。

5、使用者自定義應用（UFOP）質量及規模未知
七牛除了提供官方的資料處理服務，也支援客戶將自定義資料處理模組部署到七牛雲端儲存的就近計算環境，避免遠端讀寫資料的效能開銷和流量成本，滿足使用者多方位的資料處理需求。但是各種UFOP執行在同一個平臺上就可能會存在部分UFOP的質量問題或請求量過大而分配的資源不足導致影響平臺上其他服務的正常執行。

為了解決以上問題，七牛基於資源管理系統Mesos自主研發了一套容器排程框架（DoraFramework），通過容器技術打造了易擴充套件、易部署、高自由度的資料處理平臺Dora。

整體架構圖如下所示：

通過容器技術可以實現跨機器實現彈性的實時排程，排程框架根據具體的業務負載情況動態的排程容器的個數， 很好的解決了靜態配置導致的資源利用率不高的問題 。而容器秒啟的特性也解決了當有大量突發請示進入，可以快速啟動服務的問題。

在網路方面，由於UFOP是使用者部署執行的服務，並不知道使用者是否有開啟其他的埠使用，所以使用的是Bridge模式，需要對外使用埠的都需要通過NAT進行暴露，這樣服務內部使用了什麼埠並不會對外界環境造成影響 ，對平臺環境做了非常好的安全隔離。

資料處理平臺的排程系統我們選擇的是Mesos+自研容器排程框架（DoraFramework）。

各元件介紹：

MESOS：由Zookeeper，Mesos Master，Mesos Agent 構成了基礎的MESOS 資料中心作業系統，可以統一管理機房中的所有物理機，負責資源層面的排程，是二層排程系統最基礎的執行環境 。

DoraFramework： 業務層排程框架，通過DoraFramework使用 Mesos管理所有的物理機資源，完成業務程序的排程與管理。

Consul：包含服務發現，健康檢查和KV儲存功能的一個開源叢集管理系統，DoraFramework排程系統使用Consul的服務發現和健康檢查機制提供基礎的服務發現功能，使用KV儲存功能來儲存DoraFramework的metadata。

Prometheus：一個開源的監控系統，實現機器級別，容器級別及業務系統級別的監控。

Pandora： 七牛的內部的日誌控制管理系統，負責生產環境所有日誌的匯聚及處理。

在這個架構中，我們選擇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排程架構的對比：

1. DoraFramework排程系統的服務註冊與發現使用Consul實現， Consul是用於實現分散式系統的服務發現與配置，支援跨資料中心的內部服務或外部服務的發現， 對外提供DNS介面，而Marathon-lb並不支援跨資料中心的服務發現。

2. Marathon是通過Marathon-lb所在節點的servicePort服務埠或VHOST來發現服務 ，要求網路模式必須為Bridge，但我們有些服務使用的是Host模式。因為Marathon-lb還負責負載均衡的功能，在大型的業務環境下，如果Marathon-lb出現異常，則會影響框架正確的服務發現。

3. Dora排程系統可以做更精確的彈性排程。因為它不僅支援做資源使用層面的監控，還支援做業務級別的監控，在對例項進行排程時就可以根據實際的業務壓力進行排程。

4.  Dora排程系統內的負載均衡元件是通過從Consul中獲取到所有的可用例項的地址進行負載分發，並可以根據每個例項的業務負載情況進行更精確的分發。而Marathon-lb並沒有業務層的監控資料。

5.  Consul提供系統級和應用級健康檢查，可以通過配置檔案及HTTP API兩種方式來定義健康檢查，並支援TCP，HTTP，Script，Docker和Timeto Live（TTL）五種方式做Check。Marathon的預設的Health Checks 只檢查Mesos中的任務狀態，當任務為running時，就被認為是health狀態，這樣不能做應用級的健康檢查。Marathon通過REST API可以檢視應用的健康狀態， 但只支援TCP、HTTP和Command三種方式。

6. Dora排程系統提供的監控棧在業務程序執行過程會彙總採集業務執行狀況指標，如請求次數，請求延時等資訊，業務程序對外暴露一個標準的http監控介面，監控介面的資料產出符合Prometheus監控資料格式。Prometheus通過配置Consul作為服務發現地址，會從Consul中獲取需要收集監控資料的業務程序列表，從業務程序暴露的http監控介面pull監控資料。

我們使用Consul做註冊中心，實現服務的註冊與發現。Consul自帶key/value儲存，可通過DNS介面做服務發現，且具體健康檢查的功能，並支援跨資料中心的服務發現。API Gateway 可以通過 Consul提供的DNS介面查詢到服務所有的可用例項的列表資訊，並將請求進行轉發。

如下圖：

1）服務的自動註冊和撤銷

新增微服務例項時，採取的原則是等待例項為執行狀態後將例項的訪問地址註冊到Consul Client 的 Service Registration，並配置這個服務的健康檢查，再將資料同步到 Consul Server的服務登錄檔中。

對於減少例項時，採取的原則是先將例項從Consul Server的服務登錄檔中刪除，等待冷卻時間之後，再從通過排程系統將這個例項銷燬。從而完成服務的自動註冊和撤銷。

2）服務發現

外在系統想訪問服務時，可通過服務名稱從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則是一個開放的平臺，不僅可以執行七牛自己的資料處理服務，也支援執行使用者自定義的資料處理服務，可以使使用者從繁雜的運維管理和架構設計中脫離出來，從而專注於實現資料處理單元。

目前七牛資料處理平臺的業務支撐能力如下：

以上就是今晚分享的七牛雲基於容器技術的海量資料處理平臺的全部內容，感謝大家。