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

成都創(chuàng)新互聯(lián)是一家專業(yè)從事網(wǎng)站制作、網(wǎng)站設(shè)計的網(wǎng)絡公司。作為專業(yè)網(wǎng)站建設(shè)公司,成都創(chuàng)新互聯(lián)依托的技術(shù)實力、以及多年的網(wǎng)站運營經(jīng)驗,為您提供專業(yè)的成都網(wǎng)站建設(shè)、網(wǎng)絡營銷推廣及網(wǎng)站設(shè)計開發(fā)服務！

Container的優(yōu)勢總結(jié)為以下四點:

• 提高計算密度

一個虛機占用的資源比一個Container占用的資源不止多十倍。在一個物理機上開一百個虛機是很困難的，但要實現(xiàn)100多個，甚至幾百個 Container是很正常的。騰訊在大量使用Container。某大型互聯(lián)網(wǎng)公司上次升級發(fā)行版，主要就是為了使用Cgroups，方便限定資源，以 充分利用CPU。要知道有能力維護自己版本內(nèi)核的公司，做出這樣的決定是非常不容易的，可見其好處是巨大的。

大互聯(lián)網(wǎng)公司非常適合Container，F(xiàn)acebook一臺虛機都沒有，因為這些互聯(lián)網(wǎng)公司要求充分利用計算資源。虛機起碼還要再跑一個Guest系統(tǒng)，太耗資源。

同時，在這些大公司內(nèi)部并沒有很多操作系統(tǒng)，集群只有一種操作系統(tǒng)，甚至連版本號都是固定的。因此，不需要虛機的異構(gòu)操作系統(tǒng)特性。

另外，在操作系統(tǒng)上還有Runtime Library，Container不需要重復加載，極大的節(jié)省內(nèi)存占用。

最后，因為公用的資源更多，Container相對來講更容易超售，實際出售量的和超過了物理機的量

• 更精細的資源控制

這里以目前最為熱門的Linux Container（ LXC）為例來說，Linux Container分為兩個部分，Cgroups用來做資源限制，Namespace來做資源隔離。最近Linux內(nèi)核對LXC相關(guān)改進非常多，其中3.8版對Namespace新增了user，未來的3.11會加入更好的 CRIU支持，使得Container看上去可能更像一個虛擬機。

另外Container在數(shù)據(jù)庫隔離方面也有著自身的優(yōu)勢。云化的數(shù)據(jù)庫通常有兩種思路：

第一，建立一個大數(shù)據(jù)庫供所有人使用。但如何做資源隔離和安全隔離呢？ SAE通過增加SQL過濾器 （CSDN近期將對SAE首席架構(gòu)師叢磊進行采訪，詳解SAE的資源隔離策略），將不合理的SQL全部過濾掉。盛大云的MongoDB服務也采用類似的策 略，通過判斷執(zhí)行時間來限定不合理的請求。但這種方法存在弊端，首先不能窮舉所有不合理的請求，這是一個典型的停機問題，即便是工程上實用的做法，維護巨 量的規(guī)則庫也會讓管理員痛不欲生，看看殺毒軟件要維護多少特征就知道了。其次需要修改數(shù)據(jù)庫代碼，而這些修改目前看不會被社區(qū)接受，因為社區(qū)認為資源隔離 并不是數(shù)據(jù)庫該做的事。

第二，把每個用戶的數(shù)據(jù)庫放一個Container里，用Container來做資源限制。不需要對數(shù)據(jù)庫進行修改。每個 用戶的Container內(nèi)有自己的數(shù)據(jù)庫，用戶之間的資源是完全隔離開的。不過有觀點認為每個Container啟動一個實例太浪費資源。其實，相同的 Runtime并不會重復占用資源，而且還能更好的限制資源，操作簡單。目前一些Heroku的第三方插件是用這種方式進行數(shù)據(jù)庫隔離的。 OpenShift通過Gear和Cartridges對資源進行隔離，每個應用有自己私有的小數(shù)據(jù)庫。

• 更短的provisioning時間

虛機的provisioning時間在分鐘級，而Container在秒級。設(shè)想在淘寶雙十一的場景下，虛機需要幾分鐘時間啟動顯然太慢了。另外 LXC目前還有個非常有趣的技術(shù)，叫做systemd，是下一代的啟動器，可以極大加快啟動速度，并且與LXC結(jié)合得十分完美，有些高級功能就是依賴 LXC實現(xiàn)的。

這部分還有另外一個非常重要的技術(shù)就是文件系統(tǒng)。提高provisioning時間，需要文件系統(tǒng)配合，像ploop、aufs、overlayfs等文件系統(tǒng)都有一些非常有趣的技術(shù)可以用在Container的快照、復制等方面。

• Container式的PaaS組裝更靈活

用戶根據(jù)自己的需要組裝自己的PaaS，我認為這是趨勢。不同的模塊之間有不同的實現(xiàn)，可以替換。比如你認為 Docker對LXC的封裝不好，就可以換一個。

Cloud Foundry也開始重視LXC，通過Warden把Container進行封裝，但是從技術(shù)的角度來講Cloud Foundry的架構(gòu)過于大，它想把PaaS所有事都做了，但每一塊做得都不怎么好，耦合度又高。比如我想把Warden換成Docker就很難。

Cloud Foundry為代表的PaaS平臺傾向做得很重，而像Docker是輕量的框架代表。我認為輕量的平臺更好，更有前途，因為更加靈活。PaaS到底該長成什么樣去年我還覺得比較清楚，但今年反而覺得變數(shù)會非常多，所以我更看好靈活的方案。

Docker項目在Github上發(fā)布不到兩天，就在Go語言排行榜上排名第一，說明社區(qū)很認可。額外說一句Go語言寫的PaaS工具非常多，有大放異彩的趨勢。而Cloud Foundry幾乎都是仰仗VMware財大氣粗。大家共同參與，項目才有生命力。Cloud Foundry的社區(qū)貢獻度非常差，大部分都是VMware（Pivotal）自己的工程師貢獻。

Container的趨勢和挑戰(zhàn)

和虛機相比，LXC的隔離做個并不徹底，而包括熱遷移的等高級功能也正在完善中。程顯峰將LXC的發(fā)展趨勢和挑戰(zhàn)總結(jié)為以下四點：

• Container獲得了更廣泛的支持

OpenStack對LXC現(xiàn)在有很強的支持。當OpenStack支持Container了，這會導致該技術(shù)在互聯(lián)網(wǎng)圈子里得到推廣。同時，在OpenStack+LXC基礎(chǔ)上還會有些創(chuàng)新。

另外， ActiveState Software早就把Cloud Foundry和LXC綁到一起，推出了商業(yè)版。

這一陣子比較火的 CoreOS、 dotCloud、 PiCloud等公司都是LXC的堅定支持者，systemd的作者以及 OpenVZ的開發(fā)團隊都齊心協(xié)力支持LXC。

vps就是Container典型的應用場景，基本上全球市場上90%的VPS平臺都使用OpenVZ。它是一種Container，但是因為對Container的修改過大，不被社區(qū)接受。但OpenVZ的商業(yè)版本比Linux Container成熟得多，可以支持熱遷移。OpenVZ的作者為Linux  Container提交了百十多個patch。已經(jīng)有很多社區(qū)的活躍者對Linux  Container做貢獻。

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

資源限定和隔離做得并不徹底，比如時間就隔離不了?，F(xiàn)在LXC隔離也就幾個方面，進程、掛載資源、用戶，大概也就六點，實際上還遠遠不夠。

虛機熱遷移技術(shù)已經(jīng)非常成熟，而LXC還有差距，也在改進中。據(jù)報道，在Linux kernel 3.11中會有很大改善。

• 調(diào)試工具逐步完善

云計算調(diào)試是個非常頭疼的事情，如果應用跑在虛機里，管理員是很難進行管理的。而Container對操作系統(tǒng)有一些透明性，如process有異常調(diào)用，管理員可以看到。

大家為什么不用云計算？大部分人都說部署習慣不一樣，調(diào)試部署不方便，大家為什么還愿意用虛擬機？虛擬機的調(diào)試方式跟他在實體機上調(diào)試方式?jīng)]有任何差異，這種習慣是很難改變的。

Cloud Foundry、SAE、Azure的調(diào)試都解決的不徹底。僅僅通過本地模擬器進行調(diào)試，并不能解決根本問題。

調(diào)試工具近期也會有一些新的突破，語言級別的像Ruby2.0以后加了對DTrace支持。我很看好Dtrace和SystemTap之類的技術(shù)的，尤其是在PaaS調(diào)試上，大家可以關(guān)注一下 章亦春、 余鋒的博客。

PaaS服務依然不夠完善

盡管各種PaaS層出不窮，Cloud Foundry、OpenShift、Azure也在不遺余力的打造更易用的PaaS平臺，但仍存在各種不足和挑戰(zhàn)。無論自建還是使用第三方平臺，PaaS還遠未成熟。程顯峰認為：

• PaaS平臺沒有統(tǒng)一的認識

PaaS到底應該搭成什么樣？什么樣是成熟的PaaS？現(xiàn)在都沒有統(tǒng)一的認識。微軟Azure、Heroku以及Cloud Foundry，各家PaaS的邊界和內(nèi)容都不一樣。

微軟Azure有彈性的數(shù)據(jù)庫、 Service Bus。 亞馬遜也有類似的服務。這些服務到底屬于IaaS還是PaaS呢？用戶需要的是非常完整的服務，無論對于IaaS還是PaaS都有大量的工作需要去做。所 以，現(xiàn)在看PaaS，要想在一個體系下提供服務，我認為是很難的。而Docker這種靈活的方案，只做某一塊服務，再組裝在一起可能是更好的方式。

從上面說的我們也可以看出，現(xiàn)在的云計算模型已經(jīng)遠遠不是三層的IaaS、PaaS、SaaS那么簡單的了。很多組件都能作為一個服務呢，這些組件 應該放在什么位置呢？實際上這個關(guān)系非常復雜，各家都有各家的看法，這些看法隨著時間改動也還是很大。我的一個觀點是從單個技術(shù)上突破做成大家都認可的組 件比較容易，總體結(jié)構(gòu)要想達成一致比較難。

• 國內(nèi)沒有完善的公有云 自建IaaS也很麻煩

PaaS要底層基礎(chǔ)資源必須彈性，如果采取自建私有云的方式，很可能需要去搭建OpenStack，工作量非常大。如果植根于公有云，國內(nèi)沒有美國 那樣成熟的亞馬遜、Azure或Rackspace，阿里云的API還不夠健全，無法支撐。在國內(nèi)如果底層資源彈性問題無法解決，PaaS就是空中樓閣。

標準和互操作也是比較頭痛的問題。國內(nèi)互聯(lián)網(wǎng)公司相互合作不夠，對于標準和規(guī)范重視程度也遠遠不夠。有人說云就是水電，但問題是水電是高度同質(zhì)的，目前還沒看到哪些云是同質(zhì)的。國外還有些公司做跨平臺云的管理，國內(nèi)就更難了，這也是做一個公有PaaS的潛在風險。

當然，國內(nèi)的網(wǎng)絡割裂比較嚴重也是對云計算發(fā)展的不利影響。這些都本不該是一個PaaS提供商該考慮的問題，但是我們的國情就要求必須要考慮。

• 需要堅實的服務支持

PaaS還需要其他服務支撐，比如Cache、負載均衡、數(shù)據(jù)庫、消息隊列、日志，這些服務只有全部包含PaaS平臺才有價值。當開發(fā)者在PaaS上運行了應用，如果還要自己搭建這些服務，然后做HA，這就背離了PaaS的設(shè)計初衷。因為，實際上應用并不是運維的重點，重點上面提到的那些周邊的服務，這些服務的運維成本很高，而且還不體現(xiàn)開發(fā)者的核心價值。

京東做得更好。由于Cloud Foundry的服務并不是云化的，不提供HA。京東需要做云化，自己做了上面所說的基礎(chǔ)服務。

展望Cloud Foundry、OpenShift、Azure

Cloud Foundry今年將推出商業(yè)版，Azure越來越重視開源社區(qū)，變的更加開放， OpenShift繼續(xù)著云化戰(zhàn)略。在采訪結(jié)束前，程顯峰進行了總結(jié)：

京東云底層使用了OpenStack + Cloud Foundry，從長遠上看仍然會走互聯(lián)網(wǎng)式的技術(shù)路線。也許再晚一個月做決策，京東就會選擇OpenShift了，因為從技術(shù)角度來講，OpenShift比Cloud Foundry要好一點。

OpenShift代碼寫的還算規(guī)矩，而Cloud Foundry的代碼并不是社區(qū)的產(chǎn)物，很多地方都不像大公司的作品。我認為但凡是脫離社區(qū)單搞一套，從歷史上看絕大多數(shù)都沒好結(jié)果。

從我看的一些報告來看，VMware在虛擬化技術(shù)上的領(lǐng)先優(yōu)勢已經(jīng)不明顯。微軟的平臺與VMware看不出明顯的差距。畢竟微軟有操作系統(tǒng)和大量商 用軟件，這些技術(shù)積累是其他公司很難擁有的。同時微軟有自己的商用的公有云Azure，對新技術(shù)是很好的試驗場，VMware還沒運營自己的公有云。

“Container的優(yōu)勢有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！