過去一年，無服務器計算（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技術有四種不同的方式：
- 如果是由數百個微服務組成的巨型組件，那麼微服務本身可以分解爲數百個功能。與PaaS不同，在使用無服務器框架時，DevOps團隊可以免於擔心更新，應用程序擴展、縮小，空閒成本以及複雜的構建和部署操作，核心功能及其邏輯的所有內容都由基礎架構提供商處理。
- 無服務器技術並不關注用於開發，測試和部署它們的DevOps方法，這與通常對開發人員工作流程要求很嚴格的PaaS不同。
- 與PaaS上部署的應用程序不同，無服務器功能的啓動延遲非常低。
- 與PaaS相比，無服務器框架功能有限，增加的簡單性確實伴隨着特徵差異。
與在PaaS上運行相比，無服務器框架在Kubernetes上運行得更好。大多數PaaS技術因在幾個領域（開發人員工作流程、架構和定價）過於嚴格而贏得讚譽，這使得它們不適合運行無服務器工作負載。用Brendan Burns的話說，第一代平臺即服務（PaaS）正是爲了讓開發人員採用無服務器架構。麻煩的是，太多重疊的概念被混合到單片產品中。在大多數的第一代PaaS中，開發人員體驗無服務器和定價模型都在一個不可分割的整體中混合。因此，想要採用無服務器，但可能不符合開發人員的特定要求（例如特定編程語言）或者想要爲大型應用程序提供更具成本效益的定價模型的用戶都會被迫放棄無服務器計算。