Containers vs Serverless：本質區別是什么？

在云計算領域，容器和無服務器計算已經占據了發展前列。

作者 | Emra Samdan

翻譯 | bocloudresearch

一點歷史

在不久以前，應用程序的開發、部署和維護要比現在復雜得多，耗時也多。在最初，維護不僅需要修復應用程序的代碼，還需要修復對物理機器的支持。保持服務器、硬件和軟件的更新也是非常關鍵的任務。

在本世紀初，一種名為“基礎設施即服務(IaaS)”的新模式迅速流行起來。IaaS提供了從第三方提供商租用遠程服務器和虛擬機的可能性，這些提供商可以完全負責管理硬件、網絡和預訂。

IaaS出現之后，消除開發人員的所有非編碼職責來簡化開發人員工作，這一想法推動了新方法、模型和服務的創新。

容器是什么?

Docker的官方網站提供了以下簡短而優雅的定義:“容器是一個標準的軟件單元，它將代碼及其所有依賴項打包，從而使應用程序在不同的計算環境之間快速、可靠地運行。換句話說，通過使用容器，開發人員可以確保他們的應用程序可以在任何云平臺或本地服務器上運行。在某些方面，容器類似于虛擬機，比如兩者都是隔離資源。但是，虛擬機模擬物理設備，而容器創建應用程序層的抽象。

無服務器計算是什么？

在無服務器計算中，整個應用程序或應用程序的一部分被解耦為多個函數，每個函數都響應諸如HTTP請求、新消息到達消息隊列、或在存儲中保存或修改新對象等時間觸發的。平臺可以在特定的時間或周期運行這些函數，這對cron jobs（定時任務）很有幫助。

要使此系統工作，開發人員只需編寫功能代碼，并將其及其依賴項打包到zip文件中，然后將該zip文件發送到無服務器端點，由提供商負責供應和擴展。

無服務器的關鍵特性之一是“按需付費”模型，在這種模型中，公司僅按函數的實際執行時間付費。如今，AWS Lambda應該是最受歡迎的無服務器提供商。

容器和無服務器有什么共同之處嗎?

是的。現在，無服務器和容器都很流行，它們允許開發人員專注于自己的代碼而不是基礎設施，這極大地提高了開發速度。容器和 serverless 都非常適合于微服務和基于組件的體系結構。在使用它們時，部署和擴展通常比使用傳統的單體架構更快、更具成本效益，因為你操作的是應用程序的一小部分，而不是整個應用程序。雖然容器和serverless 有這些共性，但是每種技術都有自己的優勢、弊端和用例。

容器化的優勢

容器的第一個優勢是可移植性。由于容器已經包含了它需要運行的所有內容，因此只需放置一臺安裝了容器引擎的機器即可運行。容器與平臺無關，因此它們可以運行在Linux、Windows、macOS、Mesos、Docker、Swarm或Kubernetes上。它們甚至可以在另一個容器中運行。

在計算資源使用方面，容器也比虛擬機更高效。盡管容器和虛擬機都是虛擬化的，但是虛擬機會使用自己的操作系統來模擬整個計算機，因此會消耗更多的資源。另一方面，容器可以共享同一操作系統，從而使操作系統更小，更快地啟動和關閉。

容器的另一個好處是允許開發人員完全控制應用程序。雖然這意味著必須手動配置系統設置，但這也意味著擁有真正的靈活性。這在serverless上是無法實現的，因為無服務器的所有內容都是由云提供商管理的。

容器的用例

當我們想要將一些大型的單體應用程序重構為更小的獨立部分， 以便遷移到微服務體系結構并獲得更好的性能、可測試性和擴展速度時，容器確實是很有幫助的。例如，將以前的大型應用程序拆分為幾個獨立的服務：其中一個負責用戶管理，另一個負責轉換媒體文件等。每個服務都可以輕松擴展，以便在其職責范圍的負載增加時提供更好的性能。但這對于單體應用程序來說是不可能實現的，在單體應用程序中，需要向整個系統添加新實例，這既昂貴又耗時。

因此，容器適合于長時間運行的應用程序，以及具有特定系統需求的應用程序，如果沒有對系統的完全控制，這些應用程序很難設置。

Serverless的優勢

由于上面提到的“按需付費”模型，托管無服務器應用程序的成本可能比使用任何其他方法都要低得多。無需為功能的空閑時間付費，如果沒有流量，那么每月的賬單上就不會有費用。幾乎所有無服務器的提供商都有免費層，其中包括每月固定數量的請求和執行時間。通常情況下，所提供的數量足以使小網站或初創公司免費運行。

對于容器，將應用程序分發到部件或微服務是關鍵步驟。在serverless中，它是將應用程序或其各個部分分發到單個函數中，每個函數負責特定的邏輯段。工程師更容易理解和開發單個功能的邏輯，這極大地提高了開發和部署速度。與部署整個應用程序相比，部署一小部分功能的風險更小。

無服務器的另一個巨大優勢是自動伸縮。無服務器的函數在提供者控制下的小型、無狀態的臨時容器中運行。提供者對響應負載峰值的擴展承擔全部責任，并且可以在幾秒鐘內啟動數百個實例。而且，仍然只需要為所有函數的總執行時間付費。

什么時候使用無服務器比較好?

Serverless的事件驅動特性使得它對于不總是需要運行的應用程序(或其部分)非常有用。

假設你正在為一個現有的應用程序開發媒體處理功能。新模塊雖然不會經常使用，但是仍然需要足夠的計算能力來完成它的任務。將其放如應用程序中可能需要切換到更強大的實例——這是一個冒險的舉動，因為如果同時運行一些繁重的任務，可能會導致其他所有用戶的延遲。在這種情況下，還需要支付更多的費用，并且仍然面臨由上述瓶頸所導致的一些問題。

相反，如果選擇了serverless，那么媒體處理功能將與應用程序的其余部分隔離。當它不被使用時，就不需要為此付費，并且可以始終確保它不會影響到應用程序的其他部分。

容器的弊端

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

即使容器可以在共享計算機中快速擴展，但由于需要對計算機本身進行擴展，因此其他擴展也不很快。 但是，將容器與業務流程系統（如Kubernetes或AWS ECS）一起使用可以使擴展更智能。

無服務器的弊端

對于大多數開發人員來說，serverless最可怕的部分是供應商鎖定。當你提交到serverless時，實際上是在單個云提供商上進行堆棧。這些函數中使用的無服務器應用程序和 api 的體系結構因不同的提供商而有所不同，因此更改提供商或切換到內部解決方案的成本可能很高。盡管如此，有一些專家并不同意這個觀點，他們聲稱廠商鎖定實際上并不是一個問題。

使用無服務器方法不容易實現可觀察性、監視和調試。由于應用程序可以被分散到多個部分，而每個部分都有自己的 bug 和錯誤，所以控制和查看全局變得非常重要。

容器和無服務器可以一起操作嗎?

容器和無服務器可以一起操作，答案是肯定的。將主要應用程序功能作為一個容器化的微服務來運行，同時將無服務器使用于某些后臺操作或很少使用的功能（但占用CPU），可能會非常有效。

另一個有趣的組合是AWS Fargate提供的。該服務結合了無服務器和容器的優點，允許你更好地控制你的應用程序，而不必擔心伸縮難題。

結論

容器和無服務器通常被認為是相互競爭的技術。但仔細觀察就會發現它們只是不同的技術，當在同一個項目中使用時，它們實際上可以彌補彼此的缺陷。重要的是要記住，“舊的”并不意味著“過時”，“新的”并不意味著“更好”。解決方案的有效性取決于特定的用例、項目需求、團隊經驗和團隊偏好。