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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

連接到現(xiàn)實(shí)

    開發(fā)人員將無服務(wù)器與容器視作哪個(gè)最適合應(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ù)器計(jì)算，負(fù)載均衡和網(wǎng)絡(luò)尋址以及其他操作方面由無服務(wù)器云框架處理，你可能需要采取特殊步驟，將無服務(wù)器組件與托管在數(shù)據(jù)中心中較傳統(tǒng)的云上的應(yīng)用程序組件集成起來。

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

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

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

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