無服務(wù)vs容器，2022誰來稱霸？

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

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

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

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

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

? 即使完全沒有任何負(fù)載需求，服務(wù)器也在持續(xù)運行，因此會消耗大量不必要的資源。

? 需要負(fù)責(zé)完成服務(wù)器維護(hù)以及正常運行時間保障等日常工作。

? 需要負(fù)責(zé)對服務(wù)器進(jìn)行適當(dāng)?shù)陌踩隆?/p>

? 隨著使用量的增加，我們需要親自管理服務(wù)器擴(kuò)展工作；與之對應(yīng)，當(dāng)工作負(fù)載回落，我們又得進(jìn)行規(guī)模收縮。

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

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

我們?yōu)槭裁葱枰萜骰?/p>

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

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

下面來看容器中常見的幾種綁定要素：

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

? 依賴項

? 庫

? 二進(jìn)制文件

? 配置文件

但為了管理這些容器，我們還需要仰仗另一套專用軟件，例如Docker Swarm、Kubernetes等等。這些軟件可以幫助我們編排容器，將其正確推送至不同的目標(biāo)設(shè)備并保證它們在那里順暢運行。

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

#1.壽命限制

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

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

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

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

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

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

容器：在容器一邊，我們倒是可以充分發(fā)揮緩存優(yōu)勢。為了保證即使在容器終止后數(shù)據(jù)仍能正常存儲，我們需要一種存儲機(jī)制來容納容器之外的數(shù)據(jù)。說到這里，有些朋友可能要問，緩存有那么重要嗎？為什么我們在討論中總要提起緩存？

確實重要，因為如果容器將要在目標(biāo)文件上生成的對象之前就曾經(jīng)出現(xiàn)過，那么直接重用原有結(jié)果能夠節(jié)約下大量時間。而這些原有結(jié)果正是要由緩存來存放。所以在緩存的加持下，新容器能獲得極快的構(gòu)建速度。

#3. 無延遲與啟動時間

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

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

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

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

#4. 可擴(kuò)展性

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

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

#5 可移植性與遷移

無服務(wù)器：假定大家已經(jīng)在使用AWS的多種不同服務(wù)，這時候選擇Lambda函數(shù)肯定是明智之舉，因為其能夠與其他服務(wù)順暢集成且可支持快速訪問。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#8. 高強度資源處理

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

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

#9. 測試

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

#10. 維護(hù)

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

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

#11. 成本比較

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

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

#12. 部署時間

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

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

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

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

? 如果您的流量模式會自動變化，那么無服務(wù)器計算不僅能自動消解波動、還能在沒有流量時暫時關(guān)閉。

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

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

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

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

什么時候選容器？：容器用例解析

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

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

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

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

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

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

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

? Docker等容器編排平臺能夠通過自動規(guī)模伸縮解決流量無法預(yù)測的問題（但請注意，容器的規(guī)模伸縮過程無法即時完成）。

小結(jié)

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

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

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

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