容器的六大理解誤區(qū)

容器的六大理解誤區(qū)

誤區(qū)一：容器啟動速度快，秒級啟動

這是很多人布道容器的時候經(jīng)常說的一句話，往往人們會啟動一個 Nginx 之類的應(yīng)用，的確很快就能夠啟動起來了。

容器為啥啟動快，一是沒有內(nèi)核，二是鏡像比較小。

然而容器是有主進程的，也即 Entrypoint，只有主進程完全啟動起來了，容器才算真正的啟動起來。

用一個比喻：容器更像人的衣服，人站起來了，衣服才站起來，人躺下了，衣服也躺下了。衣服有一定的隔離性，但是隔離性沒那么好。衣服沒有根(內(nèi)核)，但是衣服可以隨著人到處走。

所以按照一個 Nginx 來評判一個容器的啟動速度有意義么？對于 Java 應(yīng)用，里面安裝的是 Tomcat，而 Tomcat 的啟動，加載 War，并且真正的應(yīng)用啟動起來。

如果你盯著 Tomcat 的日志看的話，還是需要一些時間的，根本不是秒級；如果應(yīng)用啟動起來要一兩分鐘，僅僅談容器的秒級啟動是沒有意義的。

現(xiàn)在 OpenStack 中 VM 的啟動速度也優(yōu)化的越來越快了，啟動一個 VM 的時候，原來需要從 Glance 下載虛擬機鏡像。

后來有了一個技術(shù)，是在 Glance 和系統(tǒng)盤共享 Ceph 存儲的情況下，虛擬機鏡像無需下載，啟動速度就快很多。

而且容器之所以啟動速度快，往往建議使用一個非常小的鏡像，例如 alpine，里面很多東西都裁剪掉了，啟動的速度就更快了。

OpenStack 的虛擬機鏡像也可以經(jīng)過大量的裁剪，實現(xiàn)快速的啟動。

我們可以精細(xì)的衡量虛擬機啟動的每一個步驟，裁剪掉相應(yīng)的模塊和啟動的過程，大大降低虛擬機的啟動時間。

例如在 UnitedStack 的一篇博客里面 https://www.ustack.com/blog/build-block-storage-service，我們可以看到這樣的實現(xiàn)和描述：

使用原生的 OpenStack 創(chuàng)建虛擬機需要 1~3 分鐘，而使用改造后的 OpenStack 僅需要不到 10 秒鐘時間。

這是因為 nova-compute 不再需要通過 HTTP 下載整個鏡像，虛擬機可以通過直接讀取 Ceph 中的鏡像數(shù)據(jù)進行啟動。

所以對于虛擬機的整體啟動時間，現(xiàn)在優(yōu)化的不錯的情況下，一般能夠做到十幾秒到半分鐘以內(nèi)。

這個時間和 Tomcat 的啟動時間相比較，其實不算是負(fù)擔(dān)，和容器的啟動速度相比，沒有質(zhì)的差別，可能有人會說啟動速度快一點也是快。

尤其是對于在線環(huán)境的掛掉自修復(fù)來講，不是分秒必爭么？關(guān)于自修復(fù)的問題，我們下面另外說。

然而虛擬機有一個好處，就是隔離性好，如果容器是衣服，虛擬機就是房子，房子立在那里，里面的人無論站著還是躺著，房子總是站著的，房子也不會跟著人走。

使用虛擬機就像人們住在公寓里面一樣，每人一間，互不干擾，使用容器像大家穿著衣服擠在公交車?yán)锩妫此聘綦x，誰把公交弄壞了，誰都走不了。

綜上所述，容器的啟動速度不足以構(gòu)成對 OpenStack 虛擬機的明顯優(yōu)勢，然而虛擬機的隔離性，則秒殺容器。

誤區(qū)二：容器輕量級，每個主機會運行成百上千個容器

很多人會做實驗，甚至?xí)蛻粽f，容器平臺多么多么牛，你看我們一臺機器上可以運行成百上千個容器，虛擬機根本做不到這一點。

但是一個機器運行成百上千個容器，有這種真實的應(yīng)用場景么？對于容器來講，重要的是里面的應(yīng)用，應(yīng)用的核心在于穩(wěn)定性和高并發(fā)支撐，而不在于密度。

我在很多演講的會議上遇到了很多知名的處理雙十一和 618 的講師，普遍反饋當(dāng)前的 Java 應(yīng)用基本上 4 核 8G 是標(biāo)配，如果遇見容量不足的情況，少部分通過縱向擴容的方式進行，大部分采用橫向擴容的方式進行。

如果 4 核 8G 是標(biāo)配，不到 20 個服務(wù)就可以占滿一臺物理服務(wù)器，一臺機器跑成百上千個 Nginx 有意思么？ 這不是一個嚴(yán)肅的使用場景。

當(dāng)然現(xiàn)在有一個很火的 Serverless 無服務(wù)架構(gòu)，在無服務(wù)器架構(gòu)中，所有自定義代碼作為孤立的、獨立的、常常細(xì)粒度的函數(shù)來編寫和執(zhí)行，這些函數(shù)在例如 AWS Lambda 之類的無狀態(tài)計算服務(wù)中運行。

這些計算服務(wù)可以是虛擬機，也可以是容器。對于無狀態(tài)的函數(shù)來講，需要快速的創(chuàng)建可刪除，而且很可能執(zhí)行一個函數(shù)的時間本身就非常短，在這種情況下容器相比于虛擬機還是有一定優(yōu)勢的。

目前無服務(wù)架構(gòu)比較適用于運行一些任務(wù)型批量操作，利用進程級別的橫向彈性能力來抵消進程創(chuàng)建和銷毀帶來的較大的代價。

在 Spark 和 Mesos 的集成中，有一個 Fine-Grained 模式，在大數(shù)據(jù)的執(zhí)行時候，任務(wù)的執(zhí)行進程早就申請好了資源，與等在那里分配資源不同，這種模式是當(dāng)任務(wù)分配到的時候才分配資源。

好處就是對于資源的彈性申請和釋放的能力，壞處是進程的創(chuàng)建和銷毀還是粒度太大，所以這種模式下 Spark 運行的性能會差一些。

Spark 的這種做法思想類似無服務(wù)架構(gòu)，你會發(fā)現(xiàn)我們原來學(xué)操作系統(tǒng)的時候，說進程粒度太大，每次都創(chuàng)建和銷毀進程會速度太慢。

為了高并發(fā)，后來有了線程，線程的創(chuàng)建和銷毀輕量級的多，當(dāng)然還是覺得慢，于是有了線程池，事先創(chuàng)建在了那里，用的時候不用現(xiàn)創(chuàng)建，不用的時候交回去就行。

后來還是覺得慢，因為線程的創(chuàng)建也需要在內(nèi)核中完成，所以后來有了協(xié)程，全部在用戶態(tài)進行線程切換。

例如 AKKA，Go 都使用了協(xié)程，你會發(fā)現(xiàn)趨勢是為了高并發(fā)，粒度是越來越細(xì)的，現(xiàn)在很多情況又需要進程級別的，有種風(fēng)水輪流轉(zhuǎn)的感覺。

誤區(qū)三：容器有鏡像，可以保持版本號，可以升級和回滾

容器有兩個特性，一個是封裝，一個是標(biāo)準(zhǔn)。有了容器鏡像，就可以將應(yīng)用的各種配置，文件路徑，權(quán)限封裝起來，然后像孫悟空說“定”，就定在了封裝好的那一刻。

鏡像是標(biāo)準(zhǔn)的，無論在哪個容器運行環(huán)境，將同樣的鏡像運行起來，都能還原當(dāng)時的那一刻。

容器的鏡像還有版本號，我們可以根據(jù)容器的版本號進行升級，一旦升級有錯，可以根據(jù)版本號進行回滾，回滾完畢則能夠保證容器內(nèi)部還是原來的狀態(tài)。

但是 OpenStack 虛擬機也是有鏡像的，虛擬機鏡像也是可以打 snapshot 的，打 snapshot 的時候，也會保存當(dāng)時的那一刻所有的狀態(tài)，而且 snapshot 也可以有版本號，也可以升級和回滾。

似乎容器有的這些特性 OpenStack 虛擬機都有，二者有什么不同呢？

虛擬機鏡像大，而容器鏡像小。虛擬機鏡像動不動就幾十個 G 甚至上百 G，而容器鏡像多幾百 M。

虛擬機鏡像不適合跨環(huán)境遷移。例如開發(fā)環(huán)境在本地，測試環(huán)境在一個 OpenStack 上，開發(fā)環(huán)境在另一個 OpenStack 上，虛擬機的鏡像的遷移非常困難，需要拷貝非常大的文件。

而容器就好的多，因為鏡像小，可以很快的從不同的環(huán)境之間遷移。

虛擬機鏡像不適合跨云遷移。當(dāng)前沒有一個公有云平臺支持虛擬機鏡像的下載和上傳(安全的原因，盜版的原因)，因而一個鏡像在不同的云之間，或者同一個云不同的 Region 之間，無法進行遷移，只能重新做一個鏡像，這樣環(huán)境的一致性就得不到保障。

而容器的鏡像中心是獨立于云之外的，只要能夠連上鏡像中心，到哪個云上都可以下載，并且因為鏡像小，下載速度快，鏡像是分層的，每次只需要下載差異的部分。

OpenStack 對于鏡像方面的優(yōu)化，基本上還是在一個云里面起作用，一旦跨多個環(huán)境，鏡像方便的多。

誤區(qū)四：容器可以使用容器平臺管理自動重啟實現(xiàn)自修復(fù)

容器的自修復(fù)功能是經(jīng)常被吹噓的。因為容器是衣服，人躺下了，衣服也躺下了，容器平臺能夠馬上發(fā)現(xiàn)人躺下了，于是可以迅速將人重新喚醒工作。

而虛擬機是房子，人躺下了，房子還站著。因而虛擬機管理平臺不知道里面的人能不能工作，所以容器掛了會被自動重啟，而虛擬機里面的應(yīng)用掛了，只要虛擬機不掛，很可能沒人知道。

這些說法都沒錯，但是人們慢慢發(fā)現(xiàn)了另外的場景，就是容器里面的應(yīng)用沒有掛，所以容器看起來還啟動著，但是應(yīng)用已經(jīng)不工作沒有反應(yīng)了。

當(dāng)啟動容器的時候，雖然容器的狀態(tài)起來了，但是里面的應(yīng)用還需要一段時間才能提供服務(wù)。

所以針對這種場景，容器平臺會提供對于容器里面應(yīng)用的 health check，不光看容器在不在，還要看里面的應(yīng)用能不能用，如果不能，可自動重啟。

一旦引入了 health check，和虛擬機的差別也不大了，因為有了 health check，虛擬機也能看里面的應(yīng)用是否工作了，不工作也可以重啟應(yīng)用。

還有就是容器的啟動速度快，秒級啟動，如果能夠自動重啟修復(fù)，那就是秒級修復(fù)，所以應(yīng)用更加高可用。

這個觀點當(dāng)然不正確，應(yīng)用的高可用性和重啟的速度沒有直接關(guān)系。高可用性一定要通過多個副本來實現(xiàn)，在任何一個掛掉之后，不能通過這一個應(yīng)用快速重啟來解決，而是應(yīng)該靠掛掉的期間，其他的副本馬上把任務(wù)接過來進行解決。

虛擬機和容器都可以有多副本，在有多個副本的情況下，重啟是 1 秒還是 20 秒，就沒那么重要了，重要的是掛掉的這段時間內(nèi)，程序做了什么。

如果程序做的是無關(guān)緊要的操作，那么掛了 20 秒，也沒啥關(guān)系；如果程序正在進行一個交易和支付，那掛掉 1 秒也不行，也必須能夠修復(fù)回來。

所以應(yīng)用的高可用性要靠應(yīng)用層的重試，冪等去解決，而不應(yīng)該靠基礎(chǔ)設(shè)施層重啟的快不快來解決。

對于無狀態(tài)服務(wù)，在做好重試的機制的情況下，通過自動重啟修復(fù)是沒有問題的，因為無狀態(tài)的服務(wù)不會保存非常重要的操作。

對于有狀態(tài)服務(wù)，容器的重啟不但不是推薦的，而且可能是災(zāi)難的開始。

一個服務(wù)有狀態(tài)，例如數(shù)據(jù)庫，在高并發(fā)場景下，一旦掛了，哪怕只有 1 秒，我們必須要弄清楚這 1 秒都發(fā)生了什么，哪些數(shù)據(jù)保存了，哪些數(shù)據(jù)丟了，而不能盲目的重啟，否則很可能會造成數(shù)據(jù)的不一致性，后期修都沒法修。

例如高頻交易下的數(shù)據(jù)庫掛了，按說 DBA 應(yīng)該嚴(yán)格審核丟了哪些數(shù)據(jù)，而不是在 DBA 不知情的情況下，盲目的重啟了，DBA 還覺得沒什么事情發(fā)生，最終很久才能發(fā)現(xiàn)問題。

所以容器是比較適合部署無狀態(tài)服務(wù)的，隨便重啟都可以。

而容器部署有狀態(tài)容器不是不能，而是要非常小心，甚至都是不推薦的。

雖然很多的容器平臺都支持有狀態(tài)容器，然而平臺往往解決不了數(shù)據(jù)問題，除非你對容器里面的應(yīng)用非常非常熟悉。

當(dāng)容器掛了，你能夠準(zhǔn)確的知道丟了哪些，哪些要緊，哪些不要緊，而且要寫代碼處理這些情況，然后才能支持重啟。

網(wǎng)易這面的數(shù)據(jù)庫在主備同步的情況下，是通過修改 MySQL 源代碼，保證主備之間數(shù)據(jù)完全同步，才敢在主掛了的情況下，備自動切換主。

而宣傳有狀態(tài)容器的自動重啟，對于服務(wù)客戶來講是很不經(jīng)濟的行為，因為客戶往往沒有那么清楚應(yīng)用的邏輯，甚至應(yīng)用都是買的。

如果使用有狀態(tài)容器，任憑自動重啟，最終客戶發(fā)現(xiàn)數(shù)據(jù)丟失的時候，還是會怪到你的頭上。

所以有狀態(tài)的服務(wù)自動重啟不是不可用，需要足夠?qū)I(yè)才行。

誤區(qū)五：容器可以使用容器平臺進行服務(wù)發(fā)現(xiàn)

容器平臺 Swarm，Kubernetes，Mesos 都是支持服務(wù)發(fā)現(xiàn)的，當(dāng)一個服務(wù)訪問另一個服務(wù)，都會有服務(wù)名轉(zhuǎn)化為 VIP，然后訪問具體的容器。

然而人們會發(fā)現(xiàn)，基于 Java 寫的應(yīng)用，服務(wù)之間的調(diào)用多不會用容器平臺的服務(wù)發(fā)現(xiàn)，而是用 Dubbo 或者 Spring Cloud 的服務(wù)發(fā)現(xiàn)。

因為容器平臺層的服務(wù)發(fā)現(xiàn)，還是做的比較基礎(chǔ)，基本是一個域名映射的過程，對于熔斷，限流，降級都沒有很好的支持。

然而既然使用服務(wù)發(fā)現(xiàn)，還是希望服務(wù)發(fā)現(xiàn)中間件能夠做到這一點，因而服務(wù)之間的服務(wù)發(fā)現(xiàn)之間使用容器平臺的少，越是需要高并發(fā)的應(yīng)用，越是如此。

那容器平臺的服務(wù)發(fā)現(xiàn)沒有用了么？不是，慢慢你會發(fā)現(xiàn)，內(nèi)部的服務(wù)發(fā)現(xiàn)是一方面，這些 Dubbo 和 Spring Cloud 能夠搞定，而外部的服務(wù)發(fā)現(xiàn)就不同了。

比如訪問數(shù)據(jù)庫，緩存等，到底是應(yīng)該配置一個數(shù)據(jù)庫服務(wù)的名稱，還是 IP 地址呢？

如果使用 IP 地址，會造成配置十分復(fù)雜，因為很多應(yīng)用配置之所以復(fù)雜，就是依賴了太多的外部應(yīng)用，也是最難管理的一方面。

如果有了外部的服務(wù)發(fā)現(xiàn)，配置就會簡單很多，也只需要配置外部服務(wù)的名稱就可以了，如果外部服務(wù)地址變了，可以很靈活的改變外部的服務(wù)發(fā)現(xiàn)。

誤區(qū)六：容器可以基于鏡像進行彈性伸縮

在容器平臺上，容器有副本數(shù)的，只要將副本數(shù)從 5 改到 10，容器就基于鏡像進行了彈性伸縮。

其實這一點虛擬機也能做到，AWS 的 Autoscaling 就是基于虛擬機鏡像的，如果在同一個云里面，就沒有區(qū)別。

當(dāng)然如果是跨云無狀態(tài)容器的彈性伸縮，容器方便很多，可以實現(xiàn)混合云模式，當(dāng)高并發(fā)場景下，將無狀態(tài)容器擴容到公有云，這一點虛擬機是做不到的。

容器理解誤區(qū)總結(jié)：

如上圖，左面是經(jīng)常掛在嘴邊的所謂容器的優(yōu)勢，但是虛擬機都能一一懟回去。

如果部署的是一個傳統(tǒng)的應(yīng)用，這個應(yīng)用啟動速度慢，進程數(shù)量少，基本不更新，那么虛擬機完全能夠滿足需求：

應(yīng)用啟動慢：應(yīng)用啟動 15 分鐘，容器本身秒級，虛擬機很多平臺能優(yōu)化到十幾秒，兩者幾乎看不出差別。

內(nèi)存占用大：動不動 32G，64G 內(nèi)存，一臺機器跑不了幾個。

基本不更新：半年更新一次，虛擬機鏡像照樣能夠升級和回滾。

應(yīng)用有狀態(tài)：停機會丟數(shù)據(jù)，如果不知道丟了啥，就算秒級啟動有啥用，照樣恢復(fù)不了，而且還有可能因為丟數(shù)據(jù)，在沒有修復(fù)的情況下，盲目重啟帶來數(shù)據(jù)混亂。

進程數(shù)量少：兩三個進程相互配置一下，不用服務(wù)發(fā)現(xiàn)，配置不麻煩。

如果是一個傳統(tǒng)應(yīng)用，根本沒有必要花費精力去容器化，因為白花了力氣，享受不到好處。

容器化，微服務(wù)，DevOps 三位一體

什么情況下，才應(yīng)該考慮做一些改變呢？

傳統(tǒng)業(yè)務(wù)突然被互聯(lián)網(wǎng)業(yè)務(wù)沖擊了，應(yīng)用老是變，三天兩頭要更新，而且流量增大了，原來支付系統(tǒng)是取錢刷卡的，現(xiàn)在要互聯(lián)網(wǎng)支付了，流量擴大了 N 倍。

沒辦法，一個字：拆

拆開了，每個子模塊獨自變化，少相互影響。拆開了，原來一個進程扛流量，現(xiàn)在多個進程一起扛。

所以稱為微服務(wù)。

微服務(wù)場景下，進程多，更新快，于是出現(xiàn) 100 個進程，每天一個鏡像。

容器樂了，每個容器鏡像小，沒啥問題，虛擬機哭了，因為虛擬機每個鏡像太大了。

所以微服務(wù)場景下，可以開始考慮用容器了。

虛擬機怒了，老子不用容器了，微服務(wù)拆分之后，用 Ansible 自動部署是一樣的。

這樣說從技術(shù)角度來講沒有任何問題，然而問題是從組織角度出現(xiàn)的。

一般的公司，開發(fā)會比運維多的多，開發(fā)寫完代碼就不用管了，環(huán)境的部署完全是運維負(fù)責(zé)，運維為了自動化，寫 Ansible 腳本來解決問題。

然而這么多進程，又拆又合并的，更新這么快，配置總是變，Ansible 腳本也要常改，每天都上線，不得累死運維。

所以在如此大的工作量情況下，運維很容易出錯，哪怕通過自動化腳本。這個時候，容器就可以作為一個非常好的工具運用起來。

除了容器從技術(shù)角度，能夠使得大部分的內(nèi)部配置可以放在鏡像里面之外，更重要的是從流程角度，將環(huán)境配置這件事情，往前推了，推到了開發(fā)這里，要求開發(fā)完畢之后，就需要考慮環(huán)境部署的問題，而不能當(dāng)甩手掌柜。

這樣做的好處就是，雖然進程多，配置變化多，更新頻繁，但是對于某個模塊的開發(fā)團隊來講，這個量是很小的，因為 5-10 個人專門維護這個模塊的配置和更新，不容易出錯。

如果這些工作量全交給少數(shù)的運維團隊，不但信息傳遞會使得環(huán)境配置不一致，部署量會大非常多。

容器是一個非常好的工具，就是讓每個開發(fā)僅僅多做 5% 的工作，就能夠節(jié)約運維 200% 的工作，并且不容易出錯。

然而本來運維該做的事情開發(fā)做了，開發(fā)的老大愿意么？開發(fā)的老大會投訴運維的老大么？

這就不是技術(shù)問題了，其實這就是 DevOps，DevOps 不是不區(qū)分開發(fā)和運維，而是公司從組織到流程，能夠打通，看如何合作，邊界如何劃分，對系統(tǒng)的穩(wěn)定性更有好處。

所以微服務(wù)，DevOps，容器是相輔相成，不可分割的。

不是微服務(wù)，根本不需要容器，虛擬機就能搞定，不需要 DevOps，一年部署一次，開發(fā)和運維溝通再慢都能搞定。

所以，容器的本質(zhì)是基于鏡像的跨環(huán)境遷移。

鏡像是容器的根本性發(fā)明，是封裝和運行的標(biāo)準(zhǔn)，其他什么 namespace，cgroup，早就有了，這是技術(shù)方面。

在流程方面，鏡像是 DevOps 的良好工具。容器是為了跨環(huán)境遷移的，第一種遷移的場景是開發(fā)，測試，生產(chǎn)環(huán)境之間的遷移。

如果不需要遷移，或者遷移不頻繁，虛擬機鏡像也行，但是總是要遷移，帶著幾百 G 的虛擬機鏡像，太大了。

第二種遷移的場景是跨云遷移，跨公有云，跨 Region，跨兩個 OpenStack 的虛擬機遷移都是非常麻煩，甚至不可能的，因為公有云不提供虛擬機鏡像的下載和上傳功能，而且虛擬機鏡像太大了，一傳傳一天。

所以跨云場景下，混合云場景下，容器也是很好的使用場景。這也同時解決了僅僅私有云資源不足，扛不住流量的問題。

容器的十大正確使用場景

根據(jù)以上的分析，我們發(fā)現(xiàn)容器推薦使用在下面的場景下：

部署無狀態(tài)服務(wù)，同虛擬機互補使用，實現(xiàn)隔離性。

如果要部署有狀態(tài)服務(wù)，需要對里面的應(yīng)用十分的了解。

作為持續(xù)集成的重要工具，可以順利在開發(fā)，測試，生產(chǎn)之間遷移。

適合部署跨云，跨 Region，跨數(shù)據(jù)中心，混合云場景下的應(yīng)用部署和彈性伸縮。

以容器作為應(yīng)用的交付物，保持環(huán)境一致性，樹立不可變更基礎(chǔ)設(shè)施的理念。

運行進程基本的任務(wù)類型的程序。

用于管理變更，變更頻繁的應(yīng)用使用容器鏡像和版本號，輕量級方便的多。

使用容器一定要管理好應(yīng)用，進行 health check 和容錯的設(shè)計。

容器 虛擬化

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。