無伺服器計算将會取代容器？

無伺服器計算是目前的一項熱門話題，甚至熱過了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毫秒的觸發次數計費。實際成本通常也相當低，這裡有部分原因是因為無伺服器涉及的功能很小型，執行相對簡單的任務，并且在正常的容器中執行，開銷很小。

      低維護成本

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

      簡易性

标準的程式設計環境、沒有伺服器和容器部署的開銷，你可以更加專注于編寫代碼。從應用程式角度來看，無伺服器的功能基本上是一種外部服務，它不需要緊密內建到應用程式的容器生态系統中。

     無伺服器計算的應用場景

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

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

● 處理實時資料流并上傳。無伺服器功能可以清理、解析并過濾傳入的資料流，處理上傳的檔案，管理來自實時裝置的輸入，并處理與間歇性的或高吞吐量的資料流相關的主要任務。使用無伺服器功能，可以将資源密集型的實時程序從主應用程式移出（避免占用主應用的資源）。

●  負責高容量的背景程序。你可以使用無伺服器功能将資料移動到長期存儲上，以及轉換、處理和分析資料，并将名額轉發到分析服務上。比如，在銷售點系統中，無伺服器功能可以用來協調庫存、客戶、訂單和交易資料庫，以及間歇性的任務，如補貨和标記差異。

     無伺服器計算的局限

不過無伺服器計算有一些非常明确的局限。以Lambda為例，它對功能函數的大小、記憶體占用和利用時間有内部限制。

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

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

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

     容器在哪些方面做得更好

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

你可以做得更大

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

你可以完全掌控

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

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

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

協同工作

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

另一方面，無伺服器計算非常适用于可在背景運作或外部服務通路的單個任務。基于容器的系統可以将這些任務交給無伺服器應用程式，而不必占用主程式的資源。對無伺服器應用程式來說，它可以為多個用戶端提供服務，并且在容器系統中可以與其他無伺服器應用程式完全獨立地進行更新、更新和切換。

結論

無伺服器計算服務和容器服務之間是平台間的競争嗎？答案是：基本不是。基于容器和無伺服器的計算正在當今不斷發展的世界中，互相地為現在的雲計算和持續傳遞軟體提供更好的支援。

本文轉自 RancherLabs 51CTO部落格，原文連結:http://blog.51cto.com/12462495/2073777