開發函數計算的正確姿式——輕鬆解決大依賴部署

時間 2021-02-14

標籤 php html java node python git github 服務器 php7 架構欄目設計模式简体版

原文原文鏈接

前言

首先介紹下在本文出現的幾個比較重要的概念：php

函數計算（Function Compute）: 函數計算是一個事件驅動的服務，經過函數計算，用戶無需管理服務器等運行狀況，只需編寫代碼並上傳。函數計算準備計算資源，並以彈性伸縮的方式運行用戶代碼，而用戶只需根據實際代碼運行所消耗的資源進行付費。函數計算更多信息參考。
Fun: Fun 是一個用於支持 Serverless 應用部署的工具，能幫助您便捷地管理函數計算、API 網關、日誌服務等資源。它經過一個資源配置文件（template.yml），協助您進行開發、構建、部署操做。Fun 的更多文檔參考。
NAS: 阿里雲文件存儲NAS是一個可共享訪問，彈性擴展，高可靠，高性能的分佈式文件系統。在函數計算的場景中，因爲其有代碼包的限制，可使用 NAS 存放一些不常常變更的文件，好比數據模型、靜態資源等。參考。
ROS: 阿里雲資源編排服務（ROS）助您簡化雲計算資源的管理。您能夠遵循ROS定義的模板規範，在模板中定義所需雲計算資源的集合及資源間依賴關係。ROS自動完成全部資源的建立和配置，實現自動化部署和運維。更多文檔參考。

備註: 本文介紹的技巧須要 Fun 版本大於等於 3.4.0。html

基本上全部的 faas 平臺爲了優化函數的冷啓動，都會加入代碼包的限制。阿里雲函數計算（FC）也不例外。FC 要求壓縮後的代碼包大小不超過 50MB。因爲用戶的函數代碼可能須要大量的依賴庫，因此代碼包很容易達到函數計算設定的閾值。java

傳統解決方式

基於平臺硬性要求下，依然有不少途徑來解決函數計算上傳代碼包大小受限的問題。下面列舉 3 種常見的解決方案。備註: 包括不侷限於如下方案。node

1. 提交工單

提交函數計算工單，由後臺人員爲您帳號開通上傳限制白名單。但提交工單依然有代碼包的限制。部署時代碼包上傳時間長，而且也增長了函數的冷啓動時間，影響函數性能。PS：經過使用預留模式能夠徹底去除冷啓動，因爲超出本文範圍，這裏再也不闡述。python

2. 利用 OSS 來實現

對代碼包進行分類，除項目代碼和少許依賴庫能夠在建立函數時上傳到函數計算，用戶將部分依賴庫預先上傳到 OSS，並在函數被觸發執行時開始從 OSS 上加載依賴，這類依賴的加載操做都可定義應用層冷啓動，當加載依賴結束後，應用層冷啓動才結束，函數的處理邏輯纔開始執行，應用層冷啓動的開銷每每會致使毛刺的產生，影響函數的性能。您能夠將從 OSS 加載代碼包的代碼邏輯放在 initializer 函數中。既能夠解決函數計算對上傳代碼包的限制問題，又不影響函數的性能。但須要用戶進行額外的操做。參考使用 initializer 接口解決函數計算上傳代碼包大小受限問題。git

3. 基於文件系統 Nas

咱們經過 NAS 存放一些體積比較大且不易變更的資源。這使得即便在依賴比較大的場景下依舊適用。NAS 在幫助函數計算解決大依賴問題的同時，因爲其自身的配置也比較複雜，也增長了函數計算的使用難度。如何管理 Nas 資源、上傳本地資源到Nas 以及服務級別的 Nas 相關配置參考開發函數計算的正確姿式 —— 使用 Fun NAS 管理 NAS 資源。github

本文旨在介紹第四種方式 -- 使用 Fun 工具來解決函數計算對上傳代碼包的限制，使得部署步驟簡單明瞭，不需關心額外的配置。同時也展示 Fun 工具對大依賴場景的順滑體驗，Let's go!服務器

注：已經得到 fc 支持的 runtime 有 nodejs6，nodejs8，nodejs10，python2.7，python3，java8，php7.2，dotnetcore2.1，custom。目前基於全部 fc 支持的 runtime，大依賴場景下除 php7.2 和 dotnetcore2.1 其餘都支持。php7

環境準備

Fun 安裝教程能夠直接在這裏下載二進制版本的 Fun，解壓後便可使用。
執行fun --version檢查 Fun 是否安裝成功。架構

$ fun --version
3.4.0

Fun 斷定大依賴的標準是什麼？

fun install是 fun 工具的一個子命令，用於安裝 pip，apt 依賴等，提供了命令行接口和 Funfile 描述文件兩種形式。對於 fun install 安裝的依賴，當 fun deploy 部署時會自動處理大依賴。

當 Fun 檢測打包的代碼壓縮後超過限制（50M），會根據對應的 runtime 分離大依賴和代碼。Fun 會將大依賴目錄分爲：系統依賴和語言依賴。系統依賴的本地路徑爲.fun/root，語言依賴根據函數 runtime 獲得，各個 runtime 對應的大依賴目錄映射以下：

語言（runtime）

大依賴目錄（directory）

nodejs6

node_modules

nodejs8

node_modules

nodejs10

node_modules

python2.7

.fun/python

python3

.fun/python

java8

.fun/build/artifacts

custom

自定義執行環境custom 大依賴目錄爲/，能夠理解爲其餘 runtime 大依賴目錄的合集。例如：函數 runtime 爲 custom，若目錄下存在node_modules或.fun/python等，Fun 在部署嚮導過程當中會把它們都認定爲大依賴，會分別對其處理。

Fun deploy 對大依賴的支持

函數計算的命令行工具Fun如今原生支持了這種大依賴部署，不須要任何額外操做。僅僅執行fun deploy：

$ fun deploy

總體流程以下圖所示：

fun deploy會自動完成依賴的部署。而當檢測到打包的函數目錄超過了平臺的限制時，會進入到配置嚮導，幫助用戶自動化地配置。即上圖能夠理解爲：Fun 經過內置 NAS（阿里雲文件存儲）解決方案，能夠一鍵幫用戶建立、配置 NAS，並上傳依賴到 NAS 上。而函數計算在運行時，能夠自動從 NAS 讀取到函數依賴。

大依賴嚮導

大依賴嚮導部分截圖以下：

Fun 部署當前函數時，檢測到壓縮後（.zip）依賴超過了 50M，提示配置嚮導（後續日誌省略...）。只須要輸入回車或 yes 便可。最後 Fun 會自動完成配置，成功部署資源到函數計算。

體驗升級

fun deploy大依賴嚮導完成後，函數會部署到函數計算並對外提供服務。此時大依賴和代碼經過 NAS 進行了分離，再次部署時打包本地代碼目錄時因爲沒有了大依賴，因此部署速度會很是的快。

這裏推薦一篇使用fun deploy進行大依賴部署的實戰案例，展現了 Fun 工具對大依賴場景的順滑體驗Serverless 實戰 —— 快速開發一個分佈式 Puppeteer 網頁截圖服務。

Fun package 對大依賴的支持

Fun Package 是用來將代碼、編譯產物、靜態資源等本地資源上傳到 OSS 的功能。使用fun Package的場景，一般是，想僅僅經過一個模板文件進行部署的場景。好比，本地開發完成後，能夠經過fun package，將模板依賴的本地資源上傳到 OSS，這樣，不管是在其餘服務器上部署，仍是使用 ROS 部署時，僅僅經過一個文本格式的模板文件，就能夠完成了。推薦閱讀 Fun Package 功能介紹。

非大依賴場景

流程以下圖所示：

經過 Fun Package 能夠將模板文件包含的本地資源一鍵上傳到 OSS 上，完成資源的打包操做。

模版文件差別

將打包後的模板文件（template.packaged.yml）與原文件相比較，能夠發現，差別僅僅在使用了本地資源的場景，好比：

- CodeUri: './'
+ CodeUri: 'oss://bucket/PackageDemo/function/39ce6e9109a23d313bc267b1a5211273'

大依賴場景

流程以下圖所示：

當遇到打包的函數體積過大時，一樣會進入大依賴嚮導，Fun 內置 Ros 的解決方案，幫你完成自動配置。同時 Fun 會分開大依賴和代碼並分別上傳到 OSS。這樣作的目的下文中會有提到。

模版文件差別

大依賴場景下打包完成後生成的 template.packaged.yml 模版文件會與非大依賴場景下有所不一樣，除上述 CodeUri 的差別外，還會新增許多資源描述做爲使用 Ros 部署時的前置條件，例如 NasCpFunc , 這裏只介紹一種，其它不作贅述。

NasCpFunc:
  Type: 'Aliyun::Serverless::Function'
  Properties:
    Handler: index.cpFromOssToNasHandler
    Runtime: nodejs8
    CodeUri: 'oss://ellison-hongkong/9e610f5540e21ace83d5b742241da6aa'
    MemorySize: 3072
    Timeout: 300

NasCpFunc 爲大依賴場景下 Fun 爲用戶內置的資源函數，能夠將它理解爲一個輔助函數。當用 Ros 方式部署時，將自動執行輔助函數。它用於實現從 OSS 上下載大依賴（.zip）以及解壓到 Nas 的功能。這也就是爲何上述 fun pakckage 打包時，要將大依賴和代碼分離開並分別上傳到 OSS 的緣由。

Fun Packge + Ros 部署實戰

Serverless 實戰——使用 Rendertron 搭建 Headless Chrome 渲染解決方案使用 Rendertron +函數計算快速搭建一個能夠直接用於生產的 Headless Chrome 渲染解決方案，以便於幫助網站更好的進行 SEO。基於文章，咱們將升級文章中一鍵部署的體驗。您能夠參照上述文章中步驟，其中依賴安裝，項目編譯等均無需額外操做。

Rendertron 項目代碼依賴過大，基於 Fun 工具對大依賴項目的支持，現將其原 Fun deploy 部署改造爲 Fun Packge + Ros 部署方式。Fun package 自動處理大依賴上傳到 OSS，Ros 部署將大依賴從 OSS 解壓到 Nas，同時模版中描述的資源自動建立成功。基於函數計算，項目的服務架構以下：

1. Fun pakcage

按照 RenderTron 文章中步驟操做，在一鍵部署前，執行 fun package 命令：

fun package --oss-bucket aliyun-ellison

這裏的--oss-bucket名稱爲本身所擁有讀寫權限的 OSS 的 Bucket 名稱。完整日誌以下：

2. Ros 部署

ROS 經過 Transform 宏實現了將函數計算的模板語法轉換爲 ROS 支持的語法。這意味着對於 Fun 規範文檔裏描述的語法規則，ROS 是一樣支持的。同時，ROS 支持的資源也能在 Fun 模板文件中進行聲明瞭，好比 RAM、函數工做流等等。

在體驗上，因爲 ROS 部署，要求資源必須「雲化」。也就是沒辦法直接使用本地的代碼資源。必須先經過 fun package 命令將資源上傳到 oss。

可見這一步咱們已經完成，不論是大依賴場景仍是非大依賴場景，fun package 打包完成後，後續的部署操做，只須要徹底基於這個打包後的模板文件（template.packaged.yml）便可。再也不依賴本地的代碼等資源，能夠簡化部署的難度。

最後將資源經過 ROS 的方式進行部署，推薦閱讀開發函數計算的正確姿式 —— 使用 ROS 進行資源編排。

fun deploy --use-ros --stack-name bucket-name

--stack-name表示要部署的環境，能夠基於該名稱的不一樣，創建多套開發環境，好比 test、staging、prod。

3. 驗證

可經過上述 RenderTron 文章中提到的方式驗證，這裏不作贅述。

常見問題梳理 FAQ

1. 大依賴被一個服務下的兩個函數同時引用，Fun 是怎麼處理的呢？

Fun 支持大依賴的場景是函數級別的，即當打包某一函數時發現超過限制纔會進入嚮導。當兩個函數處於相同 runtime 和 codeUri，Fun 會在結束第一次嚮導時，同時自動配置第二個函數，確保部署後，兩個函數都部署成功且可用。

2. 大依賴自動配置後，若是我本地添加了新的依賴，部署時會自動將依賴更新到 Nas 嗎？

不會。若是添加了新的依賴，好比 node_modules 目錄添加了新的依賴庫，須要在 template.yml 模版文件所在目錄執行 fun nas sync，將本地 nas 資源同步到 nas 服務。若是修改了代碼，只須要使用 fun deploy 從新部署便可。因爲大依賴和代碼經過 NAS 進行了分離，依賴一般不須要頻繁變化，因此調用的頻率比較低，而 fun deploy 的因爲沒有了大依賴，部署速度也會很是的快。

3. 爲何 java8 環境 Fun 支持大依賴的目錄是 .fun/build/artifacts？

在不少場景，編譯型語言從源碼距離交付物實際上是有必定的距離，好比 java，寫完 java 代碼後，還要考慮如何編譯、打包的問題。Fun build 的職責就是完成從源碼到交付產物的構建過程，推薦閱讀《開發函數計算的正確姿式 —— 使用 Fun Build 構建函數》。
Fun build 會將編譯打包後的交付產物 copy 到 .fun/build/artifacts 目錄，在部署時檢測到代碼大小超過限制，天然會去 .fun/build/artifacts下查找對應serviceName/functionName目錄，並將全部的 jar 包上傳到 Nas。因此 Fun 大依賴部署支持 java8 是以 Fun build 的場景爲基礎。將來 Fun 會集成更多的解決方案，敬請期待！