虛擬機已死 容器才是未來？

　　虛擬機 vs 容器

　　也許有人會說 docker pull/push 多方便啊，docker build 多方便啊，可不要忘了，vm image storage 早在 openstack 里就解決了，自己處理也不是個大事，vm image build 也有 Hashicorp 的 Packer 工具代勞，不是個事。Docker 自豪的官方 docker registry 其實大家最多用用 base os image，那些 app 級別的出于信任以及定制考慮都會自己 build。而 Docker 自豪的 layered storage 也是無數(shù)血淚，aufs & overlayfs 坑了多少人?容器社區(qū)最近還特崇拜 immutable deployment，以把容器根文件系統(tǒng)弄做只讀的為榮，全然不管有緊急安全更新或者功能修正怎么處理——什么，你要說 docker rm && docker run 再起一批不就完事么?真有這么簡單就好了。

　　像 Linux kernel 和 git 那種才是正經(jīng) unix 設(shè)計的思想，分層堆疊，底層提供mechanism，高層提供 policy，各取所需，可惜人總是易于被洗腦，在接受各種高大上policy的時候全然忘了mechanism還在不在自己手里。

　　回合二：正確性之爭

　　強隔離、full OS 體驗、保留 mechanism，這才是正道。另外容器還隱藏了一個坑，/proc/cpuinfo和free命令輸出是host os的，這坑了無數(shù)探測系統(tǒng)資源自動決定默認(rèn)線程池和內(nèi)存池大小的程序，尤以Java最為普遍。

　　回合三：性能之爭

　　容器粉絲津津樂道——啟動容器快，容器的開銷少。這兩點確實如此但好處真的有那么巨大么?誰有事沒事不停創(chuàng)建虛擬機?誰的虛擬機生命周期平均在分鐘級別?誰的“用完全啟動時間”平均在秒級? 至于說到虛擬機浪費的資源太多，其實也就是個障眼法。理論上服務(wù)器的資源利用率平均不應(yīng)該超過 80%而實際上絕大部分公司的服務(wù)器資源利用率應(yīng)該都不到 50%，大量的CPU、內(nèi)存、本地磁盤都是常年浪費的，所以 VM 的額外開銷不過是浪費了原本就在浪費的資源罷了。就單機的巔峰 I/O 能力來言，VM 確實不敵容器。但平時根本就用不到巔峰狀態(tài)， 原本一個 VM 里多進程干的事，非得搞多個容器跑，這容器開銷，這人力開銷怎么算?

　　關(guān)于容器還有一個幻想，那就是可以在物理機上直接跑容器，開銷巨低、管理巨方便，用專用物理機方式提供多租戶強隔離。前面兩點上面已經(jīng)駁過了，話說 還有人用 openstack 管理 docker 容器呢。 我只是說一下第三點，在一臺物理機上直接跑容器的一個最容易被忽視的問題：現(xiàn)在用來提供云服務(wù)的物理機一般都是硬件超級牛逼，跑上百個容器都沒問題，但問題在于用戶很可能只需要幾個容器，所以要么跟人共用物理機，要么浪費資源白交錢。哪怕用戶需要上百個容器，出于容災(zāi)考慮，也不可以把上百容器部署到一臺物 理機上，所以還是要么跟人共用物理機，要么浪費資源。

　　方案

　　以上是我的觀點，我并不是“容器黑”，而是“實用白”。AWS、Azure、GCE 都主推在虛擬機上跑容器，按虛擬機收費，這非常明智的解決了問題：老的純 VM 基礎(chǔ)設(shè)施不用動，計費照舊，單物理機可以被安全的多租戶共用，資源隔離有保證(起碼比共享內(nèi)核強多了)，把容器管理軟件如“kubernetes”給用 戶，既滿足用戶的容器需求，又不擔(dān)心容器的多租戶問題。

　　所以我認(rèn)為：以 VM 為基礎(chǔ)，以容器為輔助點，要買就買 VM，自己管理容器，別買 CAAS 直接提供的容器，別看不到底下物理機或者虛擬機。用 VM 還是用容器，冷靜考察自己的應(yīng)用上容器是否有好處。最后，殘念，VM 開源管理軟件能搞個比 OpenStack 簡單的東西嗎?