[Build 2016] Azure Function: 事件驅動式的雲端應用

Azure Function 是微軟在 Build 2016 時宣佈的新服務,它和之前 Amazon 的 AWS Lambda 以及 Google 的 Cloud Function 一樣,都是 Serverless 型的運算應用,適合作為以事件驅動方式觸發的小程式,而且開發人員不需要在乎它被執行的環境的細節,只需要寫好程式丟上去就行了。

要把一個雲端應用丟上雲端環境,除了開發程式之外,最令人覺得麻煩的還是系統的組態,即使是最簡單的 Azure Web App,它還是有某種程度的組態工作,對於不懂系統管理的開發者而言,要叫他去搞定系統組態的工作可能會要了他的命,因此是否有一個不需要做任何系統組態工作的雲端環境,只要丟程式碼上去就能跑了? 是的,Amazon 率先提出了解決方案,稱為 AWS Lambda,它做到了只要丟程式碼上去就能完成應用程式部署工作的目標,後來 Google 也推出了 Cloud Function 來支援這種需求。而 Azure 終於在晚了數個月之後的 Build 2016 宣布了 Azure Functions 服務。

Azure Functions 是一個以事件驅動 (Event-Driven) 為基礎的無伺服器服務 (Serverless Service),所謂的無伺服器服務是指開發人員不需要在乎伺服器的任何細節,就能部署自己的應用程式,而這裡所指的伺服器細節,是連應用程式的組態都不太需要 (當然也會有例外),只要寫好你的程式碼就能直接在雲端上執行,至於伺服器和執行環境的調配,就由 Azure 去傷腦筋就夠了。Azure Functions 是 Azure App Services 的成員之一,就目前看到的 Public Preview,它是執行在 App Service 之上,類似於 API App 的服務,不過它的本質又是源自於 Azure Web App 早已存在的 WebJobs,WebJobs 本身就是一個能單獨執行程式的環境,而且能支援 C#, node.js, Python, batch, PowerShell 與 bash 等指令或程式,Azure Functions 目前繼承了這樣的能力,所以它目前可用的語言基本上都是 WebJobs 上能用的,不過 Azure Functions 會為它配置一個 API 入口,所以你可以把 Azure Functions 視為 WebJobs + API App 的合體產物。

Azure Functions 已經能在 Azure Ibiza Portal 上看到了:

在新增 Function 的功能時,有一個點和以前不太一樣,Functions 有分為傳統模式 (Classic) 以及動態 (Dynamic) 模式,傳統模式表示使用 App Service Plan,動態模式表示由 Azure 自行調配執行環境所需的資源,開發人員只需要決定要用多少記憶體即可。可用範圍為 128MB-1536MB,且可以後續再調,一開始只要用 128MB 就夠了。

新增完成時會進入歡迎頁面,而且一開始就給你三個範本,分別是 Timer (週期型)、Data Processing (處理資料型) 以及 Web Hook + API 型,你可以由這個入口建立一個 Function 來玩一玩。

不過我選擇左邊的 New Function,這時可以看到其他的範本。

你可以選擇 Language: C# (當然也有其他的語言,前面有提及了),Scenario 選擇 Core,然後往下拉,找到 HttpTrigger-C#,選擇它,然後命名它或接受預設命名 (我是接受預設命名 HttpTriggerCSharp1),然後按 Create。

當 Function 建立完成時,會將你帶到 Function 的編輯器,這可以直接線上編輯 (不過先不用奢望它會有 Code Completion / Intellisense),不過即使不編輯,它本身也已經是個可執行的 Function 了,而它的角色是一個 Web API,上方可以看到這支 Function 的 URL。

把視窗往下拉,你會看到 Logs 和 Run 的區塊,Logs 是 Azure Web App 就開始有的 Log Streaming 功能,它會在 Function 被觸發時寫入記錄,開發人員也可以在程式中使用 TraceWriter 來寫入記錄;Run 是可以測試 Function 用的,你可以按一下 Run 按鈕,會得到 "Hello Azure" 的結果,而這是這支 Azure Function 的預設功能。

這個 Function 因為有 URL,所以當然也可以被外部叫用,不過你應該會注意到這個 Function 的 URL 有 code 參數,Azure Function 會驗證這個值來授權,開發人員也可以決定要用何種授權方式 (Azure AD, FB, Google, Twitter 等 Azure Web App 原先就支援的驗證方式)。因此在使用時,要帶著這個 code,我們以 Google REST Client 為例來叫用,你會發現會得到相同的結果 (若沒有帶code參數,你會得到 HTTP 401,若沒有把 ContentType 設為 application/json,你會得到 HTTP 500)。

試驗完後,把畫面拉回上方,你會看到三個頁籤,Develop、Integrate 與 Monitor,Develop 就是寫程式的地方;Integrate 是整合流程的地方;Monitor 是監控 Function 存取的地方,不過 Monitor 目前暫時無作用,因此你可以看看 Integrate,以這個範例而言,它會接受來自 HTTP 的要求,因此 Trigger 上有一個 req (HTTP) 的參數,對應到的是 Code 的 req 參數,Output 則是 res (HTTP),表示 HTTP 的輸出資料流,這個部份會因為應用程式的不同而有所差異,而且 Azure Functions 想做的是輕量又單純, 因此它原則上只會有一個 Function,這個 Function 要完成特定的工作,這點和之前寫 Cloud Application 時要做整個專案是有明顯差異的。

如果要對 Function 做更多設定,可以選擇 "Function app settings",這裡的設定會影響到在這個 Function App 裡面所有的 Function,包含授權、CORS、API Metadata、CI (部署時使用),或是你可以更進一步去設定 Function App 的整體環境,這時會打開原始的 App Services 應用程式的組態畫面。

OK,本篇文章帶你先 Overview 一下 Azure Functions 這個新服務,我們後面會有機會再繼續探討如何使用這個服務。

PS: Azure Functions 的收費模式是以執行次數 (被呼叫的次數) 計算,每 100 萬次一個收費單位。在公開預覽階段,執行前 100 萬次的 Function 是免費的,使用 Dynamic Hosting (本例就是) 的話可免費到 2016/4/22,之後費用細節會在官方網站更新。

Reference: https://azure.microsoft.com/en-us/documentation/services/functions/