Container的新機遇：Docker

從技術上看，Container並不是近幾年的創新，OpenVZ、FreeBSD jails、Solaris Zones等都是Container技術（輕量級虛擬化技術，OS層虛擬化技術）的 實現，而Fedora和Mozilla中國的區表明 Gerard Braad在接受CSDN採訪時進一步擴展了Container的概念：

瀏覽器的沙箱從資源隔離的角度，以及Java的J2EE Container從標準抽象化的角度，其實跟Container的概念是一致的。

當下，PaaS愈來愈多的和Container聯繫在一塊兒，Container的高資源利用率等特性偏偏是PaaS須要的。

Container的優點總結爲如下四點:

• 提升計算密度
  

一個虛機佔用的資源比一個Container佔用的資源不止多十倍。在一個物理機上開一百個虛機是很困難的，但要實現100多個，甚至幾百個 Container是很正常的。騰訊在大量使用Container。某大型互聯網公司上次升級發行版，主要就是爲了使用Cgroups，方便限定資源，以 充分利用CPU。要知道有能力維護本身版本內核的公司，作出這樣的決定是很是不容易的，可見其好處是巨大的。

大互聯網公司很是適合Container，Facebook一臺虛機都沒有，由於這些互聯網公司要求充分利用計算資源。虛機起碼還要再跑一個Guest系統，太耗資源。

同時，在這些大公司內部並無不少操做系統，集羣只有一種操做系統，甚至連版本號都是固定的。所以，不須要虛機的異構操做系統特性。

另外，在操做系統上還有Runtime Library，Container不須要重複加載，極大的節省內存佔用。

最後，由於公用的資源更多，Container相對來說更容易超售，實際出售量的和超過了物理機的量

• 更精細的資源控制

這裏以目前最爲熱門的Linux Container（ LXC）爲例來講，Linux Container分爲兩個部分，Cgroups用來作資源限制，Namespace來作資源隔離。最近Linux內核對LXC相關改進很是多，其中3.8版對Namespace新增了user，將來的3.11會加入更好的 CRIU支持，使得Container看上去可能更像一個虛擬機。

另外Container在數據庫隔離方面也有着自身的優點。雲化的數據庫一般有兩種思路：

第一，創建一個大數據庫供全部人使用。但如何作資源隔離和安全隔離呢？ SAE經過增長SQL過濾器 （CSDN近期將對SAE首席架構師叢磊進行採訪，詳解SAE的資源隔離策略），將不合理的SQL所有過濾掉。盛大雲的MongoDB服務也採用相似的策 略，經過判斷執行時間來限定不合理的請求。但這種方法存在弊端，首先不能窮舉全部不合理的請求，這是一個典型的停機問題，即使是工程上實用的作法，維護巨 量的規則庫也會讓管理員痛不欲生，看看殺毒軟件要維護多少特徵就知道了。其次須要修改數據庫代碼，而這些修改目前看不會被社區接受，由於社區認爲資源隔離 並非數據庫該作的事。

第二，把每一個用戶的數據庫放一個Container裏，用Container來作資源限制。不須要對數據庫進行修改。每一個 用戶的Container內有本身的數據庫，用戶之間的資源是徹底隔離開的。不過有觀點認爲每一個Container啓動一個實例太浪費資源。其實，相同的 Runtime並不會重複佔用資源，並且還能更好的限制資源，操做簡單。目前一些Heroku的第三方插件是用這種方式進行數據庫隔離的。 OpenShift經過Gear和Cartridges對資源進行隔離，每一個應用有本身私有的小數據庫。

• 更短的provisioning時間

虛機的provisioning時間在分鐘級，而Container在秒級。設想在淘寶雙十一的場景下，虛機須要幾分鐘時間啓動顯然太慢了。另外 LXC目前還有個很是有趣的技術，叫作systemd，是下一代的啓動器，能夠極大加快啓動速度，而且與LXC結合得十分完美，有些高級功能就是依賴 LXC實現的。

這部分還有另一個很是重要的技術就是文件系統。提升provisioning時間，須要文件系統配合，像ploop、aufs、overlayfs等文件系統都有一些很是有趣的技術能夠用在Container的快照、複製等方面。

• Container式的PaaS組裝更靈活

用戶根據本身的須要組裝本身的PaaS，我認爲這是趨勢。不一樣的模塊之間有不一樣的實現，能夠替換。好比你認爲 Docker對LXC的封裝很差，就能夠換一個。

Cloud Foundry也開始重視LXC，經過Warden把Container進行封裝，可是從技術的角度來說Cloud Foundry的架構過於大，它想把PaaS全部事都作了，但每一塊作得都不怎麼好，耦合度又高。好比我想把Warden換成Docker就很難。

Cloud Foundry爲表明的PaaS平臺傾向作得很重，而像Docker是輕量的框架表明。我認爲輕量的平臺更好，更有前途，由於更加靈活。PaaS到底該長成什麼樣去年我還以爲比較清楚，但今年反而以爲變數會很是多，因此我更看好靈活的方案。

Docker項目在Github上發佈不到兩天，就在Go語言排行榜上排名第一，說明社區很承認。額外說一句Go語言寫的PaaS工具很是多，有大放異彩的趨勢。而Cloud Foundry幾乎都是仰仗VMware財大氣粗。你們共同參與，項目纔有生命力。Cloud Foundry的社區貢獻度很是差，大部分都是VMware（Pivotal）本身的工程師貢獻。

Container的趨勢和挑戰

和虛機相比，LXC的隔離作個並不完全，而包括熱遷移的等高級功能也正在完善中。程顯峯將LXC的發展趨勢和挑戰總結爲如下四點：

• Container得到了更普遍的支持

OpenStack對LXC如今有很強的支持。當OpenStack支持Container了，這會致使該技術在互聯網圈子裏獲得推廣。同時，在OpenStack+LXC基礎上還會有些創新。

另外， ActiveState Software早就把Cloud Foundry和LXC綁到一塊兒，推出了商業版。

這一陣子比較火的 CoreOS、 dotCloud、 PiCloud等公司都是LXC的堅決支持者，systemd的做者以及 OpenVZ的開發團隊都齊心合力支持LXC。

VPS就是Container典型的應用場景，基本上全球市場上90%的VPS平臺都使用OpenVZ。它是一種Container，可是由於對Container的修改過大，不被社區接受。但OpenVZ的商業版本比Linux Container成熟得多，能夠支持熱遷移。OpenVZ的做者爲Linux  Container提交了百十多個patch。已經有不少社區的活躍者對Linux  Container作貢獻。

• LXC在有些方面與虛機有差距

資源限定和隔離作得並不完全，好比時間就隔離不了。如今LXC隔離也就幾個方面，進程、掛載資源、用戶，大概也就六點，實際上還遠遠不夠。

虛機熱遷移技術已經很是成熟，而LXC還有差距，也在改進中。據報道，在Linux kernel 3.11中會有很大改善。

• 調試工具逐步完善

雲計算調試是個很是頭疼的事情，若是應用跑在虛機裏，管理員是很難進行管理的。而Container對操做系統有一些透明性，如process有異常調用，管理員能夠看到。

你們爲何不用雲計算？大部分人都說部署習慣不同，調試部署不方便，你們爲何還願意用虛擬機？虛擬機的調試方式跟他在實體機上調試方式沒有任何差別，這種習慣是很難改變的。

Cloud Foundry、SAE、Azure的調試都解決的不完全。僅僅經過本地模擬器進行調試，並不能解決根本問題。

調試工具近期也會有一些新的突破，語言級別的像Ruby2.0之後加了對DTrace支持。我很看好Dtrace和SystemTap之類的技術的，尤爲是在PaaS調試上，你們能夠關注一下 章亦春、 餘鋒的博客。

PaaS服務依然不夠完善

儘管各類PaaS層出不窮，Cloud Foundry、OpenShift、Azure也在竭盡全力的打造更易用的PaaS平臺，但仍存在各類不足和挑戰。不管自建仍是使用第三方平臺，PaaS還遠未成熟。程顯峯認爲：

• PaaS平臺沒有統一的認識

PaaS到底應該搭成什麼樣？什麼樣是成熟的PaaS？如今都沒有統一的認識。微軟Azure、Heroku以及Cloud Foundry，各家PaaS的邊界和內容都不同。

微軟Azure有彈性的數據庫、 Service Bus。 亞馬遜也有相似的服務。這些服務到底屬於IaaS仍是PaaS呢？用戶須要的是很是完整的服務，不管對於IaaS仍是PaaS都有大量的工做須要去作。所 以，如今看PaaS，要想在一個體系下提供服務，我認爲是很難的。而Docker這種靈活的方案，只作某一塊服務，再組裝在一塊兒多是更好的方式。

從上面說的咱們也能夠看出，如今的雲計算模型已經遠遠不是三層的IaaS、PaaS、SaaS那麼簡單的了。不少組件都能做爲一個服務呢，這些組件 應該放在什麼位置呢？實際上這個關係很是複雜，各家都有各家的見解，這些見解隨着時間改動也仍是很大。個人一個觀點是從單個技術上突破作成你們都承認的組 件比較容易，整體結構要想達成一致比較難。

• 國內沒有完善的公有云 自建IaaS也很麻煩

PaaS要底層基礎資源必須彈性，若是採起自建私有云的方式，極可能須要去搭建OpenStack，工做量很是大。若是植根於公有云，國內沒有美國 那樣成熟的亞馬遜、Azure或Rackspace，阿里雲的API還不夠健全，沒法支撐。在國內若是底層資源彈性問題沒法解決，PaaS就是空中樓閣。

標準和互操做也是比較頭痛的問題。國內互聯網公司相互合做不夠，對於標準和規範重視程度也遠遠不夠。有人說雲就是水電，但問題是水電是高度同質的，目前還沒看到哪些雲是同質的。國外還有些公司作跨平臺雲的管理，國內就更難了，這也是作一個公有PaaS的潛在風險。

固然，國內的網絡割裂比較嚴重也是對雲計算髮展的不利影響。這些都本不應是一個PaaS提供商該考慮的問題，可是咱們的國情就要求必需要考慮。

• 須要堅實的服務支持

PaaS還須要其餘服務支撐，好比Cache、負載均衡、數據庫、消息隊列、日誌，這些服務只有所有包含PaaS平臺纔有價值。當開發者在PaaS上運行了應用，若是還要本身搭建這些服務，而後作HA，這就背離了PaaS的設計初衷。由於，實際上應用並非運維的重點，重點上面提到的那些周邊的服務，這些服務的運維成本很高，並且還不體現開發者的核心價值。

京東作得更好。因爲Cloud Foundry的服務並非雲化的，不提供HA。京東須要作雲化，本身作了上面所說的基礎服務。

展望Cloud Foundry、OpenShift、Azure

Cloud Foundry今年將推出商業版，Azure愈來愈重視開源社區，變的更加開放， OpenShift繼續着雲化戰略。在採訪結束前，程顯峯進行了總結：

京東雲底層使用了OpenStack + Cloud Foundry，從長遠上看仍然會走互聯網式的技術路線。也許再晚一個月作決策，京東就會選擇OpenShift了，由於從技術角度來說，OpenShift比Cloud Foundry要好一點。

OpenShift代碼寫的還算規矩，而Cloud Foundry的代碼並非社區的產物，不少地方都不像大公司的做品。我認爲但凡是脫離社區單搞一套，從歷史上看絕大多數都沒好結果。

從我看的一些報告來看，VMware在虛擬化技術上的領先優點已經不明顯。微軟的平臺與VMware看不出明顯的差距。畢竟微軟有操做系統和大量商 用軟件，這些技術積累是其餘公司很難擁有的。同時微軟有本身的商用的公有云Azure，對新技術是很好的試驗場，VMware還沒運營本身的公有云。

微軟如今特別擁抱社區。Azure的命令行客戶端已經沒啥微軟的味道了。微軟想明白了，用不用微軟技術無所謂，爲微軟的雲付費就能夠了。官方支持不少開發語言。微軟還單獨 成立了開放技術公司 Microsoft Open Technologies，專門配合社區，這其實是一個很是大的事業部。