共計 4721 個字符，預計需要花費 12 分鐘才能閱讀完成。

本篇內容介紹了“Container 的優勢有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓丸趣 TV 小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

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 還沒運營自己的公有云。

“Container 的優勢有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注丸趣 TV 網站，丸趣 TV 小編將為大家輸出更多高質量的實用文章！