天天都在說,無伺服器計算到底是什麼?

語言: CN / TW / HK

過去一年,無伺服器計算(serverless)已成為構建和執行現代應用程式和服務的普遍架構替代方案。無伺服器應用程式允許開發人員專注於程式碼,而不是基礎架構配置和管理。這加快了研發和釋出週期,並允許更好、更有效的擴充套件。 無伺服器計算已成為各大趨勢榜單的常客,但是,這個天天被說來說去的東西到底是什麼?

無伺服器計算與新興體系結構和技術密切相關,比如微服務和容器。Greenfield、雲原生應用通常基於微服務,這使它們成為在容器上執行的理想選擇(Docker)。無伺服器允許應用程式和基礎架構之間進一步分離和抽象,成為開發跨不同環境執行的現代微服務程式的理想模式。

隨著無伺服器應用程式的使用越來越多(Lambda 是 AWS 提供的最受歡迎的雲服務),希望為內部工程師提供無伺服器體驗的企業也越來越多,這意味著無伺服器計算將成為混合雲環境中的重要技術。

雖然無伺服器計算提供了很多好處,但是與容器一起成功實施還是存在很多挑戰,特別是 IT 運營層面。雖然無伺服器計算加速了開發,但它需要 Kubernetes 叢集才能執行,而 Kubernetes 的部署和管理非常困難。此外,這些新技術增加了企業支援的 IT 環境、工具和應用程式的複雜性。

無伺服器架構簡介

首先,我們需要了解一些定義。

雲原生:雲原生架構最關鍵的特性是動態擴充套件以支援大量使用者及大型分散式開發和運營團隊。如果你認為雲端計算本質是多租戶時,這個要求就更為重要。在這個領域內,我們需要解決的典型問題如下:

1、動態擴縮容能力

2、自動處理破壞應用程式可用性的跨層故障

3、通過確保元件本身提供松耦合來適應大型開發團隊的能力

4、能夠使用幾乎任何型別的基礎設施(計算,儲存和網路)

Micro 和 Serverless:現代應用架構演變

大多數企業的傳統應用程式本質上是單片式的,在應用程式元件、基礎架構、開發團隊、技術和工具之間具有緊密耦合和相互依賴性。這種耦合對開發速度和靈活性,新技術的採用或 DevOps 實踐,以及易於擴充套件和操作應用程式提出了挑戰。

微服務是面向服務的體系結構(SOA)範例的自然演進。在這種說法下,應用程式被分解為鬆散耦合的業務功能,每個功能對映到一個或多個微服務。每個微服務都是為特定的,細粒度業務功能而構建的,可以由獨立的開發人員或團隊處理。通過作為單獨的程式碼工件,它不僅從工具或通訊角度鬆散耦合,而且從構建、部署、升級和維護角度來看,每個微服務都可以選擇本地化資料儲存。採用這種方法的重要優點是,每個微服務都可以使用與應用程式其他部分隔離的技術堆疊來建立。

容器是執行微服務最有效,最優化的方式,可以使用容器編排解決方案(例如開源 Kubernetes)來處理容器叢集的執行時操作。

無伺服器計算是技術趨勢的下一步。

無伺服器計算是軟體開發的新範例,基於此,應用程式開發人員可專注於編寫程式功能,不必花費時間和精力來配置、管理、部署和執行這些程式所需的資源。

在此範例中,雲或基礎架構提供商需要為應用程式執行所有必需的管道,以便在收到請求後對其進行例項化。開發人員專注於應用程式的程式碼,底層資料中心提供商有責任可靠地管理執行它所需的相關資源。

功能即服務(FaaS)是最常見的無伺服器計算型別,其中,應用程式被開發為針對粒度用例的純軟體功能(如果願意,可以使用非常精細的微服務)。然後,多個功能可以組合並可選地與微服務應用程式結合使用以執行業務功能。

無伺服器計算允許細粒度計費,由於其獲取空閒功能以消耗更低的 CPU 和記憶體,因此叢集資源與實際使用比例和部署大小成正比。當功能空閒時,伺服器資源不會被例項化,因此降低了成本。但請記住,計費優勢對實際使用模式非常敏感。每 10 秒執行一秒鐘功能在 Lambda 上會便宜一些,但如果每 10 秒執行 2 秒,那麼在 EC2 上會便宜一些。使用者必須準確模擬使用情況,並評估無伺服器是否真的能節省資金。

無伺服器架構的特點

無伺服器體系結構或功能即服務(FaaS)符合以下主要原則:

  • 整體處於松耦合架構狀態,雖然使用這些的應用是典型 Web 或客戶端程式,但也支援物聯網、流資料等的大量使用。這些應用程式利用基於雲的第三方服務,比如事件、訊息傳遞,身份驗證服務等。
  • 支援各種資料模型——NoSQL 占主導地位,因為無伺服器體系結構中的函式是輕量級的,需要將所有依賴打包到一個靈活的資料庫中,NoSQL 就非常合適。
  • 要求橫向擴充套件作為一項基本原則,應用程式應根據吞吐量自動向上或向下擴充套件。
  • 從開發人員的角度來看,無伺服器框架提供的靈活性使其成為開發數字應用程式快速且經濟高效的方式。
  • FaaS 應用程式需要從底層基礎架構堆疊中完全抽象出來,這是很關鍵的,因為開發團隊可以專注應用程式程式碼,而不必擔心底層 OS、儲存和網路的維護。
  • 自動管理雲原生無伺服器應用程式的供應、部署、規模週期,從擴充套件和故障轉移角度來看,支援任何負載的全天候操作。

因此,FaaS 架構的整體流程非常簡單:

  • API Manager 接收事件
  • 管理器建立 http 請求,函式被啟動
  • 該函式首先在容器中例項化。容器具有函式執行所需的所有配置,包括其依賴性
  • 該函式處理請求
  • 自動銷燬容器
  • 使用者只需在執行函式期間支付所消耗的資源(RAM,CPU,磁碟等)

無伺服器計算解決了開發人員面臨的最大挑戰(即使用 PaaS 或容器編排平臺,如 Kubernetes)——需要擁有、擴充套件和管理基礎架構。執行這些無伺服器工作負載的容器既不是由開發人員配置也不是由其監控或以其他方式管理的,但他們可以構建執行應用程式而無需擔心伺服器。

關於無伺服器與 PaaS 的說明

無伺服器框架與 PaaS 技術有四種不同的方式:

  1. 如果是由數百個微服務組成的巨型元件,那麼微服務本身可以分解為數百個功能。與 PaaS 不同,在使用無伺服器框架時,DevOps 團隊可以免於擔心更新,應用程式擴充套件、縮小,空閒成本以及複雜的構建和部署操作,核心功能及其邏輯的所有內容都由基礎架構提供商處理。
  2. 無伺服器技術並不關注用於開發,測試和部署它們的 DevOps 方法,這與通常對開發人員工作流程要求很嚴格的 PaaS 不同。
  3. 與 PaaS 上部署的應用程式不同,無伺服器功能的啟動延遲非常低。
  4. 與 PaaS 相比,無伺服器框架功能有限,增加的簡單性確實伴隨著特徵差異。

與在 PaaS 上執行相比,無伺服器框架在 Kubernetes 上執行得更好。大多數 PaaS 技術因在幾個領域(開發人員工作流程、架構和定價)過於嚴格而贏得讚譽,這使得它們不適合執行無伺服器工作負載。用 Brendan Burns 的話說,第一代平臺即服務(PaaS)正是為了讓開發人員採用無伺服器架構。麻煩的是,太多重疊的概念被混合到單片產品中。在大多數的第一代 PaaS 中,開發人員體驗無伺服器和定價模型都在一個不可分割的整體中混合。因此,想要採用無伺服器,但可能不符合開發人員的特定要求(例如特定程式語言)或者想要為大型應用程式提供更具成本效益的定價模型的使用者都會被迫放棄無伺服器計算。

分享到: