摘要：問能否談一下迅雷云使用的過程其實最初的時候，迅雷團隊對是懷有謹慎的態度的。三調度算法是迅雷云定制優化的。迅雷在使用這方面一直沒有把數據層面交給迅雷云之外的系統。

  
非商業轉載請注明作譯者、出處，并保留本文的原始鏈接：http://www.ituring.com.cn/article/201256

曾金龍就職于迅雷網絡，是國內覆蓋面最廣的“迅雷P2P引擎”核心研發成員。他畢業于中山大學，具有計算機科學碩士學位，他的研究方向是P2P網絡、音視頻傳輸和CEP系統。曾金龍對Docker技術有著深入的理解，是國內較早將Docker引入到實際軟件開發、測試和部署中的人。他在2015年出版了《Docker開發實踐》一書。

問：作為迅雷P2P引擎的核心開發成員，能否談一下當時開發的經歷以及克服了哪些困難？

我一開始工作的時候就進入到了一家在P2P領域NO.1的公司，而且還是核心團隊，所以壓力非常大。我發現，現實的P2P依然處在第一代P2P的水平，和研究上的P2P有很大差異。我們在高校里面研究的是各種結構化的P2P，叫做第二代P2P。這就意味著即便我是以P2P為研究方向來到了迅雷，但一切都是歸零的。這是理想與現實之間的差異，對我個人而言是個困難。

開發上的困難有兩個方面，一是新做的項目往往配置基礎環境會耗費大量的時間，而且開發不會碰到的問題在測試和運營那里會“莫名其妙”地出現，所以容器是解決程序員痛點的好技術。另外就是迅雷云是全國最大的P2P數據平臺，所以里面有非常多分工不同的服務器，有打洞的Punch服務、有索引的Hub服務、跟蹤的Tracker服務以及CDN管理服務等，而且處理的數據量非常大。讓公司各個事業群的項目組合理管理和使用這些集群確實不容易，而大多數問題都來自不正確的使用，所以我們必須為各個事業群提供更為易用的服務和更加統一的接口。所以我們后面在迅雷云引入了Docker。

問：能否談一下迅雷云使用Docker的過程？

其實最初的時候，迅雷團隊對Docker是懷有謹慎的態度的。不能因為別人說好我們就用，需要先試，真的好我們才敢用，嘗到甜頭我們才愿意用。一開始我們用Docker來加快團隊之間的協作效率，因為通過它部署的環境可以一次構建到處使用，所以開發、測試和部署都能夠在一個非常一致的環境中進行，這是很初級的用法。隨著對這個模式的認可，迅雷內部越來越多的團隊接納了我們的建議，于是迅雷、迅雷看看、迅雷游戲都采用了Docker，引入到了開發、測試和部署中。

后面我們的服務器項目基本就遷移到了Docker之上。當然，一開始大家對Docker的安全性都會有所顧慮，但其實大多數顧慮都是因為對Docker不夠理解而產生的。有了內部產品線的支持，我們后面把迅雷云部分服務器資源用Docker重新部署。迅雷云本身就是一個非常高效的集群系統，現在引入Docker是為了讓資源使用更加便捷。因為研發人員的流動性比較高，不是所有的開發者對迅雷云內部資源的使用都熟悉，所以我們現在就是借助Docker去為各個業務的開發提供一套更普適的接口。

問：迅雷云在容器方面做了哪些優化和調整？

一是整合現有的集群，將部分集群更改為Docker集群，特別是新增部分。二、由于迅雷云是一個重數據、輕業務的云，所以在數據管理方面，像Docker的Data volumes和Data volume containers這種簡單的方式還是不能夠滿足，所以我們主要還是以迅雷云自己的管理系統為主。為了能夠讓Docker之上的業務更好地使用我們的集群，我們添加了適配層。三、調度算法是迅雷云定制優化的。最后，我們有自建的私有倉庫，提供常用鏡像，讓我們的開發更加快速。

問：Adrian Cockcroft是云技術社區中的思想家之一，他將微服務與Docker的結合視為一種顛覆，認為這種開發方式會極大提高開發團隊敏捷性和適應性。請問迅雷云團隊是否有這方面的實踐？對于這方面的技術融合你有什么樣的建議？

微服務是把一個原本很復雜的服務解耦拆解為一些相對功能單一的服務，這在迅雷云內部是一直都非常提倡的。我們認為一個服務專心做好一件事是最好的，這對解耦、易用、升級都非常有好處。迅雷內部把Hub服務和Tracker服務都進行了分解和抽象，提供給各個項目組。Hub本身是很復雜的，但我們的服務接口卻是個位數，包括對CDN資源服務的使用方面我們也是重構了一套更加簡單易用的服務。

有一點很遺憾的是我覺得迅雷云里面做得最好的微服務并沒有使用到Docker，也就是我們的“水晶計劃”。這主要是因為我們的節點是各種客戶端設備，但我們的設計宗旨依然是遵循微服務的。水晶計劃的節點是各種各樣的設備，差異性非常大。但沒有關系，在用戶那里，它就是可靠的CDN。我個人覺得微服務加上Docker是非常合適的，因為微服務很重要的一點就是解耦，而采用容器技術來解耦隔離是非常恰當的。再進一步考慮到服務的擴容和遷移的話，微服務設計加上Docker作為載體也是非常合適的。我的建議就是，一個服務一個容器，或者說一種服務，一類容器，這樣一一對應地去部署。

問：Docker的image和安全問題一直都受到關注，特別在去年的出現的ShellShock和Heartbleed問題之后，請問在Docker的安全方面你是否有哪些經驗可以分享？

其實，越多人使用的技術越安全，但一旦不安全造成的損失也非常大。迅雷在使用Docker這方面一直沒有把數據層面交給迅雷云之外的系統。即便是Docker使用迅雷云的數據，也是通過我們的適配層，而通過適配層接進來的操作是要經過授權的，對使用能力也要進行限制，同時操作都是可跟蹤和統計的。另外就是對用戶的授權管理，嚴格規范的管理在安全方面很有必要。還有就是做好隔離工作，不僅僅是通過內核的Namespace/cgroup，同時也可以在不同層面隔離，比如VM和容器的隔離等。

問：在ClusterHQ最近的一項調查中顯示，只有38%的IT專業人士在生產環境中使用容器，人們對于容器技術使用的顧慮包括安全、數據管理、IT人員技能、永久存儲與可靠性等問題。你認為以Docker為代表的容器技術面臨的最大阻礙是什么？是否在不遠的未來有望跨越技術應用的鴻溝？

我覺得當前容器技術面臨的最大阻力是安全問題和管理工具。安全性一直是企業使用容器所擔心的問題，而另一個問題就是管理工具，特別是對集群的管理。現有的集群管理工具，比如Kubernetes，并不是很好上手，對于很多運維人員而言，特別是對一些小企業來說，運維人員可能并沒有深入地去學習這些工具怎么使用。所以如果這些工具的部署配置和使用能夠非常簡單，那么容器在實際生產中可能會越來越廣泛。

這種情況有些類似于ISO/OSI的參考模型和TCP/IP協議模型，前者從設計上而言是很優秀的，但后者卻成了事實標準，為什么？因為簡單。所以一門好技術，不但要技術本身好，而且要做到讓別人更好地接納也很重要。Docker相對于以前的諸如lxc的系統是一個進步，我希望Docker能繼續做好整個工具鏈，讓Docker集群更加平易近人。

問：Docker, CoreOS, 以及其他業界成員一起創立了“開放容器計劃（OCP)”，你認為OCP的成立對于軟件開發行業會造成什么影響？

Docker和CoreOS這對競爭對手握手言和，一起成立OCP，對于整個容器生態圈而言是一個非常重大的利好。因為OCP可以讓容器技術更加統一化，如果所有的容器都遵循一套標準，那么使用容器的開發者就省了很多麻煩。而且有了統一的標準，就意味著在不同平臺上的容器也可以相互遷移，Docker的鏡像可以遷移到CoreOS上，反之亦然。破除各自為陣，容器技術會變得更加易用，同時也會加快其在產業上的應用。

問：Docker和CoreOS各自都具有哪些優勢？它們的結合會帶來哪些好處？

Docker更想去做一個以容器為中心的服務平臺，所以它給用戶提供了很多便利的操作，還包括一些集群管理工具鏈。CoreOS則更加側重容器本身的標準化，CoreOS的開放標準更能夠促進容器的開放，這也是OCP的宗旨，此外，CoreOS在安全性和可組合性上也做得更好。它們的結合可以取二者優勢，彌補各自不足。

問：Docker最新發布的“Docker試驗性發布”是一次有趣的嘗試，請問你是否使用過上面的實驗性功能？你覺得這個系統的發布對于Docker來說有哪些好處？

如果你指的是out-of-process volume plugins，我有了解但沒有使用過。在對數據方面采用插件的形式，讓用戶自己去適配不同的存儲系統是非常有必要的，所以我覺得這個功能非常有用。我在上面也提到了，我們迅雷云就寫了一套適配層去操作我們自己的數據系統。所以后面我們團隊會去深入地理解這個功能，然后跟進。

問：學習Docker的進階過程有哪幾個階段？你希望程序員們以怎樣的方式使用《Docker開發實踐》這本書？

我覺得學習Docker有三個階段。第一個階段是對Docker本身功能的使用，也就是入門層，你要理解什么是鏡像、容器、Registry、Dockerfile等，了解這些對象的基本操作，能夠構建出自己的應用環境來。第二個階段是能夠駕馭Docker集群。這個階段你需要學習和使用Docker相關的工具，比如Kubernetes、Shipyard、Machine+Swarm+Compose等，根據不同的需求，需要使用不同的工具。第三個階段就是發現和解決這些工具里面的問題，為自己的場景深度定制。

我覺得程序員可以從兩個方面來使用好《Docker開發實踐》這本書，一方面可以把它當做開發手冊，因為這本書的內容幾乎涵蓋了Docker所有的知識點，我們對其內容進行了很系統地梳理。所以當你對Docker有什么疑問的時候，把《Docker開發實踐》放在電腦前面，隨手翻一翻基本就可以解決。另一方面，可以作為案例引導。這本書后面兩篇甄選了當前經典的應用場景，一步步帶領讀者把服務搭建起來，并且把可能遇到的問題都標出來，教讀者如何解決。所以，讀者也可以參照本書的案例去更好更快地在實際生產中使用Docker，提升效率、少走彎路。

問：《Docker開發實踐》的高級篇對Docker生態圈做了非常翔實的介紹和實踐，為什么要對Docker生態圈著墨如此之多？對于這部分內容的遴選你有什么樣的標準和原則？

Docker本身的操作其實很簡單，如果復雜的話，Docker就不會像今天這樣成功。然而我所知道的市面上之前所有關于Docker的書籍，都是把基礎操作寫了一大篇，然后堆砌一些案例，就成了一本書，我認為這是在浪費讀者的錢和時間。基礎的東西寫成幾章是合理的，寫成一本書就是打腫臉充胖子了。我們在《Docker開發實踐》中把這些內容進行了壓縮，不想去濫竽充數，也不會去浪費筆墨。

上面我提到的Docker面臨的阻礙很大一點就是它的工具鏈不完善和不易用。你會發現在網絡上程序員求助最多的也是Docker生態圈的實踐，因為Docker做得還不夠好，稍微不小心就犯錯。所以，既然基礎篇不該講那么多，而且生態圈又是使用Docker的開發者心中的痛點，那么我就著重筆墨去寫這部分，讓大家少走彎路。這部分內容看上去有些散，每一章都是講一個工具或者是一組工具，但是書中選的Kubernetes、Shipyard等都是我們最需要的和最熱點的工具，而且它們的構建又相對復雜。所以，我遴選的原則就是，重要又是難點的，我就選。所以這就成了《Docker開發實踐》中的高級篇。