前言：在 Serverless 架構下，雖然更多精力是關注業務代碼，但是實際上對一些配置和成本也是需要關注的，并且必要的時候還需要根據配置與成本對 Serverless 應用進行配置和代碼優化。
Serverless 架構帶來的除了一種新的架構、一種新的程式設計範式，還包括思路上的轉變，尤其是開發過程中的一些思路轉變。有人說要把 Serverless 架構看成一種天然的分布式架構，需要用分布式架構的思路去開發 Serverless 應用。誠然，這種說法是正确的。但是在一些情況下，Serverless 還有一些特性，是以要轉變開發觀念。
在傳統 Web 架構中，上傳檔案是非常簡單和便捷的，例如 Python 的 Flask 架構：
但是在 Serverless 架構下，檔案卻不能直接上傳，原因如下：
一般情況下，一些雲平台的API網關觸發器會将二進制檔案轉換成字元串，不便直接擷取和存儲；
一般情況下，API 網關與 FaaS 平台之間傳遞的資料包有大小限制，很多平台限制資料包大小為 6MB 以内；
FaaS 平台大多是無狀态的，即使存儲到目前執行個體中，也會随着執行個體釋放而使檔案丢失。
是以，傳統 Web 架構中常用的上傳檔案方案不太适合在 Serverless 架構中直接使用。在 Serverless 架構中，上傳檔案的方法通常有兩種：一種是轉換為 Base64 格式後上傳，将檔案持久化到對象存儲或者 NAS 中，但 API 網關與 FaaS 平台之間傳遞的資料包有大小限制，是以此方法通常适用于上傳頭像等小檔案的業務場景。
另一種上傳方法是通過對象存儲等平台來上傳，因為用戶端直接通過密鑰等來将檔案直傳到對象存儲是有一定風險的，是以通常是用戶端發起上傳請求，函數計算根據請求内容進行預簽名操作，并将預簽名位址返給用戶端，用戶端再使用指定的方法上傳，上傳完成之後，通過對象存儲觸發器等來對上傳結果進行更新等，如下圖所示。
在 Serverless 架構下檔案上傳檔案示例
以阿裡雲函數計算為例，針對上述兩種常見的上傳方法通過 Bottle 來實作。在函數計算中，先初始化對象存儲相關的對象等：
第一種上傳方法，通過 Base64 上傳之後，将檔案持久化到對象存儲：
第二種上傳方法，擷取預簽名的對象存儲位址，再在用戶端發起上傳請求，直傳到對象存儲：
HTML 部分：
通過 Base64 上傳的用戶端 JavaScript 實作：
用戶端通過預簽名位址，直傳到對象存儲的用戶端 JavaScript 實作：
整體效果如圖中所示。
Serverless 架構下檔案上傳實驗 Web 端效果
此時，我們可以在目前頁面進行不同類型的檔案上傳方案實驗。
應用在執行過程中，可能會涉及檔案的讀寫操作，或者是一些檔案的持久化操作。在傳統的雲主機模式下，可以直接讀寫檔案，或者将檔案在某個目錄下持久化，但是在 Serverless 架構下并不是這樣的。
由于 FaaS 平台是無狀态的，并且用過之後會被銷毀，是以檔案并不能直接持久化在執行個體中，但可以持久化到其他的服務中，例如對象存儲、NAS 等。
同時，在不配置 NAS 的情況下，FaaS 平台通常情況下隻具備 /tmp 目錄可寫權限，是以部分臨時檔案可以緩存在 /tmp 檔案夾下。
（1) 異步
函數計算是請求級别的隔離，是以可以認為這個請求結束了，執行個體就有可能進入一個靜默狀态。而在函數計算中，API 網關觸發器通常是同步調用（以阿裡雲函數計算為例，通常隻在定時觸發器、OSS 事件觸發器、MNS 主題觸發器和 IoT 觸發器等幾種情況下是異步觸發）。
這就意味着當 API 網關将結果返給用戶端的時候，整個函數就會進入靜默狀态，或者被銷毀，而不是繼續執行完異步方法。是以通常情況下像 Tornado 等架構就很難在 Serverless 架構下發揮其異步的作用。當然，如果使用者需要異步能力，可以參考雲廠商所提供的異步方法。
以阿裡雲函數計算為例，阿裡雲函數計算為使用者提供了一種異步調用能力。當函數的異步調用被觸發後，函數計算會将觸發事件放入内部隊列，并傳回請求 ID，而不會傳回具體的調用情況及函數執行狀态。如果使用者希望獲得異步調用的結果，可以通過配置異步調用目标來實作，如圖所示。
函數異步功能原理簡圖
（2) 定時任務
在 Serverless 架構下，應用一旦完成目前請求，就會進入靜默狀态，甚至執行個體會被銷毀，這就導緻一些自帶定時任務的架構沒有辦法正常執行定時任務。函數計算通常是由事件觸發，不會自主定時啟動。例如 Egg 項目中設定了一個定時任務，但是在實際的函數計算中如果沒有通過觸發器觸發該函數，該函數不會被觸發，也不會從内部自動啟動來執行定時任務，此時可以使用定時觸發器，通過定時觸發器觸發指定方法來替代定時任務。
（1） 靜态資源與業務邏輯
在 Serverless 架構下，靜态資源更應該在對象存儲與 CDN 的加持下對外提供服務，否則所有的資源都在函數中。通過函數計算對外暴露，不僅會讓函數的業務邏輯并發度降低，也會造成更多的成本。尤其是将一些已有的程式遷移到 Serverless 架構上，例如 Wordpress 等，更要注意将靜态資源與業務邏輯進行拆分，否則在高并發情況下，性能與成本都将會受到比較嚴峻的考驗。
（2） 業務邏輯的拆分
在衆多雲廠商中，函數的收費标準都是依靠運作時間、配置的記憶體以及産生的流量收費的。如果一個函數的記憶體設定不合理，會導緻成本成倍增加。想要保證記憶體設定合理，更要保證業務邏輯結構的可靠性。
以阿裡雲函數計算為例，一個應用有兩個對外接口，其中有一個接口的記憶體消耗在 128MB 以下，另一個接口的記憶體消耗穩定在 3000MB 左右。這兩個接口平均每天會被觸發 10000 次，并且時間消耗均在 100 毫秒。如果兩個接口寫到一個函數中，那麼這個函數可能需要将記憶體設定在 3072MB，同時使用者請求記憶體消耗較少的接口在冷啟動情況下難以得到較好的性能；如果兩個接口分别寫到函數中，則兩個函數記憶體分别設定成 128MB 以及 3072MB 即可，如表所示。
通過上表可以明确看出合理、适當地拆分業務會在一定程度上節約成本。上面例子的成本節約近 50%。
_關于作者：劉宇（江昱）國防科技大學電子資訊專業在讀博士，阿裡雲 Serverless 産品經理，阿裡雲 Serverless 雲布道師，CIO 學院特聘講師。
本書會通過多個開源項目、多個雲廠商的多款雲産品，以及多種途徑向讀者介紹什麼是 Serverless 架構、如何上手 Serverless 架構、不同領域中 Serverless 架構的應用以及如何從零開發一個 Serverless 應用等。本書可以幫助讀者将 Serverless 架構融入到自己所在的領域，把 Serverless 項目真實落地，獲得 Serverless 架構帶來的技術紅利。