大家在工作中或許或多或少都接觸過(guò)Docker，那你知道Docker以及容器化背后的原理到底是什么嗎？
容器化技術(shù)滿天下，那為什么只有Docker被大家所熟知呢？
后Docker時(shí)代，到底誰(shuí)才是云原生時(shí)代的王者？
我們相信本系列文章能幫您解答這些疑惑。
在云時(shí)代以前，開發(fā)者如需構(gòu)建一個(gè)線上的站點(diǎn)，必須自己維護(hù)物理服務(wù)器。但是隨著業(yè)務(wù)發(fā)展，大體量服務(wù)器逐漸增多，隨之而來(lái)的是硬件、場(chǎng)地和維護(hù)成本的不斷提高。對(duì)于面向C端的站點(diǎn)來(lái)說(shuō)，網(wǎng)絡(luò)熱點(diǎn)事件具有隨機(jī)性，流量的變化并不可控，難免會(huì)遭遇站內(nèi)流量暴漲的情況。此時(shí)如果沒有備用服務(wù)器，突發(fā)的大流量很可能會(huì)沖垮整個(gè)站點(diǎn)。但在沒有突發(fā)事件的時(shí)候，備用服務(wù)器的采購(gòu)和維護(hù)成本又讓人不可忽略。
哪里有問(wèn)題，哪里就有商機(jī)。有人想到，如果買一批服務(wù)器放在外網(wǎng)，安排專人管理，然后按照用戶的需要租賃出去，不正好解決了這個(gè)問(wèn)題嗎？
于是，一場(chǎng)云計(jì)算的好戲，正式上演。
云計(jì)算時(shí)代的大幕拉開，大廠先后登臺(tái)，讓我們先簡(jiǎn)單做一下回顧。
2006年，亞馬遜成立aws，從云端存儲(chǔ)業(yè)務(wù)開始。
2008年，云計(jì)算初創(chuàng)。
2009年，阿里云成立。目前最新的數(shù)據(jù)表明，2020年度IaaS市場(chǎng)份額調(diào)查，阿里云位居全球第三，亞太第一；前兩名分別是亞馬遜和微軟，市場(chǎng)份額達(dá)9.5%，超過(guò)谷歌的6.1%，亞馬遜40.8%，微軟17%。國(guó)內(nèi)市場(chǎng)份額40% ，第二是華為云，占18%。
2010年，OpenStack由NASA發(fā)布。OpenStack是一個(gè)IaaS架構(gòu)，可以用其架構(gòu)來(lái)搭建自己的私有云，讓任何人都可以自行創(chuàng)建和提供云計(jì)算服務(wù)。對(duì)比而言，AWS和aliyun都是自研架構(gòu)，OpenStack是開源的。所以公司如果需要，完全可以接入OpenStack搭建自己的私有云。（當(dāng)然前提需要有OpenStack核心開發(fā)能力）。
2010-2013年之間，云計(jì)算的全球份額被aws和OpenStack瓜分。
這時(shí)的云計(jì)算技術(shù)，本質(zhì)都是虛擬化技術(shù)，將硬件資源作為基礎(chǔ)設(shè)施提供給用戶，簡(jiǎn)稱IaaS。簡(jiǎn)單理解，IaaS就是將一個(gè)很大的服務(wù)器，通過(guò)虛擬化技術(shù)拆分成多個(gè)小的虛擬服務(wù)器，提供服務(wù)，類似于在本機(jī)裝了虛擬機(jī)。
但是，IaaS時(shí)代的虛擬機(jī)還是太過(guò)于笨重了。每一臺(tái)虛擬機(jī)都需要消耗CPU、內(nèi)存等計(jì)算資源才能支撐應(yīng)用的運(yùn)行。即便應(yīng)用再小，系統(tǒng)的開銷都是固定的成本。如何為IaaS減肥，讓虛擬機(jī)系統(tǒng)的開銷降到最低？
2013年開始，云計(jì)算正式進(jìn)入了PaaS時(shí)代。PaaS時(shí)代，云計(jì)算所銷售的單元，從虛擬機(jī)變成了應(yīng)用運(yùn)行平臺(tái)。于是，云廠商提供的服務(wù)更多，資源利用率也更高了。
什么是PaaS？我們用一個(gè)通俗的例子來(lái)解釋。如果我們現(xiàn)在是一個(gè)燒餅店老板，采用IaaS模式意味著我們需要用別人廚房、鍋爐、煤氣，自己和面做餡料，做燒餅。如果是PaaS，我們燒餅的面粉、餡料和調(diào)料都是別人提供好了，我們只需要把餅烤熟。
云廠商該如何構(gòu)建一套好用的PaaS服務(wù)呢？借力開源項(xiàng)目，成為各廠商的共識(shí)。
PaaS的核心是平臺(tái)。最早出現(xiàn)在開發(fā)者視野中的PaaS開源項(xiàng)目中，vmware創(chuàng)立的Cloud Foundry是知名度最高的。與IaaS提供云上虛擬機(jī)的服務(wù)方式不同，基于Cloud Foundry的云計(jì)算能夠提供應(yīng)用托管的功能。開發(fā)者只需要通過(guò)一條簡(jiǎn)單的命令比如：cf push "我的應(yīng)用"，就可以將項(xiàng)目打成一個(gè)壓縮包，上傳到Cloud Foundry服務(wù)器。而Cloud foundry會(huì)開啟自己的調(diào)度器，在一群云主機(jī)中找到滿足用戶需求的主機(jī)（系統(tǒng)版本、性能、個(gè)數(shù)），然后通過(guò)容器化技術(shù)，在主機(jī)上創(chuàng)建一個(gè)容器，在容器中下載壓縮包，解壓并運(yùn)行，最終成為一個(gè)對(duì)外提供服務(wù)的應(yīng)用。
此外，Cloud Foundry平臺(tái)對(duì)這些應(yīng)用項(xiàng)目提供分發(fā)，災(zāi)備，監(jiān)控，重啟等等服務(wù)（這也是我們提供給用戶的核心服務(wù)）。這種托管服務(wù)解放了開發(fā)者的生產(chǎn)力，讓他們不用再關(guān)心應(yīng)用的運(yùn)維狀況，而是專心開發(fā)自己的應(yīng)用。而這就是PaaS的“初心”，平臺(tái)即服務(wù)。
這里就會(huì)有同學(xué)問(wèn)了，容器是什么？容器是用來(lái)解決多個(gè)應(yīng)用資源沖突與隔離性問(wèn)題的技術(shù)。Linux上的namespace機(jī)制和cgroups命令都能用做資源隔離和限制，這些都是容器技術(shù)。
容器技術(shù)并不是Docker創(chuàng)建的，在Docker興起之前，就已經(jīng)被其他公司商用了，但是為什么現(xiàn)在一談起容器，所有人第一時(shí)間想到的就是Docker呢？這就要提到Cloud Foundry的死亡。
Cloud Foundry似乎已經(jīng)和我們現(xiàn)在使用的云功能區(qū)別不大，但2021年的現(xiàn)實(shí)情況卻是Cloud Foundry已經(jīng)死了。
我們看過(guò)互聯(lián)網(wǎng)上很多文章，再結(jié)合我們活字格公有云開發(fā)的經(jīng)驗(yàn)，我們認(rèn)為這個(gè)項(xiàng)目的致命缺陷集中它的打包機(jī)制上。
Cloud Foundry最核心的組件就是應(yīng)用的打包和分發(fā)機(jī)制，也是開發(fā)者打交道最多的功能。Cloud Foundry為每一種主流的語(yǔ)言都定義了一套打包的方式，這些方式之間毫無(wú)章法。但就是這個(gè)打包功能，成了Cloud Foundry的軟肋，一直為用戶所詬病。開發(fā)者不得不為每一種語(yǔ)言，每一種框架，甚至是每個(gè)版本應(yīng)用維護(hù)一個(gè)打好的包，還有可能出現(xiàn)本機(jī)運(yùn)行成功，打了個(gè)包上傳上去之后就無(wú)法運(yùn)行的情況。情況最嚴(yán)重的時(shí)候，開發(fā)者在調(diào)試云平臺(tái)系統(tǒng)上花的時(shí)間都已經(jīng)比開發(fā)一個(gè)新軟件的時(shí)間要長(zhǎng)了。
本來(lái)是為賦能開發(fā)者的而生的技術(shù)，Cloud Foundry卻對(duì)開發(fā)者如此不友好。當(dāng)開發(fā)者的抱怨積累到一定程度，想要在PaaS浪潮中央站穩(wěn)腳跟的Cloud Foundry被后起之秀Docker“紅牌罰出局”也就順理成章了。
最初，Docker是一個(gè)當(dāng)時(shí)還叫dotCloud的公司（2010年由所羅門?？怂箘?chuàng)建，Y Combinator孵化）開發(fā)的容器項(xiàng)目。在Cloud Foundry困于打包問(wèn)題時(shí)，Docker正在悄悄積蓄力量，在開源后的短短幾個(gè)月內(nèi)就迅速崛起，成為一個(gè)不容忽視的PaaS技術(shù)方案，吸引了云服務(wù)開發(fā)者的眼球。
滑稽的是，在Docker剛開源的時(shí)候，Cloud Foundry的首席產(chǎn)品經(jīng)理 James Bayer就在社區(qū)做了一次詳細(xì)的對(duì)比，告訴用戶Docker和Cloud Foundry一樣，都是使用了Namespace和Cgroups技術(shù)的沙箱而已，沒什么值得關(guān)注的。
事實(shí)上，Docker也確實(shí)就和他所說(shuō)的一樣，采用了這個(gè)“傳統(tǒng)”的技術(shù)方案，但是Docker與Cloud Foundry相比，做了一點(diǎn)小小的創(chuàng)新，體現(xiàn)了所羅門?？怂沟倪h(yuǎn)見。從2010他就開始考慮應(yīng)用打包的一致性與復(fù)用性問(wèn)題，并提出了創(chuàng)新的解決方案，最終對(duì)Cloud Foundry造成了毀滅性的打擊。這個(gè)解決方案就是Docker鏡像。
（Docker，圖片來(lái)自官網(wǎng)）
剛開源的Docker迅速爆火，憨態(tài)可掬的小鯨魚，對(duì)用戶友好的文檔，三分鐘部署一個(gè)Nginx集群的宣傳語(yǔ)，以及Docker Image這個(gè) “微不足道的創(chuàng)新”，讓Docker席卷整個(gè)PaaS領(lǐng)域。
Docker成功的關(guān)鍵，在于Docker鏡像幾乎完美地解決了Cloud Foundry在打包方面的軟肋。
所謂的鏡像，其實(shí)也是一個(gè)壓縮包，但是比起Cloud Foundry那種執(zhí)行文件+啟動(dòng)腳本的打包結(jié)果，鏡像提供給用戶的是一套完整的運(yùn)行環(huán)境，每一個(gè)鏡像都可以指定操作系統(tǒng)版本，內(nèi)部可以構(gòu)建程序執(zhí)行的文件結(jié)構(gòu)，并且一份鏡像可以完全共享在多處使用。
此外，Docker還給開發(fā)者提供了一套完善的鏡像制作流程，這套流程與編程語(yǔ)言和框架無(wú)關(guān)。開發(fā)者只需要按照該流程，定制對(duì)應(yīng)程序所需要的運(yùn)行的操作系統(tǒng)環(huán)境即可。
總之，Docker 鏡像完美解決了兩個(gè)問(wèn)題：
1.本地環(huán)境和服務(wù)器環(huán)境的差異
2.同一份鏡像可以讓所有的機(jī)器進(jìn)行復(fù)用
從這一刻開始，PaaS的市場(chǎng)已經(jīng)完全是Docker的天下。
本文是系列文章的第一期，我們一起回顧了IaaS取代物理服務(wù)器，基于IaaS構(gòu)建PaaS的發(fā)展路線。在構(gòu)建PaaS時(shí)，我們經(jīng)歷了Cloud Foundry的衰敗，見證了Docker的成功。
但是，只依靠Docker就能構(gòu)建起完整的PaaS服務(wù)嗎？我們的活字格最終選擇了哪個(gè)技術(shù)方案？云計(jì)算的故事還沒有講完，敬請(qǐng)期待下期精彩內(nèi)容。
聯(lián)系客服
