如何打造百億級數據處理量的彈性調度容器平臺

七牛雲數據處理團隊的容器技術實踐經驗

1、數據處理業務場景

首先介紹一下七牛數據處理業務的背景。七牛雲目前平臺上有超過 50 萬家企業客戶，圖片超過 2000 億張，累積超過 10 億小時的視頻。 用戶把這些圖片和視頻存儲在七牛上後會有一些數據處理方面的需求，如縮放、裁剪、水印等。

這些文件持續在線且數據種類多樣，若是用戶把這些文件在本身的基板上處理好後再上傳到七牛，是很是不合算的事情。而七牛最早提供基於存儲的數據處理功能方便用戶去作數據處理，這些數據處理一般放在企業的客戶端或服務器端來操做，對接上七牛雲存儲的數據處理接口後，便可對圖片和音頻進行豐富的實時轉碼功能，轉碼生成的新規格文件放在七牛提供的緩存層供 App 調用，不用佔用存儲空間，對企業來講不只成本大大下降，還可提升開發效率。

下圖爲一個圖片裁剪的數據處理示例：

七牛的文件處理程序簡稱 FOP（File Operation），不一樣的文件處理操做使用不一樣的 FOP。用戶只需上傳一個原文件就能夠經過使用七牛的數據處理功能獲得各類樣式豐富的文件。下圖爲文件從上傳存儲處處理到分發的流程圖：

2、海量數據處理平臺的挑戰

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

1. 日均請求量百億級，CPU 密集型計算
   目前系統天天有近百億的數據處理請求量，擁有近千臺的計算集羣，整個存量、增量都很是大。而數據處理集羣中絕大部分的機器都是用來跑圖片、音視頻轉碼的，這些都是 CPU 密集型的計算，這意味着後臺須要不少臺機器，並且 CPU 的核數越多越好。在年末數據處理平臺可能會在目前近千臺的計算集羣基礎上翻好幾倍，須要有快速物理擴展和高效智能管理的能力。
2. 服務器負載不均衡，資源利用率不高
   實時在線處理的業務處理時間短，可是量大，須要大量的實例來應對高併發的狀況。而異步處理的業務處理時間長，也須要分配足夠的資源來。當實時業務並不繁忙而異步處理業務增加時，並不能使用分配給實時業務的資源， 這種靜態資源分配機制帶來的分配不合理問題，致使服務器負載不均衡，資源利用率不高。
3. 突發流量不可測量， 大量冗餘資源
   在新接入用戶並不能徹底正確的預測請求量，原來的模式是經過快速擴容機器並驗證上線，須要必定的處理時間，對於這種非計劃內的請求量須要準備大量的冗餘資源來應對突發流量。
4. 集羣負載太重，不能自動按需擴展
   個別用戶突增數據處理請求時致使集羣負載壓力過大，CPU 處理變慢， 請求時間變長，請求任務堆積，影響其餘業務，並不能在現有的資源基礎上進行快速擴展，也不能根據實際的業務壓力進行按需自動擴展集羣實例。
5. 用戶自定義應用（UFOP）質量及規模未知
   七牛除了提供官方的數據處理服務，也支持客戶將自定義數據處理模塊部署到七牛雲存儲的就近計算環境，避免遠程讀寫數據的性能開銷和流量成本，知足用戶多方位的數據處理需求。可是各類 UFOP 運行在同一個平臺上就可能會存在部分 UFOP 的質量問題或請求量過大而分配的資源不足致使影響平臺上其餘服務的正常運行。

3、自研容器調度系統介紹

爲了解決以上問題，七牛基於資源管理系統 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 調度架構的對比：

1. DoraFramework 調度系統的服務註冊與發現使用 Consul 實現， Consul 是用於實現分佈式系統的服務發現與配置，支持跨數據中心的內部服務或外部服務的發現， 對外提供 DNS 接口，而 Marathon-lb 並不支持跨數據中心的服務發現。
2. Marathon 是經過 Marathon-lb 所在節點的 servicePort 服務端口或 VHOST 來發現服務 ，要求網絡模式必須爲 Bridge。由於 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 中註冊的全部健康實例的訪問地址， 再將請求發送給實例。

4、海量數據處理平臺實踐

咱們生產環境的配置管理採用的是 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：七牛雲存儲的設計目標是針對海量小文件的存儲，因此它對文件系統的第一個改變也是去關係，也就是去目錄結構（有目錄意味着有父子關係）。因此七牛雲存儲不是文件系統，而是鍵值存儲，或對象存儲。咱們每一個大文件都是切割成小文件存儲下來的，元信息單獨存放在數據庫中，用戶請求的時候經過業務層合併處理後返回。所以理論上磁盤只存儲小文件，大文件存儲和讀取的性能主要在於文件切割和合並。

本文做者： 陳愛珍@七牛雲佈道師，更多雲行業技術洞見請訪問七牛雲博客。