容器化的必要性，在于它解決了一個(gè)重要問(wèn)題：確保軟件在某一計(jì)算環(huán)境遷移至另一計(jì)算環(huán)境時(shí)，仍能正確運(yùn)行。容器化應(yīng)用程序還幫助不同團(tuán)隊(duì)得以獨(dú)立處理應(yīng)用程序中的不同部分；只要各組件間的交互方式不出現(xiàn)重大變化，各團(tuán)隊(duì)就能安心打理自己的環(huán)節(jié)。如此一來(lái)，整個(gè)軟件開發(fā)流程會(huì)變得更輕松、開發(fā)者也能更快測(cè)試一切潛在錯(cuò)誤。

在敏捷化、DevOps的世界中，上述能力的重要意義不言自明。容器能幫助開發(fā)者建立起信心，讓他們堅(jiān)信自己的軟件在任何環(huán)境下都能順利運(yùn)行。也正是容器化趨勢(shì)催生出了當(dāng)下同樣熱門的“微服務(wù)架構(gòu)”。

下面來(lái)看容器中常見(jiàn)的幾種綁定要素：

? 應(yīng)用程序本體

? 依賴項(xiàng)

? 庫(kù)

? 二進(jìn)制文件

? 配置文件

但為了管理這些容器，我們還需要仰仗另一套專用軟件，例如Docker Swarm、Kubernetes等等。這些軟件可以幫助我們編排容器，將其正確推送至不同的目標(biāo)設(shè)備并保證它們?cè)谀抢镯槙尺\(yùn)行。

既然無(wú)服務(wù)器和容器都很重要，那二者的區(qū)別在哪里？下面我們就將逐一比較它們?cè)趯?shí)際部署中的具體表現(xiàn)：

#1.壽命限制

無(wú)服務(wù)器：大家應(yīng)該了解，函數(shù)的壽命往往很“短”。這里的短，一般是在5分鐘以內(nèi)。函數(shù)的這種臨時(shí)特性，意味著運(yùn)行該函數(shù)的容器也會(huì)在一次執(zhí)行之后即告清除。

但也正是這種較短的生命周期，讓函數(shù)獲得了極高的敏捷性，幫助開發(fā)人員得以自由靈活地將應(yīng)用程序推向各類易于擴(kuò)展的生產(chǎn)環(huán)境。

容器：容器的情況則有所不同。容器始終保持運(yùn)行，而且在執(zhí)行完畢后也不會(huì)被消除。這就讓容器得以充分利用緩存性能優(yōu)勢(shì)，同時(shí)被迫放棄了瞬時(shí)擴(kuò)展的能力。

#2. 狀態(tài)持久性

無(wú)服務(wù)器：如前文所述，函數(shù)總是具有臨時(shí)性或者說(shuō)“短壽命”特性，這也決定了它們的無(wú)狀態(tài)屬性。而函數(shù)越是保持這種無(wú)狀態(tài)性，就適合被用來(lái)組合并構(gòu)建起強(qiáng)大的整體解決方案。

無(wú)狀態(tài)計(jì)算的強(qiáng)大之處，在于幫助開發(fā)人員編寫出眾多強(qiáng)大的、可重用的函數(shù)并靈活組合起來(lái)。但也正是由于這種無(wú)狀態(tài)性，導(dǎo)致函數(shù)無(wú)法緩存任何內(nèi)容以供后續(xù)使用。沒(méi)有了緩存機(jī)制，其延遲水平也就更高。

容器：在容器一邊，我們倒是可以充分發(fā)揮緩存優(yōu)勢(shì)。為了保證即使在容器終止后數(shù)據(jù)仍能正常存儲(chǔ)，我們需要一種存儲(chǔ)機(jī)制來(lái)容納容器之外的數(shù)據(jù)。說(shuō)到這里，有些朋友可能要問(wèn)，緩存有那么重要嗎？為什么我們?cè)谟懻撝锌傄崞鹁彺妫?

確實(shí)重要，因?yàn)槿绻萜鲗⒁谀繕?biāo)文件上生成的對(duì)象之前就曾經(jīng)出現(xiàn)過(guò)，那么直接重用原有結(jié)果能夠節(jié)約下大量時(shí)間。而這些原有結(jié)果正是要由緩存來(lái)存放。所以在緩存的加持下，新容器能獲得極快的構(gòu)建速度。

#3. 無(wú)延遲與啟動(dòng)時(shí)間

無(wú)服務(wù)器：函數(shù)的無(wú)狀態(tài)與不可緩存兩大特性，決定了其必然不具備在待機(jī)期間持續(xù)運(yùn)行的函數(shù)副本，這就必然導(dǎo)致調(diào)用時(shí)間更長(zhǎng)。所以函數(shù)只有兩種狀態(tài)：1）“保溫”狀態(tài)，即代碼根據(jù)命令執(zhí)行的15分鐘以內(nèi)；除此之外的任何其他時(shí)段皆屬于2）冷啟動(dòng)狀態(tài)。

結(jié)果就是，對(duì)于存在眾多并發(fā)用戶的應(yīng)用場(chǎng)景，無(wú)服務(wù)器計(jì)算必然存在延遲問(wèn)題。為此，大家可以添加以下代碼使得函數(shù)始終“保溫”。

但這畢竟只是權(quán)宜之計(jì)，只適用于函數(shù)數(shù)量不大的場(chǎng)景。面對(duì)數(shù)量眾多的大規(guī)模系統(tǒng)，我們根本無(wú)法正確管理所有虛擬函數(shù)。所以以上方法只適用于函數(shù)數(shù)量較少，沒(méi)必要驚動(dòng)整體容器的情況。

容器：容器誕生于前無(wú)服務(wù)器時(shí)代，所以它當(dāng)然不像無(wú)服務(wù)器那樣“轉(zhuǎn)瞬即逝”。容器就在那里，隨時(shí)準(zhǔn)備著接收我們的HTTPS請(qǐng)求、再以低延遲甚至即時(shí)方式做出響應(yīng)。憑借著緩存優(yōu)勢(shì)，容器的啟動(dòng)速度很快、無(wú)需重復(fù)創(chuàng)建文件，單靠緩存數(shù)據(jù)引用就足夠定位并重用原有結(jié)構(gòu)。

#4. 可擴(kuò)展性

無(wú)服務(wù)器：在無(wú)服務(wù)器架構(gòu)中，應(yīng)用程序后端會(huì)自動(dòng)且固有地進(jìn)行擴(kuò)展以滿足負(fù)載需求。另外，無(wú)服務(wù)器計(jì)算更像是自來(lái)水供應(yīng)系統(tǒng)：只要服務(wù)商把總閘打開，消費(fèi)者那邊就永遠(yuǎn)會(huì)有水可用，且只需要為自己家中龍頭里流出的水量付費(fèi)。相比之下，容器技術(shù)則更像是挨家挨戶配送的桶裝飲用水，在可擴(kuò)展性上顯然不及無(wú)服務(wù)器計(jì)算。

容器：在使用基于容器的架構(gòu)時(shí)，開發(fā)者需要根據(jù)需求提前部署相應(yīng)數(shù)量的容器，借此滿足應(yīng)用程序的擴(kuò)展申請(qǐng)。此外，隨著需求量增加，我們往往需要部署更多容器以應(yīng)對(duì)負(fù)載波動(dòng)。而在實(shí)際需求超過(guò)容器配置預(yù)期時(shí)，就必然要出現(xiàn)可擴(kuò)展性瓶頸、且沒(méi)有很好的即時(shí)解決辦法。

#5 可移植性與遷移

無(wú)服務(wù)器：假定大家已經(jīng)在使用AWS的多種不同服務(wù)，這時(shí)候選擇Lambda函數(shù)肯定是明智之舉，因?yàn)槠淠軌蚺c其他服務(wù)順暢集成且可支持快速訪問(wèn)。

即使您并沒(méi)有使用AWS服務(wù)、而且擔(dān)心供應(yīng)商鎖定問(wèn)題，也可以通過(guò)域映射/DNS變更等方式保證代碼中使用的所有API端點(diǎn)和URL始終處于您的控制之下。

這樣我們就可以隨時(shí)切斷特定服務(wù)，并將其重新定向至您所選定的其他端點(diǎn)（例如其他FaaS服務(wù)商）。這種方式顯然比在不受控制或者您無(wú)法調(diào)整的端點(diǎn)中部署硬編碼代碼要安全得多。

但考慮到市面上FaaS服務(wù)商眾多，大家對(duì)供應(yīng)商鎖定問(wèn)題的擔(dān)憂也自有道理。以Lambda為例，如果它無(wú)法滿足您所在地區(qū)的特定要求，大家可以執(zhí)行以下操作。一切Lambda處理程序的代碼都應(yīng)處于隔離狀態(tài)，僅僅以“墊片”的形式在其他模塊/類中充當(dāng)邏輯。

這種方式不僅提高了可重用性，而且能夠大大降低重構(gòu)時(shí)Lambda遷移的便捷度與直接性。另外，這種方式還有利于支持單元測(cè)試。下面來(lái)看瘦Lambda處理程序?qū)嵗?br style="box-sizing:border-box;" />
說(shuō)起遷移，目前人們對(duì)于如何將FaaS融入現(xiàn)有DevOps框架仍充當(dāng)爭(zhēng)議。組織可能一口氣編寫了幾百個(gè)函數(shù)，但在一段時(shí)間之后再也沒(méi)人清楚哪些函數(shù)中包含著哪些其他函數(shù)、又有多少函數(shù)仍在正常使用。

容器：如果大家選擇了基于容器的微服務(wù)架構(gòu)，就能享受到由此帶來(lái)的良好可移植性。我們可以輕松將程序代碼從開發(fā)者的筆記本電腦處轉(zhuǎn)移到本地?cái)?shù)據(jù)中心或者不同云服務(wù)商的云計(jì)算平臺(tái)，整個(gè)過(guò)程既不費(fèi)力也不費(fèi)神。

隨著企業(yè)承擔(dān)的創(chuàng)新壓力越來(lái)越大、產(chǎn)品上市時(shí)間越來(lái)越短，微服務(wù)架構(gòu)的加持能幫助大家快速為應(yīng)用程序建立起全新版本。因此，如果大家是出于降低遷移難度、使用豐富的容器技術(shù)堆棧等目的而決定從單體式應(yīng)用程序轉(zhuǎn)向容器，那么微服務(wù)架構(gòu)應(yīng)該是個(gè)理想的探索起點(diǎn)。

然而，在云平臺(tái)上運(yùn)行容器時(shí)仍然涉及眾多依賴項(xiàng)。例如代碼升級(jí)需要協(xié)同規(guī)劃，具體涵蓋容器主機(jī)、容器鏡像、容器引擎以及容器編排等。

對(duì)于某些需要遷移至微服務(wù)形式的遺留應(yīng)用程序，直接“容器化”所帶來(lái)的操作難度和成本往往要低于對(duì)整體應(yīng)用程序進(jìn)行重構(gòu)。

#6. 開發(fā)環(huán)境與語(yǔ)言支持

無(wú)服務(wù)器：主流FaaS服務(wù)商所能支持的語(yǔ)言種類非常有限，主要有Node.js、Python、Java、C#以及Go（以AWS Lambda為例）。

容器：容器能為大家提供良好的異構(gòu)開發(fā)環(huán)境、供您使用一切您所熟悉的技術(shù)堆棧。考慮到如今的開發(fā)者往往同時(shí)精通多種開發(fā)語(yǔ)言，這種廣泛的支持性在人員招聘層面往往極具優(yōu)勢(shì)。

如果大家正打算為新項(xiàng)目招聘開發(fā)人員，那容器能避免我們過(guò)多考慮微服務(wù)架構(gòu)中的語(yǔ)言選擇。不同微服務(wù)可以獨(dú)立部署、獨(dú)立擴(kuò)展，各服務(wù)之間擁有明確的模塊邊界，不同服務(wù)可以由任何語(yǔ)言編寫并由不同團(tuán)隊(duì)負(fù)責(zé)管理。

#7. 系統(tǒng)控制

無(wú)服務(wù)器：由于消除了基礎(chǔ)設(shè)施層面的復(fù)雜性，AWS Lambda等FaaS服務(wù)中的函數(shù)用起來(lái)可謂便捷順滑。這樣，大家可以更多專注于產(chǎn)品開發(fā)與業(yè)務(wù)成果實(shí)現(xiàn)。也就是說(shuō)，無(wú)服務(wù)器計(jì)算能夠顯著縮短產(chǎn)品的上市時(shí)間，但容器卻不然。但以AWS Lambda為例，無(wú)服務(wù)器計(jì)算在使用時(shí)有著諸多注意事項(xiàng)、一旦違反很可能引發(fā)問(wèn)題。

容器：容器方面的難題主要集中在集群配置上，這些嚴(yán)峻的挑戰(zhàn)要求我們具備扎實(shí)的容器技術(shù)背景。好在微服務(wù)層面的控制難度不算很高，而且Kubernetes等編排框架也能幫助我們提高架構(gòu)的治理與控制效率。

基于容器的微服務(wù)架構(gòu)讓我們掌握了對(duì)于容器系統(tǒng)的全面控制權(quán)，從而實(shí)現(xiàn)策略設(shè)置、資源分配與管理。此外，我們還能對(duì)安全和遷移服務(wù)進(jìn)行精細(xì)化控制。

而憑借這種完全控制特性，我們可以隨時(shí)通過(guò)容器系統(tǒng)查看容器內(nèi)外的基本情況，進(jìn)而跨越多種環(huán)境和大量資源開展全面且有效的測(cè)試與調(diào)試。相比之下，我們無(wú)法驗(yàn)證函數(shù)的本地實(shí)現(xiàn)與測(cè)試，所以很難提前判斷其運(yùn)行性能。

#8. 高強(qiáng)度資源處理

讓我們繼續(xù)以AWS Lambda為例，如果某一函數(shù)的處理時(shí)長(zhǎng)超過(guò)5分名，系統(tǒng)就會(huì)要求我們將該任務(wù)拆分成多個(gè)更小的任務(wù)。當(dāng)然，類似的限制要求還有很多。

大家最多可以為單一函數(shù)分配1.5 GB的內(nèi)存，而部署包則不能超過(guò)50 MB。但在容器方面，我們則可根據(jù)應(yīng)用程序的實(shí)際需求隨意分配計(jì)算資源。

#9. 測(cè)試

無(wú)服務(wù)器：我們往往很難對(duì)基于無(wú)服務(wù)器的Web應(yīng)用程序進(jìn)行測(cè)試，因?yàn)殚_發(fā)者通常無(wú)法在本地環(huán)境中重現(xiàn)這種實(shí)際后端環(huán)境。
容器：由于各容器運(yùn)行在部署時(shí)所處的同一平臺(tái)之上，我們可以相對(duì)簡(jiǎn)單地在生產(chǎn)部署之前對(duì)基于容器的應(yīng)用程序進(jìn)行各類測(cè)試。

#10. 維護(hù)

無(wú)服務(wù)器：無(wú)服務(wù)器類應(yīng)用程序的維護(hù)難度比大多數(shù)人想象中低得多。由于無(wú)服務(wù)器服務(wù)商（例如AWS Lambda）一力承擔(dān)起服務(wù)器的管理及軟件更新等日常事務(wù)，因此整體維護(hù)負(fù)擔(dān)會(huì)維持在很低的水平。

容器：與幫助開發(fā)者告別維護(hù)煩惱的無(wú)服務(wù)器不同，容器要求開發(fā)者們繼續(xù)承擔(dān)從管理到更新的所有容器維護(hù)工作。

#11. 成本比較

無(wú)服務(wù)器：之前已經(jīng)提到，使用AWS Lambda等無(wú)服務(wù)器函數(shù)進(jìn)行應(yīng)用程序部署能幫助大家擺脫不必要的資源開銷，確保應(yīng)用程序代碼只根據(jù)調(diào)用操作適時(shí)運(yùn)行。這種形式完全不同于以往大家熟悉的無(wú)論用不用、都要持續(xù)付費(fèi)的本地基礎(chǔ)設(shè)施系統(tǒng)。

容器：容器在成本方面表現(xiàn)得比較傳統(tǒng)，同樣是在沒(méi)人用時(shí)也始終保持運(yùn)行，所以客戶需要根據(jù)服務(wù)器空間向云服務(wù)商付費(fèi)。

#12. 部署時(shí)間

無(wú)服務(wù)器： 由于無(wú)服務(wù)器函數(shù)在體量上小于容器微服務(wù)，而且其中不捆綁任何系統(tǒng)依賴項(xiàng)，所以每款應(yīng)用程序的部署時(shí)長(zhǎng)只需要幾毫秒。另外，無(wú)服務(wù)器應(yīng)用程序能夠在代碼部署完成后立即上線。

容器：雖然容器的初始設(shè)置時(shí)間較長(zhǎng)，但在全面配置設(shè)定完成之后，后續(xù)部署也能在幾秒內(nèi)結(jié)束。

什么時(shí)候選無(wú)服務(wù)器？：無(wú)服務(wù)器用例解析

無(wú)服務(wù)器計(jì)算特別適合以下用例：

? 如果您的流量模式會(huì)自動(dòng)變化，那么無(wú)服務(wù)器計(jì)算不僅能自動(dòng)消解波動(dòng)、還能在沒(méi)有流量時(shí)暫時(shí)關(guān)閉。

? 如果大家擔(dān)心服務(wù)器的維護(hù)成本以及應(yīng)用程序消耗的資源，那就表明您適合選擇無(wú)服務(wù)器計(jì)算。

? 如果您不想花太多時(shí)間思考代碼在哪里運(yùn)行、具體怎么運(yùn)行，請(qǐng)選擇無(wú)服務(wù)器。

? 無(wú)服務(wù)器網(wǎng)站與應(yīng)用程序的編寫與部署流程不涉及任何基礎(chǔ)設(shè)施設(shè)置環(huán)節(jié)。因此，我們可以在幾天之內(nèi)通過(guò)無(wú)服務(wù)器計(jì)算構(gòu)建起功能完備的應(yīng)用程序或網(wǎng)站。

? 無(wú)服務(wù)器架構(gòu)允許您為應(yīng)用程序構(gòu)建起各類性能強(qiáng)勁的圖像與視頻服務(wù)。您可以使用這些服務(wù)動(dòng)態(tài)調(diào)整圖像大小，或者針對(duì)不同類型的目標(biāo)設(shè)備執(zhí)行視頻轉(zhuǎn)碼等。

什么時(shí)候選容器？：容器用例解析

以下幾種應(yīng)用程序部署需求特別適合選擇容器技術(shù)：

? 如果您想要自主選擇操作系統(tǒng)，并充分控制其中安裝的編程語(yǔ)言和運(yùn)行時(shí)版本。

? 如果您打算使用某些軟件的特定版本，那容器也是最好的選擇。

? 如果您之前一直在使用傳統(tǒng)大型服務(wù)器來(lái)處理Web API、機(jī)器學(xué)習(xí)計(jì)算以及其他各種需要長(zhǎng)時(shí)間運(yùn)行的業(yè)務(wù)流程，不妨試試容器——運(yùn)行效果基本一樣，而成本卻較傳統(tǒng)服務(wù)器更低。

? 如果您打算開發(fā)新的容器原生應(yīng)用程序。

? 如果您打算對(duì)某款體量龐大且極為復(fù)雜的單體式應(yīng)用程序進(jìn)行重構(gòu)，那最好選擇容器——容器更適合復(fù)雜的應(yīng)用結(jié)構(gòu)。

? 有些組織也在使用容器將現(xiàn)有應(yīng)用程序直接遷移至更為現(xiàn)代的環(huán)境當(dāng)中。Kubernetes等容器編排工具包含一系列明確的已知最佳實(shí)踐，能夠輕松管理大規(guī)模容器設(shè)置。

? Docker等容器編排平臺(tái)能夠通過(guò)自動(dòng)規(guī)模伸縮解決流量無(wú)法預(yù)測(cè)的問(wèn)題（但請(qǐng)注意，容器的規(guī)模伸縮過(guò)程無(wú)法即時(shí)完成）。

小結(jié)

聊了這么多，大家到底會(huì)做何選擇？看起來(lái)無(wú)服務(wù)器和容器各有各的優(yōu)勢(shì)。根據(jù)具體用例，兩者都有可能成為最佳或者最差的解決方案，所以咱們最好別抱任何心理預(yù)設(shè)。

如果您的現(xiàn)有應(yīng)用程序體量很大而且運(yùn)行在本地，那么不妨先把它遷移到容器當(dāng)中，之后再把某些組件轉(zhuǎn)換為函數(shù)。而如果您已經(jīng)擁有完全基于微服務(wù)架構(gòu)的應(yīng)用程序而且不介意供應(yīng)商鎖定問(wèn)題，那直接選擇無(wú)服務(wù)器也挺好。

無(wú)論如何，無(wú)服務(wù)器架構(gòu)那獨(dú)一無(wú)二的成本效益值得每位朋友認(rèn)真考量。

總而言之，我們不能說(shuō)無(wú)服務(wù)器的出現(xiàn)就意味著容器技術(shù)的消亡，至少短期之內(nèi)不能。而且容器與無(wú)服務(wù)器也在各自的道路上不斷發(fā)展，二者相互競(jìng)爭(zhēng)、持續(xù)演變出新形態(tài)才是我們消費(fèi)者最樂(lè)于看到的未來(lái)。