騰訊云：我們究竟如何推出無伺服器雲函數？

4月26日消息，騰訊雲推出國內首款FaaS(Function as a Service，函數即服務) 產品——無伺服器雲函數SCF。那麼，雲函數的真正內涵是什麼、架構原理，關鍵技術和發展趨勢是什麼？騰訊雲基礎產品團隊下文將對上述問題進行解答。

背景：無伺服器雲函數的用戶價值核心信息：第一，用戶只需要上傳代碼即可以最簡捷的方式使用騰訊雲高效穩定的基礎設施；第二，兼具成本低廉的特點，代碼按需運行，空閑時不收費。經測試，按調用次數和運行時間付費，在每個月請求不足百萬時，使用無伺服器雲函數比使用多台雲主機搭建集群的成本減少約70%。

無伺服器雲函數（Serverless Cloud Function）是騰訊雲提供的無伺服器（serverless）執行環境，幫助用戶在沒有購買和管理伺服器時仍能運行代碼。用戶只需要使用雲平台支持的語言編寫核心代碼及設置代碼運行的條件，代碼即可在騰訊雲基礎設施上彈性、安全地運行，並可完全管理底層計算資源，包括伺服器CPU、內存、網路、代碼部署、彈性伸縮、負載均衡等服務。使用無伺服器雲函數將可免除所有運維性操作，企業和開發者可以更加專註於核心業務的開發，實現快速上線和迭代，把握業務發展的節奏。

一、雲函數的價值及使用場景

隨著雲計算服務市場的成熟，用戶對雲計算接受程度逐漸提高，藉助各類基礎雲組件，將業務上線時間從月級縮短到天級，但對比傳統模式，用戶仍需基於雲組件重構非功能性需求；雲函數嘗試將業務演算法和流程提煉出來交由用戶實現，打通各種雲服務，並實現通用的負載均衡、自動伸縮、故障容災、安全監管等通用功能，真正使得用戶像搭積木一樣打造個性化服務，將業務上線時間從天級縮短到分鐘級。

相比雲主機，雲函數更適合於支持微服務架構業務場景。以圖片多規格壓縮服務為例，該服務在用戶上傳圖片至COS時，自動將原始圖片壓縮成適配手機、平板、電腦等多種大小的規格。如利用雲函數實現該服務，用戶只需創建函數，定義函數觸發條件為「圖片上傳」，在線編輯或使用IDE完成代碼編寫後上傳，服務即構建完成。用戶上傳圖片時，自動調用定義的函數完成圖片的多規格壓縮，雲函數平台根據上傳併發量自動擴縮容函數實例，並最終按照實際調用消耗計費。

從該示例可以看出，雲函數為用戶帶來的主要價值為：

加快用戶服務上線時間，用戶只需實現業務演算法及流程，上線時間縮短為分鐘級；

減少用戶的運營負擔，用戶無須承擔服務擴容，故障恢復運維工作；

消除用戶的資源成本，用戶無需承擔資源閑置費用，只為實際調用消耗付費；

二、雲函數架構原理

雲函數平台整體架構原理如圖所示。雲函數為用戶提供SDK/WEBUI兩種使用方式，並通過事件註冊與回調機制與其它雲組件打通，提供標準的API介面；調用分髮根據函數所屬的區域，用戶，名字，版本號，鑒權等信息申請函數實例，並將調用均勻的分發到可用函數實例；函數管理負責創建/修改/刪除函數，並提供函數代碼管理，版本管理等功能；函數調度根據函數資源需求選擇合適的位置創建/銷毀函數實例；函數實例部署用戶定義的函數，負責函數的執行及監管。

從雲函數的定位及架構原理看，衡量雲函數平台的關鍵技術指標可概括為：

不僅支持業務快速上線，且能實現持續發展；

不僅支持業務按需取用，且能釋放閑置資源；

不僅支持業務永不中斷，且能擴展運行範圍；

不僅支持業務自由運行，且能避免干擾入侵；

下文將展開詳述。

三、支持業務快速上線，且能實現持續發展

支持業務分鐘級上線，需要儘可能的減少用戶研發工作量，雲函數用戶僅需提供簡單的函數配置及代碼即可完成上線。以圖片壓縮為例，用戶自行編輯python代碼如下，即可實現一個圖片壓縮服務：

其中第1行引入依賴庫，第4~9行解析輸入參數，第11行調用庫完成圖片壓縮，12~15行判斷結果及返回。用戶可在線完成代碼的編輯並提交，也可像開發本地程序一樣使用喜歡的IDE編輯，調試通過後打成zip包通過SDK提交，提交成功服務即上線。

支持業務可持續發展，需提供用戶函數平滑升級及版本變更能力，當用戶更新函數代碼或配置后，新調用請求被分發至新函數實例，原調用請求執行完成後，舊函數實例自動消亡，服務在客戶不感知情況下平滑更新。即將支持用戶函數多版本管理，將函數別名映射至用戶指定版本，在客戶不感知情況下實現多版本間平滑切換。

函數運行過程中間，用戶列印日誌，標準輸出/錯誤輸出日誌分類上傳至騰訊雲日誌服務平台，用戶可實時監控函數運行情況。

四、支持業務按需取用，且能釋放閑置資源

要支持雲函數真正按需取用，需實現用戶第一次調用時延遲分配資源，函數調用過程如下圖所示：

雲函數平台在調用分發時，會判斷是否有函數實例存在，如若不存在，則實時啟動實例，實例啟動完成後，才開始執行函數調用。為了達到第一次調用足夠快的目標，在調用過程中需分階段逐層優化：

分發調用階段：需減少調用分發層級，比如對於用戶主動發起的http同步調用，正常路徑可免去存入持久化隊列過程；

鏡像及代碼下載階段：需盡量預部署以減少下載時間，比如對新提交函數，并行啟動預載入，使得第一次調用發起時無須再去實時下載；

容器啟動過程：需簡化容器啟動腳本，使得啟動過程盡量輕量，對於對延時敏感的業務，提供實例預留機制，用戶可選擇預留少量實例以減少第一次調用的額外延時；

執行函數調用：需盡量減少函數參數，返回數據及日誌傳遞導致的內存拷貝次數；

返回調用：需盡量減少返回層級；

通過逐層優化，第一次調用平台耗時可控制在3s左右，後續調用平台耗時控制在10ms左右。

隨著客戶請求量的增加或減少，函數實例隨著自動擴縮容，一般演算法如下：

If當前請求數當前實例數擴容閾值：擴容實例

else當前請求數當前實例數縮容閾值：縮容實例

當縮容至最後一個函數實例時，為避免函數實例短時間內重複啟動/停止導致客戶調用延時增加，需保留一段時間延遲釋放。

五、支持業務永不中斷，且能擴展運行範圍

要支持雲函數永不中斷，需實現2個容災目標：

硬體故障時服務不中斷

平台升級時服務不中斷

為實現這三個容災目標，整體架構需實現set化，且在各層均需對應的支持：

接入層：基於騰訊雲CLB實現橫向擴展，負載均衡，7層路由能力；

邏輯層：實現模塊無狀態化，模塊內部無狀態數據，可隨意啟停替換；

數據層：採用一致性存儲倉庫存儲關鍵數據；

節點層：實現快速節點故障檢測及替換恢復；

比如平台內部Invoker模塊實例硬體故障時，如下圖所示，由於invoker模塊無狀態，，故障時可由接入層CLB模塊自動剔除，剔除后新請求分發至剩餘invoker模塊實例，已接收的非同步事件可由其它invoker重試完成，同步http調用會直接返回給用戶錯誤請求，由用戶重試，在故障invoker實例恢復后，自動添加至CLB中，繼續分擔負載。

當平台需要升級API介面時，採用只增不改策略，提供新版本API介面，保持用戶原有服務兼容性，用戶採用新介面時，CLB通過7層路由，路由至新版本invoker模塊實例，舊版本實例隨著負載的降低逐步縮容，新版本實例隨著負載升高逐步擴容，以此實現了用戶透明的版本平滑升級。

要實現雲函數需與各類雲組件打通，需要雲組件提供事件註冊及回調機制，雲組件提供可註冊事件及對應的回調介面，雲函數確保雲組件通信的用戶許可權打通傳遞。當前雲函數實現了與騰訊雲COS存儲組件的打通，馬上將實現與騰訊雲CMQ、雲監控等其它雲產品的打通，並將運行範圍擴展至CDN邊緣節點，實現邊緣計算。

六、支持業務自由運行，且能避免干擾入侵

雲函數需支持用戶本地測試通過的代碼無縫在雲函數平台，需具備足夠的兼容性，及用戶函數運行時環境，需要具備和用戶開發測試環境類似的軟體包，安全等配置；同時避免函數間干擾，防止惡意入侵。

為了避免用戶函數間干擾，雲函數使用了Docker容器來封裝函數實例，通過docker的名字隔離、空間隔離、許可權限制等機制實現用戶間隔離，輔以實時衝突監控調度等措施及時處理干擾。

為了避免用戶執行代碼影響整個雲函數平台，如下圖所示，實現了雲函數管理平台與用戶函數的隔離，用戶函數無法感知管理平台的網路地址，運行日誌等信息，從而無從影響雲函數平台的運行。

為了避免用戶惡意代碼對網路的探測和入侵，如下圖所示，用戶函數實例被限制到了受限的公共VPC網路，需通過網關實現與外網服務、其它函數實例、雲組件的互訪，同時，為了支持用戶函數實例與個人CVM虛擬機的集成，雲函數平台通過彈性網卡打通了與其私有VPC的網路通信。

七、雲函數行業進展趨勢

近年Serverles、微服務等理念逐步深入人心，雲函數開始被用戶了解接受。為了滿足用戶對於更快速上線、更低成本、更優架構的求索，騰訊雲推出了雲函數產品。用戶不妨從解決實際問題開始試用雲函數，比如實現存儲於COS的圖片、視頻、文件的計算，將定時任務從CVM遷移至雲函數，減少資源成本等。隨著雲函數可聯動雲組件的拓展，支持語言的豐富，調試工具，流程引擎等逐步完善，雲函數會逐步成為整個雲平台的粘合劑，將各種雲組件融合一起，到時可支持更為複雜的狀態服務場景，成為用戶通用體貼厚實的後盾。

歡迎試用騰訊雲-雲函數產品，雲函數解決安全接入、故障容災、自動伸縮、成本優化、版本管理等後台通用問題，用戶可更省心專註的投入到業務創新。希望通過雲函數能更深入的開放騰訊多年在海量服務耕耘修鍊的能力，共享給廣大用戶使用，與大家一起成長。