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

主要內(nèi)容包括四個方面：

海量數(shù)據(jù)處理的業(yè)務(wù)場景

海量數(shù)據(jù)處理平臺的挑戰(zhàn)

自研容器調(diào)度框架介紹

海量數(shù)據(jù)處理平臺實踐

一、數(shù)據(jù)處理業(yè)務(wù)場景

首先介紹一下七牛數(shù)據(jù)處理業(yè)務(wù)的背景。七牛云目前平臺上有超過50萬家企業(yè)客戶，圖片超過2000億張，累積超過10億小時的視頻。 用戶把這些圖片和視頻存儲在七牛上后會有一些數(shù)據(jù)處理方面的需求，如縮放、裁剪、水印等。這些文件持續(xù)在線且數(shù)據(jù)種類多樣，如果用戶把這些文件在自己的基板上處理好后再上傳到七牛，是非常不合算的事情。而七牛最先提供基于存儲的數(shù)據(jù)處理功能方便用戶去做數(shù)據(jù)處理，這些數(shù)據(jù)處理通常放在企業(yè)的客戶端或服務(wù)器端來操作，對接上七牛云存儲的數(shù)據(jù)處理接口后，即可對圖片和音頻進行豐富的實時轉(zhuǎn)碼功能，轉(zhuǎn)碼生成的新規(guī)格文件放在七牛提供的緩存層供App調(diào)用，不用占用存儲空間，對企業(yè)來說不僅成本大大降低，還可提高開發(fā)效率。 下圖為一個圖片裁剪的數(shù)據(jù)處理示例：

七牛的文件處理程序簡稱FOP（File Operation），不同的文件處理操作使用不同的FOP。用戶只需上傳一個原文件就可以通過使用七牛的數(shù)據(jù)處理功能得到各種樣式豐富的文件。下圖為文件從上傳存儲到處理到分發(fā)的流程圖：

二、海量數(shù)據(jù)處理平臺的挑戰(zhàn)

七牛云的海量數(shù)據(jù)成就了Dora十分強大的數(shù)據(jù)處理能力，目前七牛的數(shù)據(jù)處理服務(wù)已經(jīng)日處理數(shù)近百億次。面對這樣海量的數(shù)據(jù)處理請求，原有的數(shù)據(jù)處理平臺也面臨著新的挑戰(zhàn)：

日均請求量百億級，CPU 密集型計算
目前系統(tǒng)每天有近百億的數(shù)據(jù)處理請求量，擁有近千臺的計算集群，整個存量、增量都非常大。而數(shù)據(jù)處理集群中絕大部分的機器都是用來跑圖片、音視頻轉(zhuǎn)碼的，這些都是CPU密集型的計算，這意味著后臺需要很多臺機器，而且CPU的核數(shù)越多越好。在年底數(shù)據(jù)處理平臺可能會在目前近千臺的計算集群基礎(chǔ)上翻好幾倍，需要有快速物理擴展和高效智能管理的能力。

服務(wù)器負(fù)載不均衡，資源利用率不高
實時在線處理的業(yè)務(wù)處理時間短，但是量大，需要大量的實例來應(yīng)對高并發(fā)的情況。而異步處理的業(yè)務(wù)處理時間長，也需要分配足夠的資源來。當(dāng)實時業(yè)務(wù)并不繁忙而異步處理業(yè)務(wù)增長時，并不能使用分配給實時業(yè)務(wù)的資源， 這種靜態(tài)資源分配機制帶來的分配不合理問題，導(dǎo)致服務(wù)器負(fù)載不均衡，資源利用率不高。

突發(fā)流量不可測量， 大量冗余資源
在新接入用戶并不能完全正確的預(yù)測請求量，原來的模式是通過快速擴容機器并驗證上線，需要一定的處理時間，對于這種非計劃內(nèi)的請求量需要準(zhǔn)備大量的冗余資源來應(yīng)對突發(fā)流量。

集群負(fù)載過重，不能自動按需擴展
個別用戶突增數(shù)據(jù)處理請求時導(dǎo)致集群負(fù)載壓力過大，CPU處理變慢， 請求時間變長，請求任務(wù)堆積，影響其他業(yè)務(wù)，并不能在現(xiàn)有的資源基礎(chǔ)上進行快速擴展，也不能根據(jù)實際的業(yè)務(wù)壓力進行按需自動擴展集群實例。

用戶自定義應(yīng)用（UFOP）質(zhì)量及規(guī)模未知
七牛除了提供官方的數(shù)據(jù)處理服務(wù)，也支持客戶將自定義數(shù)據(jù)處理模塊部署到七牛云存儲的就近計算環(huán)境，避免遠程讀寫數(shù)據(jù)的性能開銷和流量成本，滿足用戶多方位的數(shù)據(jù)處理需求。但是各種UFOP運行在同一個平臺上就可能會存在部分UFOP的質(zhì)量問題或請求量過大而分配的資源不足導(dǎo)致影響平臺上其他服務(wù)的正常運行。

三、自研容器調(diào)度系統(tǒng)介紹

為了解決以上問題，七牛基于資源管理系統(tǒng)Mesos自主研發(fā)了一套容器調(diào)度框架（DoraFramework），通過容器技術(shù)打造了易擴展、易部署、高自由度的數(shù)據(jù)處理平臺Dora。整體架構(gòu)圖如下所示：

各組件介紹：

Mesos：由ZooKeeper、Mesos Master、Mesos Agent構(gòu)成了基礎(chǔ)的Mesos數(shù)據(jù)中心操作系統(tǒng)，可以統(tǒng)一管理機房中的所有物理機，負(fù)責(zé)資源層面的調(diào)度，是二層調(diào)度系統(tǒng)最基礎(chǔ)的運行環(huán)境 。

DoraFramework：業(yè)務(wù)層調(diào)度框架，通過DoraFramework使用Mesos管理所有的物理機資源，完成業(yè)務(wù)進程的調(diào)度與管理。

Consul：包含服務(wù)發(fā)現(xiàn)，健康檢查和KV存儲功能的一個開源集群管理系統(tǒng)，DoraFramework調(diào)度系統(tǒng)使用Consul的服務(wù)發(fā)現(xiàn)和健康檢查機制提供基礎(chǔ)的服務(wù)發(fā)現(xiàn)功能，使用KV存儲功能來存儲DoraFramework的metadata。

Prometheus：一個開源的監(jiān)控系統(tǒng)，實現(xiàn)機器級別，容器級別及業(yè)務(wù)系統(tǒng)級別的監(jiān)控。

Pandora： 七牛的內(nèi)部的日志控制管理系統(tǒng)，負(fù)責(zé)生產(chǎn)環(huán)境所有日志的匯聚及處理。

在這個架構(gòu)中，我們選擇通過容器技術(shù)實現(xiàn)跨機器實現(xiàn)彈性的實時調(diào)度。調(diào)度框架可以根據(jù)具體的業(yè)務(wù)負(fù)載情況動態(tài)的調(diào)度容器的個數(shù)， 很好的解決了靜態(tài)配置導(dǎo)致的資源利用率不高的問題 。而容器秒啟的特性也解決了當(dāng)有大量突發(fā)請示進入，可以快速啟動服務(wù)的問題。在網(wǎng)絡(luò)方面，由于UFOP是用戶部署運行的服務(wù)，并不知道用戶是否有開啟其他的端口使用，所以使用的是Bridge模式，需要對外使用端口的都需要通過NAT進行暴露，這樣服務(wù)內(nèi)部使用了什么端口并不會對外界環(huán)境造成影響 ，對平臺環(huán)境做了非常好的安全隔離。

數(shù)據(jù)處理平臺的調(diào)度系統(tǒng)我們選擇的是Mesos 自研容器調(diào)度框架（DoraFramework）。選擇Mesos做為資源管理系統(tǒng)一個是因為Mesos的相對其他的容器調(diào)度系統(tǒng)更成熟，Kubernetes是2015 才發(fā)布可生產(chǎn)環(huán)境運行的版本，Docker Swarm則是2016年才發(fā)布，這兩個產(chǎn)品的生產(chǎn)實踐在調(diào)研時基本還沒什么大型生產(chǎn)實踐經(jīng)驗，而Mesos則已有七八年的歷史，且資源管理方面已經(jīng)在如蘋果，Twitter等大型公司得到生產(chǎn)實踐，穩(wěn)定性比較好；第二個是因為Mesos支持調(diào)度成千上萬的節(jié)點，以七牛目前已經(jīng)達到近千臺物理機的規(guī)模，且每年都在大幅度增長的情況，Meoso這種支持超大規(guī)模調(diào)度的資源管理框架更合適七牛的業(yè)務(wù)發(fā)展； 第三是因為Mesos的簡單性，開放性及可擴展性，Mesos是一個開源的分布式彈性資源管理系統(tǒng)，整個Mesos系統(tǒng)采用了雙層調(diào)度框架：第一層由Mesos收集整個數(shù)據(jù)中心的資源信息，再將資源分配給框架；第二層由框架自己的調(diào)度器將資源分配給自己內(nèi)部的任務(wù)。Mesos自身只做資源層的管理，這種簡單性帶來的則是穩(wěn)定性。而容器的調(diào)度框架則可以使用開源框架如Marathon/chronos或自主研發(fā)。Kubernetes雖然功能很豐富，但是也比較復(fù)雜，組件及概念都比較多，并且缺乏開放性和可擴展性，只能使用它提供的調(diào)度功能，而不能根據(jù)自身業(yè)務(wù)的情況定制調(diào)度框架，會造成對Kubernetes過于依賴的情況。

為什么不選擇Mesos的核心框架Marathon 而選擇自研，出于三方面的考慮：1. Marathon有些方面不支持我們期望的使用姿勢，比如不太好無縫對接服務(wù)發(fā)現(xiàn)；2. Marathon采用Scala開發(fā)，出了問題不好排查，也不方便我們做二次開發(fā)；3. 如果選用Marathon的話，我們上面還是要再做一層對 Marathon的包裝才能作為Dora的調(diào)度服務(wù)，這樣模塊就會變多，部署運維會復(fù)雜。

DoraFramework是七牛使用go語言自研的容器調(diào)度框架。DoraFramework實現(xiàn)了Mesos兩層調(diào)度中業(yè)務(wù)進程的調(diào)度，是Dora調(diào)度系統(tǒng)中的核心組件，通過與Mesos和consul組件之間的交互， 對外提供API接口。架構(gòu)圖如下：

DoraFramework主要功能介紹：

• 自動化應(yīng)用的部署
• 服務(wù)注冊與發(fā)現(xiàn)
• 彈性調(diào)度容器數(shù)量
• 負(fù)載均衡
• 支持在指定機器上增加或減少實例
• 支持高可用
• 應(yīng)用的版本和升級管理
• 支持獲取實例的狀態(tài)及日志數(shù)據(jù)
• 支持業(yè)務(wù)級別的監(jiān)控
• 支持實例的故障修復(fù)

DoraFramework與Marathon調(diào)度架構(gòu)的對比：

DoraFramework調(diào)度系統(tǒng)的服務(wù)注冊與發(fā)現(xiàn)使用Consul實現(xiàn)， Consul是用于實現(xiàn)分布式系統(tǒng)的服務(wù)發(fā)現(xiàn)與配置，支持跨數(shù)據(jù)中心的內(nèi)部服務(wù)或外部服務(wù)的發(fā)現(xiàn)， 對外提供DNS接口，而Marathon-lb并不支持跨數(shù)據(jù)中心的服務(wù)發(fā)現(xiàn)。

Marathon是通過Marathon-lb所在節(jié)點的servicePort服務(wù)端口或VHOST來發(fā)現(xiàn)服務(wù) ，要求網(wǎng)絡(luò)模式必須為Bridge。因為Marathon-lb還負(fù)責(zé)負(fù)載均衡的功能，在大型的業(yè)務(wù)環(huán)境下，如果Marathon-lb出現(xiàn)異常，則會影響框架正確的服務(wù)發(fā)現(xiàn)。

Dora調(diào)度系統(tǒng)可以做更精確的彈性調(diào)度。因為它不僅支持做資源使用層面的監(jiān)控，還支持做業(yè)務(wù)級別的監(jiān)控，在對實例進行調(diào)度時就可以根據(jù)實際的業(yè)務(wù)壓力進行調(diào)度。

Dora調(diào)度系統(tǒng)內(nèi)的負(fù)載均衡組件是通過從Consul中獲取到所有的可用實例的地址進行負(fù)載分發(fā)，并可以根據(jù)每個實例的業(yè)務(wù)負(fù)載情況進行更精確的分發(fā)。而Marathon-lb并沒有業(yè)務(wù)層的監(jiān)控數(shù)據(jù)。

Consul提供系統(tǒng)級和應(yīng)用級健康檢查，可以通過配置文件及HTTP API兩種方式來定義健康檢查，并支持TCP、HTTP、Script、Docker和Timeto Live（TTL）五種方式做Check。Marathon的默認(rèn)的Health Checks只檢查Mesos中的任務(wù)狀態(tài)，當(dāng)任務(wù)為running時，就被認(rèn)為是health狀態(tài)，這樣不能做應(yīng)用級的健康檢查。Marathon通過REST API可以查看應(yīng)用的健康狀態(tài)， 但只支持TCP、HTTP和Command三種方式。

Dora調(diào)度系統(tǒng)提供的監(jiān)控棧在業(yè)務(wù)進程運行過程會匯總采集業(yè)務(wù)運行狀況指標(biāo)，如請求次數(shù)，請求延時等信息，業(yè)務(wù)進程對外暴露一個標(biāo)準(zhǔn)的http監(jiān)控接口，監(jiān)控接口的數(shù)據(jù)產(chǎn)出符合Prometheus監(jiān)控數(shù)據(jù)格式。Prometheus通過配置Consul作為服務(wù)發(fā)現(xiàn)地址，會從Consul中獲取需要收集監(jiān)控數(shù)據(jù)的業(yè)務(wù)進程列表，從業(yè)務(wù)進程暴露的http監(jiān)控接口pull監(jiān)控數(shù)據(jù)。

我們使用Consul做注冊中心，實現(xiàn)服務(wù)的注冊與發(fā)現(xiàn)。Consul自帶key/value存儲，可通過DNS接口做服務(wù)發(fā)現(xiàn)，且具體健康檢查的功能，并支持跨數(shù)據(jù)中心的服務(wù)發(fā)現(xiàn)。API Gateway可以通過Consul提供的DNS接口查詢到服務(wù)所有的可用實例的列表信息，并將請求進行轉(zhuǎn)發(fā)。

服務(wù)的自動注冊和撤銷
新增微服務(wù)實例時，采取的原則是等待實例為運行狀態(tài)后將實例的訪問地址注冊到Consul Client的Service Registration，并配置這個服務(wù)的健康檢查，再將數(shù)據(jù)同步到 Consul Server的服務(wù)注冊表中。

對于減少實例時，采取的原則是先將實例從Consul Server的服務(wù)注冊表中刪除，等待冷卻時間之后，再從通過調(diào)度系統(tǒng)將這個實例銷毀。從而完成服務(wù)的自動注冊和撤銷。

服務(wù)發(fā)現(xiàn)
外在系統(tǒng)想訪問服務(wù)時，可通過服務(wù)名稱從Consul Server提供的DNS接口查詢到當(dāng)前服務(wù)在Consul Server中注冊的所有健康實例的訪問地址， 再將請求發(fā)送給實例。

四、海量數(shù)據(jù)處理平臺實踐

我們生產(chǎn)環(huán)境的配置管理采用的是Ansible，Ansible默認(rèn)使用SSH進行遠程連接，無需在被管節(jié)點上安裝附加軟件，可以批量系統(tǒng)配置、批量部署、批量運行命令等，非常適合七牛的大規(guī)模IT環(huán)境。而Playbooks 是一種簡單的配置管理系統(tǒng)與多機器部署系統(tǒng)的基礎(chǔ)，使用非常簡單，且具有可讀性，非常適合于復(fù)雜應(yīng)用的部署。我們通過Ansible可以實現(xiàn)數(shù)據(jù)處理平臺的一鍵式安裝和刪除，新增和刪除節(jié)點，還包括對組件版本的升級及回退，以及生產(chǎn)環(huán)境的批量配置修改等操作，簡化了復(fù)雜的運維配置管理工作。

在實踐中，選擇一臺主機做為中控機，安裝Ansible，再配置這臺中控機與所有遠程主機的SSH互信，再在中控機上配置Playbook文件，即可對多臺主機進行批量操作。對于簡單的操作，可執(zhí)行如下命令：
$ansible-playbook?main.yml?-i?hosts
在main.yml里編輯所有需要做的操作，在hosts文件里寫入所有需求操作的主機IP地址，即可完成對hosts文件里所有主機的批量操作。而對于復(fù)雜的操作，則可通過編寫Playbook進行配置。roles里存放不同的角色任務(wù)，比如Mesos Master上執(zhí)行的任務(wù)和Mesos Agent上執(zhí)行的任務(wù)不同，則可放在不同的roles里，也可以把Mesos、Zookeeper、Consul放的不同的roles里。tasks里則是role里具體執(zhí)行的任務(wù)，handlers則是tasks里觸發(fā)執(zhí)行的任務(wù)。template則是模板文件，比如我們需要個性Consul的默認(rèn)配置文件，可以修改后的配置文件放在這個目錄下，在執(zhí)行時用這個文件替換默認(rèn)的配置文件。

在監(jiān)控方面，數(shù)據(jù)處理平臺擁有完整的監(jiān)控體系，包括了主機監(jiān)控，容器監(jiān)控，服務(wù)監(jiān)控，流量監(jiān)控，日志監(jiān)控。主機和容器的監(jiān)控主要通過Prometheus的各種Exporter來做，采集到包括CPU、內(nèi)存、網(wǎng)絡(luò)以及磁盤的實時使用情況，服務(wù)監(jiān)控和流量監(jiān)控則通過七牛自己的監(jiān)控程序進行監(jiān)控，可以監(jiān)控到服務(wù)的狀態(tài)、存活性、句柄數(shù)、及所有處理命令的請求數(shù)、失敗數(shù)等。日志監(jiān)控則是通過七牛內(nèi)部的日志平臺Pandora系統(tǒng)進行監(jiān)控，包括收集系統(tǒng)日志，容器日志和業(yè)務(wù)進程日志。通過修改開源的文件收集器Filebeat的output，將采集到的日志全部傳送到七牛內(nèi)部的日志監(jiān)控系統(tǒng)Pandora進行日志監(jiān)控。

監(jiān)控數(shù)據(jù)顯示如下：

以上就是七牛云數(shù)據(jù)處理平臺基于容器技術(shù)實踐的情況。目前七牛的數(shù)據(jù)處理平臺具備零運維、高可用、高性能的數(shù)據(jù)處理服務(wù)能力，可讓用戶輕松應(yīng)對圖片、音視頻及其他各類數(shù)據(jù)的實時、異步處理場景。七牛的數(shù)據(jù)處理業(yè)務(wù)系統(tǒng)不僅可以處理來自七牛云存儲的數(shù)據(jù)處理請求，也支持來自非七牛云存儲的數(shù)據(jù)處理請求，還可以直接處理來自七牛云分發(fā)Fusion的數(shù)據(jù)處理請求，用來提高CDN中間源數(shù)據(jù)的處理速度。而數(shù)據(jù)處理平臺Dora則是一個開放的平臺，不僅可以運行七牛自己的數(shù)據(jù)處理服務(wù)，也支持運行用戶自定義的數(shù)據(jù)處理服務(wù)，并具備豐富的運維管理功能，可以使用戶從繁雜的運維管理和架構(gòu)設(shè)計中脫離出來，從而專注于實現(xiàn)數(shù)據(jù)處理單元。 七牛數(shù)據(jù)處理平臺的業(yè)務(wù)支撐能力如下：

Q&A

Q：請問管理系統(tǒng)是基于什么開發(fā)的？這個系統(tǒng)會開源嗎？
A：Dora的調(diào)度框架是基本GO語言開發(fā)的。目前不會開源，但提供私有部署。 Q：剛開始看Mesos框架實現(xiàn)，請問自定義的Scheduler中如何調(diào)用自定義的executor？
A：Schesuler跟executor這個都是按照Mesos最新的v1版的HTTP API去做的，這個沒有不兼容的問題，只是mesos go版本的SDK有些老舊，更新也比較緩慢，這個地方我們自己根據(jù)需要做了些更改。 Q：請問目前Consul集群是多大規(guī)模呢？有沒有考慮Consul擴展的性能瓶頸呢？
A：Consul是在每個slave節(jié)點上會有一個Consul的Agent ，我們一個機房有200多臺專門用于數(shù)據(jù)處理的機器，所以Consul的集群規(guī)模也就這么大，單機房。對我們當(dāng)前來說不存在瓶頸，因為我們對Consul的使用的場景相對單一簡單：作為Metadata的可靠存儲，Metadata的更新其實并不是很頻繁，這個我們參考過別人做過的一些性能測試和我們自己的一些測試，性能是滿足需求的。另外一個功能就是服務(wù)發(fā)現(xiàn)與實例的健康檢查，健康檢查是由運行在每個機器上的Consul Agent負(fù)責(zé)的，均攤到每個機器上，其實單個機器上的實例數(shù)不會特別的多，所以這部分也沒有太大的壓力。當(dāng)然了，這個也是跟業(yè)務(wù)規(guī)模相關(guān)的，假定哪天Consul的擴展性成我們的問題了，也說明我們的業(yè)務(wù)量特別特別的大了，我們也是很期望這一天到來的。 Q：Dora是否可以支持MySQL的自動伸縮擴容？
A：Dora系統(tǒng)的應(yīng)用場景還是運行一些數(shù)據(jù)處理命令這類無狀態(tài)的服務(wù)。MySQL這類系統(tǒng)不適合直接跑在Dora這個里面，如果期望MySQL跑在Mesos上面的話，需要自己實現(xiàn)一個專門針對MySQL的調(diào)度器，因為MySQL實例的擴縮容，實例故障的修復(fù)都有MySQL自身特定的需求。我們公司MySQL這類有狀態(tài)服務(wù)的容器化是由公司另一個容器平臺實現(xiàn)的。MySQL的用的是Percona XtraDB Cluster方案，我們利用另一個容器平臺的API寫了一個Percona XtraDB Cluster的調(diào)度器，把Percona XtraDB Cluster的大部分運維操作在容器平臺上自動化了。 Q：你們的Ansible host文件是動態(tài)生成的嘛？代碼推送也是通過Ansible嘛？新增刪除節(jié)點，以及回滾等操作是如何實現(xiàn)的？
A：最開始實踐的時候不是動態(tài)生成的，其實我們是可以從Consul中獲取到當(dāng)前集群里面的節(jié)點和節(jié)點的一些簡單的配置信息，后面有考慮從Consul里面拿節(jié)點信息，動態(tài)生成用于Ansible灰度的host文件。代碼推送也是使用的Ansible，如果能和外網(wǎng)連接的機器，也可以使用GitHub。因為我們的Playbook的角色是通過組件區(qū)分的，新增刪除節(jié)點只需要修改Host文件，把相應(yīng)的節(jié)點加入安裝或刪除相應(yīng)的組件。如回滾操作：$?ansible-playbook?rollback.yml?-i?hosts?-e?"hosts_env=XXX?app_env=XXX?version_env=XXX"
參數(shù)說明：

• hosts_env：表示要回滾的主機組，如Master
• app_env：表示要回滾的組件，如ZooKeeper
• xxx_version：表示要回滾組件的版本號，如v1.0.1.20160918

Q：Dora的調(diào)度策略是怎么樣的？可否簡單介紹一下。
A：首先保證同一種數(shù)據(jù)處理命令的實例盡量均勻分散在不同的機器上，然后再是保證均衡每個機器上的負(fù)載。 Q：Prometheus目前是單機的，數(shù)據(jù)量大了怎么辦？Prometheus 的監(jiān)控數(shù)據(jù)是存在InfluxDB嗎？
A：目前我們是按業(yè)務(wù)拆分server，數(shù)據(jù)量可以支撐。我們沒有使用InfluxDB，還是用的原生的LevelDB。 Q：這么大文件量，你們在存儲技術(shù)方面有什么特別的處理嗎？怎么實現(xiàn)高性能和海量存儲之間均衡？
A：七牛云存儲的設(shè)計目標(biāo)是針對海量小文件的存儲，所以它對文件系統(tǒng)的第一個改變也是去關(guān)系，也就是去目錄結(jié)構(gòu)（有目錄意味著有父子關(guān)系）。所以七牛云存儲不是文件系統(tǒng)，而是鍵值存儲，或?qū)ο蟠鎯ΑＮ覀兠總€大文件都是切割成小文件存儲下來的，元信息單獨存放在數(shù)據(jù)庫中，用戶請求的時候通過業(yè)務(wù)層合并處理后返回。因此理論上磁盤只存儲小文件，大文件存儲和讀取的性能主要在于文件切割和合并。

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

原文發(fā)布時間為：2016-11-02

本文作者：陳

本文來自云棲社區(qū)合作伙伴Dockerone.io，了解相關(guān)信息可以關(guān)注Dockerone.io。

原文標(biāo)題：DockOne微信分享( 九十一）：打造百億級數(shù)據(jù)處理量的彈性調(diào)度容器平臺

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。