國內首個函數計算：按代碼實際運行資源付費

4月26日，在雲棲大會?南京峰會上，阿里雲宣布函數計算（Function Compute）啟動邀測。這是國內首個事件驅動的無伺服器計算平台。用戶按需調用、按需付費，無需管理伺服器等基礎設施，特別適用於應用場景中有明顯波峰波谷的企業。

通過函數計算，用戶無需再管理伺服器等基礎設施，只需編寫代碼並上傳。函數計算會為用戶準備好計算資源，以彈性、可靠的方式運行代碼，並提供日誌查詢，性能監控，報警等功能。

藉助於函數計算，可以快速構建任何類型的應用和服務，無需管理和運維。更棒的是，只需要為代碼實際運行消耗的資源付費 ——代碼未運行則不產生費用。

讓我們以構建一個視頻處理後端服務為例，來體驗以serverless的方式開發應用的高效。

在示例場景中，用戶將生成的高清視頻文件上傳到阿里雲對象存儲（OSS）上，這些視頻文件需要轉碼為不同碼率的文件（360P，720P，……）以適配不同的播放設備。最終結果文件被存儲到OSS上，由用戶消費。

如果以傳統的server-based方式構建系統，用戶需要購買和設置伺服器，編碼實現高性能伺服器軟體。並且要考慮一系列容量預估、容錯、運維監控等方面的問題。

例如：

需要多少台伺服器？什麼規格？

如何配置網路/操作系統？

如何部署升級?

如何處理伺服器宕機？

如何負載均衡？

如何根據負載實時動態伸縮？

如何對系統監控報警？

……

server-based後端服務

如果以serverless的方式構建系統，用戶只需要編寫處理單個請求的視頻轉碼函數，並設置相應的OSS觸發器即可，函數計算系統會保證函數被可靠的執行。大大提高了開發效率。

serverless後端

架構總覽

接下來，讓我們從安全性，可用性和可擴展性的角度來審視函數計算的架構。看看它是如何幫助用戶構建彈性高可用的應用。

整個系統架構如下圖所示。API服務層完成身份驗證，元數據的讀寫等功能。如果是同步函數調用請求，則API Server從資源調度模塊獲取可用的函數執行引擎並發送請求，最後取回結果。如果是非同步調用，則將事件寫入到消息隊列後即返回。由事件分發模塊分發事件，整個流程和同步調用類似。

函數計算架構

安全性和訪問控制

作為一個通用的計算服務，函數計算允許用戶運行任意代碼。因此保證用戶信息安全是函數計算最高優先順序的目標。我們在系統設計中堅持以下兩個原則：

使用最高級別的安全隔離技術，提供與阿里雲ECS同等級的安全隔離性。

訪問用戶的任何資源均需得到用戶的顯式授權。

整個計算環境的隔離分為兩個層面：

執行用戶函數的計算資源和函數計算系統的網路是相互隔離的。

不同用戶的計算資源和網路是相互隔離的。

通過多層次，多維度的安全隔離，確保用戶和函數計算服務本身的信息安全性。

此外，由於用戶的函數被其他用戶或服務調用或者訪問其他資源會涉及到費用和數據安全，因此函數計算要求用戶授權。例如，用戶想使用阿里雲對象存儲服務（OSS）觸發器時，需要授權OSS服務調用相關函數的許可權。通過對觸發器的管理，用戶可以非常方便的了解指定函數可能被哪些事件源服務調用。關於函數計算的授權模型，請參閱相關文檔。

高可用

要保證用戶函數被可靠的執行，函數計算需要處理以下兩類場景：

非預期中斷。例如程序崩潰，機器宕機，網路分割故障（network partition）等等。

預期中斷。例如用戶函數、函數計算系統的升級等等。

非預期中斷的處理能力是任何分布式系統都要具備的基本能力，相關技術已經非常成熟，細節我們不再贅述。函數計算本身和依賴的阿里雲服務都具備高可用的特性。在有條件的區域，函數計算的系統會跨多個可用區部署，提供更高級別的容災能力。

對於預期的中斷，函數計算系統自身和用戶函數都可以做到平滑升級。當升級發生時，正在執行的請求不會被終止，系統會等待請求處理完成，再執行升級操作。未來我們將支持函數的多版本（幫助用戶快速回滾）、灰度發布等功能，進一步減輕用戶的運維負擔。

實時彈性伸縮

實時彈性伸縮是函數計算的核心優勢，當用戶負載出現波峰時，系統能實時擴張資源，平滑應對峰值訪問。以非同步事件處理為例，整個處理流程分為三步：

事件寫入函數計算的事件隊列。

事件分發器從隊列中讀取事件，並調用對應的函數處理事件。

用戶函數處理事件。

函數計算系統會監控用戶的負載變化，各組件均能夠根據用戶負載動態伸縮。如上圖所示，當用戶A的事件產生速率變大時，系統會自動在每個環節給A分配更多的資源，以匹配事件處理的能力。

函數計算採用多級資源調度策略，系統會根據用戶負載和資源池水位預判需求，提前準備好計算資源。依託于飛天分布式平台多年的積累，在調度的實時性和準確性上取得了很好的平衡，具備毫秒級彈性伸縮的能力。

另一方面，實時彈性伸縮也是一柄雙刃劍，函數有可能被錯誤觸發，不但影響服務可用性，也給用戶造成財務損失。以上述視頻轉碼系統為例，每當有新的視頻被上傳到對象服務（OSS）的指定目錄後，函數就會被觸發進行轉碼。但如果用戶不小心把處理後的結果文件也寫入到了源目錄，則形成了一個事件觸發的環，導致函數會以指數級速度被錯誤觸發，且永遠不能終止。因此系統必須要能控制和隔離錯誤函數的影響。

函數計算在用戶粒度設置了函數最大並發調用限制（允許用戶自定義），保證用戶的費用不會超過一個上限。同時，整個系統從不同層次，不同維度對用戶使用的資源進行流控，確保在多租戶的環境中，用戶不會互相影響。此外，提供豐富的監控和報警功能，能夠及時通知用戶處理。

總結

雲的第一階段，是基礎設施的雲化，使得用戶有能力使用大規模的計算能力。雲的下一階段的發展，是要解決用戶使用雲的成本和效率問題，幫助用戶實現業務能力的雲化。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！