Container的優勢有哪些

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

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的優勢有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！