如何打造百億級數據處理量的彈性調度容器平臺
一、數據處理業務場景
這些文件持續在線且數據種類多樣，如果用戶把這些文件在自己的基板上處理好后再上傳到七牛，是非常不合算的事情。而七牛最先提供基于存儲的數據處理功能方便用戶去做數據處理，這些數據處理通常放在企業的客戶端或服務器端來操作，對接上七牛云存儲的數據處理接口后，即可對圖片和音頻進行豐富的實時轉碼功能，轉碼生成的新規格文件放在七牛提供的緩存層供 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 則已有七八年的歷史，且資源管理方面已經在如蘋果，推ter 等大型公司得到生產實踐，穩定性比較好。
第二個是因為 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：七牛云存儲的設計目標是針對海量小文件的存儲，所以它對文件系統的第一個改變也是去關系，也就是去目錄結構（有目錄意味著有父子關系）。所以七牛云存儲不是文件系統，而是鍵值存儲，或對象存儲。我們每個大文件都是切割成小文件存儲下來的，元信息單獨存放在數據庫中，用戶請求的時候通過業務層合并處理后返回。因此理論上磁盤只存儲小文件，大文件存儲和讀取的性能主要在于文件切割和合并。
來自：http://www.cnblogs.com/qiniu/p/6042798.html