一些歷史

不久之前，開發，部署和運維還相當復雜。在一開始，運維不僅需要修補程序代碼，還要支持物理機器。保持服務器，硬件與軟件處于最新狀態也是一項艱巨的任務。

在2000年代，一個新的模型——架構即服務(IaaS)很快流行起來。IaaS提供了從第三方租用遠程服務器與虛擬機的可能性。這些提供商負責管理硬件，網絡以及預留空間。

在IaaS出現之后，為開發者減負，讓他們卸下所有非開發任務的想法推動了新方法，模型和服務的創新。

什么是容器?

Docker官方給出了如下簡短而優雅的定義：“容器是一個標準軟件單元，它將代碼及其依賴打包到一起，因而應用可以快速穩定地運行在不同的計算環境中。”換句話來說，使用容器，開發者能確保應用能運行在任何云平臺上或本地服務器上。在某些方面，容器與虛擬機相類似，都是獨立的資源。然而，虛擬機模仿物理機，而容器創建了軟件層的抽象。

什么是無服務器計算？

在無服務器計算中，整個應用或應用的一部分被分成多個功能，每個都會被一個事件觸發，例如HTTP請求，新消息到達消息隊列，或保存和修改數據。也能夠在某個特定時間或周期性地執行，這個特性對計劃任務很有用。

對于這樣的系統，開發者只需要寫功能代碼，將它與它的依賴一起打包到一個壓縮文件，并將壓縮文件發到無服務的終端。供應商負責配置和擴展。

無服務器的一個關鍵特性是“即用即付”模型，企業只需要為他們功能的實際執行時間付費。如今，AWS Lambda是最流行的無服務器供應商。

容器與無服務器有共通之處嗎？

是的！如今，無服務器與容器都很流行，因為他們能讓開發者專注于代碼而不是基礎設施。這提高了開發速度。容器與無服務器都能與微服務及基于組件的開發完美契合。相對于經典的一體化架構，使用無服務與容器，開發部署都會更快，性價比也更高，因為你在操作應用的小部分，而不是整體。盡管有這些共性，兩個技術都有各自的優劣以及各自的使用場景。

容器的優勢

容器的第一大優勢就是可移植性。由于容器包含了運行所需的一切依賴，只需要一個安裝有容器引擎的機器就可以運行。容器是平臺無關的，它可以運行在Linux, Windows, macOS, Mesos, Docker, Swarm, 或 Kubernetes，甚至可以運行在其他容器內部。

容器比虛擬機性能更好。雖然容器與虛擬機都是虛擬化的，虛擬機消耗更多的資源，因為他們運行著整個操作系統來模擬完整的機器。而容器可以共享同一個操作系統，這使它們更小，啟停速度更快。

容器的另一個好處是運行開發者獲得程序的完全控制。雖然這意味著系統設置必須手動配置，但這也意味著你擁有真正的靈活性。這一點無服務器是做不到的，因為幾乎所有的管理都由云供應商負責。

容器的使用場景

如果你想重構一些大的一體化應用到微服務架構，并獲得更好的性能，可測試性，以及擴展速度，容器非常有用。將過去的大應用分成幾個小服務——一個負責用戶管理，一個負責轉換媒體文件等等。每個服務都可以在負載提高時輕易地擴展來提供更好的性能。這些一體化應用就辦不到，除非像整個系統添加一個新實例，這樣既不經濟，又耗時間。

總的來說，容器適合于長期運行的程序，以及對系統有特殊要求的應用。

無服務器的優勢

由于“即用即付”模式，使用無服務器的花費會大大降低。在應用的空閑時間你不必付費，因此如果沒有流量，你就不用交月費。幾乎所有的無服務供應商都有免費使用，包含一個按月的固定請求數和執行時間。通常提供的數值對一個小型網站來說已經足夠了。

使用容器，將應用分成微服務是關鍵的一步。而使用無服務器，是將應用分成單個的功能，每個復雜一個特定的邏輯。這大大降低了開發和部署的速度，因為對于工程師來說這更容易理解。部署功能塊也比部署整個應用所冒的風險更小。

無服務的另一個好處是爆發自動伸縮。無服務器的功能運行在小的，無狀態的，短暫存在的容器中。供應商負責擴展應用來應對負載高峰，可以在幾秒鐘之內運行起來成百上千個實例。記住，你只需要為你的功能的執行時間付費。

什么時候使用無服務器？

事件驅動的無服務器對于那些不需要一直運行的應用很有用。

假設你在為一個已有應用開發一個媒體處理功能。新的模塊不經常使用，但是也需要足夠的計算能力完成它的任務。將它放在應用里需要遷移到一個性能更強的實例——一個冒險的舉動，因為，如果一些繁重的任務一起運行，會給所有的用戶帶來延遲，這時你就需要性能更好的機器，而這同樣會帶來風險。

如果你選擇無服務器，媒體處理模塊會與應用的其余部分隔離。在不用時你不需要付費并且不會影響你程序的其余部分。

無服務器，不是你不需要服務器，而是供應商為你提供服務器，這個服務器在你用的時候就存在，不用的時候就不存在(不收費),這簡直就是薛定諤的服務器。

容器的缺點

即使程序沒人使用，也至少有一個承載容器的虛擬機實例在運行。因此，容器比無服務器更貴。

即使容器可以在共享的機器上快速擴展，額外擴展并不快，因為機器自身也需要擴展。不過，利用容器協調系統例如Kubernetes,AWS ECS...使擴展更容易。

無服務器的缺點

對于大部分開發者，最可怕的事是廠商綁定。使用無服務器，你不可避免地要選擇一個云供應商，不同供應商之間使用的架構與API都不相同，如果要改變供應商或其他的解決方案，代價有些高昂。不過，也有一些專家不同意，聲稱廠商綁定不成問題。

使用無服務器，觀測，監控與調試都不容易。因為程序可能被分成了多個部分，每一部分都有各自的bug與錯誤，掌控全局變得很重要。幸運的是，現在可以使用Thundra,一個為無服務器提供了完整可觀測性的工具，聚合了性能指標和日志。

容器和無服務器可以一起使用嗎？

令人驚訝的是，是的！讓主程序功能作為容器化的微服務運行，而對于一些后臺操作或很少使用但是消耗CPU的功能使用無服務器。

另一種又去的結合方式是使用AWS Fargate。這個服務結合了無服務器與容器的優點，運行你更好地控制你的程序而不用擔心擴展——AWS負責。如果你對此感興趣，查看關于AWS Fargate的這篇文章。

總結

容器與無服務器通常被認為是相互競爭的技術。通過進一步的觀察，發現他們只是不同的技術而已——在同一個項目中一起使用可以優勢互補。記住“舊的”不意味著是“死的”，“新的”不代表“更好”。哪種方案有效取決于你的使用場合，項目需求，團隊經驗以及團隊偏好。