京東的Docker鏡像存儲系統(tǒng)Speedy

jieforest

鏡像是Docker項目最大的創(chuàng)新點之一，所有的Docker容器都源于鏡像。不可否認鏡像存儲是Docker工作流中的重要一環(huán)，Docker Registry是官方提供的開源項目用以保存鏡像，同時它也提供了后端存儲系統(tǒng)來解決鏡像的落地問題，比如Local Filesystem、S3、Swift。Speedy是由京東開源的一個分布式鏡像后端存儲系統(tǒng)，在架構(gòu)設(shè)計上更好的解決了擴展性和可用性的問題。就Speedy項目的更多細節(jié)，InfoQ采訪了其負責人田琪。另外，田琪也是也是全球架構(gòu)師峰會北京站2015《云服務(wù)架構(gòu)探索》專題的出品人。

受訪嘉賓介紹
田琪，京東資深架構(gòu)師。10年互聯(lián)網(wǎng)行業(yè)從業(yè)經(jīng)驗，分別就職于搜狐、新浪、騰訊、京東等公司，目前負責京東云主機及云數(shù)據(jù)庫的架構(gòu)及研發(fā)工作，曾在新浪微博負責新浪微博的底層平臺研發(fā)工作，主導了Redis在新浪微博的大規(guī)模定制開發(fā)與應(yīng)用。之后加入騰訊負責騰訊大規(guī)模分布式存儲項目的研發(fā)與架構(gòu)工作，為騰訊眾多業(yè)務(wù)產(chǎn)品線提供高可靠的存儲服務(wù)。

InfoQ：能否介紹下你們的Docker鏡像存儲系統(tǒng)Speedy？為什么要做Speedy？

田琪：我們通過Docker搭建了我們的彈性計算云平臺，服務(wù)于公司內(nèi)外各項業(yè)務(wù)。在搭建整個平臺過程中遇到了很多問題，存儲是其中一項待解決的問題。Docker官方提供了Docker Registry服務(wù)，但是最終的鏡像文件落地存儲并沒有提供，目前支持的第三方存儲服務(wù)主要是S3、Swift等。

我們也調(diào)研了一些開源分布式存儲項目。發(fā)現(xiàn)主要存在幾個問題：一是架構(gòu)上傾向于無中心，或者一致性哈希等方式管理存儲節(jié)點，運維方面我們比較擔心可控性問題，另外增減機器都需要涉及文件數(shù)據(jù)的遷移，不利于線上系統(tǒng)穩(wěn)定。二是大多開源方案都沒有提供高性能的存儲引擎，即只提供了數(shù)據(jù)分布的算法，但數(shù)據(jù)落地沒有提供存儲層的優(yōu)化，這樣產(chǎn)生大量文件時就會存在性能問題。三是針對大文件沒有特別的優(yōu)化措施。

認識到這些問題后，我們決定自己研發(fā)分布式存儲系統(tǒng)，來解決和優(yōu)化上述的問題。

jieforest

InfoQ：能否介紹下Speedy整體的后端流程和邏輯？

jieforest

Speedy本身主要涉及模塊：

1）Docker Registry Driver
2）ChunkMaster
3）ChunkServer
4）ImageServer

Docker Registry Driver是一個遵照Docker Registry 1.0協(xié)議實現(xiàn)的驅(qū)動，完成Docker Registry與后端存儲系統(tǒng)的對接工作。ChunkServer與ChunkMaster組成了一個通用的對象存儲服務(wù)，ChunkMaster是中心節(jié)點，緩存了所有ChunkServer的信息，ChunkServer本身是最終鏡像數(shù)據(jù)落地的存儲節(jié)點，多個ChunkServer會構(gòu)成一個組，擁有唯一的組ID，上傳這個組內(nèi)的所有ChunkServer都成功才算成功，下載可以隨機選擇其中一個節(jié)點下 載。

ImageServer本身是一個無狀態(tài)的Proxy服務(wù)，它相當于是后面通用對象存儲服務(wù)的一個接入層，Driver發(fā)起的鏡像上傳、下載操作會直接發(fā)給ImageServer，ImageServer中緩存了ChunkMaster中的存儲節(jié)點信息，通過這些信息，ImageServer會進行ChunkServer節(jié)點的選擇操作，找到一組合適的ChunkServer機器完成鏡像的上傳或下載操作。

上傳流程

首先我們通過docker push命令發(fā)起上傳鏡像的操作，Docker本身會進行多次與后端存儲系統(tǒng)的交互（這里我要簡單吐個槽，合理的情況是這個結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)分開存儲，Docker本身用JSON表示結(jié)構(gòu)化的描述信息，也是上傳到后端存儲系統(tǒng)的，個人覺得Docker的元數(shù)據(jù)管理方面很混亂），最后一次交互是上傳鏡像的layer數(shù)據(jù)到Docker Registry。

如果使用默認的本地存儲，Docker Registry就直接把數(shù)據(jù)寫到了磁盤上，我們這里通過自己實現(xiàn)的Driver完成與后端對象存儲系統(tǒng)的上傳工作。

我們的Driver首先會對源源不斷上傳過來的字節(jié)流進行切割，按照配置的固定大小并發(fā)上傳到ImageServer中，并在上傳的HTTP請求中攜帶了該分片的索引及位置信息。

ImageServer在收到該分片上傳請求后，根據(jù)自己從ChunkMaster中同步過來的chunk信息來動態(tài)選擇一組ChunkServer，并將分片上傳到該組ChunkServer中的所有實例上，都成功才返回成功。并將分片索引位置信息及上傳成功返回的文件ID提交給MetaServer保存Driver在收到所有分片的上傳成功返回后，再返回給前端Docker，整個上傳流程結(jié)束。

下載流程

首先Docker通過docker pull請求下載鏡像，同樣在真正下載數(shù)據(jù)開始前，Docker同Docker Registry以及后端的存儲系統(tǒng)間也會產(chǎn)生多次的數(shù)據(jù)交互，這里省略，最后一步是下載對應(yīng)的Image Layer數(shù)據(jù)。Docker Registry在收到下載請求后首先通過ImageServer從MetaServer里獲取到該文件path對應(yīng)的分片信息，主要是分片的個數(shù)，及每一片的索引，然后將這些分片下載請求并發(fā)的發(fā)送給ImageServer服務(wù)器。

ImageServer收到分片下載請求后，查詢MetaServer獲得對應(yīng)的文件ID，該文件ID中包含有ChunkServer的位置信息，隨后請求相應(yīng)ChunkServer下載數(shù)據(jù)并返回給Driver。Driver收到分片下載的數(shù)據(jù)后，會根據(jù)分片的位置索引進行 排序，按文件分片順序返回給Docker。

jieforest

InfoQ：相比來說，Speedy有哪些優(yōu)勢？

田琪：我們系統(tǒng)設(shè)計主要考慮幾點：

1）架構(gòu)傾向于簡單、可控、容易部署
2）提供Linux C編寫的高效存儲引擎，存儲上將多個小文件合并成一個大文件存儲，減少元數(shù)據(jù) 存儲空間開銷和性能開銷，同時在原生文件系統(tǒng)上通過預分配空間方式，提供接近裸盤的讀寫性能，但兼具原 生文件系統(tǒng)的易用性。
3）針對大文件做優(yōu)化，提供斷點續(xù)傳、失敗重試等功能。

InfoQ：Speedy的官網(wǎng)提到目前已經(jīng)支持Registry 1.0，接下來有沒有計劃支持2.0？

田琪： Registry 2.0主要是針對安全和性能方面做了一些改進，具體可以參考GitHub上的說明。目前已經(jīng)可用。Speedy項目已經(jīng)給官方提交了針對Speedy的Registry 2.0的驅(qū)動，正在等待官方合并。

jieforest

InfoQ：Speedy的性能如何？

田琪： Speedy提供了高性能的存儲引擎，整體系統(tǒng)的瓶頸在于網(wǎng)這一層，我們的測試數(shù)據(jù)如下，可以看到在千兆網(wǎng)絡(luò)環(huán)境下，上傳和下載都達到了網(wǎng)卡的性能瓶頸而不是存儲本身，上傳是下載性能的1/3，原因是由于上傳是三副本的原因，后續(xù)我們考慮引入Erasure Code的方式，仍有性能提升空間。

jieforest

InfoQ：Docker Registry的單點問題，你們有好的解決方案嗎？

田琪：我們在線上部署是通過無狀態(tài)部署多點的方式來解決Registry單點問題的，Docker Registry 1.0服務(wù)本身內(nèi)部沒有任何本地存儲，所有元數(shù)據(jù)信息都是通過后端存儲系統(tǒng)落地的，所以可以無狀態(tài)多點部署來解決。

InfoQ：Docker Registry的權(quán)限控制，京東內(nèi)部是如何處理的？

田琪：由于我們的Docker彈性計算云服務(wù)是服務(wù)于公司內(nèi)部和生態(tài)用戶，即實際是一個私有云服務(wù)，我們內(nèi)部本身也不需要搭建類似 Docker Hub的服務(wù)，所以并沒有嚴格的權(quán)限控制問題。

InfoQ：Docker Registry 1.0的并發(fā)性能并不好，從你的分析來看，主要的并發(fā)瓶頸在哪里？

田琪：這個問題可以從整體Docker上傳鏡像流程說起，這個流程本身有很多待改進的地方，從鏡像生成的驅(qū)動到Docker Registry 1.0的設(shè)計都有提升空間，比如鏡像生成驅(qū)動部分使用Device Mapper等方式都是需要通過比對本地文件系統(tǒng)文件來生成Diff Layer，之后與Docker Registry 1.0產(chǎn)生多次元數(shù)據(jù)的交互，最后才會發(fā)起Layer本身數(shù)據(jù)的上傳下載請求，并且針對大文件也沒有任何優(yōu)化，不支持斷點續(xù)傳等功能。這些環(huán)節(jié)在 Docker Registry 2.0中有很多改善，相信后續(xù)也會持續(xù)發(fā)展。

jieforest

原文見： http://www.infoq.com/cn/news/2015/09/speedy-docker-image-storage

wq4113

樓主辛苦了