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

無服務器計算是當前的一項熱門話題，甚至熱過了Docker容器。

這麼講是說無服務器計算要成爲容器的替代品嗎？或者它是能夠和容器一同使用的另外一項流行技術嗎？

在這篇文章中，我將爲你介紹無服務器計算須要瞭解的內容，以及該如何將它融於你的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毫秒的觸發次數計費。實際成本一般也至關低，這裏有部分緣由是由於無服務器涉及的功能很小型，執行相對簡單的任務，而且在常規的容器中執行，開銷很小。

低維護成本

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

簡易性

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

無服務器計算的應用場景

何時你會用到無服務器計算？能夠考慮以下場景與可能：

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

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

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

無服務器計算的侷限

不過無服務器計算有一些很是明確的侷限。以Lambda爲例，它對功能函數的大小、內存佔用和利用時間有內部限制。

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

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

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

容器在哪些方面作得更好

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

你能夠作得更大

基於容器的應用程序能夠像你所須要的那樣規模大而又複雜。例如，你能夠將一個很是龐大而複雜的總體應用程序重構爲一系列基於容器的微服務，徹底按照從新設計的系統要求定製新的體系結構。若是想要重構一樣的應用程序而且在無服務平臺上運行，可能會由於大小和內存限制遇到多個技術瓶頸。由此產生的應用程序可能由極其分散的微服務組成，而每一個碎片的可用性和延遲時間很是的不肯定。

你能夠徹底掌控

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

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

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

協同工做

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

另外一方面，無服務器計算很是適用於可在後臺運行或外部服務訪問的單個任務。基於容器的系統能夠將這些任務交給無服務器應用程序，而沒必要佔用主程序的資源。對無服務器應用程序來講，它能夠爲多個客戶端提供服務，而且在容器系統中能夠與其餘無服務器應用程序徹底獨立地進行更新、升級和切換。

結論

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

如需轉載，請註明出處謝謝！

公衆號：RancherLabs

官 網：http://cnrancher.com