【51CTO.com快譯】無服務器計算和容器是用來減少云托管應用開銷的兩種架構。不過它們在許多重要的方面都有所不同。容器比虛擬機“輕”，而無服務器部署比容器更“輕”，并且更容易擴展。在本文中，我們將和您討論無服務器計算和容器之間的區別，以及該如何進行選擇。
無服務器
在傳統的應用開發實踐中，為了將程序部署到服務器上，以供用戶使用，我們往往需要經歷規劃容量，采購硬件，安裝軟件，以及準備應用等環節。這些通常需要一周到幾個月的時間。再加上應用的初期運營，這可謂既耗時又費力。
隨著按需使用的云服務廣泛流行，我們解決問題的能力逐漸增強。雖然資本性支出(CAPEX)和運營性支持(OPEX)仍會產生成本，但是我們在容量規劃、部署時間、以及硬件管理上的花銷將大幅減少。其中，最典型的云計算應用便是無服務器。
無服務器可以被定義為一種方法。該方法用短暫的計算能力代替了長時間運行的計算提供機制。此類臨時計算力只是按需而存在的，并且會在使用完畢后立即消失。
當然，無服務器并不意味著真的沒有服務器，而是我們不需要管理服務器。也就是說，由于我們在由AWS、Google或Azure等云計算供應商，所提供的硬件上運行自己的服務，因此，我們將服務器的維護委托給了第三方(通常是云計算供應商)，由它們根據需求將資源分配到服務器上，以便我們專注于開發運行所需的服務。
實際上，無服務器計算是一種執行模型。在該模型中，硬件是由云計算供應商管理的。無服務器無需預定義的硬件，只要在執行時觸發和獲取硬件資源，并在執行完成后停止已獲取的硬件，直到觸發另一個動作為止。例如，某個內容管理應用可以讓用戶將圖像上傳到自己撰寫的文章中。如果我們處于使用了AWS Lambda來構建的無服務器架構中，那么圖像將首先被上傳到S3存儲桶處，并觸發一個事件。該觸發器會調用一個用多種編程語言編寫的AWS Lambda函數，來調整圖像的大小，并對其進行壓縮，以適合多種設備的顯示。可見，由觸發事件調用的AWS Lambda代碼或功能，會在云計算提供商所提供的硬件上執行。完畢后該硬件會處于停止狀態，并等待其他的觸發器。
功能即服務(Faas)
為了能夠動態創建和管理服務器，開發人員需要以功能函數的形式編寫應用代碼。也就是說，根據無服務器計算的Faas概念，軟件開發人員可以無需編寫基礎架構的代碼，而只專注于編寫和部署那些單獨的、能夠在毫秒內處理請求的各種功能、操作、以及業務邏輯。而讓云計算提供商調配與管理服務器，以及代為執行的功能代碼。
值得注意的是：在部署功能時，我們需要以一種事件的形式來進行調用。該事件可以是來自API網關(HTTP請求)的任何時間、另一個無服務器功能的事件、或是S3之類另一個云計算的事件。
無服務器提供商
目前，大多數主流云計算提供商都擁有自己的無服務器產品。其中，AWS Lambda于2014年率先推出了首款成熟的無服務器框架。它不但支持諸如Node.js、Java、Python和C#等多種編程語言，而且能與許多其他AWS服務相集成。
當然，您也可以選用Google Cloud Functions、Microsoft的Azure功能、IBM的OpenWhisk(開源的無服務器平臺)，以及Iron.io和Webtask等。
無服務器的優缺點
我們首先來看看無服務器能夠為開發人員提供的優點：
- 按使用付費：由于我們僅為那些在服務器上執行代碼的時間付費，因此那些空閑的服務器時間是不計費的。
- 彈性：利用無服務器架構，應用程序可以自動擴展，以適應流量的激增，并在用戶較少的情況下自行縮減。
- 花費在管理上的時間和費用更少：正是由于云計算接手了基礎架構，以及服務的縮放，因此用戶不但能夠花費更少的時間與資源，還能夠專注于自身的業務。
- 減少開發并縮短上市的時間：開發人員和組織擁有更多的時間來專注于構建產品，并將其發布到市場上;云計算供應商則負責保護與修補操作系統。
- 微服務方法：通過微服務方法，開發人員可以構建出模塊化、功能專一、且松耦合的軟件。此類軟件比整體應用要更加靈活、且更易于管理。
當然，無服務器計算也存在著如下缺點：
- 供應商鎖定和透明度降低：這是向云端無服務器遷移的主要問題之一。由于后端完全由云計算供應商進行管理，一旦我們將現有的功能移至其他云服務平臺，則會導致應用程序的重大更改。此類更改不僅僅是代碼層面上的，那些與之關聯的數據庫、訪問管理、存儲等其他服務，也會涉及到向其他平臺的移植和更改的問題。
- 支持的編程語言：由于特定功能需用相應的語言編寫，因此它無法支持所有的語言。例如：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。
- 不適合需要長時間運行的任務：由于此類功能在本質上是基于事件的，因此它們不太適合長時間運行的任務。例如：Lambda的超時限制為15分鐘。而在其他無服務器平臺上，時限為9分鐘到60分鐘不等。在實際應用場景中，長時間運行的流程用例有許多種，例如：視頻處理、大數據分析、批量數據轉換、批處理事件、長期同步的請求和統計計算等。顯然，這些情況都不太適合無服務器計算。
- 難以調試：僅部分工具可以進行遠程調試，而像Azure之類的服務僅提供鏡像的本地開發環境。
- 隱藏成本：功能調用的自動縮放往往意味著成本的自動縮放。而這可能會使您難以衡量自己的業務成本。
- 需要更好的工具：為了跟蹤已部署的大量功能，我們往往需要借助一些更好的工具，例如：針對開發的腳本、框架;針對診斷的逐步調試、本地運行時;以及針對云端調試和可視化的用戶界面、分析和監控。
- 響應應用事件延遲的較高：由于硬件在相當長的一段時間內處于空閑狀態，并且功能僅在觸發時運行，因此服務器可能需要一段時間才能喚醒并提供功能服務。
- 學習曲線：我們需要將傳統的整體應用轉換為微服務，再將其編寫為功能。這些都需要我們深入了解架構及其工作原理。
容器
容器是操作系統虛擬化的一種方法，可以讓用戶在資源隔離的進程中，運行某個應用程序及其依賴項。其中，容器包含了應用程序及其需要正常運行的所有依賴項，即：系統庫、系統設置和其他文件。因此，無論在何處托管的應用，容器化應用都能夠以相同的方式運行在容器中。
軟件從一個計算環境輕松地轉移和部署到另一個計算環境時，容器能夠保障其可靠地運行。這種轉移既可能是從開發人員的筆記本電腦到測試環境，也可能是從過渡環境到生產環境，還可能是從數據中心的物理機到私有或公共云中的虛擬機。
由于容器需要硬件才能運行，因此構建硬件并在其上部署容器便是我們的責任。具體說來，容器會通過在機器上劃分出單獨的用戶空間，以便在每個環境中僅運行一個應用。而多個用戶空間環境則可以共享主機的內核與硬件。也就是說，主機的內核將負責為容器提供必要的內存、CPU和其他硬件。
容器使您可以輕松地將應用代碼、配置和依賴項，打包到那些易用的構建塊中，以提高環境的一致性、運營效率、開發人員生產力、以及版本控制。容器可以對資源進行精細化的控制，從而提高整體架構的效率。
容器的優點
- 增強的可移植性：容器的主要優點是，我們可以將應用程序及其所有依賴項，組合到一個小的程序包中，以便在任何地方運行。這種靈活性和可移植性，方便了應用被輕松地部署到多個不同的操作系統和硬件平臺上。
- 與供應商無關：容器并不依賴于某個云計算供應商。我們創建好基本應用和依賴項的映像后，便可在任何地方運行它們。
- 完全控制應用程序：由于團隊負責打包應用程序及其依賴項，因此他們擁有完全的控制權。
- 大型和復雜的應用：我們可以將大型且復雜的應用打包，并在容器中運行。
- 可擴展性：在我們的控制下，容器可以根據其基礎架構，進行最大程度的擴展。
- 安全靈活性：在設置策略、管理資源和安全性方面，我們對容器具有完全的靈活性和控制能力。
- 更少的開銷：由于不包含任何操作系統的鏡像，因此容器比傳統的硬件或虛擬機環境需要更少的系統資源。
- 一致性的操作：無論它們被部署在何處，DevOps團隊總能確保應用程序在容器中的相同位置運行。
- 更高的效率：容器使應用程序可以更快地進行部署、修補或擴展。
容器的缺點
- 性能開銷：容器不會以裸機(bare-metal)的速度運行。雖然容器比虛擬機更能有效地利用資源，但是鑒于其覆蓋的網絡，容器與主機系統之間的接口，因此它仍然會產生性能開銷。
- 不支持圖形界面：Docker容器被設計為，可用于部署無需圖形界面的服務器應用解決方案。雖然我們可以使用諸如X11視頻轉發之類創造性策略，在容器內運行GUI應用程序，但是這些方案并不太好用。
- 管理：我們通過管理容器和配置來完成工作，但是如果沒有協調工具，我們將難以輕松地管理容器的擴展。
- 安全性：安全性是容器的最大問題。由于容器沒有內核，因此它需要通過主機的內核，來進行硬件通信。如果容器內運行的應用存在缺陷，則會產生安全漏洞。
- 并非所有應用都能受益：通常，只有那些被作為一組離散微服務運行的應用，才能從容器模式中獲益。
- 監控：隨著應用的發展，越來越多的容器會被添加進來。而我們很難合理監控這些高度分散且持續變化的容器。
- 減慢開發進程：在每次更改代碼庫時，我們都需要打包容器，并確保所有容器在部署到生產環境之前都能夠正確地通信。同時，我們也需要通過頻繁的安全修復、以及其他修補程序，使容器的操作系統能夠保持最新。
無服務器與容器
無服務器和容器縱然有著許多共同點，下面我們來看看它們之間的主要區別：
- 服務器空間：由于無服務器計算實際上是運行在服務器上，因此它需要云計算供應商決定是否需要供應和調整服務器空間，而不會為特定的功能或應用分配特定的機器。而容器則位于預先配置、并準備就緒的機器上。
- 部署：在無服務器計算中，部署并運行某項功能是由云計算供應商負責的。每當某個功能需要被觸發并執行時，它會被部署到供應商的已知服務器上。而在容器中，開發人員需要負責部署容器，并使容器保持運行的狀態。
- 彈性：供應商會根據負載，考慮在無服務器中擴展對應的功能。而對于容器的擴展，則需要通過增加容器數量，來進行人動干預。隨著容器編排(orchestration)平臺的引入，諸如kubernetes之類編排引擎會自動根據負載的增加擴展容器。
- 按使用付費：無服務器的優勢是價格。在觸發功能時，我們只需支付執行該功能所需的時間和資源。而容器需要持續處于正常運行狀態，因此費用往往更高。
- 維護：在無服務器架構中，開發團隊無需管理后端，而由供應商負責對運行代碼的服務器進行管理和軟件更新。在容器方面，開發團隊有責任保持硬件的更新、修補和維護。
- 測試：由于很難在本地計算機上復制后端環境，因此我們很難在本地測試無服務器的功能。而無論容器被部署在何處，它都可以在本地計算機上被輕松地測試和運行。
- 擴展的成本：容器技術能夠按需擴展應用。而無服務器有時可能會面臨空間和內存限制。
- 緩慢地擴展：無服務器的擴展是由供應商完成的，而容器的擴展則由應用開發團隊來負責和定義。因此與無服務器相比，容器的擴展速度較慢。
- 支持編程語言：無服務器無法支持所有的編程語言。而我們可以使用任何編程語言來構建容器。我們只需編寫代碼，與資源庫一起打包，并在容器中運行即可。
- 長時間運行的任務：如前所述，無服務器計算不太適合長時間運行的任務。而容器則可以運行任何類型的應用程序或任務。
- 開發時間：使用無服務器，我們只需考慮編寫代碼，其余部分都將由供應商來負責。而容器則涉及到諸如構建映像、移植等其他工作。
- 監控：供應商通過工具，來監控無服務器各項功能的執行、以及響應時間等。而在容器中，開發團隊需要通過安裝監控工具，來捕獲各種詳細的信息。
選擇哪種架構?
總的說來，無服務器和容器并不構成競爭關系，它們同屬云計算動態架構，都可根據不同的需求，用于部署微服務。
何時該使用容器?
容器最適合用于運行較長的流程。在這些流程中，您需要對環境進行高度控制，并且擁有足夠的資源來設置和維護應用程序。同時，云容器也是遷移單體式傳統式(monolithic legacy)應用的最佳方法。我們可以將這些應用分解成為容器化的微服務，然后使用kubernetes或swarm等引擎進行編排(orchestrate)。
何時使用無服務器?
無服務器適合于那些按需執行，卻無需維持任務運行的應用程序。當團隊關注的是開發速度和成本最小化，而并非管理擴展性和架構問題時，無服務器是理想的選擇。
簡而言之，當您需要靈活性或遷移舊服務時，請選擇容器和容器編排。當您注重開發速度、自動擴展、并要顯著降低運行時成本時，請選擇無服務器。
無服務器和容器能協同工作嗎?
毫無疑問，無服務器和容器是可以協同工作的。兩者互為補充。我們可以使用基于容器的微服務架構，來構建大型、復雜的應用程序，并處理諸如數據傳輸、文件備份、觸發無服務器功能警報等后端任務。
值得一提的是，Fargate是一種適用于Amazon ECS(Elastic Container Service)和EKS(Elastic Kubernetes Service)的計算引擎，它使我們能夠運行容器，而無需管理服務器。Fargate有效地將容器的便攜性，以及無服務器的靈活性與易用性相結合。您可以在無需添加、配置或擴展虛擬服務器的情況下運行容器。
原標題：Serverless Computing vs Containers: How to Choose，作者：Jagadish Manchala
【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】
