主題

• 函數(shù)代碼

• 函數(shù)配置

• 指標和警報

• 處理流

• 安全最佳實踐

有關 Lambda 應用程序最佳實踐的更多信息，請參閱 Serverless Land 中的?Application design。

函數(shù)代碼

• 從核心邏輯中分離 Lambda 處理程序。這樣您可以創(chuàng)建更容易進行單元測試的函數(shù)。在 Node.js 中可能如下所示：

  exports.myHandler = function(event, context, callback) {	var foo = event.foo;	var bar = event.bar;	var result = MyLambdaFunction (foo, bar);
  
  	callback(null, result);
  }function MyLambdaFunction (foo, bar) {	// MyLambdaFunction logic here}
  

• 利用執(zhí)行環(huán)境重用來提高函數(shù)性能。連接軟件開發(fā)工具包 (SDK) 客戶端和函數(shù)處理程序之外的數(shù)據(jù)庫，并在?/tmp?目錄中本地緩存靜態(tài)資產(chǎn)。由函數(shù)的同一實例處理的后續(xù)調(diào)用可重用這些資源。這樣就可以通過縮短函數(shù)運行時間來節(jié)省成本。

  為了避免調(diào)用之間潛在的數(shù)據(jù)泄露，請不要使用執(zhí)行環(huán)境來存儲用戶數(shù)據(jù)、事件或其他具有安全影響的信息。如果您的函數(shù)依賴于無法存儲在處理程序的內(nèi)存中的可變狀態(tài)，請考慮為每個用戶創(chuàng)建單獨的函數(shù)或單獨的函數(shù)版本。

• 使用 keep-alive 指令來維護持久連接。Lambda 會隨著時間的推移清除空閑連接。在調(diào)用函數(shù)時嘗試重用空閑連接會導致連接錯誤。要維護您的持久連接，請使用與運行時關聯(lián)的 keep-alive 指令。有關示例，請參閱在 Node.js 中通過 Keep-Alive 重用連接。

• 使用環(huán)境變量將操作參數(shù)傳遞給函數(shù)。例如，您在寫入 Amazon S3 存儲桶時，不應對要寫入的存儲桶名稱進行硬編碼，而應將存儲桶名稱配置為環(huán)境變量。

• 控制函數(shù)部署程序包中的依賴關系。AWS Lambda 執(zhí)行環(huán)境中包括若干庫，例如適用于 Node.js 和 Python 運行時的 AWS 軟件開發(fā)工具包（完整列表位于此處：Lambda 運行時）。Lambda 會定期更新這些庫，以支持最新的功能組合和安全更新。這些更新可能會使 Lambda 函數(shù)的行為發(fā)生細微變化。要完全控制您的函數(shù)所用的依賴項，請使用部署程序包來打包所有依賴項。

• 將部署程序包大小精簡為只包含運行時必要的部分。這樣會減少調(diào)用前下載和解壓縮部署程序包所需的時間。對于用 Java 或 .NET Core 編寫的函數(shù)，請不要將整個 AWS 軟件開發(fā)工具包庫作為部署程序包的一部分上傳，而是要根據(jù)所需的模塊有選擇地挑選軟件開發(fā)工具包中的組件（例如 DynamoDB、Simple Storage Service (Amazon S3) 軟件開發(fā)工具包模塊和?Lambda 核心庫）。

• 將依賴關系?.jar?文件置于單獨的 /lib 目錄中，可減少 Lambda 解壓縮部署程序包（用 Java 編寫）所需的時間。這樣比將函數(shù)的所有代碼置于具有大量?.class?文件的同一 jar 中要快。有關說明，請參閱使用 .zip 或 JAR 文件歸檔部署 Java Lambda 函數(shù)：

• 將依賴關系的復雜性降至最低。首選在執(zhí)行環(huán)境啟動時可以快速加載的更簡單的框架。例如，首選更簡單的 Java 依賴關系注入 (IoC) 框架，如?Dagger?或?Guice，而不是更復雜的?Spring Framework。

• 避免在 Lambda 函數(shù)中使用遞歸代碼，因為如果使用遞歸代碼，函數(shù)便會自動調(diào)用自身，直到滿足某些任意條件為止。這可能會導致意想不到的函數(shù)調(diào)用量和升級成本。如果您不慎執(zhí)行此操作，請立即將函數(shù)保留并發(fā)設置為?0?來限制對函數(shù)的所有調(diào)用，同時更新代碼。

• Lambda 函數(shù)代碼中不要使用非正式的非公有 API。對于 AWS Lambda 托管式運行時，Lambda 會定期為 Lambda 的內(nèi)部 API 應用安全性和功能更新。這些內(nèi)部 API 更新可能不能向后兼容，會導致意外后果，例如，假設您的函數(shù)依賴于這些非公有 API，則調(diào)用會失敗。請參閱?API 參考以查看公開發(fā)布的 API 列表。

• 編寫冪等代碼。為您的函數(shù)編寫冪等代碼可確保以相同的方式處理重復事件。您的代碼應該正確驗證事件并優(yōu)雅地處理重復事件。有關更多信息，請參閱如何使我的 Lambda 函數(shù)具有冪等性？。

函數(shù)配置

• 對您的 Lambda 函數(shù)進行性能測試是確保選擇最佳內(nèi)存大小配置的關鍵環(huán)節(jié)。增加內(nèi)存大小會觸發(fā)函數(shù)可用 CPU 的同等水平的增加。函數(shù)的內(nèi)存使用率是根據(jù)調(diào)用情況確定的，可以在?Amazon CloudWatch?中查看。每次調(diào)用都將生成一個?REPORT:?條目，如下所示：

  REPORT RequestId: 3604209a-e9a3-11e6-939a-754dd98c7be3	Duration: 12.34 ms	Billed Duration: 100 ms Memory Size: 128 MB	Max Memory Used: 18 MB
  

  分析?Max Memory Used:?字段能夠確定函數(shù)是否需要更多內(nèi)存，或函數(shù)的內(nèi)存大小是否過度配置。

  要為您的函數(shù)查找適合的內(nèi)存配置，我們建議使用開源 AWS Lambda 功率調(diào)諧項目。有關更多信息，請參閱 GitHub 上的?AWS Lambda 功率調(diào)諧。

  為了優(yōu)化函數(shù)性能，我們還建議部署可以利用高級矢量擴展 2 (AVX2)?的庫。這樣一來，您就可以處理艱巨的工作負載，如機器學習推理、媒體處理、高性能計算（HPC）、科學模擬和財務建模。有關更多信息，請參閱使用 AVX2 創(chuàng)建更快的 AWS Lambda 函數(shù)。

• 對您的 Lambda 函數(shù)進行加載測試，確定最佳超時值。分析函數(shù)的運行時間很重要，這樣更容易確定依賴關系服務是否有問題，這些問題可能導致并發(fā)函數(shù)以超出您的預期的速度增加。如果您的 Lambda 函數(shù)進行網(wǎng)絡調(diào)用的資源無法處理 Lambda 擴縮，這就更加重要。

• 設置 IAM policy 時使用最嚴格的權限。了解您的 Lambda 函數(shù)所需的資源和操作，并限制這些權限的執(zhí)行角色。有關更多信息，請參閱Lambda 資源訪問權限：

• 熟悉Lambda 配額。在確定運行時資源限制時，負載大小、文件描述符和 /tmp 空間通常會被忽略。

• 刪除不再使用的 Lambda 函數(shù)。這樣，未使用的函數(shù)就不會不必要地占用有限的部署程序包空間。

• 如果您使用 Amazon Simple Queue Service 作為事件源，請確保該函數(shù)的預計調(diào)用時間值不超過隊列上的可見性超時值。這同樣適用于?CreateFunction?和?UpdateFunctionConfiguration。

  • 對于?CreateFunction，AWS Lambda 會使函數(shù)創(chuàng)建流程失敗。

  • 對于?UpdateFunctionConfiguration，它可能會導致該函數(shù)的重復調(diào)用。

指標和警報

• 使用?使用 Lambda 函數(shù)指標?和?CloudWatch Alarms，而不是在您的 Lambda 函數(shù)代碼中創(chuàng)建和更新指標。追蹤 Lambda 函數(shù)的運行狀況是更加有效的方式，這樣您就可以在早期開發(fā)過程中發(fā)現(xiàn)問題。例如，您可以根據(jù) Lambda 函數(shù)調(diào)用的預計持續(xù)時間配置警報，以解決函數(shù)代碼引起的瓶頸或延遲。

• 利用您的日志記錄庫和?AWS Lambda 指標和維度捕捉應用程序錯誤（例如，ERR、ERROR、WARNING 等）

• 使用?AWS Cost Anomaly Detection?來檢測您賬戶中的異?；顒?。Cost Anomaly Detection 使用機器學習技術來持續(xù)監(jiān)控您的成本和使用情況，并盡力減少誤報。Cost Anomaly Detection 使用來自 AWS Cost Explorer 的數(shù)據(jù)，該數(shù)據(jù)最長可能會延遲 24 小時。因此，發(fā)生使用后最長可能需要 24 小時才會檢測到異常。要開始使用 Cost Anomaly Detection，您必須首先注冊 Cost Explorer。然后訪問 Cost Anomaly Detection。

處理流

• 測試不同批處理和記錄的大小，這樣每個事件源的輪詢頻率都會根據(jù)函數(shù)完成任務的速度進行調(diào)整。CreateEventSourceMapping?BatchSize 參數(shù)控制每次調(diào)用可向您的函數(shù)發(fā)送記錄的最大數(shù)量。批處理大小如果較大，通?？梢愿行У匚沾罅坑涗浀恼{(diào)用開銷，從而增加吞吐量。

  默認情況下，Lambda 會在記錄可用時盡快調(diào)用您的函數(shù)。如果 Lambda 從事件源中讀取的批處理只有一條記錄，則 Lambda 將會只向該函數(shù)發(fā)送一條記錄。為避免在記錄數(shù)量較少的情況下調(diào)用該函數(shù)，您可以配置?batching window（批處理時段），讓事件源緩沖最多五分鐘的記錄。調(diào)用函數(shù)前，Lambda 會持續(xù)從事件源中讀取記錄，直到收集完整批處理、批處理時段到期或批處理達到 6MB 的有效負載時為止。有關更多信息，請參閱批處理行為：

• 通過增加分區(qū)提高 Kinesis 流處理吞吐量。一個 Kinesis 流由一個或多個分區(qū)組成。Lambda 輪詢每個分區(qū)時最多會使用一個并發(fā)調(diào)用。例如，如果您的流有 100 個活躍分區(qū)，則最多可以并發(fā)運行 100 個 Lambda 函數(shù)調(diào)用。增加分區(qū)數(shù)量會直接增加 Lambda 函數(shù)并發(fā)調(diào)用的最大數(shù)量，還可增加 Kinesis 流處理的吞吐量。如果您增加 Kinesis 流中的分區(qū)數(shù)量，請確保您已為數(shù)據(jù)選擇了合適的分區(qū)鍵（請參閱分區(qū)鍵），這樣相關記錄將會位于同一分區(qū)中，而且也可合理分配您的數(shù)據(jù)。

• 在 IteratorAge 上使用?Amazon CloudWatch，確定是否正在處理您的 Kinesis 流。例如，將 CloudWatch 警報的最大值設置配置為 30000（30 秒）。

安全最佳實踐

• 監(jiān)控 AWS Lambda 的使用情況，因為它與使用 AWS Security Hub 的安全最佳實踐有關。Security Hub 使用安全控件來評估資源配置和安全標準，以幫助您遵守各種合規(guī)框架。有關使用 Security Hub 評估 Lambda 資源的更多信息，請參閱《AWS Security Hub 用戶指南》中的?AWS Lambda 控件。文章來源地址http://www.zghlxwxcb.cn/news/detail-734173.html

到了這里，關于使用AWS Lambda函數(shù)的最佳實踐！的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！