摘要：所以，無論是容器還是虛擬機，都可以實現(xiàn)彈性伸縮，其核心就是要注意狀態(tài)和數(shù)據(jù)的分離和共享問題。通常來說，穩(wěn)態(tài)的應(yīng)用適合虛擬機，敏態(tài)的應(yīng)用容器更勝一籌，但也不完全都是這樣。

筆者案

前陣子與行業(yè)內(nèi)的朋友聊到企業(yè)云的建設(shè)路線選擇事宜，在涉及到虛擬化和容器技術(shù)的選擇議題上討論的比較多，基于當(dāng)前容器技術(shù)在某些場景中有替代虛擬化的趨勢，市場上也聽到一些聲稱容器可能會完全取代虛擬化的聲音。我個人也在思考，這兩種技術(shù)然道是完全對立的嗎？容器真的會完全取代虛擬化技術(shù)嗎？這里，我從一些基本的技術(shù)細節(jié)來洞察兩者的差異性，并從應(yīng)用場景的角度來分析企業(yè)該如何對這兩種技術(shù)做出合理的選擇決策。

常見 誤區(qū) ?

虛擬機資源占用高、啟動速度慢、難以實現(xiàn)彈性伸縮

資源占用

實質(zhì)上，這要從操作系統(tǒng)和應(yīng)用兩個層面去分析：

每個虛擬機是獨立的操作系統(tǒng)，而容器則是多個容器共享一個操作系統(tǒng)，因此，虛擬機比容器實際上是多的是操作系統(tǒng)層的消耗，但這帶來了容器所沒有的高度隔離性。

比如在容器應(yīng)用場景中，出于安全考慮，是不建議以root權(quán)限在容器中運行應(yīng)用的，但隨之而來就會導(dǎo)致已有應(yīng)用的兼容性問題，而虛擬機卻沒有這個限制，無論在資源的隔離性和安全性方面都很好，所以，資源的消耗所帶來的影響是相對的；

而應(yīng)用程序的消耗呢？實際上這取決于應(yīng)用本身，虛擬化本身并不會給應(yīng)用帶來太多的性能損耗，而容器技術(shù)本身也沒有說能夠讓一個應(yīng)用的資源消耗變少。

速度問題，分開來講則包括啟動速度和運行速度，容器啟動速度快？

有一種說法是說容器能夠秒級啟動，我認為如果實踐一下，你就會發(fā)現(xiàn)這秒級啟動遠比我們想象的時間要長，比如說，如果你是在一個沒有運行過某個容器應(yīng)用的節(jié)點上第一次運行它的話，那么很顯然，數(shù)秒甚至數(shù)分鐘的鏡像下載過程是少不了的，這個時間可是取決于鏡像的大小和網(wǎng)絡(luò)的速度。

當(dāng)鏡像下載完，容器啟動的時候，有心看看容器啟動日志就知道，容器確實秒級啟動，而里面的應(yīng)用程序呢？

所以，這就是為什么Kubernetes提供了Liveness 和Readiness等健康檢查探針的原因，容器秒級啟動，應(yīng)用程序卻不是秒級啟動的。

那虛擬機是否可以做到秒級啟動？

當(dāng)然，經(jīng)過優(yōu)化后的IaaS云平臺架構(gòu)，每個節(jié)點將無需重復(fù)下載虛擬機鏡像，甚至可以直接從分布式存儲卷上調(diào)用模板鏡像快速啟動新的虛擬機，這可比容器要快多了。

這就類似于kubernets節(jié)點在某個docker鏡像經(jīng)過第一次啟動后本地緩存了該容器鏡像一樣，第二次就飛快啟動的效果，只不過，虛擬機還需要經(jīng)歷一個操作系統(tǒng)啟動的過程，但如果對操作系統(tǒng)進行適當(dāng)?shù)膬?yōu)化，其實也可以縮短到十幾秒，如果效仿容器只運行一個應(yīng)用的話，那其實啟動速度差不太多；那運行速度呢？其實就相同的應(yīng)用來說，其實是差不多的，容器并沒有在應(yīng)用上對已有應(yīng)用進行改造，其運行速度還是取決于應(yīng)用本身和底層硬件效能的。

難以彈性伸縮？

未必，包括AWS、Openstack都提供了autoscaling功能，虛擬機實際上早已經(jīng)有彈性伸縮功能。只不過在虛擬化環(huán)境中，開發(fā)和運維人員要特別注意彈性應(yīng)用所需的分布式架構(gòu)和無狀態(tài)化的考量，而這兩點在容器的屬性上是默認的。也就是虛擬化架構(gòu)并沒有告訴開發(fā)和運維人員需要將狀態(tài)數(shù)據(jù)從虛擬機中拿出去，而容器的層次化存儲模型則時刻提醒著開發(fā)人員將數(shù)據(jù)和有狀態(tài)的配置放置在容器之外；而無狀態(tài)化或輕量化往往又是彈性伸縮所必須考慮的重要因素之一。

所以，無論是容器還是虛擬機，都可以實現(xiàn)彈性伸縮，其核心就是要注意狀態(tài)和數(shù)據(jù)的分離和共享問題。

虛擬化未來會消失、會被容器完全顛覆和取代嗎？

這個問題也是具有片面性的。至少從目前來看，并非所有應(yīng)用都適合在容器中運行，除此之外，虛擬化經(jīng)過多年的發(fā)展，已經(jīng)形成了完整的軟件定義的云數(shù)據(jù)中心架構(gòu)（通常稱為IaaS）和眾多相關(guān)的生態(tài)技術(shù)。無論是公有云還是私有云都是由虛擬化及相關(guān)技術(shù)生態(tài)逐步發(fā)展而來，包括軟件定義計算（虛擬機）、軟件定義存儲（分布式存儲，包括分布式的塊存儲和對象存儲技術(shù)），以及軟件定義網(wǎng)絡(luò)（比如SDN、vFW、ELB等）。在現(xiàn)有的IaaS平臺中無一不是成熟的解決方案，然道容器平臺都不需要這些技術(shù)就能支持所有業(yè)務(wù)應(yīng)用了？實際我們看到的情況是，獨立的容器云平臺往往可能要再造一遍輪子！

實際上，容器與虛擬機同屬于計算形態(tài)，其之間的關(guān)系可以是從屬關(guān)系（容器運行在虛擬機中），也可以是并列關(guān)系（如云平臺提供物理機直接運行容器），兩者所需的計算、存儲、網(wǎng)絡(luò)等技術(shù)完全可以通過已有的IaaS平臺實現(xiàn)復(fù)用和共享，而不是對立或取代。而且，企業(yè)要兼容不同的應(yīng)用形態(tài)，業(yè)務(wù)需要異構(gòu)和共存、相輔相成，以滿足企業(yè)不同階段、不同層次的業(yè)務(wù)要求。

如何 選擇 ?

那我們?nèi)绾芜x擇和應(yīng)用這兩種技術(shù)呢？在實際的實踐當(dāng)中，業(yè)務(wù)場景的需求，才是企業(yè)對不同技術(shù)選擇的優(yōu)先考量。

通常來說，穩(wěn)態(tài)的應(yīng)用適合虛擬機，敏態(tài)的應(yīng)用容器更勝一籌，但也不完全都是這樣。

為什么呢？

并非所有應(yīng)用都適合用容器

比如傳統(tǒng)的關(guān)系型數(shù)據(jù)庫應(yīng)用，則不是像容器場景中宣稱的那樣隨時都可以隨便重啟的，而且，數(shù)據(jù)庫的高可用也不是像Kubernetes那樣掛一個服務(wù)發(fā)現(xiàn)就能解決的，而是應(yīng)當(dāng)使用數(shù)據(jù)庫本身的高可用架構(gòu)來實現(xiàn)以確保數(shù)據(jù)的可靠性和一致性！

場景化需求才是兩種技術(shù)選擇的關(guān)鍵

之前我們也說過，容器更適合于無狀態(tài)化的應(yīng)用，當(dāng)然，輕量狀態(tài)或者業(yè)務(wù)本身有一致性保證的邏輯存在的業(yè)務(wù)應(yīng)用也是適合的，因為容器也有數(shù)據(jù)持久化技術(shù)（如kubernetes的StatefulSet 、PV等）。當(dāng)然，如果一個應(yīng)用本身啟動速度和資源消耗與虛擬機無異的話（如傳統(tǒng)的單體應(yīng)用），那其實在生產(chǎn)上改造成容器的收效也不大，但在開發(fā)測試環(huán)境當(dāng)中，卻能一定程度上提高資源利用和提高重復(fù)測試的效率，所以還是要看應(yīng)用場景來取用不同技術(shù)的，穩(wěn)態(tài)和敏態(tài)的選擇也并非絕對。

應(yīng)用架構(gòu)和選擇趨勢

從企業(yè)業(yè)務(wù)角度出發(fā)，業(yè)務(wù)應(yīng)用已經(jīng)逐步成為企業(yè)的關(guān)鍵競爭力，比如制造業(yè)的車聯(lián)網(wǎng)、金融業(yè)的能力開放平臺等，按照Gartner的預(yù)測，到2020年，企業(yè)75％的應(yīng)用將是由企業(yè)自己開發(fā)而非購買，這意味著什么呢？

可以說，未來的所有企業(yè)，無論哪個行業(yè)，軟件都將成為企業(yè)的核心競爭力之一，客戶的需求從線下逐步轉(zhuǎn)移到線上，由人與人的交互，逐步向人機交互甚至是設(shè)備間的自動化交互，因此，軟件將成為其中最為關(guān)鍵的因素。

針對這樣的趨勢，企業(yè)提出了如下需求：

如何提高軟件的迭代效率以加快產(chǎn)品推出速度，要求搶在競爭對手之前發(fā)布、或者縮短與競爭對手的發(fā)布時間；

快速上線后，還能根據(jù)客戶的需求不斷調(diào)整，要求平臺的迭代速度可以按天計量，而不是過去的數(shù)個月甚至是半年一年才發(fā)布一次；

新業(yè)務(wù)可以隨時擴展，隨時給客戶帶來驚喜的同時不會影響到已有業(yè)務(wù)的穩(wěn)定運行。

綜上所述，其實這些需求已經(jīng)超出了我們今天虛擬化和容器之間的話題，但從本質(zhì)上看，又有所關(guān)聯(lián)。

為什么呢？

微服務(wù)的提出首先在互聯(lián)網(wǎng)公司對上述幾個需求得到了驗證，但同時，缺乏敏捷架構(gòu)的支持帶來的則是人肉運維的低效制約著微服務(wù)架構(gòu)潛力與效能的發(fā)揮。

微服務(wù)雖然帶來了業(yè)務(wù)的擴展性，但架構(gòu)復(fù)雜程度也是驟然上升，這也是為什么傳統(tǒng)業(yè)務(wù)如果沒有業(yè)務(wù)壓力并無需立即對傳統(tǒng)業(yè)務(wù)進行微服務(wù)改造的原因；而面對微服務(wù)帶來的復(fù)雜性挑戰(zhàn)，模塊的標準化、開發(fā)運維組織架構(gòu)的調(diào)整則是必然的趨勢，也就是說技術(shù)上要標準化，組織上要流程化：

技術(shù)標準化：IaaS提供統(tǒng)一標準化的基礎(chǔ)資源構(gòu)建，包括基礎(chǔ)資源計算（虛擬機和容器）、存儲、網(wǎng)絡(luò)，穩(wěn)態(tài)業(yè)務(wù)單元應(yīng)用，如數(shù)據(jù)庫，以及敏態(tài)業(yè)務(wù)單元如中間件、消息緩存等

組織流程化：也就是通常我們可能經(jīng)常聽到的DevOps，包括技術(shù)和組織兩個層面：

技術(shù)方面包括主要體現(xiàn)在技術(shù)工具上，這部分的趨勢是將各環(huán)節(jié)所涉及的工具鏈進行集成、鏈接，根據(jù)工作流程實現(xiàn)流水線式的作業(yè)模式，當(dāng)然，業(yè)內(nèi)也有很多廠商在將這些接口、流程進行聚合形成標準化的產(chǎn)品，幫助企業(yè)快速構(gòu)建起工具鏈流水線。

組織方面則需要打通部門墻，融通開發(fā)、測試、運維，實現(xiàn)開發(fā)運維一體化的軟件開發(fā)生產(chǎn)的企業(yè)組織體系，這就需要企業(yè)高層，特別是正在建設(shè)自有軟件團隊的企業(yè)CIO們要考量和規(guī)劃的：包括部門組織的調(diào)整、軟件生產(chǎn)文化的建設(shè)等，不單純是技術(shù)的問題。

總結(jié)

總結(jié)下來，虛擬機和容器技術(shù)本身并不對立，也不存在誰取代誰的問題，關(guān)鍵是企業(yè)是否合理運用技術(shù)在合理的應(yīng)用場景當(dāng)中解決相應(yīng)的技術(shù)問題，未來的企業(yè)級云平臺也應(yīng)該囊括對這些技術(shù)的支持，以滿足企業(yè)對不同業(yè)務(wù)所需不同技術(shù)棧的靈活選擇！

文｜啟迪云計算解決方案顧問 林文煒