1.2.2　Serverless關鍵技術

圖1-8是典型的Serverless系統架構，從中可以看到一些Serverless的常用概念。

? 事件源（Event Sources）：事件的生產者，可能是HTTP請求、消息隊列的事件等，通過同步或異步的方式去觸發函數。

? 觸發器（Trigger）：函數的REST呈現，通常是RESTful URL。當事件源將事件推/拉到觸發器時，FaaS平臺會查找觸發器和函數的映射關系，從而啟動該函數實例，以響應被推/拉到觸發器的事件。

? FaaS控制器（FaaS Controller）：FaaS平臺的核心組件，管理函數的生命周期、擴容和縮容等。可以將函數實例縮容為0，同時在收到對函數的請求時迅速啟動新的函數實例。

? 函數實例（Function Instance）：執行函數的環境，包含函數代碼、函數運行環境（如JRE、Node.js）、上下文信息（如函數運行的配置，通常以環境變量注入）。一個函數實例可以同時處理1個或N個事件（取決于平臺的具體實現）。函數實例通常內置可觀測性，將日志和監控信息上報到對應的日志和監控服務中。

? 函數編程模型（Programming Model）：通常表現為函數的編碼規范，如簽名、入口的方法名等。函數的編程模型一般會提供同步/異步/異常處理機制，開發者只需要處理輸入（事件、上下文），并返回結果即可。

? BaaS平臺：函數通常是無狀態的，其狀態一般存儲在BaaS服務中，如NoSQL數據庫等。函數可以基于REST API或BaaS服務提供的SDK來訪問BaaS服務，而不用關心這些服務的擴容和縮容問題。

結合圖1-8中典型Serverless架構的架構元素，從Serverless系統的實現來看，其關鍵技術需求包括以下幾點。

? 函數編程模型：提供友好的編程模型，使開發者可以聚焦于業務邏輯，為開發者屏蔽編碼中最困難的部分，如并發編程等。同時，需要原生支持函數的編排，盡量減少開發者的學習成本。

? 快速擴容：傳統的基礎設施通常都是從1到n擴容的，而Serverless平臺需要支持從0到n擴容，以更快的擴容速度應對流量的變化。同時，傳統基礎設施基于資源的擴容決策周期（監控周期）過長，而Serverless平臺可達到秒級甚至毫秒級的擴容速度。

? 快速啟動：函數被請求時才會創建實例，該準備過程會消耗較長的時間，影響函數的啟動性能。同理，對于新到達的并發請求，會產生并發的冷啟動問題。Serverless平臺需要降低冷啟動時延，以滿足應用對性能的訴求。

? 高效連接：函數需要將狀態或數據存放在后端BaaS服務中，而對接這些服務往往需要繁雜的API，造成開發人員的學習負擔。如果能提供統一的后端訪問接口，則可以降低開發和遷移成本。另外，Serverless平臺的函數實例生命周期通常較短，對于如RDS數據庫等后端服務無法保持長連接。然而，在并發冷啟動場景下，大量函數實例會同時創建與數據庫的連接，可能會導致數據庫負載增加而訪問失敗。為此，Serverless平臺需要為函數提供完備、高效、可靠的BaaS服務連接/訪問接口。

? 安全隔離：Serverless是邏輯多租的服務，租戶的函數代碼可能運行在同一臺服務器上。基于容器的方式，一旦單個租戶的函數遭受攻擊，造成容器逃逸，會影響服務器上所有租戶的函數安全。所以，通常Serverless平臺會采用安全容器的方式，引入輕量級虛擬化技術來保證隔離性，但這同時會引入額外的性能（啟動）和資源開銷等問題。因此，Serverless平臺需要兼顧極致性能和安全隔離。

雖然業界涌現的各種Serverless系統在實現上可能有所不同（如本節介紹的多個函數計算平臺），但基本的概念、原理和關鍵技術是相通的，各個系統在實現時都需要應對以上所述的技術挑戰。