2022年即將到來(lái)，如同DevOps浪潮中的大多數(shù)趨勢(shì)一樣，選無(wú)服務(wù)器還是選容器已經(jīng)成為困擾無(wú)數(shù)從業(yè)者的應(yīng)用程序部署難題。而且從目前的情況看，這場(chǎng)決定軟件開發(fā)思路的大討論恐怕不會(huì)很快結(jié)束。

然而，這場(chǎng)關(guān)于無(wú)服務(wù)器與容器的比較，核心究竟是什么?到底是在爭(zhēng)二者誰(shuí)更流行，還是說(shuō)有人覺得無(wú)服務(wù)器只是容器的某種替代品?更有甚者，似乎有些人認(rèn)為無(wú)服務(wù)器只是適用于容器環(huán)境的一種常規(guī)技術(shù)。

在本文中，我們將對(duì)這兩項(xiàng)技術(shù)做出詳盡比較，希望真正較量出個(gè)高下。但如果沒有明確的勝負(fù)，我們至少也要弄清楚二者有哪些共同點(diǎn)與區(qū)別、各自適合哪些應(yīng)用用例。閑言少敘，讓我們先從背景信息聊起。

[[441778]]

我們?yōu)槭裁葱枰獰o(wú)服務(wù)器計(jì)算?

多年以來(lái)，我們一直習(xí)慣于把應(yīng)用程序部署在大型服務(wù)器之上。而由此帶來(lái)的資源管理或供應(yīng)責(zé)任自然全部由我們自己承擔(dān)。這種方式帶來(lái)了以下幾個(gè)問題：

• 即使完全沒有任何負(fù)載需求，服務(wù)器也在持續(xù)運(yùn)行，因此會(huì)消耗大量不必要的資源。
• 需要負(fù)責(zé)完成服務(wù)器維護(hù)以及正常運(yùn)行時(shí)間保障等日常工作。
• 需要負(fù)責(zé)對(duì)服務(wù)器進(jìn)行適當(dāng)?shù)陌踩隆?/li>
• 隨著使用量的增加，我們需要親自管理服務(wù)器擴(kuò)展工作;與之對(duì)應(yīng)，當(dāng)工作負(fù)載回落，我們又得進(jìn)行規(guī)模收縮。

面對(duì)這么多現(xiàn)實(shí)問題，中小型企業(yè)乃至個(gè)人顯然不愿意、甚至沒辦法投入相應(yīng)的精力。另外，傳統(tǒng)服務(wù)器模式的上述特性還會(huì)影響產(chǎn)品的整體上市時(shí)間與交付成本，而這些正是決定定制化軟件開發(fā)命運(yùn)的核心所在。

“無(wú)服務(wù)器計(jì)算”的概念于是應(yīng)愿而生。借助無(wú)服務(wù)器計(jì)算，我們可以獲得一套執(zhí)行模型，由云服務(wù)商(包括AWS、Azure或者Google Cloud)通過動(dòng)態(tài)分配的資源執(zhí)行一段段代碼。作為用戶，我們只需要承擔(dān)應(yīng)用程序代碼運(yùn)行所對(duì)應(yīng)的資源用量費(fèi)用。如果把這種計(jì)算成本與傳統(tǒng)服務(wù)器相比較，我們會(huì)發(fā)現(xiàn)支出將得到大幅削減。這樣，我們的整體計(jì)算體驗(yàn)將達(dá)成“無(wú)服務(wù)器”狀態(tài)(服務(wù)器資源的管理成本更低)。所以再次強(qiáng)調(diào)，無(wú)服務(wù)器不是沒有服務(wù)器——基礎(chǔ)設(shè)施還在，只是不再困擾我們。

我們?yōu)槭裁葱枰萜骰?

容器化的必要性，在于它解決了一個(gè)重要問題：確保軟件在某一計(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)看容器中常見的幾種綁定要素：

• 應(yīng)用程序本體
• 依賴項(xiàng)
• 庫(kù)
• 二進(jìn)制文件
• 配置文件

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

下圖所示，為容器化技術(shù)的基本工作原理：

既然無(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ù)使用。沒有了緩存機(jī)制，其延遲水平也就更高。

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

確實(shí)重要，因?yàn)槿绻萜鲗⒁谀繕?biāo)文件上生成的對(duì)象之前就曾經(jīng)出現(xiàn)過，那么直接重用原有結(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ì)算必然存在延遲問題。為此，大家可以添加以下代碼使得函數(shù)始終“保溫”。

但這畢竟只是權(quán)宜之計(jì)，只適用于函數(shù)數(shù)量不大的場(chǎng)景。面對(duì)數(shù)量眾多的大規(guī)模系統(tǒng)，我們根本無(wú)法正確管理所有虛擬函數(shù)。所以以上方法只適用于函數(shù)數(shù)量較少，沒必要驚動(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í)際需求超過容器配置預(yù)期時(shí)，就必然要出現(xiàn)可擴(kuò)展性瓶頸、且沒有很好的即時(shí)解決辦法。

5 可移植性與遷移

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

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

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

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

這種方式不僅提高了可重用性，而且能夠大大降低重構(gòu)時(shí)Lambda遷移的便捷度與直接性。另外，這種方式還有利于支持單元測(cè)試。下面來(lái)看瘦Lambda處理程序?qū)嵗?/p>

說(shuō)起遷移，目前人們對(duì)于如何將FaaS融入現(xiàn)有DevOps框架仍充當(dāng)爭(zhēng)議。組織可能一口氣編寫了幾百個(gè)函數(shù)，但在一段時(shí)間之后再也沒人清楚哪些函數(shù)中包含著哪些其他函數(shù)、又有多少函數(shù)仍在正常使用。

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

容器：容器方面的難題主要集中在集群配置上，這些嚴(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í)通過容器系統(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)超過5分名，系統(tǒng)就會(huì)要求我們將該任務(wù)拆分成多個(gè)更小的任務(wù)。當(dāng)然，類似的限制要求還有很多。

大家最多可以為單一函數(shù)分配1.5 GB的內(nèi)存，而部署包則不能超過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)，同樣是在沒人用時(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)、還能在沒有流量時(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)通過無(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)能夠通過自動(dòng)規(guī)模伸縮解決流量無(wú)法預(yù)測(cè)的問題(但請(qǐng)注意，容器的規(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ú)服務(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ái)。