[[345172]]

【51CTO.com快譯】無服務(wù)器計算和容器是用來減少云托管應(yīng)用開銷的兩種架構(gòu)。不過它們在許多重要的方面都有所不同。容器比虛擬機“輕”，而無服務(wù)器部署比容器更“輕”，并且更容易擴展。在本文中，我們將和您討論無服務(wù)器計算和容器之間的區(qū)別，以及該如何進行選擇。

無服務(wù)器

在傳統(tǒng)的應(yīng)用開發(fā)實踐中，為了將程序部署到服務(wù)器上，以供用戶使用，我們往往需要經(jīng)歷規(guī)劃容量，采購硬件，安裝軟件，以及準(zhǔn)備應(yīng)用等環(huán)節(jié)。這些通常需要一周到幾個月的時間。再加上應(yīng)用的初期運營，這可謂既耗時又費力。

隨著按需使用的云服務(wù)廣泛流行，我們解決問題的能力逐漸增強。雖然資本性支出(CAPEX)和運營性支持(OPEX)仍會產(chǎn)生成本，但是我們在容量規(guī)劃、部署時間、以及硬件管理上的花銷將大幅減少。其中，最典型的云計算應(yīng)用便是無服務(wù)器。

無服務(wù)器可以被定義為一種方法。該方法用短暫的計算能力代替了長時間運行的計算提供機制。此類臨時計算力只是按需而存在的，并且會在使用完畢后立即消失。

當(dāng)然，無服務(wù)器并不意味著真的沒有服務(wù)器，而是我們不需要管理服務(wù)器。也就是說，由于我們在由AWS、Google或Azure等云計算供應(yīng)商，所提供的硬件上運行自己的服務(wù)，因此，我們將服務(wù)器的維護委托給了第三方(通常是云計算供應(yīng)商)，由它們根據(jù)需求將資源分配到服務(wù)器上，以便我們專注于開發(fā)運行所需的服務(wù)。

實際上，無服務(wù)器計算是一種執(zhí)行模型。在該模型中，硬件是由云計算供應(yīng)商管理的。無服務(wù)器無需預(yù)定義的硬件，只要在執(zhí)行時觸發(fā)和獲取硬件資源，并在執(zhí)行完成后停止已獲取的硬件，直到觸發(fā)另一個動作為止。例如，某個內(nèi)容管理應(yīng)用可以讓用戶將圖像上傳到自己撰寫的文章中。如果我們處于使用了AWS Lambda來構(gòu)建的無服務(wù)器架構(gòu)中，那么圖像將首先被上傳到S3存儲桶處，并觸發(fā)一個事件。該觸發(fā)器會調(diào)用一個用多種編程語言編寫的AWS Lambda函數(shù)，來調(diào)整圖像的大小，并對其進行壓縮，以適合多種設(shè)備的顯示?？梢姡捎|發(fā)事件調(diào)用的AWS Lambda代碼或功能，會在云計算提供商所提供的硬件上執(zhí)行。完畢后該硬件會處于停止?fàn)顟B(tài)，并等待其他的觸發(fā)器。

功能即服務(wù)(Faas)

為了能夠動態(tài)創(chuàng)建和管理服務(wù)器，開發(fā)人員需要以功能函數(shù)的形式編寫應(yīng)用代碼。也就是說，根據(jù)無服務(wù)器計算的Faas概念，軟件開發(fā)人員可以無需編寫基礎(chǔ)架構(gòu)的代碼，而只專注于編寫和部署那些單獨的、能夠在毫秒內(nèi)處理請求的各種功能、操作、以及業(yè)務(wù)邏輯。而讓云計算提供商調(diào)配與管理服務(wù)器，以及代為執(zhí)行的功能代碼。

值得注意的是：在部署功能時，我們需要以一種事件的形式來進行調(diào)用。該事件可以是來自API網(wǎng)關(guān)(HTTP請求)的任何時間、另一個無服務(wù)器功能的事件、或是S3之類另一個云計算的事件。

無服務(wù)器提供商

目前，大多數(shù)主流云計算提供商都擁有自己的無服務(wù)器產(chǎn)品。其中，AWS Lambda于2014年率先推出了首款成熟的無服務(wù)器框架。它不但支持諸如Node.js、Java、Python和C#等多種編程語言，而且能與許多其他AWS服務(wù)相集成。

當(dāng)然，您也可以選用Google Cloud Functions、Microsoft的Azure功能、IBM的OpenWhisk(開源的無服務(wù)器平臺)，以及Iron.io和Webtask等。

無服務(wù)器的優(yōu)缺點

我們首先來看看無服務(wù)器能夠為開發(fā)人員提供的優(yōu)點：

• 按使用付費：由于我們僅為那些在服務(wù)器上執(zhí)行代碼的時間付費，因此那些空閑的服務(wù)器時間是不計費的。
• 彈性：利用無服務(wù)器架構(gòu)，應(yīng)用程序可以自動擴展，以適應(yīng)流量的激增，并在用戶較少的情況下自行縮減。
• 花費在管理上的時間和費用更少：正是由于云計算接手了基礎(chǔ)架構(gòu)，以及服務(wù)的縮放，因此用戶不但能夠花費更少的時間與資源，還能夠?qū)Ｗ⒂谧陨淼臉I(yè)務(wù)。
• 減少開發(fā)并縮短上市的時間：開發(fā)人員和組織擁有更多的時間來專注于構(gòu)建產(chǎn)品，并將其發(fā)布到市場上;云計算供應(yīng)商則負(fù)責(zé)保護與修補操作系統(tǒng)。
• 微服務(wù)方法：通過微服務(wù)方法，開發(fā)人員可以構(gòu)建出模塊化、功能專一、且松耦合的軟件。此類軟件比整體應(yīng)用要更加靈活、且更易于管理。

當(dāng)然，無服務(wù)器計算也存在著如下缺點：

• 供應(yīng)商鎖定和透明度降低：這是向云端無服務(wù)器遷移的主要問題之一。由于后端完全由云計算供應(yīng)商進行管理，一旦我們將現(xiàn)有的功能移至其他云服務(wù)平臺，則會導(dǎo)致應(yīng)用程序的重大更改。此類更改不僅僅是代碼層面上的，那些與之關(guān)聯(lián)的數(shù)據(jù)庫、訪問管理、存儲等其他服務(wù)，也會涉及到向其他平臺的移植和更改的問題。
• 支持的編程語言：由于特定功能需用相應(yīng)的語言編寫，因此它無法支持所有的語言。例如：AWS Lambda只直接支持Java、C#、Python和Node.js(JavaScript)，Google Cloud Functions只與Node.js配合使用，Microsoft Azure Functions與JavaScript、C#、F#、Python和PHP配合使用，而IBM OpenWhisk只支持JavaScript、Python、Java和Swift。
• 不適合需要長時間運行的任務(wù)：由于此類功能在本質(zhì)上是基于事件的，因此它們不太適合長時間運行的任務(wù)。例如：Lambda的超時限制為15分鐘。而在其他無服務(wù)器平臺上，時限為9分鐘到60分鐘不等。在實際應(yīng)用場景中，長時間運行的流程用例有許多種，例如：視頻處理、大數(shù)據(jù)分析、批量數(shù)據(jù)轉(zhuǎn)換、批處理事件、長期同步的請求和統(tǒng)計計算等。顯然，這些情況都不太適合無服務(wù)器計算。
• 難以調(diào)試：僅部分工具可以進行遠程調(diào)試，而像Azure之類的服務(wù)僅提供鏡像的本地開發(fā)環(huán)境。
• 隱藏成本：功能調(diào)用的自動縮放往往意味著成本的自動縮放。而這可能會使您難以衡量自己的業(yè)務(wù)成本。
• 需要更好的工具：為了跟蹤已部署的大量功能，我們往往需要借助一些更好的工具，例如：針對開發(fā)的腳本、框架;針對診斷的逐步調(diào)試、本地運行時;以及針對云端調(diào)試和可視化的用戶界面、分析和監(jiān)控。
• 響應(yīng)應(yīng)用事件延遲的較高：由于硬件在相當(dāng)長的一段時間內(nèi)處于空閑狀態(tài)，并且功能僅在觸發(fā)時運行，因此服務(wù)器可能需要一段時間才能喚醒并提供功能服務(wù)。
• 學(xué)習(xí)曲線：我們需要將傳統(tǒng)的整體應(yīng)用轉(zhuǎn)換為微服務(wù)，再將其編寫為功能。這些都需要我們深入了解架構(gòu)及其工作原理。

容器

容器是操作系統(tǒng)虛擬化的一種方法，可以讓用戶在資源隔離的進程中，運行某個應(yīng)用程序及其依賴項。其中，容器包含了應(yīng)用程序及其需要正常運行的所有依賴項，即：系統(tǒng)庫、系統(tǒng)設(shè)置和其他文件。因此，無論在何處托管的應(yīng)用，容器化應(yīng)用都能夠以相同的方式運行在容器中。

軟件從一個計算環(huán)境輕松地轉(zhuǎn)移和部署到另一個計算環(huán)境時，容器能夠保障其可靠地運行。這種轉(zhuǎn)移既可能是從開發(fā)人員的筆記本電腦到測試環(huán)境，也可能是從過渡環(huán)境到生產(chǎn)環(huán)境，還可能是從數(shù)據(jù)中心的物理機到私有或公共云中的虛擬機。

由于容器需要硬件才能運行，因此構(gòu)建硬件并在其上部署容器便是我們的責(zé)任。具體說來，容器會通過在機器上劃分出單獨的用戶空間，以便在每個環(huán)境中僅運行一個應(yīng)用。而多個用戶空間環(huán)境則可以共享主機的內(nèi)核與硬件。也就是說，主機的內(nèi)核將負(fù)責(zé)為容器提供必要的內(nèi)存、CPU和其他硬件。

容器使您可以輕松地將應(yīng)用代碼、配置和依賴項，打包到那些易用的構(gòu)建塊中，以提高環(huán)境的一致性、運營效率、開發(fā)人員生產(chǎn)力、以及版本控制。容器可以對資源進行精細化的控制，從而提高整體架構(gòu)的效率。

容器的優(yōu)點

• 增強的可移植性：容器的主要優(yōu)點是，我們可以將應(yīng)用程序及其所有依賴項，組合到一個小的程序包中，以便在任何地方運行。這種靈活性和可移植性，方便了應(yīng)用被輕松地部署到多個不同的操作系統(tǒng)和硬件平臺上。
• 與供應(yīng)商無關(guān)：容器并不依賴于某個云計算供應(yīng)商。我們創(chuàng)建好基本應(yīng)用和依賴項的映像后，便可在任何地方運行它們。
• 完全控制應(yīng)用程序：由于團隊負(fù)責(zé)打包應(yīng)用程序及其依賴項，因此他們擁有完全的控制權(quán)。
• 大型和復(fù)雜的應(yīng)用：我們可以將大型且復(fù)雜的應(yīng)用打包，并在容器中運行。
• 可擴展性：在我們的控制下，容器可以根據(jù)其基礎(chǔ)架構(gòu)，進行最大程度的擴展。
• 安全靈活性：在設(shè)置策略、管理資源和安全性方面，我們對容器具有完全的靈活性和控制能力。
• 更少的開銷：由于不包含任何操作系統(tǒng)的鏡像，因此容器比傳統(tǒng)的硬件或虛擬機環(huán)境需要更少的系統(tǒng)資源。
• 一致性的操作：無論它們被部署在何處，DevOps團隊總能確保應(yīng)用程序在容器中的相同位置運行。
• 更高的效率：容器使應(yīng)用程序可以更快地進行部署、修補或擴展。

容器的缺點

• 性能開銷：容器不會以裸機(bare-metal)的速度運行。雖然容器比虛擬機更能有效地利用資源，但是鑒于其覆蓋的網(wǎng)絡(luò)，容器與主機系統(tǒng)之間的接口，因此它仍然會產(chǎn)生性能開銷。
• 不支持圖形界面：Docker容器被設(shè)計為，可用于部署無需圖形界面的服務(wù)器應(yīng)用解決方案。雖然我們可以使用諸如X11視頻轉(zhuǎn)發(fā)之類創(chuàng)造性策略，在容器內(nèi)運行GUI應(yīng)用程序，但是這些方案并不太好用。
• 管理：我們通過管理容器和配置來完成工作，但是如果沒有協(xié)調(diào)工具，我們將難以輕松地管理容器的擴展。
• 安全性：安全性是容器的最大問題。由于容器沒有內(nèi)核，因此它需要通過主機的內(nèi)核，來進行硬件通信。如果容器內(nèi)運行的應(yīng)用存在缺陷，則會產(chǎn)生安全漏洞。
• 并非所有應(yīng)用都能受益：通常，只有那些被作為一組離散微服務(wù)運行的應(yīng)用，才能從容器模式中獲益。
• 監(jiān)控：隨著應(yīng)用的發(fā)展，越來越多的容器會被添加進來。而我們很難合理監(jiān)控這些高度分散且持續(xù)變化的容器。
• 減慢開發(fā)進程：在每次更改代碼庫時，我們都需要打包容器，并確保所有容器在部署到生產(chǎn)環(huán)境之前都能夠正確地通信。同時，我們也需要通過頻繁的安全修復(fù)、以及其他修補程序，使容器的操作系統(tǒng)能夠保持最新。

無服務(wù)器與容器

無服務(wù)器和容器縱然有著許多共同點，下面我們來看看它們之間的主要區(qū)別：

• 服務(wù)器空間：由于無服務(wù)器計算實際上是運行在服務(wù)器上，因此它需要云計算供應(yīng)商決定是否需要供應(yīng)和調(diào)整服務(wù)器空間，而不會為特定的功能或應(yīng)用分配特定的機器。而容器則位于預(yù)先配置、并準(zhǔn)備就緒的機器上。
• 部署：在無服務(wù)器計算中，部署并運行某項功能是由云計算供應(yīng)商負(fù)責(zé)的。每當(dāng)某個功能需要被觸發(fā)并執(zhí)行時，它會被部署到供應(yīng)商的已知服務(wù)器上。而在容器中，開發(fā)人員需要負(fù)責(zé)部署容器，并使容器保持運行的狀態(tài)。
• 彈性：供應(yīng)商會根據(jù)負(fù)載，考慮在無服務(wù)器中擴展對應(yīng)的功能。而對于容器的擴展，則需要通過增加容器數(shù)量，來進行人動干預(yù)。隨著容器編排(orchestration)平臺的引入，諸如kubernetes之類編排引擎會自動根據(jù)負(fù)載的增加擴展容器。
• 按使用付費：無服務(wù)器的優(yōu)勢是價格。在觸發(fā)功能時，我們只需支付執(zhí)行該功能所需的時間和資源。而容器需要持續(xù)處于正常運行狀態(tài)，因此費用往往更高。
• 維護：在無服務(wù)器架構(gòu)中，開發(fā)團隊無需管理后端，而由供應(yīng)商負(fù)責(zé)對運行代碼的服務(wù)器進行管理和軟件更新。在容器方面，開發(fā)團隊有責(zé)任保持硬件的更新、修補和維護。
• 測試：由于很難在本地計算機上復(fù)制后端環(huán)境，因此我們很難在本地測試無服務(wù)器的功能。而無論容器被部署在何處，它都可以在本地計算機上被輕松地測試和運行。
• 擴展的成本：容器技術(shù)能夠按需擴展應(yīng)用。而無服務(wù)器有時可能會面臨空間和內(nèi)存限制。
• 緩慢地擴展：無服務(wù)器的擴展是由供應(yīng)商完成的，而容器的擴展則由應(yīng)用開發(fā)團隊來負(fù)責(zé)和定義。因此與無服務(wù)器相比，容器的擴展速度較慢。
• 支持編程語言：無服務(wù)器無法支持所有的編程語言。而我們可以使用任何編程語言來構(gòu)建容器。我們只需編寫代碼，與資源庫一起打包，并在容器中運行即可。
• 長時間運行的任務(wù)：如前所述，無服務(wù)器計算不太適合長時間運行的任務(wù)。而容器則可以運行任何類型的應(yīng)用程序或任務(wù)。
• 開發(fā)時間：使用無服務(wù)器，我們只需考慮編寫代碼，其余部分都將由供應(yīng)商來負(fù)責(zé)。而容器則涉及到諸如構(gòu)建映像、移植等其他工作。
• 監(jiān)控：供應(yīng)商通過工具，來監(jiān)控?zé)o服務(wù)器各項功能的執(zhí)行、以及響應(yīng)時間等。而在容器中，開發(fā)團隊需要通過安裝監(jiān)控工具，來捕獲各種詳細的信息。

選擇哪種架構(gòu)?

總的說來，無服務(wù)器和容器并不構(gòu)成競爭關(guān)系，它們同屬云計算動態(tài)架構(gòu)，都可根據(jù)不同的需求，用于部署微服務(wù)。

何時該使用容器?

容器最適合用于運行較長的流程。在這些流程中，您需要對環(huán)境進行高度控制，并且擁有足夠的資源來設(shè)置和維護應(yīng)用程序。同時，云容器也是遷移單體式傳統(tǒng)式(monolithic legacy)應(yīng)用的最佳方法。我們可以將這些應(yīng)用分解成為容器化的微服務(wù)，然后使用kubernetes或swarm等引擎進行編排(orchestrate)。

何時使用無服務(wù)器?

無服務(wù)器適合于那些按需執(zhí)行，卻無需維持任務(wù)運行的應(yīng)用程序。當(dāng)團隊關(guān)注的是開發(fā)速度和成本最小化，而并非管理擴展性和架構(gòu)問題時，無服務(wù)器是理想的選擇。

簡而言之，當(dāng)您需要靈活性或遷移舊服務(wù)時，請選擇容器和容器編排。當(dāng)您注重開發(fā)速度、自動擴展、并要顯著降低運行時成本時，請選擇無服務(wù)器。

無服務(wù)器和容器能協(xié)同工作嗎?

毫無疑問，無服務(wù)器和容器是可以協(xié)同工作的。兩者互為補充。我們可以使用基于容器的微服務(wù)架構(gòu)，來構(gòu)建大型、復(fù)雜的應(yīng)用程序，并處理諸如數(shù)據(jù)傳輸、文件備份、觸發(fā)無服務(wù)器功能警報等后端任務(wù)。

值得一提的是，F(xiàn)argate是一種適用于Amazon ECS(Elastic Container Service)和EKS(Elastic Kubernetes Service)的計算引擎，它使我們能夠運行容器，而無需管理服務(wù)器。Fargate有效地將容器的便攜性，以及無服務(wù)器的靈活性與易用性相結(jié)合。您可以在無需添加、配置或擴展虛擬服務(wù)器的情況下運行容器。

原標(biāo)題：Serverless Computing vs Containers: How to Choose，作者：Jagadish Manchala

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】