獨立簡單的功能使開發更容易，事件驅動的執行使操作性價比更高！

開發人員花費無數個小時用代碼解決業務問題。 然后輪到ops團隊花費無數個小時，首先弄清楚如何獲得開發人員在任何可用計算機上編寫和運行的代碼，然后確保這些計算機順利運行。第二部分真的是一項永無止境的任務。 為什么不將這部分留給別人呢？

在過去二十年中，IT的許多創新：虛擬化，云計算，容器 ，一直專注于確保不必過多考慮代碼運行的底層物理機器。無服務器計算是一種越來越流行的范式，它將這種愿望用于其邏輯結論：使用無服務器計算，你無需了解代碼運行的硬件或操作系統，因為服務提供商都會為你提供服務。

什么是無服務器計算？

無服務器計算是云的執行模型，云提供商在其中動態分配，然后僅為執行特定代碼片段所需的計算資源和存儲向用戶收費。當然，仍然涉及服務器，但它們的供應和維護完全由提供商負責。亞馬遜無服務器的倡導者Chris Munns在2017年的會議上表示，從團隊編寫和部署代碼的角度來看，“根本沒有服務器可以管理或配置。這包括沒有裸機，沒有虛擬，沒有容器，任何涉及你管理主機，修補主機或在操作系統級別處理任何東西的東西，都不是你應該做的事情。這就是無服務器的世界。”

正如開發人員Mike Roberts所解釋的那樣，該術語曾被用于所謂的后端即服務場景，其中移動應用程序將連接到完全托管在云中的后端服務器。但是今天，當人們談論無服務器計算或無服務器架構時，它們意味著功能即服務產品，其中客戶編寫的代碼只解決業務邏輯并將其上傳到提供商。該提供程序負責所有硬件配置，虛擬機和容器管理，甚至是多線程等通常內置于應用程序代碼中的任務。

無服務器函數是事件驅動的，這意味著只有在請求觸發時才會調用代碼。提供商僅對該執行所使用的計算時間收費，而不是維護物理或虛擬服務器的固定月費。這些功能可以連接在一起以創建處理管道，或者它們可以作為更大應用程序的組件，與在容器中或在傳統服務器上運行的其他代碼交互。

無服務器計算的優點和缺點

從該描述中，無服務器計算的兩個最大好處應該是明確的：開發人員可以專注于他們編寫的代碼的業務目標，而不是基礎設施問題；組織只需要以非常精細的方式支付他們實際使用的計算資源，而不是購買物理硬件或租用大多數閑置的云實例。

正如Bernard Golden指出的那樣，后一點對事件驅動的應用程序特別有益。例如，你可能有一個大部分時間處于空閑狀態的應用程序，但在某些條件下必須同時處理許多事件請求。或者，你可能擁有一個應用程序來處理從具有有限或間歇性Internet連接的IoT設備發送的數據。在這兩種情況下，傳統方法都需要配置一個能夠處理峰值工作能力的強大服務器，但是大多數時候服務器都未得到充分利用。使用無服務器架構，你只需為實際使用的服務器資源付費。無服務器計算也適用于特定類型的批處理。無服務器架構用例的規范示例之一是上載和處理一系列單個圖像文件并將它們發送到應用程序的另一部分的服務。

也許無服務器功能最明顯的缺點是，它們是故意短暫的，正如AlexSoft所說，“不適合長期任務。”大多數無服務器提供商不會讓你的代碼執行超過幾分鐘，當你啟動一個函數，它不會保留以前運行的實例中的任何有狀態數據。一個相關的問題是，無服務器代碼可能需要幾秒鐘才能啟動，對于許多用例而言不是問題，但是如果你的應用程序需要低延遲，則需要發出警告。

正如Rohit Akiwatkar和Gary Arora所指出的，許多其他缺點都與供應商鎖定有關。盡管有可用的開源選項，但無服務器市場由大型商業云提供商主導，我們將在稍后討論。這意味著開發人員通常最終會使用其供應商提供的工具，這使得如果他們變得不滿意就很難切換。而且，根據定義，在供應商的基礎架構上進行了大量無服務器計算，將無服務器代碼集成到內部開發和測試管道中可能很困難。

無服務器供應商：AWS Lambda，Azure Functions和Google Cloud Functions

無服務器計算的現代時代始于2014年基于亞馬遜云服務的AWS Lambda的推出。微軟于2016年推出了Azure Functions。自2017年以來一直處于測試階段的Google Cloud Functions終于達到了生產狀態，這三種服務的局限性，優勢，支持的語言和做事方式略有不同。 Rohit Akiwatkar對這三者之間的區別進行了詳細而詳細的描述。運行中還有IBM Cloud Functions，它基于開源的Apache OpenWhisk平臺。

在所有無服務器計算平臺中，AWS Lambda是最突出的，顯然已經有最多的時間來發展和成熟。

無服務器堆棧

與許多軟件領域的情況一樣，無服務器世界已經看到了軟件堆棧的發展，這些軟件堆疊了構建無服務器應用程序所需的不同組件。每個堆棧都包含一個你要編寫代碼的編程語言，一個為你的代碼提供結構的應用程序框架，以及一組平臺將理解并用于啟動代碼執行的觸發器。

雖然你可以混合使用這些類別中的不同特定產品，但根據你使用的供應商存在一些限制，但存在一些重疊。例如，對于語言，你可以在AWS Lambda上使用Node.js，Java，Go，C＃和Python，但只有JavaScript，C＃和F＃在Azure Functions上工作。在涉及觸發器時，AWS Lambda擁有最長的列表，但其中許多都是特定于AWS平臺的，如Amazon Simple Email Service和AWS CodeCommit；同時，Google Cloud Functions可以由通用HTTP請求觸發。保羅·賈沃斯基（Paul Jaworski）深入研究了三大產品中的每一個產品的堆棧。

無服務器框架

這個方程式的框架部分有點遺憾，因為這將很好地定義了如何最終構建應用程序。亞馬遜有自己的原生產品，即開源的無服務器應用程序模型（SAM），但也有其他產品，其中大多數是跨平臺的，也是開源的。其中最流行的是無服務器，并且強調它為每個支持的平臺提供相同的體驗，即AWS Lambda，Azure Functions，Google Cloud Functions和IBM OpenWhisk。另一個受歡迎的產品是Apex，它可以幫助某些提供商無法使用某些語言。

無服務器數據庫

正如我們上面提到的，使用無服務器代碼的一個怪癖是沒有持久狀態，這意味著局部變量的值不會在實例化中持續存在。你的代碼需要訪問的任何持久性數據必須存儲在其他位置，并且主要供應商的堆棧中可用的觸發器都包含你的函數可以與之交互的數據庫。

其中一些數據庫本身是無服務器。這意味著它們的行為與我們在本文中討論的其他無服務器函數非常相似，但顯而易見的例外是數據無限期存儲。但是，配置和維護數據庫所涉及的大部分管理開銷都被拋棄了。正如開發人員Jeremy Daly所說，“你需要做的就是配置一個集群，然后為你自動處理所有維護，修補，備份，復制和擴展。”與功能即服務產品一樣，你只需支付實際使用的計算時間，并根據需要調高和調低資源以滿足需求。

三大無服務器提供商各自提供自己的無服務器數據庫：亞馬遜擁有Aurora無服務器和DynamoDB，微軟擁有Azure Cosmos數據庫，Google擁有Cloud Firestore。

無服務器計算和Kubernetes

容器有助于為無服務器技術提供動力，管理它們的開銷由供應商負責，因此對用戶不可見。許多人認為無服務器計算是一種在不必處理其復雜性的情況下，獲得容器化微服務的許多優點的方法，甚至開始談論后容器世界。

實際上，容器和無服務器計算幾乎肯定會在未來許多年內共存，無服務器功能可以與容器化微服務存在于同一應用程序中。Kubernetes是最受歡迎的容器編排平臺，也可以管理無服務器基礎架構。使用Kubernetes，可以在單個集群上集成不同類型的服務。

無服務器的離線

你可能會發現無服務器計算開始的前景有點令人生畏，因為你似乎需要與供應商簽約才能玩，并了解它是如何工作的。但不要擔心：有些方法可以在你自己的本地硬件上脫機運行無服務器代碼。例如，AWS SAM提供了一個本地功能，允許你脫機測試Lambda代碼。