【51CTO.com快譯】與在更傳統的PaaS或IaaS環境中運行的應用程序相比，無服務器平臺上的應用程序在性能、存儲及更多方面提出了獨特的要求。

包括AWS、微軟和谷歌在內的各大云供應商都推出了無服務器平臺，讓用戶能夠借助一系列函數(function)，將簡單或者甚至高度復雜的應用程序組合起來。但是要在這種平臺上成功地運行云應用程序，開發團隊就要改進設計流程。

[[231651]]

開發人員在構建無服務器應用程序時，應遵循的幾個關鍵原則包括如下：

• 開發小而獨立的應用程序組件。
• 實施無狀態函數。
• 規劃壽命短的臨時函數。

1. 更小而獨立的組件

本質上，無服務器函數旨在執行單一任務。這要求開發團隊確保函數小巧，并圍繞這些獨立的應用程序組件協調開發流程。

一個好的做法是，基于觸發函數的事件類型，將函數分解成各自的函數庫。基本上，開發者應該一開始就設計每個函數，以響應一個事件。如果同一個事件觸發多個函數，將它們包含在同一個函數庫中。這樣一來，開發人員就比較容易基于觸發函數的事件來識別函數。

每個單獨的函數還應包括配置數據，以確保函數在開發、測試和生產環境中啟動時具有一致性。使用npm和webpack等工具來聲明和隔離每個函數內的依賴項也很重要。

2. 選擇無狀態

開發團隊應考慮將函數實施成無狀態服務，其中函數的狀態存儲在應用程序本身之外。你可以配置函數，以便引用作為配置數據的一部分加以管理，并與存儲庫中的函數一起存儲的數據存儲區和數據庫。

一些無服務器平臺提供了在函數調用之間持續存在的本地存儲。雖然開發人員可能忍不住將此用于更復雜的函數，但該本地存儲并不總是在函數調用之間持續存在;就算持續存在，也可能不一致。

盡量使用支持性服務，將有狀態數據存儲在數據庫、單獨的存儲數據區或緩存中。支持性服務是指函數在網絡上作為正常操作的一部分而使用的任何外部服務，包括緩存服務(比如Memcached)、數據存儲區(比如CouchDB)或數據庫(比如MySQL)。

3. 規劃臨時性

無服務器函數的好處之一是它們可以在幾毫秒內啟動，相比之下，在PaaS、容器和虛擬機上運行的大型應用程序需要幾秒鐘甚至幾分鐘，并可以同樣迅速地停止運行。因而很容易增加大量函數以應對需求，或讓并行運行的函數共同完成計算任務，然后一旦計算完畢，讓它們又停止運行。

實際上，無服務器應用程序本質上具有更強的臨時性。

這意味著，想充分獲得無服務器平臺的好處，開發人員就需要從函數的核心邏輯中刪除通常與應用程序綁定的許多組件。開發人員應該：

• 預熱函數所需的數據源;
• 搭建外部記錄和跟蹤基礎架構;以及
• 管理安全。

預熱

為了預熱函數，你需要在部署之前搭建函數與數據庫進行聯系所需的基礎架構。

為此，將函數處理程序與核心邏輯分開來。就像在寒冷天氣讓汽車空轉以改善其性能，閑置事件處理程序可確保：一旦該函數調用，就能以最佳性能運行。AWS CloudFormation和Azure Event Hubs之類的工具支持預熱過程。

外部記錄和跟蹤

函數需要能夠快速優雅地關閉。雖然無服務器平臺包含一些內置的本地存儲，但配置外部日志記錄和跟蹤服務(這種服務內置于無服務器框架本身)，或者設置自定義工具，以便函數運行時，收集和存儲來自函數的日志數據，這很重要。

AWS X-Ray和Azure Application Insights之類的工具有助于日志記錄和跟蹤。

安全

無服務器應用程序給黑客帶來了另一條潛在的攻擊途徑。如果未落實適當的安全措施，黑客很可能會啟用函數，訪問敏感數據。開發人員應為各類函數做好安全設置，以便對執行某項任務所需要的其他應用程序只能進行最低限度的訪問。

原文標題：Three ways to prepare applications for serverless platforms，作者：George Lawton

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】