做容器的研究和容器化幾年了诈唬，從最初對(duì)于容器的初步認(rèn)識(shí)，到積攢了大量的容器遷移經(jīng)驗(yàn)缩麸，并和客戶解釋了容器技術(shù)之后铸磅，發(fā)現(xiàn)原來對(duì)于容器的理解有大量的誤解，而且容器并非虛擬機(jī)的替代杭朱，而是有十分具體的應(yīng)用場(chǎng)景的阅仔。
第一部分：容器的理解誤區(qū)
誤區(qū)一：容器啟動(dòng)速度快，秒級(jí)啟動(dòng)
這是很多人布道容器的時(shí)候經(jīng)常說的一句話弧械，往往人們會(huì)啟動(dòng)一個(gè)nginx之類的應(yīng)用八酒，的確很快就能夠啟動(dòng)起來了。
容器為啥啟動(dòng)快刃唐，一是沒有內(nèi)核丘跌，二是鏡像比較小。
然而容器是有主進(jìn)程的唁桩，也即Entrypoint，只有主進(jìn)程完全啟動(dòng)起來了耸棒，容器才算真正的啟動(dòng)起來荒澡，一個(gè)比喻是容器更像人的衣服，人站起來了与殃，衣服才站起來单山，人躺下了，衣服也躺下了幅疼。衣服有一定的隔離性米奸，但是隔離性沒那么好。衣服沒有根(內(nèi)核)爽篷，但是衣服可以隨著人到處走悴晰。
所以按照一個(gè)nginx來評(píng)判一個(gè)容器的啟動(dòng)速度有意義么？對(duì)于Java應(yīng)用，里面安裝的是tomcat铡溪，而tomcat的啟動(dòng)漂辐，加載war，并且真正的應(yīng)用啟動(dòng)起來棕硫，如果你盯著tomcat的日志看的話髓涯，還是需要一些時(shí)間的，根本不是秒級(jí)哈扮。如果應(yīng)用啟動(dòng)起來要一兩分鐘纬纪，僅僅談容器的秒級(jí)啟動(dòng)是沒有意義的。
現(xiàn)在OpenStack中的VM的啟動(dòng)速度也優(yōu)化的越來越快了滑肉，啟動(dòng)一個(gè)VM的時(shí)候
包各，原來需要從Glance下載虛擬機(jī)鏡像，后來有了一個(gè)技術(shù)赦邻，是的Glance和系統(tǒng)盤共享Ceph存儲(chǔ)的情況下髓棋，虛擬機(jī)鏡像無需下載，啟動(dòng)速度就快很多惶洲。
而且容器之所以啟動(dòng)速度快按声，往往建議使用一個(gè)非常小的鏡像，例如alpine恬吕，里面很多東西都裁剪掉了签则，啟動(dòng)的速度就更快了。
OpenStack的虛擬機(jī)鏡像也可以經(jīng)過大量的裁剪铐料，實(shí)現(xiàn)快速的啟動(dòng)
我們可以精細(xì)的衡量虛擬機(jī)啟動(dòng)的每一個(gè)步驟渐裂，裁剪掉相應(yīng)的模塊和啟動(dòng)的過程，大大降低虛擬機(jī)的啟動(dòng)時(shí)間钠惩。
“使用原生的OpenStack創(chuàng)建虛擬機(jī)需要1~3分鐘柒凉，而使用改造后的OpenStack僅需要不到10秒鐘時(shí)間。這是因?yàn)閚ova-compute不再需要通過HTTP下載整個(gè)鏡像篓跛，虛擬機(jī)可以通過直接讀取Ceph中的鏡像數(shù)據(jù)進(jìn)行啟動(dòng)膝捞。”
所以對(duì)于虛擬機(jī)的整體啟動(dòng)時(shí)間愧沟，現(xiàn)在優(yōu)化的不錯(cuò)的情況下蔬咬，一般能夠做到十幾秒到半分鐘以內(nèi)。這個(gè)時(shí)間和Tomcat的啟動(dòng)時(shí)間相比較沐寺，其實(shí)不算是負(fù)擔(dān)林艘，和容器的啟動(dòng)速度相比，沒有質(zhì)的差別混坞，可能有人會(huì)說啟動(dòng)速度快一點(diǎn)也是快狐援，尤其是對(duì)于在線環(huán)境的掛掉自修復(fù)來講，不是分秒必爭(zhēng)么？關(guān)于自修復(fù)的問題咕村，我們下面另外說场钉。
然而虛擬機(jī)有一個(gè)好處，就是隔離性好懈涛，如果容器是衣服逛万，虛擬機(jī)就是房子，房子立在那里批钠，里面的人無論站著還是躺著宇植，房子總是站著的，房子也不會(huì)跟著人走埋心。使用虛擬機(jī)就像人們住在公寓里面一樣指郁，每人一間，互補(bǔ)干擾拷呆，使用容器像大家穿著衣服擠在公交車?yán)锩嫦锌玻此聘綦x，誰把公交弄壞了茬斧，誰都走不了腰懂。
綜上所述，容器的啟動(dòng)速度不足以構(gòu)成對(duì)OpenStack虛擬機(jī)的明顯優(yōu)勢(shì)项秉，然而虛擬機(jī)的隔離性绣溜，則秒殺容器。
誤區(qū)二：容器輕量級(jí)娄蔼，每個(gè)主機(jī)會(huì)運(yùn)行成百上千個(gè)容器
很多人會(huì)做實(shí)驗(yàn)怖喻，甚至?xí)蛻粽f，容器平臺(tái)多么多么牛岁诉，你看我們一臺(tái)機(jī)器上可以運(yùn)行成百上千個(gè)容器锚沸，虛擬機(jī)根本做不到這一點(diǎn)。
但是一個(gè)機(jī)器運(yùn)行成百上千個(gè)容器涕癣，有這種真實(shí)的應(yīng)用場(chǎng)景么哗蜈？對(duì)于容器來講，重要的是里面的應(yīng)用属划，應(yīng)用的核心在于穩(wěn)定性和高并發(fā)支撐，而不在于密度候生。
我在很多演講的會(huì)議上遇到了很多知名的處理雙十一和618的講師同眯，普遍反饋當(dāng)前的Java應(yīng)用基本上4核8G是標(biāo)配，如果遇見容量不足的情況唯鸭，少部分通過縱向擴(kuò)容的方式進(jìn)行须蜗，大部分采用橫向擴(kuò)容的方式進(jìn)行。
如果4核8G是標(biāo)配，不到20個(gè)服務(wù)就可以占滿一臺(tái)物理服務(wù)器明肮，一臺(tái)機(jī)器跑成百上千個(gè)nginx有意思么菱农？ 這不是一個(gè)嚴(yán)肅的使用場(chǎng)景。
當(dāng)然現(xiàn)在有一個(gè)很火的Serverless無服務(wù)架構(gòu)柿估，在無服務(wù)器架構(gòu)中循未，所有自定義代碼作為孤立的、獨(dú)立的秫舌、常常細(xì)粒度的函數(shù)來編寫和執(zhí)行的妖，這些函數(shù)在例如AWS Lambda之類的無狀態(tài)計(jì)算服務(wù)中運(yùn)行。這些計(jì)算服務(wù)可以是虛擬機(jī)足陨，也可以是容器嫂粟。對(duì)于無狀態(tài)的函數(shù)來講，需要快速的創(chuàng)建可刪除墨缘，而且很可能執(zhí)行一個(gè)函數(shù)的時(shí)間本身就非常短星虹，在這種情況下容器相比于虛擬機(jī)還是有一定優(yōu)勢(shì)的。
目前無服務(wù)架構(gòu)比較適用于運(yùn)行一些任務(wù)型批量操作镊讼，利用進(jìn)程級(jí)別的橫向彈性能力來抵消進(jìn)程創(chuàng)建和銷毀帶來的較大的代價(jià)宽涌。
在spark和mesos的集成中，有一個(gè)Fine-Grained模式狠毯，同通常大數(shù)據(jù)的執(zhí)行的時(shí)候护糖，任務(wù)的執(zhí)行進(jìn)程早就申請(qǐng)好了資源，等在那里分配資源不同嚼松，這種模式是當(dāng)任務(wù)分配到的時(shí)候才分配資源嫡良，好處就是對(duì)于資源的彈性申請(qǐng)和釋放的能力，壞處是進(jìn)程的創(chuàng)建和銷毀還是粒度太大献酗，所以這種模式下spark運(yùn)行的性能會(huì)差一些
spark的這種做法思想類似無服務(wù)架構(gòu)寝受，你會(huì)發(fā)現(xiàn)我們?cè)瓉韺W(xué)操作系統(tǒng)的時(shí)候，說進(jìn)程粒度太大罕偎，每次都創(chuàng)建和銷毀進(jìn)程會(huì)速度太慢很澄，為了高并發(fā)，后來有了線程颜及，線程的創(chuàng)建和銷毀輕量級(jí)的多甩苛，當(dāng)然還是覺得慢，于是有了線程池俏站，事先創(chuàng)建在了那里讯蒲，用的時(shí)候不用現(xiàn)創(chuàng)建，不用的時(shí)候交回去就行肄扎，后來還是覺得慢墨林，因?yàn)榫€程的創(chuàng)建也需要在內(nèi)核中完成赁酝，所以后來有了協(xié)程，全部在用戶態(tài)進(jìn)行線程切換旭等，例如AKKA酌呆，Go都使用了協(xié)程，你會(huì)發(fā)現(xiàn)趨勢(shì)是為了高并發(fā)搔耕，粒度是越來越細(xì)的隙袁，現(xiàn)在很多情況又需要進(jìn)程級(jí)別的，有種風(fēng)水輪流轉(zhuǎn)的感覺度迂。
誤區(qū)三：容器有鏡像藤乙，可以保持版本號(hào)，可以升級(jí)和回滾
容器有兩個(gè)特性惭墓，一個(gè)是封裝坛梁，一個(gè)是標(biāo)準(zhǔn)。有了容器鏡像腊凶，就可以將應(yīng)用的各種配置划咐，文件路徑，權(quán)限封裝起來钧萍，然后像孫悟空說“定”,就定在了封裝好的那一刻褐缠。鏡像是標(biāo)準(zhǔn)的，無論在哪個(gè)容器運(yùn)行環(huán)境风瘦，將同樣的鏡像運(yùn)行起來队魏，都能還原當(dāng)時(shí)的那一刻。
容器的鏡像還有版本號(hào)万搔，我們可以根據(jù)容器的版本號(hào)進(jìn)行升級(jí)胡桨，一旦升級(jí)有錯(cuò)，可以根據(jù)版本號(hào)進(jìn)行回滾瞬雹，回滾完畢則能夠保證容器內(nèi)部還是原來的狀態(tài)昧谊。
但是OpenStack虛擬機(jī)也是有鏡像的，虛擬機(jī)鏡像也是可以打snapshot的酗捌，打snapshot的時(shí)候呢诬，也會(huì)保存當(dāng)時(shí)的那一刻所有的狀態(tài)，而且snapshot也可以有版本號(hào)胖缤，也可以升級(jí)和回滾尚镰。
似乎容器有的這些特性O(shè)penStack虛擬機(jī)都有，二者有什么不同呢哪廓？
虛擬機(jī)鏡像大狗唉，而容器鏡像小。虛擬機(jī)鏡像動(dòng)不動(dòng)就幾十個(gè)G甚至上百G撩独，而容器鏡像多幾百M(fèi)敞曹。
虛擬機(jī)鏡像不適合跨環(huán)境遷移。例如開發(fā)環(huán)境在本地综膀，測(cè)試環(huán)境在一個(gè)OpenStack上澳迫，開發(fā)環(huán)境在另一個(gè)OpenStack上，虛擬機(jī)的鏡像的遷移非常困難剧劝，需要拷貝非常大的文件橄登。而容器就好的多，因?yàn)殓R像小讥此，可以很快的從不同的環(huán)境之間遷移拢锹。
虛擬機(jī)鏡像不適合跨云遷移。當(dāng)前沒有一個(gè)公有云平臺(tái)支持虛擬機(jī)鏡像的下載和上傳(安全的原因萄喳，盜版的原因)卒稳，因而一個(gè)鏡像在不同的云之間，或者同一個(gè)云不同的region直接他巨，無法進(jìn)行遷移充坑，只能重新做一個(gè)鏡像，這樣環(huán)境的一致性就得不到保障染突。而容器的鏡像中心是獨(dú)立于云之外的捻爷，只要能夠連上鏡像中心，到哪個(gè)云上都可以下載份企，并且因?yàn)殓R像小也榄，下載速度快，并且鏡像是分層的司志，每次只需要下載差異的部分甜紫。
OpenStack對(duì)于鏡像方面的優(yōu)化，基本上還是在一個(gè)云里面起作用俐芯，一旦跨多個(gè)環(huán)境棵介，鏡像方便的多。
誤區(qū)四：容器可以使用容器平臺(tái)管理自動(dòng)重啟實(shí)現(xiàn)自修復(fù)
容器的自修復(fù)功能是經(jīng)常被吹噓的吧史。因?yàn)槿萜魇且路柿桑颂上铝耍路蔡上铝嗣秤萜髌脚_(tái)能夠馬上發(fā)現(xiàn)人躺下了量愧，于是可以迅速將人重新喚醒工作漆撞。而虛擬機(jī)是房子，人躺下了，房子還站著雀久，因而虛擬機(jī)管理平臺(tái)不知道里面的人能不能工作，所以容器掛了會(huì)被自動(dòng)重啟伍掀，而虛擬機(jī)里面的應(yīng)用掛了，只要虛擬機(jī)不掛刘莹，很可能沒人知道。
這些說法都沒錯(cuò)焚刚，但是人們慢慢發(fā)現(xiàn)了另外的場(chǎng)景点弯，就是容器里面的應(yīng)用沒有掛，所以容器看起來還啟動(dòng)著矿咕，但是應(yīng)用以及不工作沒有反應(yīng)了抢肛。當(dāng)啟動(dòng)容器的時(shí)候，雖然容器的狀態(tài)起來了碳柱，但是里面的應(yīng)用還需要一段時(shí)間才能提供服務(wù)捡絮。所以針對(duì)這種場(chǎng)景，容器平臺(tái)會(huì)提供對(duì)于容器里面應(yīng)用的health check莲镣，不光看容器在不在福稳，還要看里面的應(yīng)用能不能用，如果不能瑞侮，可自動(dòng)重啟灵寺。
一旦引入了health check，和虛擬機(jī)的差別也不大了区岗，因?yàn)橛辛薶ealth check略板，虛擬機(jī)也能看里面的應(yīng)用是否工作了，不工作也可以重啟應(yīng)用慈缔。
還要就是容器的啟動(dòng)速度快叮称，秒級(jí)啟動(dòng)，如果能夠自動(dòng)重啟修復(fù)藐鹤，那就是秒級(jí)修復(fù)瓤檐，所以應(yīng)用更加高可用。
這個(gè)觀點(diǎn)當(dāng)然不正確娱节，應(yīng)用的高可用性和重啟的速度沒有直接關(guān)系挠蛉。高可用性一定要通過多個(gè)副本來實(shí)現(xiàn)，在任何一個(gè)掛掉之后肄满，不能通過這一個(gè)應(yīng)用快速重啟來解決谴古，而是應(yīng)該靠掛掉的期間，其他的副本馬上把任務(wù)接過來進(jìn)行解決稠歉。虛擬機(jī)和容器都可以有多副本掰担，在有多個(gè)副本的情況下，重啟是一秒還是20秒怒炸，就沒那么重要了带饱，重要的是掛掉的這段時(shí)間內(nèi)，程序做了什么阅羹，如果程序做的是無關(guān)緊要的操作勺疼，那么掛了20秒教寂，也沒啥關(guān)系，如果程序正在進(jìn)行一個(gè)交易和支付执庐，那掛掉一秒也不行孝宗，也必須能夠修復(fù)回來。所以應(yīng)用的高可用性要靠應(yīng)用層的重試耕肩，冪等去解決，而不應(yīng)該靠基礎(chǔ)設(shè)施層重啟的快不快來解決问潭。
對(duì)于無狀態(tài)服務(wù)猿诸，在做好重試的機(jī)制的情況下，通過自動(dòng)重啟修復(fù)是沒有問題的狡忙，因?yàn)闊o狀態(tài)的服務(wù)不會(huì)保存非常重要的操作梳虽。
對(duì)于有狀態(tài)服務(wù)，容器的重啟不但不是推薦的灾茁，而且可能是災(zāi)難的開始窜觉。一個(gè)服務(wù)有狀態(tài)，例如數(shù)據(jù)庫(kù)北专，在高并發(fā)場(chǎng)景下禀挫，一旦掛了，哪怕只有一秒拓颓，我們必須要弄清楚這一秒都發(fā)生了什么语婴，哪些數(shù)據(jù)保存了，哪些數(shù)據(jù)丟了驶睦，而不能盲目的重啟砰左，否則會(huì)很可能造成數(shù)據(jù)的不一致性，后期修都沒法修场航。例如高頻交易下的數(shù)據(jù)庫(kù)掛了缠导，按說DBA應(yīng)該嚴(yán)格審核丟了哪些數(shù)據(jù)，而不是在DBA不知情的情況下溉痢，盲目的重啟了僻造，DBA還覺得沒什么事情發(fā)生，最終很久才能發(fā)現(xiàn)問題孩饼。?
所以容器比較適合部署無狀態(tài)服務(wù)的嫡意，隨便重啟都可以。
而容器部署有狀態(tài)容器不是不能捣辆，而是要非常小心蔬螟，甚至都是不推薦的。雖然很多的容器平臺(tái)都支持有狀態(tài)容器汽畴，然而平臺(tái)往往解決不了數(shù)據(jù)問題旧巾，除非你對(duì)容器里面的應(yīng)用非常非常非常熟悉耸序，當(dāng)容器掛了，你能夠準(zhǔn)確的知道丟了哪些鲁猩，哪些要緊坎怪，哪些不要緊，而且要寫代碼處理這些情況廓握，然后才能支持重啟搅窿。網(wǎng)易這面的數(shù)據(jù)庫(kù)主備同步的情況下，是通過修改mysql源代碼隙券，保證主備之間數(shù)據(jù)完全同步男应，才敢在主掛了的情況下，備自動(dòng)切換主娱仔。
而宣傳有狀態(tài)容器的自動(dòng)重啟沐飘，對(duì)于服務(wù)客戶來講是很不經(jīng)濟(jì)的行為，因?yàn)榭蛻敉鶝]有那么清楚應(yīng)用的邏輯牲迫，甚至應(yīng)用都是買的耐朴，如果使用有狀態(tài)容器，任憑自動(dòng)重啟盹憎，最終客戶發(fā)現(xiàn)數(shù)據(jù)丟失的時(shí)候筛峭，還是會(huì)怪到你的頭上。
所以有狀態(tài)的服務(wù)自動(dòng)重啟不是不可用陪每，需要足夠?qū)I(yè)才行蜒滩。
誤區(qū)五：容器可以使用容器平臺(tái)進(jìn)行服務(wù)發(fā)現(xiàn)
容器平臺(tái)swarm, kubernetes，mesos都是支持服務(wù)發(fā)現(xiàn)的奶稠，當(dāng)一個(gè)服務(wù)訪問另一個(gè)服務(wù)俯艰，都會(huì)有服務(wù)名轉(zhuǎn)化為VIP，然后訪問具體的容器锌订。
然而人們會(huì)發(fā)現(xiàn)竹握，基于Java寫的應(yīng)用，服務(wù)之間的調(diào)用多不會(huì)用容器平臺(tái)的服務(wù)發(fā)現(xiàn)辆飘，而是用Dubbo或者spring cloud的服務(wù)發(fā)現(xiàn)啦辐。因?yàn)槿萜髌脚_(tái)層的服務(wù)發(fā)現(xiàn)，還是做的比較基礎(chǔ)蜈项，基本是一個(gè)域名映射的過程芹关，對(duì)于熔斷，限流紧卒，降級(jí)都沒有很好的支持侥衬，然而既然使用服務(wù)發(fā)現(xiàn)，還是希望服務(wù)發(fā)現(xiàn)中間件能夠做到這一點(diǎn)，因而服務(wù)之間的服務(wù)發(fā)現(xiàn)之間使用容器平臺(tái)的少轴总，越是需要高并發(fā)的應(yīng)用直颅，越是如此。
那容器平臺(tái)的服務(wù)發(fā)現(xiàn)沒有用了么怀樟？不是功偿，慢慢你會(huì)發(fā)現(xiàn)，內(nèi)部的服務(wù)發(fā)現(xiàn)是一方面往堡，這些Dubbo和spring cloud能夠搞定械荷，而外部的服務(wù)發(fā)現(xiàn)就不同了，比如訪問數(shù)據(jù)庫(kù)虑灰，緩存等吨瞎，到底是應(yīng)該配置一個(gè)數(shù)據(jù)庫(kù)服務(wù)的名稱，還是IP地址呢瘩缆？如果使用IP地址，會(huì)造成配置十分復(fù)雜佃蚜，因?yàn)楹芏鄳?yīng)用配置之所以復(fù)雜庸娱，就是依賴了太多的外部應(yīng)用，也是最難管理的一方面谐算。如果有了外部的服務(wù)發(fā)現(xiàn)熟尉，配置就會(huì)簡(jiǎn)單很多，也只需要配置外部服務(wù)的名稱就可以了洲脂，如果外部服務(wù)地址變了斤儿，可以很靈活的改變外部的服務(wù)發(fā)現(xiàn)。
誤區(qū)六：容器可以基于鏡像進(jìn)行彈性伸縮
在容器平臺(tái)上恐锦，容器有副本數(shù)的往果，只要將副本數(shù)從5改到10，容器就基于鏡像進(jìn)行了彈性伸縮一铅。其實(shí)這一點(diǎn)虛擬機(jī)也能做到陕贮，AWS的Autoscaling就是基于虛擬機(jī)鏡像的，如果在同一個(gè)云里面潘飘，就沒有區(qū)別肮之。
當(dāng)然如果跨云無狀態(tài)容器的彈性伸縮，容器方便很多卜录，可以實(shí)現(xiàn)混合云模式戈擒，當(dāng)高并發(fā)場(chǎng)景下，將無狀態(tài)容器擴(kuò)容到公有云艰毒，這一點(diǎn)虛擬機(jī)是做不到的筐高。
容器理解誤區(qū)總結(jié)
如圖，左面是經(jīng)常掛在嘴邊的所謂容器的優(yōu)勢(shì)，但是虛擬機(jī)都能一一懟回去凯傲。
如果部署的是一個(gè)傳統(tǒng)的應(yīng)用犬辰，這個(gè)應(yīng)用啟動(dòng)速度慢，進(jìn)程數(shù)量少冰单，基本不更新幌缝，那么虛擬機(jī)完全能夠滿足需求。
應(yīng)用啟動(dòng)慢：應(yīng)用啟動(dòng)15分鐘诫欠，容器本身秒級(jí)涵卵，虛擬機(jī)很多平臺(tái)能優(yōu)化到十幾秒，兩者幾乎看不出差別
內(nèi)存占用大：動(dòng)不動(dòng)32G荒叼，64G內(nèi)存轿偎，一臺(tái)機(jī)器跑不了幾個(gè)。
基本不更新：半年更新一次被廓，虛擬機(jī)鏡像照樣能夠升級(jí)和回滾
應(yīng)用有狀態(tài)：停機(jī)會(huì)丟數(shù)據(jù)坏晦，如果不知道丟了啥，就算秒級(jí)啟動(dòng)有啥用嫁乘，照樣恢復(fù)不了昆婿，而且還有可能因?yàn)閬G數(shù)據(jù)，在沒有修復(fù)的情況下蜓斧，盲目重啟帶來數(shù)據(jù)混亂仓蛆。
進(jìn)程數(shù)量少：兩三個(gè)進(jìn)程相互配置一下，不用服務(wù)發(fā)現(xiàn)挎春，配置不麻煩
如果是一個(gè)傳統(tǒng)應(yīng)用看疙，根本沒有必要花費(fèi)精去容器化，因?yàn)榘谆肆庵狈埽硎懿坏胶锰帯?/p>
第二部分：容器化能庆，微服務(wù)，DevOps三位一體
什么情況下脚线，才應(yīng)該考慮做一些改變呢相味？
傳統(tǒng)業(yè)務(wù)突然被互聯(lián)網(wǎng)業(yè)務(wù)沖擊了，應(yīng)用老是變殉挽，三天兩頭要更新丰涉，而且流量增大了，原來支付系統(tǒng)是取錢刷卡的斯碌，現(xiàn)在要互聯(lián)網(wǎng)支付了一死，流量擴(kuò)大了N倍。
沒辦法傻唾，一個(gè)字：拆
拆開了投慈，每個(gè)子模塊獨(dú)自變化承耿，少相互影響。
拆開了伪煤，原來一個(gè)進(jìn)程扛流量加袋，現(xiàn)在多個(gè)進(jìn)程一起扛。
所以稱為微服務(wù)抱既。
微服務(wù)場(chǎng)景下职烧，進(jìn)程多，更新快防泵，于是出現(xiàn)100個(gè)進(jìn)程蚀之，每天一個(gè)鏡像。
容器樂了捷泞，每個(gè)容器鏡像小足删，沒啥問題，虛擬機(jī)哭了锁右，因?yàn)樘摂M機(jī)每個(gè)鏡像太大了失受。
所以微服務(wù)場(chǎng)景下，可以開始考慮用容器了咏瑟。
虛擬機(jī)怒了拂到，老子不用容器了，微服務(wù)拆分之后响蕴，用Ansible自動(dòng)部署是一樣的谆焊。
這樣說從技術(shù)角度來講沒有任何問題惠桃。
然而問題是從組織角度出現(xiàn)的浦夷。
一般的公司，開發(fā)會(huì)比運(yùn)維多的多辜王，開發(fā)寫完代碼就不用管了劈狐，環(huán)境的部署完全是運(yùn)維負(fù)責(zé)，運(yùn)維為了自動(dòng)化呐馆，寫Ansible腳本來解決問題肥缔。
然而這么多進(jìn)程，又拆又合并的汹来，更新這么快续膳，配置總是變，Ansible腳本也要常改收班，每天都上線坟岔，不得累死運(yùn)維。
所以這如此大的工作量情況下摔桦，運(yùn)維很容易出錯(cuò)社付，哪怕通過自動(dòng)化腳本承疲。
這個(gè)時(shí)候，容器就可以作為一個(gè)非常好的工具運(yùn)用起來鸥咖。
除了容器從技術(shù)角度燕鸽，能夠使得大部分的內(nèi)部配置可以放在鏡像里面之外，更重要的是從流程角度啼辣，將環(huán)境配置這件事情啊研，往前推了，推到了開發(fā)這里熙兔，要求開發(fā)完畢之后悲伶，就需要考慮環(huán)境部署的問題，而不能當(dāng)甩手掌柜住涉。
這樣做的好處就是麸锉，雖然進(jìn)程多，配置變化多舆声，更新頻繁花沉，但是對(duì)于某個(gè)模塊的開發(fā)團(tuán)隊(duì)來講，這個(gè)量是很小的媳握，因?yàn)?-10個(gè)人專門維護(hù)這個(gè)模塊的配置和更新碱屁，不容易出錯(cuò)。
如果這些工作量全交給少數(shù)的運(yùn)維團(tuán)隊(duì)蛾找，不但信息傳遞會(huì)使得環(huán)境配置不一致娩脾，部署量會(huì)大非常多。
容器是一個(gè)非常好的工具打毛，就是讓每個(gè)開發(fā)僅僅多做5%的工作柿赊，就能夠節(jié)約運(yùn)維200%的工作，并且不容易出錯(cuò)幻枉。
然而本來原來運(yùn)維該做的事情開發(fā)做了碰声，開發(fā)的老大愿意么？開發(fā)的老大會(huì)投訴運(yùn)維的老大么熬甫？
這就不是技術(shù)問題了胰挑，其實(shí)這就是DevOps，DevOps不是不區(qū)分開發(fā)和運(yùn)維椿肩，而是公司從組織到流程瞻颂，能夠打通，看如何合作郑象，邊界如何劃分贡这，對(duì)系統(tǒng)的穩(wěn)定性更有好處。
所以微服務(wù)扣唱，DevOps藕坯，容器是相輔相成团南，不可分割的。
不是微服務(wù)炼彪，根本不需要容器吐根，虛擬機(jī)就能搞定，不需要DevOps辐马，一年部署一次拷橘，開發(fā)和運(yùn)維溝通再慢都能搞定。
所以喜爷，容器的本質(zhì)是基于鏡像的跨環(huán)境遷移冗疮。
鏡像是容器的根本性發(fā)明，是封裝和運(yùn)行的標(biāo)準(zhǔn)檩帐，其他什么namespace术幔，cgroup，早就有了湃密。這是技術(shù)方面诅挑。
在流程方面，鏡像是DevOps的良好工具泛源。
容器是為了跨環(huán)境遷移的拔妥，第一種遷移的場(chǎng)景是開發(fā)，測(cè)試达箍，生產(chǎn)環(huán)境之間的遷移没龙。如果不需要遷移，或者遷移不頻繁缎玫，虛擬機(jī)鏡像也行硬纤，但是總是要遷移，帶著幾百G的虛擬機(jī)鏡像碘梢，太大了咬摇。
第二種遷移的場(chǎng)景是跨云遷移伐蒂，跨公有云煞躬，跨Region，跨兩個(gè)OpenStack的虛擬機(jī)遷移都是非常麻煩逸邦，甚至不可能的恩沛，因?yàn)楣性撇惶峁┨摂M機(jī)鏡像的下載和上傳功能，而且虛擬機(jī)鏡像太大了缕减，一傳傳一天雷客。
所以跨云場(chǎng)景下，混合云場(chǎng)景下桥狡，容器也是很好的使用場(chǎng)景搅裙。這也同時(shí)解決了僅僅私有云資源不足皱卓，扛不住流量的問題。
第三部分：容器的正確使用場(chǎng)景
根據(jù)以上的分析部逮，我們發(fā)現(xiàn)容器推薦使用在下面的場(chǎng)景下娜汁。
1. 部署無狀態(tài)服務(wù)，同虛擬機(jī)互補(bǔ)使用兄朋，實(shí)現(xiàn)隔離性
2. 如果要部署有狀態(tài)服務(wù)掐禁，需要對(duì)里面的應(yīng)用十分的了解
3. 作為持續(xù)集成的重要工具，可以順利在開發(fā)颅和，測(cè)試傅事，生產(chǎn)之間遷移
4. 適合部署跨云，跨Region峡扩，跨數(shù)據(jù)中心蹭越，混合云場(chǎng)景下的應(yīng)用部署和彈性伸縮
5. 以容器作為應(yīng)用的交付物，保持環(huán)境一致性教届，樹立不可變更基礎(chǔ)設(shè)施的理念
6. 運(yùn)行進(jìn)程基本的任務(wù)類型的程序
7. 用于管理變更般又，變更頻繁的應(yīng)用使用容器鏡像和版本號(hào)，輕量級(jí)方便的多
8. 使用容器一定要管理好應(yīng)用巍佑，進(jìn)行health check和容錯(cuò)的設(shè)計(jì)
