函數計算研究與應用場景分析

1 引言

云計算的核心理念是資源復用和靈活調度，從物理機發展到虛擬機到容器，都是資源粒度不斷細化、管理調度不斷優化的過程，2014年AWS推出Lambda云服務，其提出的函數計算為核心的Serverless架構（無服務器架構）更加體現了這一理念。隨后各個云計算提供商紛紛推出函數計算云服務，例如微軟推出Azure Function，2017年4月，阿里云推出Function Compute，騰訊云推出無服務器云函數。函數計算從2017年開始以大熱姿態占據云計算領域的視野，成為2017年增長最快的云服務[1]。

函數計算是一種云服務運行環境，開發者不再需要預配置與管理后端服務器，只需要聚焦核心業務，為應用編寫一段代碼，將代碼上傳至函數計算云服務中，函數計算服務會根據代碼運行情況自動進行彈性伸縮，靈活擴展，代碼運行結束，函數計算會自動釋放云資源。對用戶而言，無需關心基礎設施層的構建與維護，提高服務部署效率。函數計算按需使用按需付費，大幅降低成本。業界認為，使用函數計算，云的費用可減少10%至90%[2]。有研究報告指出，函數計算的市場規模將從2016年的18.8億美元增長至2021年的77.2億美元，復合年增長率為32.7%[3]。

因此，需要對函數計算業界標桿及工作原理進行研究，并且對函數計算的特點及應用場景進行分析，才能將函數計算運用在最合適的業務與應用中，最大程度地提高云資源使用效率與減少成本費用。

2 業界標桿函數計算分析

2.1 AWS Lambda

AWS Lambda可以為任何類型的應用程序或后端服務運行代碼，開發者無需預配置或管理服務器。AWS Lambda按需執行代碼并自動縮放，如圖1所示。

圖1 AWS Lambda原理示意圖

AWS Lambda的主要由事件源、事件源映射、函數計算三部分組成。事件源指發布事件的云服務或者自定義程序。函數指處理事件的自定義代碼。事件源映射把事件源與函數關聯起來，當事件發生時自動觸發相應函數。事件源可以來自AWS服務或者自定義應用程序，來自AWS服務事件源分為非基于流的事件源與基于流的事件源[4]，如表1所示。

表1 AWS Lambda支持的事件源

AWS Lambda的應用場景主要有數據處理與后端兩大塊。數據處理包括實時文件處理、實時數據流處理與提取、轉換、加載。實時文件處理例如上傳數據到S3，觸發Lambda進行創建圖片處理、視頻處理、文件處理、日志處理以及收集與處理數據；實時數據流處理例如使用Kinesis接收實時數據流，觸發Lambda進行監控應用程序、整理與分析數據、生成指標、處理日志、以及接收處理IoT 數據；提取、轉換、加載例如DynamoDB的數據變化觸發Lambda進行篩選、排序等處理，并把轉換的數據加載至存儲桶。用Lambda構建后端包括IoT后端、移動后端、Web后端與第三方API請求，用以構建個性化、強大的應用程序，而同時開發者不需要再關注可擴展性與冗余備份的工作。

2.2 阿里云函數計算

開發者編寫應用和服務，并上傳至函數計算中，函數觸發運行，按需動態擴容，按量計費，如圖2所示。

圖2 阿里云函數計算原理示意圖

阿里云函數計算由四大主要元素組成：服務、函數、事件以及觸發器。使用函數計算時，首先，在服務內創建函數，服務是函數計算的最小單位，但每個服務有規定最大函數運行數量，當應用比較復雜時，可分解為多個服務，以微服務形式構建。第二，創建函數，把應用部署到函數中。第三，配置觸發器，觸發器統一管理各個事件源。當事件源中有事件發生時，如果滿足觸發器定義的規則時，事件觸發函數運行。事件源可以是對象存儲 OSS，日志服務，API 網關，定時器（Timer）和 HTTP 請求等。在觸發器中可配置事件觸發函數的方式。阿里云函數計算支持兩種觸發器，如表2所示。最后，查看執行日志與服務監控。

表2 阿里云函數計算支持的觸發器

阿里云函數計算的應用場景包括事件請求、流量突發和大數據處理。事件請求場景包括圖片與事件定制、物聯網中的低頻請求、計劃事件觸發。

2.3 Azure Function

Azure Function主要由觸發器、函數計算與綁定（輸入與輸出）三個元素構成，如圖3所示。

圖3 Azure Function原理示意圖

在Azure中，觸發器定義函數運行的觸發方式。輸入與輸出綁定是提供Azure Function連接到其他服務的聲明性方式，可以省去對Azure Function需要使用到的服務詳細信息進行硬編碼，有利于Azure Function與其他服務進行關聯與集成。每個函數有且只有一個觸發器，每個函數可以綁定多個輸入和多個輸出。觸發器是必須具備的，綁定輸入輸出則是可選的。

Azure Function的觸發器與輸入輸出綁定支持如表3所示[5]：

表3 Azure Function支持的觸發器與綁定（輸入與輸出）

注：帶星號的表示試驗性，不受支持，未來可能被棄用。

Azure Function的縮放和托管分為兩種模式，一種是應用服務模式，一種是消耗量模式。在使用Azure Function之前需要選定縮放和托管模式。應用服務模式為傳統云計算的資源管理模式，需預配置處理能力，消耗量模式為無服務架構模式，系統自動縮放自動彈性分配資源。應用服務模式在專用VM上運行，當運行時間超過允許函數執行的最長時間（10分鐘）或預期函數會接近持續運行，采用應用服務模式會更節省成本與提高效率。

Azure Function的應用場景，包括Web應用程序后端，移動應用程序后端，實時文件處理，實時流失處理，計劃任務的自動化，擴展SaaS應用程序等。

2.4 騰訊云無服務器云函數

騰訊云無服務器云函數主要由事件源與函數計算兩個核心組件組成，如圖4所示。

圖4 騰訊云無服務器云函數原理示意圖

騰訊云無服務器云函數也是事件驅動特征，事件源產生事件，去觸發云函數處理事件，而觸發器則是維護事件源與函數的對應與關聯關系。云函數的事件源可以是騰訊云自身的云服務，也可以是用戶自定義程序，如表4所示。

表4 騰訊云無服務器云函數支持的事件源

騰訊云無服務器云函數的應用場景，包括API 服務、文件處理及通知、消息轉存、業務流轉、AI 推理。

3 函數計算原理分析

3.1 工作原理分析

函數計算是一種事件驅動型服務，通過上一章節的業界標桿分析，可以歸納出，函數計算服務的原理抽象出來，一般包含事件源，函數計算以及定義與管理事件源如何觸發函數計算的規則，如圖5所示。

開發者編寫函數代碼上傳至函數計算，以及配置好函數觸發規則。當事件源有事件發生時，便會按照配置好的函數觸發規則自動觸發函數，函數計算會根據業務運行的波峰波谷情況，自動進行彈性伸縮。

圖5 業界標桿函數計算原理示意圖

觸發規則管理根據事件源類型或各個云提供商的規定放在函數計算或放在事件源內。每個云計算提供商的函數計算都有會規定允許觸發函數計算的事件源/觸發器，梳理為如表5所示。

表5 業界標桿函數計算事件源歸納表

從表5可以看出，四家業界標桿函數計算的事件源均支持網絡與內容分發、存儲、數據分析與定時事件，其中3家標桿函數計算均支持的事件源覆蓋IoT、數據庫、消息隊列等集成服務， AWS Lambda與騰訊云無服務器云函數均支持用戶自定義事件源。AWS lambda支持的事件源最多，還支持管理與機器學習事件源。

從上述標桿分析也可看出，4家標桿函數計算的應用場景均涵蓋實時數據處理與后端服務等。

3.2 啟動原理

無服務架構下的函數計算啟動主要與容器啟動策略有關。開發者首先需要把自定義代碼上傳至云存儲里，當事件源發布事件時，代碼包從云存儲中下載到函數計算運行環境中，按需觸發。函數計算啟動流程如圖6所示。

圖6 函數計算啟動示意圖

函數被事件觸發時，函數計算根據開發者的設置啟動容器（即執行環境）。容器的創建和刪除操作直接由函數計算管理，并沒有開放給開發者。函數代碼執行后，函數計算會凍結容器至少數分鐘，預期用于另一次函數調用。如果函數計算服務在再次調用函數時選擇重用容器，則解凍容器供重用，即使用Warm容器，Warm容器中會保持用戶代碼的一些初始化狀態可以直接重用，例如一些數據庫連接等，所以使用Warm容器會獲得更快的代碼運行時間，延遲小，節省成本。但函數計算并非始終重用容器，可能會根據策略或其他因素僅創建新容器而非重用現有容器，即使用Cold容器。

3.3 優勢

傳統的云計算也能進行靈活的彈性伸縮，那么使用函數計算的架構與傳統云計算相比有什么區別和優勢呢？在傳統云計算中，開發者除了需要編寫應用的代碼外，還需要管理云主機、操作系統接入控制及補丁，還需關心CPU數量、內存大小、IP地址等[6]；為應對業務量的波峰波谷變化，還必須提前預配置彈性伸縮負載均衡等策略。而為了節省成本以及資源配置最優化，開發者或運維人員必須在業務運行過程中根據實際情況不斷調整彈性伸縮負載均衡等策略，以避免閑時資源太多。這個過程耗費大量人力成本與時間成本，而資源配置卻未必能時刻達到最優。而使用函數計算后，開發者只需要編寫應用代碼上傳至函數計算，一旦有事件源發布，函數計算便會自動觸發，根據代碼自動按需對底層資源進行彈性伸縮靈活擴展，底層資源的彈性擴展對開發者來說是屏蔽的，縮減了開發者大量運維工作，大幅降低人力成本與時間成本。當函數運行完畢時，所使用的云資源會自動釋放，不存在閑時資源，對開發者而言降低應用擴展成本，對云提供商而言，削峰填谷，提高云資源利用率，可以賣出更多的云資源。

4 函數計算應用場景分析

4.1 適合函數計算的應用特點分析

適合使用函數計算的業務與應用都可以通過函數計算較好地解決成本、效率、聯通問題。這些業務與應用一般具有以下特點，第一，業務具有波峰波谷變化。第二，業務運行具有事件觸發特征。第三，應用需要關聯多種云服務。第四，應用數據更新大，一臺服務器的處理能力已不能滿足，開發者需要考慮如何配置負載均衡來應對處理請求。第五，應用版本迭代速度快，業務開發、部署、升級、擴容要求高[7]。第六，一些低頻的、維護性的后臺任務等。

然而，函數計算的特點使其并不適合所有的應用，第一，若業務波峰波谷不明顯，則使用函數計算并不能大幅節約成本，因為無法體現函數計算自動伸縮按需使用按需付費的優勢。第二，耦合性強的業務不適合使用函數計算。因為函數計算如果使用本地狀態，會有很多嚴格限制，需要假設任何進程間或者主機狀態對子進程都不可見，包括RAM和寫到本地盤上的狀態，從一個部署單元看，函數計算是無狀態的。這一點對應用架構影響很大。第三，一些大型應用程序不容易拆分搬上函數計算架構。因為函數計算一般會限制每個函數允許運行多長時間[7]，如果超出就被強行退出，例如目前AWS Lambda函數允許最多運行5分鐘，Azure Function是10分鐘。某些長時間運行的任務如果轉到函數計算架構，就需要重新設計，需要多創建幾個不同函數協調器。而在傳統架構中，只需有一個就可以。第四，函數計算的冷熱容器啟動策略，會造成應用啟動延遲10 ms到2分鐘[8]，不適合對延時要求比較高的業務[9]，最好進行場景測試。對延時要求比較高的業務，建議采用容器架構比較合適[10]。

4.2 典型應用場景

根據上述應用特點分析，適合函數計算的典型應用場景主要有四大類，第一，事件觸發類場景，例如定制圖片，定制事件，IoT中的低頻請求，音頻轉換文字處理，自動程序消息傳遞，基于定時器處理/定時器任務，日志處理，SaaS事件處理，批量任務。第二，流量突發類場景[11]，例如彈性擴展應對突發流量，轉碼和流量擴容，多媒體（視頻、圖片等）數據備份，圖片上傳、裁剪、分享等。處理大數據類場景，例如數據驅動后續分發，實時文件處理，實時數據流處理，數據庫數據提取、轉換、加載。第四，后端類場景，例如Web應用程序、IoT后端、移動后端、人工觸發。

5 運營商函數計算應用建議

云計算成為基礎設施已是共識，運營商在近幾年的云計算布局中也占了一席之地，而函數計算對云提供商與用戶是一種具有雙贏價值的云服務，因此運營商可考慮將函數計算作為開拓云計算新市場和鞏固舊市場的戰略部署。

在函數計算功能規劃上，可參照業界標桿設計為事件源、函數計算與觸發函數規則三部分組成。函數計算是事件驅動型服務，因此事件源的支持種類也很重要，可選取至少三家業界標桿均支持的事件源作為第一階段實現目標，包括IoT、網絡與內容分發、存儲、數據庫、定時事件；機器學習與自定義事件源等可作為遠期目標。

物聯網設備數量巨大及其所產生的數據量巨大，具有大量的數據收集與分析需求，且很多物聯網設備協議都是事件驅動，并且物聯網在邊緣上的應用通常都是輕量級，適合使用邏輯抽象粒度更小的函數計算進行部署。而運營商在物聯網連接上有天然優勢，可以考慮將物聯網應用場景作為函數計算的試點部署應用場景，可以選擇一些對延時要求不高的低頻的物聯網應用場景，例如智能抄表類、智能監控類、智能廣告、物品跟蹤、建筑損耗、智慧養殖、金融POS、自動售貨機等。

6 結束語

云計算發展的初始階段是基礎設施的云化，當基礎設施云化到一定程度后，用戶便開始尋求使用云計算的更省錢和更高效之道，更聚焦于業務層面的創新。本文對函數計算業界標桿產品、工作原理、適合函數計算的應用特點進行研究，以及對函數計算典型應用場景進行梳理，有利于用戶更好的了解函數計算，在合適的應用場景中匹配函數計算架構，發揮函數計算架構節約成本、提高效率的巨大價值。