本文講的是DockOne微信分享( 九十一）：打造百億級數據處理量的彈性調度容器平臺【編者的話】本次分享介紹七牛數據處理團隊的容器技術實踐經驗，分享七牛如何通過自主研發的容器調度框架打造易擴展、易部署、高自由度、高可用、高性能的數據處理平臺。

主要內容包括四個方面：

海量數據處理的業務場景

海量數據處理平臺的挑戰

自研容器調度框架介紹

海量數據處理平臺實踐

一、數據處理業務場景

首先介紹一下七牛數據處理業務的背景。七牛云目前平臺上有超過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：七牛云存儲的設計目標是針對海量小文件的存儲，所以它對文件系統的第一個改變也是去關系，也就是去目錄結構（有目錄意味著有父子關系）。所以七牛云存儲不是文件系統，而是鍵值存儲，或對象存儲。我們每個大文件都是切割成小文件存儲下來的，元信息單獨存放在數據庫中，用戶請求的時候通過業務層合并處理后返回。因此理論上磁盤只存儲小文件，大文件存儲和讀取的性能主要在于文件切割和合并。

以上內容根據2016年11月1日晚微信群分享內容整理。分享人陳2016-11-02，七牛云布道師，負責DevOps ，容器，微服務相關技術的落地研究與布道。多年企業級系統運維管理經驗，對大型分布式系統架構設計及運維有豐富的經驗。 DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加微信：liyingjiesz，進群參與，您有想聽的話題或者想分享的話題都可以給我們留言。

原文發布時間為：2016-11-02

本文作者：陳

本文來自云棲社區合作伙伴Dockerone.io，了解相關信息可以關注Dockerone.io。

原文標題：DockOne微信分享( 九十一）：打造百億級數據處理量的彈性調度容器平臺

總結

以上是生活随笔為你收集整理的DockOne微信分享( 九十一）：打造百亿级数据处理量的弹性调度容器平台的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。