虛擬機(jī)、容器和無服務(wù)器架構(gòu)都有明顯的優(yōu)缺點，但如果應(yīng)用程序不適合無服務(wù)器計算，這種部署架構(gòu)可能會破壞一切。為了防止IT出現(xiàn)災(zāi)難，就要讓開發(fā)人員對無服務(wù)器與容器進(jìn)行合理的評估，以便從中選擇一種來部署新的應(yīng)用程序。

    想確定容器或無服務(wù)器計算哪個適合，就要比較每一種架構(gòu)的功能、它將托管的應(yīng)用程序的用戶群以及成功部署所需的要素。

    雖然虛擬機(jī)不在本文討論范圍之內(nèi)，卻是IT部門中最常使用、最廣人為知的應(yīng)用程序托管架構(gòu)。它是最普遍的基礎(chǔ)設(shè)施抽象方法，不過缺點是很復(fù)雜和資源開銷大。本文主要比較無服務(wù)器計劃與容器，前者完全抽取資源，后者是操作系統(tǒng)上一個輕量、快速的隔離層。

應(yīng)用程序需要什么？

    無服務(wù)器云計算的經(jīng)濟(jì)效益在于，企業(yè)只需要在應(yīng)用程序運行時為計算資源和應(yīng)用程序的執(zhí)行時段付費，空閑時段無需付費。無服務(wù)器最適合必須總是準(zhǔn)備好，但不總是在運行的應(yīng)用程序和組件。

圖1：亞馬遜網(wǎng)絡(luò)服務(wù)（AWS）上的無服務(wù)器計算架構(gòu)顯示了無服務(wù)器如何將應(yīng)用程序與支持它們的硬件隔離開來

    比如說，濕度傳感器表明土壤干燥、需要澆水時，物聯(lián)網(wǎng)農(nóng)業(yè)應(yīng)用程序生成事件。這種傳統(tǒng)部署環(huán)境中的應(yīng)用程序可能在下雨的天氣中處于空閑狀態(tài)，等待被激活，耗用不必要的資源。而容器系統(tǒng)可以減少應(yīng)用程序消耗的資源數(shù)量，但無服務(wù)器計算可以在空閑期間消除資源。應(yīng)用程序空閑的時間越長，無服務(wù)器的優(yōu)點就越大。是不是很簡單？

    與往常一樣，實際情況要來得復(fù)雜。無服務(wù)器架構(gòu)的好處包括，可以在幾毫秒內(nèi)讓這個示例物聯(lián)網(wǎng)應(yīng)用程序準(zhǔn)備好，而不是像容器化系統(tǒng)那樣需要幾十秒，但容器化部署比較長的啟動時間不太可能影響物聯(lián)網(wǎng)應(yīng)用程序?qū)崿F(xiàn)其用途的能力。并不是空閑時間多于活動時間的每個應(yīng)用程序都適合無服務(wù)器。無服務(wù)器系統(tǒng)邏輯不僅費用比容器系統(tǒng)來得高，而且技術(shù)上也不同。

無服務(wù)器vs容器技術(shù)

    如果你深入研究無服務(wù)器的細(xì)節(jié)時，會發(fā)現(xiàn)如下術(shù)語：

• 微服務(wù)：應(yīng)用程序分解為多個更小、可獨立擴(kuò)展和部署的組件；
• 函數(shù)計算：負(fù)責(zé)托管的云按需執(zhí)行應(yīng)用程序函數(shù)，函數(shù)作為一項服務(wù)；
• lambda函數(shù)：這種匿名C++函數(shù)轉(zhuǎn)換傳遞給它們的數(shù)據(jù)集合，然后生成新的集合；
• 無狀態(tài)：不使用或不需要來自之前使用事件的數(shù)據(jù)的應(yīng)用程序。

    無服務(wù)器云計算旨在實現(xiàn)與上下文無關(guān)的處理，面向無狀態(tài)應(yīng)用程序。當(dāng)無服務(wù)器應(yīng)用程序被事件激活后，它們從根本不記得過去的代碼副本開始，依賴之前出現(xiàn)的事件或請求的任何事件都是有狀態(tài)的。如果你啟動第二個無服務(wù)器架構(gòu)副本來處理更多的工作，這第二個副本就不會自動知道第一個副本一直在做什么。

    可以通過客戶端或后端狀態(tài)控制，讓有狀態(tài)應(yīng)用程序在無服務(wù)器部署中環(huán)境運行，但這必須寫入到應(yīng)用程序的代碼中。這種選擇可能不會存在于第三方軟件中。即使某企業(yè)的應(yīng)用程序是內(nèi)部編寫的，想在無服務(wù)器部署環(huán)境中實現(xiàn)有狀態(tài)行為也需要可能復(fù)雜而昂貴的更改。

圖2：Docker容器托管模式將應(yīng)用程序代碼從底層的硬件資源中抽取出來

    容器可以運行幾乎任何應(yīng)用程序或應(yīng)用程序組件，無需對代碼進(jìn)行重大更改。而無服務(wù)器做不到這點。大多數(shù)業(yè)務(wù)應(yīng)用程序執(zhí)行事務(wù)處理，其中一個或多個數(shù)據(jù)庫被更新，這給無狀態(tài)行為提出了更艱巨的挑戰(zhàn)。事務(wù)處理應(yīng)用程序無狀態(tài)會導(dǎo)致事務(wù)沖突：針對庫存或賬戶余額的兩個查詢獨立報告銷售或取款，結(jié)果卻發(fā)生沖突，導(dǎo)致余額在零以下。企業(yè)可以結(jié)合無狀態(tài)行為和事務(wù)行為，重新設(shè)計或改造應(yīng)用程序，但這是個復(fù)雜的過程，需要經(jīng)驗和大量工作。容器則沒有這個要求。

連接到現(xiàn)實

    開發(fā)人員將無服務(wù)器與容器視作哪個最適合應(yīng)用程序的問題，但他們也要權(quán)衡每種方案的部署問題。容器網(wǎng)絡(luò)是顯式的，基于IP子網(wǎng)絡(luò)，這是最常見的應(yīng)用程序部署模式。容器系統(tǒng)在應(yīng)用程序中使用專有的IP地址空間，但管理員可以選擇性地公開組件地址，向虛擬專用網(wǎng)絡(luò)或互聯(lián)網(wǎng)上的用戶或其他應(yīng)用程序提供服務(wù)。如果使用無服務(wù)器計算，負(fù)載均衡和網(wǎng)絡(luò)尋址以及其他操作方面由無服務(wù)器云框架處理，你可能需要采取特殊步驟，將無服務(wù)器組件與托管在數(shù)據(jù)中心中較傳統(tǒng)的云上的應(yīng)用程序組件集成起來。

    容器需要一個長期的托管位置，而無服務(wù)器不需要。容器可以支持廣泛的社區(qū)訪問應(yīng)用程序和服務(wù)，響應(yīng)時間良好，但前提是你在每個地理區(qū)域都部署副本。這種部署模式可以劃分工作，在各應(yīng)用程序副本之間創(chuàng)建更多的閑置時間，從而增加成本。相比之下，只要有可用資源，無服務(wù)器應(yīng)用程序就可以在任何地方運行工作負(fù)載的任意數(shù)量的副本。

如何托管微服務(wù)？

    微服務(wù)是可以獨自共享和擴(kuò)展的分布式應(yīng)用程序代碼的獨立式組件，適合部署在容器中和無服務(wù)器云上。差異化因素歸結(jié)為你有哪種類型的微服務(wù)。由于微服務(wù)是無狀態(tài)的，因此適合無服務(wù)器部署。但是，微服務(wù)常常是多個應(yīng)用程序共享的通用組件。當(dāng)微服務(wù)被組合到幾個不同的應(yīng)用程序中時，容器托管是比無服務(wù)器更好的一種部署選擇。由于按需部署無服務(wù)器組件的請求，無服務(wù)器微服務(wù)經(jīng)常使用的話，會導(dǎo)致應(yīng)用程序的響應(yīng)時間大幅延長。

    無服務(wù)器會不斷發(fā)展，但無服務(wù)器與容器在技術(shù)和成本管理這兩個層面都有明顯差異。在某些情況下，這些差異會讓企業(yè)選擇一個、而不是另一個來得很容易；而在另一些情況下，應(yīng)用程序規(guī)劃人員必須采用混合模式，盡管這增加了一點復(fù)雜性。畢竟不存在一應(yīng)俱全式的方案。