這麽講是說無服務器計算要成為容器的替代品嗎？或者它是可以和容器一同使用的另一項流行技術嗎？

在這篇文章中，我將為你介紹無服務器計算需要了解的內容，以及該如何將它融於你的IT戰略中。

“無服務器”並不是真的沒有服務器

首先需要澄清一點：當然可能大家也都有所了解，無服務器計算並不是意味著沒有服務器。它是一個基於雲的服務，和雲上的其他服務一樣，運行在服務器上。

也就是說，稱它為無服務器，是因為服務提供者負責處理了所有的服務器側IT，而你所需要做的只是編寫代碼並部署它。無服務器計算提供者處理了除此之外幾乎所有的事務。這樣在使用體驗上就是一種無服務器的，雖然底層基礎架構並不是如此。

無服務器計算如何工作

那麽它是如何工作的呢？舉最流行的一個無服務器計算平臺AWS Lambda為例。使用它，你需要編寫代碼（C#、Java、Node.js或Python），設置一些簡單的配置參數，並且將所有的內容（以及所需的依賴項）上傳到Lambda。

在Lambda術語中，上傳的軟件包被稱作功能函數(function)。可通過運行在AWS服務（如S3或者EC2）上的應用程序調用該功能。上傳Lambda後，Lambda會將你的功能部署在一個容器中，這個容器會在該函數完成執行之前一直存在，之後會釋放掉。

需要註意的是，Lambda在這裏負責配置、部署和管理容器，而你所做的只是提供在容器中執行的代碼，其他的工作都交由後臺完成。

這會是無服務器的天下嗎？

那麽這是不是就意味著我們現在的軟件開發人員和IT團隊已不再需要直接處理容器或具體的後端IT了呢？可以只編寫代碼，把它丟到Lambda，讓AWS來處理所有其他的事情嗎？如果這聽起來讓人難以置信的話，那麽就只有一種解釋——這是不可能實現的。

如果你的DevOps交付鏈中還沒有包含它，AWS Lambda所代表的這類無服務器計算將成為非常有價值的資源。

然而，它只能成為交付鏈中的一部分。雖然無服務器計算在大多數任務中都很適用，但距全面替代並部署和管理自己的容器還相距甚遠。實際上無服務器計算應該和容器一同工作而不是替換它們。

無服務器計算的優勢

那麽，無服務器計算的優勢有哪些呢？當用它來提供服務時，無服務器計算有以下優點：

花銷低廉

使用無服務器計算，通常情況下只根據實際使用的時間和流量計費。例如，Lambda的計費標準是以每100毫秒的觸發次數計費。實際成本通常也相當低，這裏有部分原因是因為無服務器涉及的功能很小型，執行相對簡單的任務，並且在常規的容器中執行，開銷很小。

低維護成本

在無服務器平臺上部署某個功能時，平臺為你做了絕大部分的工作。除此之外，你無需再為此設置容器、系統策略和可用性級別，也無需處理任何後端服務器的任務。如果你需要的話，你還可以使用自動伸縮，或是對容量進行簡單的手動設置。

簡易性

標準的編程環境、沒有服務器和容器部署的開銷，你可以更加專註於編寫代碼。從應用程序角度來看，無服務器的功能基本上是一種外部服務，它不需要緊密集成到應用程序的容器生態系統中。

無服務器計算的應用場景

什麽時候你會用到無服務器計算？可以考慮如下場景與可能：

● 處理網站或移動應用程序的後端任務。無服務器功能可以從站點或應用程序前端接受請求（例如，來自用戶數據庫或外部源的信息），檢索信息並將其交回到前端。這是一個快速且相對簡單的任務，可以根據需要執行，很少占用前端的時間或資源，且只為後端任務的實際持續時間計費。

● 處理實時數據流並上傳。無服務器功能可以清理、解析並過濾傳入的數據流，處理上傳的文件，管理來自實時設備的輸入，並處理與間歇性的或高吞吐量的數據流相關的主要任務。使用無服務器功能，可以將資源密集型的實時進程從主應用程序移出（避免占用主應用的資源）。

● 負責高容量的後臺進程。你可以使用無服務器功能將數據移動到長期存儲上，以及轉換、處理和分析數據，並將指標轉發到分析服務上。比如，在銷售點系統中，無服務器功能可以用來協調庫存、客戶、訂單和交易數據庫，以及間歇性的任務，如補貨和標記差異。

無服務器計算的局限

不過無服務器計算有一些非常明確的局限。以Lambda為例，它對功能函數的大小、內存占用和利用時間有內部限制。

這些限制以及有限的本地支持編程語言，並不一定是基礎級別的無服務器計算所固有的，可它們也反映出系統的實際限制。對無服務器計算來說，讓功能函數體量小，避免占用太多系統資源，是非常重要的，這樣可以避免出現數量較少的高需求用戶阻礙其他用戶或者令系統過載的問題。

無服務器計算的基本性質也會產生一些內在的限制。例如，大多數監視工具如果使用無服務器功能可能很難實現，因為一般情況下你無法訪問到該功能所在的容器或者容器管理系統。

調試和性能分析也可能因此被限制在相當原始或使用間接的方式。速度和相應時間也可能不均勻；這些限制以及對大小、內存、持續時間的限制可能會影響到它在性能優先情況下的使用。

容器在哪些方面做得更好

容器可以比無服務器功能做得好的事情可以列舉出非常多，可以用一篇完整的文章做詳細的介紹。我們在這裏要做的只是指出一些無服務器功能不能替代基於容器的應用程序的主要方面。

你可以做得更大

基於容器的應用程序可以像你所需要的那樣規模大而又復雜。例如，你可以將一個非常龐大而復雜的整體應用程序重構為一系列基於容器的微服務，完全按照重新設計的系統要求定制新的體系結構。如果想要重構同樣的應用程序並且在無服務平臺上運行，可能會因為大小和內存限制遇到多個技術瓶頸。由此產生的應用程序可能由極其分散的微服務組成，而每個碎片的可用性和延遲時間非常的不確定。

你可以完全掌控

基於容器的部署可以完全控制單個容器和整個容器系統，以及它所運行的虛擬化基礎架構。這樣你可以設置策略、分配和管理資源，對安全性進行細化的控制，充分利用容器和遷移服務。而在另一方面，使用無服務器計算，只能依賴於‘他人’而不能自己控制。

你有精力去調試、測試和監控

完全掌控了容器環境，就可以全面了解容器內外的情況。這樣就能夠利用所有的資源進行有效的、全面的調試和測試，並可以在各個層面上進行深入的性能監控。你可以識別和分析性能問題，並在微服務的基礎上微調性能，來滿足對系統的具體性能需求。在系統、容器管理和容器級別上的監控訪問還可以對所有這些層面進行完整、深入的分析。

協同工作

目前的實踐中發現當無服務器計算和容器在一起工作時效果時最好的，這也需要每個平臺都做得很好。基於容器的應用程序，並結合全特性的系統來管理和部署容器，這對於大型和復雜的應用程序和應用程序套件（尤其是在企業或互聯網環境）而言是最佳的選擇。

另一方面，無服務器計算非常適用於可在後臺運行或外部服務訪問的單個任務。基於容器的系統可以將這些任務交給無服務器應用程序，而不必占用主程序的資源。對無服務器應用程序來說，它可以為多個客戶端提供服務，並且在容器系統中可以與其他無服務器應用程序完全獨立地進行更新、升級和切換。

結論

無服務器計算服務和容器服務之間是平臺間的競爭嗎？答案是：基本不是。基於容器和無服務器的計算正在當今不斷發展的世界中，互相地為現在的雲計算和持續交付軟件提供更好的支持。

無服務器計算將會取代容器？